Microsoft has world-class Identity support for different applications and for different organizations. Microsoft identity can be used for SSO in most of the applications no matter where it is.
And the base for this is a well designed Hybrid Identity. There is a lot of attributes and dependencies to understand before it works like it should and this is exactly what I will be covering in this arcticle.
Table of Contents
Active Directory and user attributes
A user has attributes and the function for these attributes is to maintain user information. There are 207 attributes in a normal user account without any extension from Exchange, Skype etc.
Two hundred and seven, well that’s a lot, but they all serve a purpose in the bigger picture. Let’s get some examples.
OU = Where the user resigns inside AD structure. Can be used for GPO filtering or in script for finding users. Or in AAD Connect to filter what users to sync.
canonicalName = the full path to the object. So the OU and the username for the user. This will be used by many powershell scripts out there for on-premises AD queries.
And with Exchange schema extension there will over 50 more.
And from I will pickup a couple.
ProxyAddresses = Proxy addresses are the user email addresses, but also used by Lync / Skype if you still have it implemented. It will have user email addresses either in SMTP or smtp prefix. There can only be one SMTP as it means the primary address, but there can be several smtp as they are aliases. With SIP there can be only on as user has only one Lync / Skype account.
TargetAddress = This attribute will be populated when a user is migrated thru a Exchange Hybrid to the cloud. It will tell AD and on-premises Exchange that mail flow to the user will be sent to this address.
Quick tip! You can also use TargetAddress to send email outside example to your gmail.com, it will just forward it, no questions asked.
So that enough about the attributes then more on what to with them.
Identity synchronization – User preparation
Microsoft currently has Azure AD Connect which will introduce your users to the cloud (it does more, but now only about user identity) and they have a good groove going on with Azure AD Connect cloud sync to provisioning the users but giving the orders from the cloud master.
Before enabling identity sync you have to check couple of things:
- Add your external UPN to Active Directory Domains and Trusts if you only have a non-routable domain name. If you have split-brain dns and external routable domain name that you will be using in Azure then you don’t have to do this step.
- Check and change users UserPrincipalName attribute to reflect your future login name. This is important because it will be the only identifier for your user. Users can still login with their old UPN so it doesn’t make any deffirence for the users profile in their computers. And yes there is also ObjectID attribute, but that won’t tell anything to anyone when collaborating or sending emails. This will be also your WindowsEmailAddress in the cloud if you don’t change them with email address policies.
- Check that the users are in their correct OU’s, this makes easier for you to manage the syncing when you probably want to filter the sync with OU structure.
- Check that user have all the information populated that is needed in the cloud. For the organizational view, Delve usage, add telephone numbers, addresses before the sync so you don’t have to populate them after wards as it will be harder that way once the SharePoint profile sync provisions the information.
Identity synchronization – Azure AD Connect
When you implement identity sync, you need access to your Azure AD and on-premise AD with user accounts. For local AD it’s recommended to use managed service account so you don’t have to worry about expiring passwords.
I’m going to go thru the technical steps with installing, instead I will talk about the best practices for it as their is step-by-step instructions all the over the web.
When you have Azure AD Connect installed and you did’t choose custom installation, you didn’t see the option to filter based on the OU’s.
If this was the case you can still modify these with synchronization Service.
And open the AD connector and choose properties.
And choose containers. From here you can choose the OU’s that you want to sync.
Then just let it run or run it manually. The first sync is full. It populates the data to SQL Express that was installed by AAD Connect Wizard.
Start-ADSyncSyncCycle -PolicyType Initial
And next run will incremental = only changes
Start-ADSyncSyncCycle -PolicyType Delta
Or you can just disable syncing user that don’t have the correct UPN Suffix directly from the connector either from GUI.
Or with PowerShell.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
Import-Module ADSync $Connector = (Get-ADSyncConnector | Where-Object {$_.Type -eq "AD"}) $UPNSuffix = "@$($Connector.Name)" # Uncomment the next line to manually specify your UPN suffix. #UPNSuffix = "@yourdomain.local" # Make sure no other rule has the same precendence. $Precedence = 99 New-ADSyncRule ` -Name 'In from AD - User Filter by UPN' ` -Description 'Filter users based on UPN.' ` -Direction 'Inbound' ` -Precedence $Precedence ` -SourceObjectType 'user' ` -TargetObjectType 'person' ` -Connector $Connector.Identifier.Guid ` -LinkType 'Join' ` -SoftDeleteExpiryInterval 0 ` -ImmutableTag '' ` -OutVariable syncRule Add-ADSyncAttributeFlowMapping ` -SynchronizationRule $syncRule[0] ` -Source @('True') ` -Destination 'cloudFiltered' ` -FlowType 'Constant' ` -ValueMergeType 'Update' ` -OutVariable syncRule New-Object ` -TypeName 'Microsoft.IdentityManagement.PowerShell.ObjectModel.ScopeCondition' ` -ArgumentList 'userPrincipalName',$UPNSuffix,'ENDSWITH' ` -OutVariable condition0 Add-ADSyncScopeConditionGroup ` -SynchronizationRule $syncRule[0] ` -ScopeConditions @($condition0[0]) ` -OutVariable syncRule Add-ADSyncRule ` -SynchronizationRule $syncRule[0] |
Identity synchronization – Problems and matching
If you don’t want to use Exchange hybrid Deployment and for that reason didn’t select Exchange attributes to the sync,
But instead you want to do third-party migration from our Exchange Server there is a possibility that you end-up with the following error.
This means that Exchange Online got the information based on msExchMailboxGuid attribute and now knows that you have mailbox and you cannot there fore license that user with Exchange Online and create a mailbox.
So you have to Null the attribute with Azure AD Connect, again not writing an section as there is multiple ready ones. Here a good and accurate one.
But it’s always a wise and recommended option to use a Hybrid Exchange. When you migrate mailboxes to the cloud you will keep the Hybrid as a management for the users cloud-based mailboxes. And it’s the only currently supported way to keep user sync between on-premise and the cloud. If not deployed your should remove the sync.
User matching in problem situations
Normally Azure AD matches users with SMTP matching, with SMTP matching it will your on-premises ProxyAddresses and attach that to objectID in the cloud.
One of these situations could be that you need to connect your domain to Azure AD, you have mailboxes on-premises and you assigned licenses to all users and created mailboxes before Azure AD Connect implementation.
Then it could be a job for Soft matching (SMTP matching) or even for Hard matching (ImmunitableID) that uses the is generated from your UserPrincipalName and ObjectID so it will be an unique identifier.
Sander Berkouwer wrote an detailed article on this one.
Now we have covered a lot of the process for understanding the identity, modifying the identity and syncing the identity, but there is still a lot after these steps.
Stay tuned (and safe) for more Identity releted content!
Over and out,
RSS - Posts