locked
ADFS in Azure fails when Site-to-Site VPN fails RRS feed

  • Question

  • We have ADFS 3.0 setup on several VMs in Azure with a Site-to-Site VPN between them and the local Network.

    All works fine until the VPN goes down and although external users can access the ADFS logon screen (via the ADFS Proxy in Azure) they are unable to authenticate, even though there are two Domain Controllers in Azure.

    We can't understand why the DC's in Azure won't authenticate the users while the VPN is down?

    As soon as the VPN comes back up again it all starts working.

    We've checked that the Azure VMs are using the correct DNS settings i.e. they are looking at the local DC rather than on-premise and that seems ok

    Anyone else had similar problems?

    Cheers for now

    Russell

    Thursday, April 30, 2015 9:14 AM

Answers

All replies

  • Hello RSBurnell,

    Azure virtual machines may need to be provided connectivity to the on-premises corporate network. It is important to note though, that if the VPN fails, authentication and other operations that depend on Windows Server Active Directory will also fail.
    While users may be able to log on using existing cached credentials, all peer-to-peer or client-to-server authentication attempts for which tickets have yet to be issued or have become stale will fail.

    You can refer to this link for more information on this:
    https://msdn.microsoft.com/en-us/library/azure/jj156090.aspx?f=255&MSPPError=-2147217396

    Thanks,
    Syed Irfan Hussain

    Thursday, April 30, 2015 2:30 PM
  • Syed,

    Thanks for the reply but we've configured the Azure infrastructure in such a way that it should continue to work for external users if the VPN goes down. We have 2 x domain controllers in Azure that should handle the ADFS authentication even if they are unable to communicate with the other DC's on-premise.

    I'm trying to find out which component of the Azure Infrastructure and/or ADFS still tries to communicate with the on-premise network when the VPN is down.

    Cheers for now

    Russell

    Thursday, April 30, 2015 2:45 PM
  • Greetings, Russell!

    There is 1 thing I see happening here and can be sure of - The ADFS servers deployed on Azure VM within a vNet is routing tokens to the DC on-prem via the VPN tunnel.

    Please make sure if that Azure VM is domain-joint as in the primary DNS is pointing to the local DC. I know you have checked this part. But I see no other reason why traffic should go through the VPN tunnel. What you can also do is capture a fiddler trace to learn the route better and troubleshoot.

    You may refer to: https://msdn.microsoft.com/en-us/library/azure/jj156090.aspx#BKMK_WhyADFS which describes your scenario.

    For one of our engineers to take a look at it in detail, you're requested to raise a Technical Support ticket (as the traces contains customer specifics) and we'll look into it.

    Thank you,

    Arvind


    Friday, May 1, 2015 7:49 AM
  • Irvind,

    Thanks for the reply and I agree that it looks like one of the servers in Azure is still trying to contact the on-premise network.

    I've double checked that all the servers in Azure are configured to use the local DCs and that their DNS servers are set to the correct (local) IP addresses. We've manually configured the DNs servers on the VMs and only have the two local DC IP's in the DNs settings within the Virtual Network in Azure.

    I had wondered about doing a network trace of some sort but wasn't sure what I could use (Netmon?) or where to install it. I guess it would have to go on the ADFS servers so that we can trace what packets are being sent once the VPN is down?

    Cheers for now

    Russell

    Friday, May 1, 2015 9:07 AM
  • Yes, Netmon would be a good tool to capture network traces. You can also use Fiddler traces for debugging AD related issues. You can run on the Azure VM hosting ADFS as it is redirecting the request to the IdP (not sure which one though - locally on Azure or on-premise)

    You may create a Technical Support Ticket and share the traces.

    Thank you,

    Arvind




    Friday, May 1, 2015 10:11 AM
  • I'll try it over the weekend and get back to you with the results.

    Cheers for now

    Russell

    Friday, May 1, 2015 11:20 AM
  • Yes, Netmon would be a good tool to capture network traces. You can also use Fiddler traces for debugging AD related issues. You can run on the Azure VM hosting ADFS as it is redirecting the request to the IdP (not sure which one though - locally on Azure or on-premise)

    You may create a Technical Support Ticket and share the traces.

    Thank you,

    Arvind




    I've just run an initial NETSH TRACE on one of the ADFS servers (without taking the VPN down) and then logged on to O365 from a remote location.

    I was surprised to see some LDAP traffic originating from the ADFS server to one of the on-premise DC's rather than one of the local DCs in Azure!

    I guess this is causing the problem if it's trying to do the same when the VPN is down, but I'm still not sure why the ADFS server isn't using the local DC's......any other ideas? If I logon to the ADFS server and run an NSLOOKUP it shows the local DC and if I then drop down to a command prompt and ping the internal domain name it also replies from the local DC. 

    Cheers for now

    Russell

     
    Friday, May 1, 2015 11:59 AM
  • I've carried out some more work on the trace results and have noticed that the ADFS Server queries DNS on the local (Azure) DC for _ldap._tcp.pdc._msdcs.internaldomain.net which correctly returns the name of the PDC emulator, which is a DC located on the on-premise network.

    The next request from the ADFS server is another DNS lookup for _ldap._tcp.AzureSiteName.PDCServerName.internaldomain.net which fails with a Name Error. I assume this is because the PDC emulator isn't located in the Azure Site?

    The ADFS Server then does a DNS lookup for _ldap._tcp.PDCServerName.internaldomain.net which also fails with a Name Error but I'm not sure why as this seems to exist in DNS.

    The ADFS Server then starts to communicate with the PDC Emulator using LDAPMessage and NetLogon protocols.

    I'm not sure why the ADFS Server is looking for the PDC Emulator as it's normally going to be on-premise rather than in Azure?

    Cheers for now

    Russell

     

    Friday, May 1, 2015 3:39 PM
  • Have you enabled extranet lockout on the ADFS/WAP servers http://blogs.technet.com/b/pie/archive/2015/10/11/adfs-extranet-lockout-and-pdc-requirement.aspx?

    Is so the ADFS servers will contact the DC running the PDC emulator role every time it validates a token. 

    • Marked as answer by RSBurnell Saturday, September 10, 2016 10:26 AM
    Monday, January 18, 2016 3:09 PM
  • Thanks for the response.

    It certainly looks like the sort of problem we're encountering (i.e. the ADFS system is looking back across the VPN for the on-premises PDC emulator) but we haven't enabled the Extranet Lockout feature!

    Cheers for now

    Russell

    Monday, January 18, 2016 4:25 PM
  • Have you enabled extranet lockout on the ADFS/WAP servers http://blogs.technet.com/b/pie/archive/2015/10/11/adfs-extranet-lockout-and-pdc-requirement.aspx?

    Is so the ADFS servers will contact the DC running the PDC emulator role every time it validates a token. 

    We did more troubleshooting the other day and found that the Extranet Lockout had been enabled, so the PDC (which is located on the on premise network) was being queried (across the VPN). We will move the PDC FSMO role to a DC in Azure and that will solve the problem.

    Many thanks

    Russell

    Saturday, September 10, 2016 10:28 AM