.png?width=100&auto=webp&quality=80&disable=upscale "Picture of John Savill")
.png?width=400&auto=webp&quality=80&disable=upscale "John Savill")
Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
A dive into some Azure AD design and deployment considerations, Part 1!
John Savill's Frequently Asked Questions
John Savill
August 23, 2017
4 Min Read
Three times a week (Monday/Wednesday/Friday), John Savill tackles your most pressing IT questions. Read through the FAQ archives, or send him your questions via email.
Q. What authentication method should I use for Azure AD?
Q. Can I select a different authentication method for different groups of Azure AD users?
Q. Can I get Linux machines to register in my AD integrated dynamic DNS?
Q. What authentication method should I use for Azure AD?
Dept - Azure
A. Most organizations will populate Azure AD with users and groups by replicating from their on-premises Active Directory Domain Services environment. When users are sourced this way there are three way in which authentication requests for the Azure AD users can be handled.
Azure AD performs the authentication. This is possible provided the users password hash (or rather a hash of the password hash) is replicated to Azure AD. This is the simplest option requiring no communication with on-premises AD infrastructure but it also means the on-premises DCs are unaware of the authentications and have no control over them.
Federation is used, for example ADFS. In this case Azure AD is configured to use federation for the authentication. When an authentication is requested the user is redirected to the federation service which performs the authentication using (normally) the on-premises AD. This is a more complicated deployment but enables the full power of ADFS as part of the authentication such as using certificate based authentication, hooking in to other MFA systems, device health and location and all the other policy capabilities of ADFS (or whatever federation platform is used). Note if you choose this option you can still replicate the password hashs to Azure AD from the previous option and use as an alternate authentication approach if the federation services were unavailable.
Pass-through authentication is used. This is the newest of the options as an addition to Azure AD Connect. In this deployment agents are deployed on-premises which listen to an authentication request queue in Azure AD (the agents make an outbound connection to Azure AD meaning no firewall exceptions). When a user authenticates against Azure AD the request is added to the queue, one of the on-premises pass-through agents takes the requests, authenticates against an on-premises DC and returns success/failure. The benefit with this approach is it uses on-premises DCs to perform the actual authentication allowing the organization to keep tighter control and visibility of authentications while removing the requirement for the infrastructure associated with federation. Note that additional instances of the pass-through agent should be deployed on-premises beyond the default single instance deployed with Azure AD Connect to provide high availability for the service.
Note that while I often say on-premises AD or DCs they don't actually have to be on-premises. They could be hosted as Azure IaaS VMs etc. I simply mean they are not Azure AD.
There is not a right or wrong answer as to which to choose as every organization has different requirements. If you are a fairly simple environment with no federation today and don't need insight on-premises of authentications then using the password hash is the simplest option. If you would like some additional visibility and control then the pass-through authentication would be a good option. If you are a larger organization using federation already then using federation is likely the approach you will take however it is important to take a step back and evaluate your needs. Once you use Azure AD you may no longer need to have federation services of your own as you can used the Azure AD federations therefore using federation is likely not ideal as you would just be introducing another dependency on it while all the other use cases would move to Azure AD. You may also need to use federation if you wanted the more advance options such as the certificate based authentication, other MFA solutions etc.
Q. Can I select a different authentication method for different groups of Azure AD users?
Dept - Azure
A. No (and yes). A single method for the authentication for an Azure AD domain (UPN) is configured. You cannot select multiple options even across different groups of users within a domain. If however you have different domains (UPNs) within an Azure AD instance then each domain has their own authentication selection.
Q. Can I get Linux machines to register in my AD integrated dynamic DNS?
Dept - DNS
A. AD integrated DNS uses secure update by default which means only machines that can authenticate will be able to register records. If you wish to have Linux machines registry there are typically two sets of configuration however this provides a far less secure configuration and is generally NOT recommended. Another option would be to manually register Linux records. If you want to enable the Linux automatically :
Firstly configure DHCP to register the host (A) and pointer (PTR) on behalf of clients that don't register themselves
Open DHCP Manager
Open the properties of the scope
Select DNS tab
Enable the option Dynamically update DNS records for DHCP clients that do not request updates
Click OK
Next configure DNS to support non-secure updates
Open DNS Manager
Open the properties of the zone
Under the General tab set the Dynamic updates to Nonsecure and secure
Click OK
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
