Migration of On Premise Users and Groups
You don’t have to sync your whole domain to the cloud. You can select which users to sync using OU’s and Groups. You can include and exclude specific OU’s and Groups
Understanding SSO, PHS, PTA and ADFS Federation Concepts
Azure AD Auth uses different languages to AD on premise.
Azure AD connect can speak both languages.
Azure AD Hybrid Identity with Password Hashed Sync Model
This model syncs the passwords to Azure AD.
Users both on premise and external can login with this method even if the connection on premise servers is down.
Azure AD Hybrid Identity with Pass Through Authentication Model
Uses Azure AD connect to sync user and groups (but not passwords).
PTA agent runs on an on premise server for authentication. These servers can be on the inside of the network (no need to be in DMZ). The on premise agent polls Azure AD constantly. It checks Azure AD for authentication requests in the queue. The information is pulled in by the on premise servers, it is NOT pushed in by Azure AD. This means you don’t need to open any extra ports etc…
Sometimes this is used where this compliance situations that say passwords can’t be store in the cloud, even if hashed.
Azure AD Hybrid Identity with Federated Authentication
This is the most complex model. There are a lot more servers required on premise for this.
Passwords are NOT stored in Azure AD. Authentication happens on premise
- Azure AD connect
- 2 x on premise federation servers (2 for redundancy)
- 2 x on premise Federated proxy servers (so your federated servers aren’t exposed to the internet
- Port 443 needs to be open to Proxy servers so need reliable firewall between internet and proxy, plus firewall between proxy servers and federated servers. Only allowing proxy servers talk to federated servers.
You point Azure AD connect to your federation servers.
Users on premise get a token from federation servers to authenticate with cloud services
- User sends a request to Azure AD to authenticate
- Azure AD points the user to the federated proxy
- The proxy talks to the federated server
- The federated server sends a request to AD
- AD (Domain controller) authenticates the user and sends the info back to federated server
- Federated servers creates a token for the client and sends this to the client through the proxy server
- Client uses this to authenticate with Azure AD
- If you lose connectivity with on premise you can’t authenticate with cloud services
You can use 3rd party authentication (it’s the only reason to use this method these days)
Using IDFIX to clean AD before syncing with Azure AD
Before syncing your Active Directory to the cloud you should clean up AD to avoid any issues.
EG: on premise AD allows you to have a space in the username, Azure AD does not. That will cause sync issues
This is a Microsoft tool you can download and run against your domain to find any potential issues with syncing from your on premise AD.
You can download this tool from GitHub. Its best to run on a client device, eg: Windows 10 machine
This tool will find any issues and can fix them for you.
Implementing Azure AD Connect sync with Active Directory on Premise
Installing Azure AD Connect:
- Download the installer through your Azure AD portal (or google search it)
- Install it on your server
- Install options:
– Express install: this automatically uses PHS and will sync all objects in your directory
– Custom install: allows you to select the authentication method and select objects to be synced
- Select custom and it will install required files
- User sign in: this is the authentication method ( PHS, PTA etc…)
- Enter a global admin account for your Azure Tenant. It then establishes a connection with the cloud and verifies credentials
- Then you select the domain you have on premise. It then creates an account to be used with the synchronisation for Azure AD. You need a domain admin account to be able to create this. OR you can create your own account if you want and set all the permissions.
- It asks if you want to use UPN to verify names
- Next you select which OU’s you want to sync. The default is to sync everything.
- Uniquely identifying users: you can use the default if you only have the users in the one domain
- Source Anchor: let Azure Manage this and it uses the ms-DS-consistencyguid which is what everyone uses.
- Filter users and devices: here you can select groups to sync
- Optional features:
– Azure AD app attribute filtering: here you can sync attributes back from cloud apps to on premise. You configure this on the next step
-Password writeback: if you select this users can change their password in the cloud and it will sync back to on premise
– Group write back: this feature has been moved. You can only set this up after you sync
– Directory extension attribute sync: this syncs extra attributes from on prem to the cloud. You configure this on the next step
- Azure AD Apps: here you can select which apps to sync back
- Azure AD attributes: here you select which extra attributes will synced to the cloud
- Directory extensions: here you select directory attributes to be synced. This is so cloud apps can query them
- Enable SSO: enter a domain admin account to create the connection for SSO
- On the last step you can select whether you want to start the sync after it is configured or enable staging mode (backup mode)
Using Azure AD Connect Health and looking for synchronization errors
Go to Azure AD -> Azure AD Connect
From here you can see the sync status, last sync etc…
Health And Analytics
At the bottom of the same page you can see Health and Analytics. From here you can download an agent to install on your domain controller which will report the health for your domain.
You can install ana gent for your AD FS servers also
Click on this to see any sync errors