locked
Use Azure Active Directory Domain Services to login to a domain from a remote location RRS feed

  • Question

  • I would like to know if I can login to a domain that has been extended by using AD Connect and AAD DS to the Azure portal. I know that you can domain join VMs in the cloud this way but can this be used to authenticate domain members from a remote location? Like a laptop on Wifi?

    Think of the way Cisco Anyconnect will let you establish a VPN connection first, before logon. This is so that logon scripts can be run and you can authenticate to the domain before you login to the laptop. I need to do the same thing but replace the VPN connection with a connection to the AAD DS via the internet. Can this be done?


    PJ McGhee

    Thursday, February 9, 2017 2:16 AM

Answers

  • If you enable AADDS, you already have two DC's in the cloud. There is really no reason to add another one. Actually, the AD that AADDS provides you is not identical to the AD that you have on-prem. It has a copy of a lot of the objects of the on-prem AD, but it is not the same as another site in your on-prem AD.

    If you want a "real" DC in the cloud, you can create a V-net with VPN tunnel to your on-prem, and then install a VM which you promote to DC.

    See this article on how to set it up: https://www.petri.com/best-practices-domain-controller-vms-azure.

    • Proposed as answer by rasmusw Tuesday, February 14, 2017 7:37 AM
    • Marked as answer by Sjoukje ZaalMVP Thursday, March 2, 2017 3:27 PM
    Tuesday, February 14, 2017 7:37 AM

All replies

  • For that to work you would need to open up the required ports for client to Domain Controller communication to the AADDS DCs.

    That is probably not a good idea.

    Instead you can use offline domain join". That has been in the client since Windows 7.

    With Windows 10 it is even possible to then setup DirectAccess for remote secure connectivity to the on-prem network (similar to AnyConnect's pre-login connection establishment, but built-in to Windows).

    Thursday, February 9, 2017 2:22 PM
  • If I enable AADDS to extend the domain to Azure from the on-premise then I can domain join new virtual servers in the cloud to the on-premise AD, this part I know and have done. But can I then take the virtual server that has been domain joined and promote it to a domain controller? Or do I have to create a VPN tunnel to the on-premise DCs?

    PJ McGhee

    Tuesday, February 14, 2017 2:20 AM
  • If you enable AADDS, you already have two DC's in the cloud. There is really no reason to add another one. Actually, the AD that AADDS provides you is not identical to the AD that you have on-prem. It has a copy of a lot of the objects of the on-prem AD, but it is not the same as another site in your on-prem AD.

    If you want a "real" DC in the cloud, you can create a V-net with VPN tunnel to your on-prem, and then install a VM which you promote to DC.

    See this article on how to set it up: https://www.petri.com/best-practices-domain-controller-vms-azure.

    • Proposed as answer by rasmusw Tuesday, February 14, 2017 7:37 AM
    • Marked as answer by Sjoukje ZaalMVP Thursday, March 2, 2017 3:27 PM
    Tuesday, February 14, 2017 7:37 AM
  • Thank you so much for this information! I have used AADDS and do understand that these DCs are in the cloud. Can the proper ports be opened to these "DCs" so that clients can authenticate to them from the internet and not have to VPN to a the LAN where the traditional AD DCs reside? 

    I have just that specific use-case scenario. I have laptop clients that need to authenticate to their domain at the Windows GINA from ANY location without the extra step of a VPN Client logon. 

    I cannot tell you how much I appreciate the time you have taken. I have not been able to get a clear answer from anyone on this and my company is also working through some of the larger VARs. No one has a clue if this can be done or not!!!!


    PJ McGhee

    Tuesday, February 14, 2017 11:41 AM
  • You don't want to have a DC on the open internet.

    It is extremely bad practice. Check out the answers to a similar question here: http://serverfault.com/questions/573681/should-i-expose-my-active-directory-to-the-public-internet-for-remote-users 

    Also check out this list of securing DC's: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack. Internet access FROM the DC is discouraged.

    You could solve your problem with DirectAccess or with Windows 10 clients that are logging on the Azure AD.

    Tuesday, February 14, 2017 3:07 PM
  • Believe me, I understand the risks inherent in putting a DC on the internet and this is not my recommendation.

    I have lookied at directaccess but that appears to be limited and requires infrastructure.

    When you mention "Windows 10 clients that are logging on the Azure AD" can you be more specific? that actually sounds exactly like what I am try to do. But this has been difficult getting a really clear answer on the use case I am trying to acheive.



    PJ McGhee

    Tuesday, February 14, 2017 9:38 PM
  • There's a series of blog posts detailing setup and features of Azure AD Join on Windows 10 devices: https://blogs.technet.microsoft.com/enterprisemobility/2015/05/28/azure-ad-join-on-windows-10-devices/

    I hope that will solve your problem.

    Wednesday, February 15, 2017 7:57 AM
  • Dear rasmusw,

    Yes, this article has been very helpful in understanding how Domain Join differs from Azure AD Join. I believe that I have my answer but if you would continue to be as generous as you have with your time so far, I would be very appreciative!

    The specfic use case is this:

    We need to disable Cached Credentials for latops. That's really at the heart of it. and we need to have the same credentials authenticate to Azure AD as well as the 2008 R2 on-premise domain. 

    To me, Azure AD doesn't quite do this although it can deliver a similar experience. What is your take on that?

    I cannot tell you how much I appreciate your time! How do I elevate your profile? Who can I thank for your time as well???

    PJ


    PJ McGhee

    Friday, February 17, 2017 12:41 PM
  • Hi PJ,

    I don't know whether the regular way of disabling cached credentials will also work when using Azure AD login. You can manage it with a registry key (https://support.microsoft.com/en-us/help/172931/cached-domain-logon-information) or using Group Policy (https://4sysops.com/archives/cached-domain-logon/), but Group Policy won't work in AAD login scenarios.

    By sync'ing passwords between AD and AAD which you can configure and with the Azure AD Connect tool, you get the same credentials both places. There is also a possibility to use ADFS, so the passwords remain in your AD. Check out the documentation for AAD Connect (https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect) for details.

    If you accept one of my answers, I get credit for it, that would be great :)

    Rasmus


    • Edited by rasmusw Monday, February 20, 2017 7:21 AM added links to urls
    Monday, February 20, 2017 7:21 AM
  • Thanks for the information! Having the creds the same in both places is going to be the way to go and using AD Connect will be the method with the least amount of infrastructure.

    The only thing that I really need to know at this point is whether we can restrict a laptop from allowing a login when the authentication mechanism is not present. Meaning Azure or the on-premise AD.

    At the end of the day, we just don't want to allow a laptop to be allowed to login if the user/PC account has been disabled in AADDS. No "offline" logon at all. Do you have any thoughts on that?



    PJ McGhee

    Monday, February 20, 2017 1:56 PM