What can I do with Azure AD?
And why should I care?
AzureAD provides functions for authentication/user and device management. AzureAD can connect to various services and products and authenticate your users for said services.
You can handle your users/devices and groups in Azure AD. Many companies are now moving to Azure AD for different reasons, but usually it is to adopt a “Cloudonly” identity.
Microsoft has released products which intends to help administrators manage the users/groups/services and devices with the aid of AzureAD.
Azure AD collects all this information into one catalouge that can be accessed by different services/software and is a “one stop” solution for handling the administration of user/account info.
- You can join computers into AzureAD and set policies/functions with the help of MDM (free – MDM is ONLY for mobile devices – computers can not be managed properly). For more complex policies and autoenrollment you would need Intune.
- You can join phones and set policies on those aswell. Just like above, you can use the MDM or intunes if you want more complex policies instead of GPO.
- You manage the users/groups in Azure AD directly (or though O365).
- You can use Azure ADDS instead of a standalone DC in Azure to manage your VMs in Azure.
Different uses of Azure AD
Azure AD: Cloudonly
Passwords reside in Azure AD and nowhere else. You manage the users through Azure AD or O365.
Azure AD: Hybrid Azure AD
You have a onsite server/AD and want to use the same username/passwords for other services in Azure (Such as Office 365).
You can install ADConnect that syncs user/password/device information to Azure so that your users would only need one password.
When you create a user in your local environment, it will sync it to Azure (and even setup the O365 licenses for example).
If the user Changes the password in Azure, it will sync back to your onsite server. Read more about the solution below.
Azure AD: Federated identity
You have ADFS SSO onpremise and you can extend it to Azure AD with the help of AzureADConnect (or set it up manually).
This solution does not sync the passwords but means your DC needs to be online and available at all times to Azure (using VPN to azure) for it to work. Read more about it below.
Azure AD: Licenses
Most of the standard functions in Azure AD is included in the free/BASIC license. Although some things that do not included are:
- Password resets online require the BASIC license (which is included in Office 365) but not in Azure Free.
- Writeback options from AzureAD requires the P1 license.
- Advanced Identity functions requires the P2 license.
Now, this is just for the AD functionality – not Intunes and other security products counted.
You can check the following:
and check out Microsoft EMS (Security suite for Azure/O365)
Lets dig deeper –
the different Azure AD services
(and what they do).
So there is a lot of confusion regarding all the different services regarding the Azure AD solutions.
Here is a quick list to sort it all out.
Active Directory (Local – Onsite)
This is the standalone server active directory. This contains all user/computer accounts on premise. Also referred to as a domain controller.
Azure AD (Azure Active Directory)
Azure is a service from Microsoft that contains many different services. One of them is Azure AD – that many of their products have access to. Office 365 for example stores all userdata in Azure AD. You can connect several product to use the same username/passwords as in Azure AD.
Hybrid Azure AD
This is when you have a local Active directory (domain controller) onsite and want to syncronise your data to Azure AD. Instead of having to add accounts in two different places – you can just add it in the domain controller onsite and it will replicate to Azure AD with the help of AzureADConnect (a software that synchronizes the user/password data).
This is known as a Hybrid Azure AD solution.
Hybrid Azure AD: What it’s for
- As a first step to migrate into Azure completely. You can setup the syncronisation to Office 365/Azure AD and manage the users onsite on your local DC
- To domain join AND join the user/device to Azure AD. Note that for automatic enrollment of devices into Intunes/MDM you would need the P2 licenses. When you domain join the computer it will automatically join the Azure AD as well through a GPO that is defined in the onsite DC.
Hybrid Azure AD: What it’s NOT for
- You cannot create a redundant AD by simply using ADConnect sync. You would need to build a DIY ADDS in Azure and have a VPN connection to your onsite enviorment. ADConnect is only to sync user/device data to Azure AD so that your users can use the same Username/password (and/or SSO features) for other services such as Office 365. It does offer a sync between Azure and your domaincontroller – but it’s not the same as having a proper server in Azure as it’s not a failover/redundancy solution.
- A way for your Azure VM to commicate with your onsite enviorment.
Hybrid Azure AD: Good to know
- Note that you will need the Azure AD P1 license to sync the passwords BACK to your local AD. This is if you synchronize the password write back feature. This will work even if only one user is licensed – but please note you are then not properly licensed. But can be good to know to test the feature properly before adapting it to a whole organisation.
- If you want to use the Azure Join or Register device – you can use the Azure AD FREE license but the clients have to be Windows 10 pro/enterprise. Earlier devices can join IF you use Intunes.
- Devices can only be properly managed with Intunes. The free MDM solution is mainly for mobile devices and is very limited when it comes to policies.
- You can filter what OU you want to sync to Azure AD (You dont need to sync all of the objects from your onsite AD).
- Will integrate with ADFS and supports multiple domains. (See https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-multiple-domains)
- It will sync disabled objects.
- Local AD will always overwrite data in Azure on the first sync. This means if you have used Azure before and THEN implemented a Hybrid AD solution you will need to make sure the onsite AD is the most recent/clean. The exception is when an attribute has a NULL value on-premises. In this case, the value in Azure AD remains, but you can still only change it on-premises to something else.
- You need to have the same UPN onsite as in Azure AD. You can set a different UPN on your onsite DC (instead of renaming the domain). Azure AD can only sync to a verified domain. This means that if you have test.com in Azure (Office 365) and test.local onsite – you will need to add test.com to your onsite environment first. Check this article for more info
Difference between Azure AD Join, Registered and Domain joined device
It’s a bit off topic – but at the same time very valid in a Hybrid AD environment. You can JOIN a device to your Azure AD or just register it. Here are the main differences.
- Joins the PC to the Azure AD and provides more functions such as SSO- although works only on Windows 10.
- Can be joined through the internet.
- For computers/devices owned by the corporation that does not need to be joined into the onsite domain.
- Stores bitlocker keys in Azure directly.
- For BOYD – you login with your personal account, but your device is a part of the Azure AD. Simple functions such as Basic SSO. No Seamless import into intune.
- Can be joined through the internet
Domain + Device registered
- Machines are joined to the onsite AD and then joined to Azure AD aswell (using the workplace join function). The machine is managed through SCCM and GPO (onsite).
- Provides simple SSO experience.
Check this blog post for a great explanation (https://blogs.technet.microsoft.com/trejo/2016/04/09/azure-ad-join-vs-azure-ad-device-registration/)
AADDS (Azure Active Directory Domain Services)
Is a standalone service in Azure – that enables a domaincontroller for virtual machines in Azure – without setting up a standalone server as a domain controller. It basically creates a domcin controller as a service – so you don’t need to worry about downtime, patching or other things.
AADDS: What it does
What it does is that it syncs user/groups and passwords from Azure AD to makes it available for the virtual computers in a Azure network. It also replicates SIDs.
You can use familiar Windows Server Active Directory management tools such as the Active Directory Administrative Center or Active Directory PowerShell to administer managed domains (Managed domains – Also known as AADDS).
- No need for virtual machines hosting your Active Directory
- Use the same groups and users as in your Azure tenant for your virtual machines.
- Passwords from your Azure tenant is replicated to your domain (SSO)
AADDS: What it does NOT
- Does not support replication.
- Any KCD services that require Domain admin will not work (as only Microsoft has Domain admin priviledge). Fix by using resourced-based KCD.
- Can not setup as trust domain to other domains (yet).
- No Domain/Enterprise admin privilege (Apps that needs it will not work)
- Schema extensions are not supported (yet)
- AD domain/forest trusts not supported (yet)
- LDAP write not supported (yet).
- User attributes can not be edited directly in AADDS IF the user is avaiable in the Azure AD. A workaround using a custom container in the AADDS can be used.
- If you DON’T sync password – you cannot use AADDS (yet)
- Can not replicate between Azure networks.
- It will publish GPO for the VM servers in the Azure network, but not for users/clients. Use a DIY ADDS server for that (or intunes).
- It will not sync back to your local AD or Azure AD (Its read only).
- Certificate/Smartcard based authentication is not supported by Azure AD Domain Services.
- Limited to one domain per Azure AD tenant.
- Limited and tied to only one vnet in Azure.
- No way of having users from other Azure AD directories.
- Does not support managed service accounts
- Suppports only standalone CA (not Enterprise CA)
- You cannot enable Azure AD Domain Services in a classic Azure virtual network.
AADDS: What should I use it for?
- If you plan on using RDS services in Azure, you can run the AADDS and not having to start a VM with DIY ADDS for that specific case.
- If you have many servers and want simple ADDS (the basics).
AADDS: What should I NOT use it for?
- As a standalone DC for your clients/users. You will need to use MDM/Intunes or a DIY AD server.
- As a backup for your local AD – again, go for a DIY AD server
- As a substitute for your onsite AD.
- To connect your clients. See below:
AADDS: Good to know
- It takes roughly 20 minutes before replications is seen in the AADDS From the Azure AD. Oneway sync from Azure AD (Can not sync back to Azure AD).
- AADDS can be used on all plans of Azure (Its not part of EMS).
- You can not add domaincontrollers/DNS servers to a managed domain/AADDS (in the virtual network it manages)!
- You can use the server with RSAT tools / manage it by web (not all functions) or with all functions from a VM in the managed network. Or if you use VPN/Expressroute.
- Do not use the same DNS domain name (such as test.com) as your onsite or Azure AD!
- If you use the .onmicrosoft domain and you need a certificate for example – you are screwed. Use a totally fresh DNS name. That is routable (not a .local).
- All users and groups are stored within the ‘AADDC Users’ container, regardless of the on-premises domain or forest from which they were synced in. You may have configured a hierarchical OU structure on-premises. However, your managed domain still has a simple flat OU structure.
- If your organization has cloud-only user accounts, all users who need to use Azure Active Directory Domain Services must change their passwords.
- Your Azure AD Domain Services managed domain is deployed in the same Azure region as the virtual network you choose to enable the service in.
- Encrypted at REST – Keys held by Microsoft. Key per tenant. Only Azure AD can exchange with the AADDS.
- AADDS is a continually billable service. Basically you can’t shut it off.
Also good to know – Regarding clients/users and GPOs
Technically, it is possible to join an on-premises client workstation to the managed domain over a site-to-site VPN or ExpressRoute connection. However, for end-user devices we strongly recommend you use either register the device with Azure AD (personal devices) or join the device to Azure AD (corporate devices). This mechanism works better over the internet and enables end users to work from anywhere. Azure AD Domain Services is great for Windows or Linux Server virtual machines deployed in your Azure virtual networks, on which your applications are deployed.
Also good to know – LDAP Write
The managed domain is read-only for user objects. Therefore, applications that perform LDAP write operations against attributes of the user object do not work in a managed domain. Additionally, user passwords cannot be changed from within the managed domain. Another example would be modification of group memberships or group attributes within the managed domain, which is not permitted. However, any changes to user attributes or passwords made in Azure AD (via PowerShell/Azure portal) or on-premises AD are synchronized to the AAD-DS managed domain.
AADDS: Final verdict.
Its great for VMs in Azure, simple to setup and works with your Azure AD. It does NOT replace a proper domain controller and does not work with managing users/computers like you are used to. Works great if you plan on a cloudonly strategy with limited users and where you don’t use many functions of the DC (such as client GPOs etc).
- Great to manage VMs/Domainservices within the VMs. It can’t talk directly with your DC onsite or similar – so it’s not a backup DC.
- Basic DS functions – great for cloudonly strategies.
- If you want to manage clients and users – use Intunes instead.
- Want to use it together with an onsite solutions – use a proper DIY AD instead.
This is when you setup a standalone Azure VM machine as a standalone domaincontroller (just as you would setup onsite). This is great if you have legacy software that needs functions that AADDC can not support and/or you want to build a redundant solution with your onsite AD. Problem is that you need to setup a whole VM to do the job and pay for it aswell.
ADFS is a different story. What it does is to setup trusts between different domains and create an SSO (single sign on – basically you don’t need to sign in multiple times). This is often used as a way to login to different vendor solutions using your Azure AD credentials. This can be setup in Azure (it’s a completely different story – maybe a different blogpost).
If you wish to use ADFS for O365 – you can use ADConnect to configure the ADFS service and no password sync takes place. Instead it queries your onsite domain server everytime someone wants to login. This is a big plus if you have other vendors that’s already federated in your environment. The downside is that you would need VPN connection to Azure AD for it to work and is a single point of failure. Password sync would only need access to UPDATE passwords but logins would still work.
The different Azure AD setups (Visualized – Old school)
Onsite + ADConnect (Hybrid AD)
|Onsite AD (with ADConnect Installed)|<—->Internet<—>|AZURE AD|
(Syncs Usernames/Passwords both ways – requires P1 license – Else only one way sync)
Onsite + DIY ADDS (Redundancy deployment)
|Onsite AD|<—->VPN/Expresslane<—>|AZURE VNET|<–>|VM ADDS SERVER|
Onsite + ADConnect and AADDS (Future cloudonly/Hybrid deployment)
|Onsite AD (with ADConnect Installed)|<—->Internet<—>|AZURE AD| —-> |Azure ADDS|
(ADDS syncs only FROM AzureAD – Not back)
AADDS + AzureAD (Cloudonly)
|User|<—->Internet<—->|AZURE AD| —–> |AADDS|
(Optional – if using VM – else just AzureAD)