Forum Discussion
Onboarding - Best Practice AD
Seen a lot of AD’s where everything in the on-prem AD are synced to AAD so +30.000 ‘objects’ are synced – even though only 2.000 employees in the company
Is there a “best practice” available somewhere how to “structure” the AD before installing AD Connect Sync to AAD – and Filtering is enabled?
Like:
Create an O365 OU
Create the various 'Security groups' in the 0365 OU
avoid nested groups
etc. etc.
My number one recommendation to customers for preparing for AAD Connect is to look at your AD data like a SQL database owner. Don't let there be any junk, make sure all your attributes are programmatically verified (i.e., if there is a rule affecting an attribute, ensure all object conform to that rule. Ex: all users must have a Department set and normalized to one of the allowed values), and of course get rid of any conditions which must use OU filtering and replace them with attribute filtering. Example. Don't put all contractors in an OU, Azure doesn't have OUs, instead set an attribute on a user to define them as internal, external, contractor, seasonal, intern, etc. so you can tell who people are when they are all synchronized to Azure into the same OU. And of course, fix all IDFIX errors ahead of time.
I have used the following.
1. Reserve three extension attributes, they don't have to be the same as mine.
- ExtensionAttribute1:
- Enter 'NoSync' if the user does not sync to Azure. Configure this in AAD Connect to not sync these object that meet this filter.
- Enter 'DoesNotMigrate' if the mailbox does not move to O365. Use this filtering when looking for mailboxes that are left on-premises. An example would be service accounts that have to be on-premises because they send too much email for throttling policies.
- Enter 'Postpone: <date>' if the mailbox cannot migrate until a future date
- ExtensionAttribute2:
- Use for licensing. This can be a single entry, string of characters, or a bitwise number. Whatever you need for your environment. You can then set up AAD Connect transforms to put people in O365 licensing groups based on this information. Example: 'O365E5;TeamsConferencing;Visio;Project;NoYammer'
- ExtensionAttribute3:
- Similar to Attribute2 but used for Admin group memberships
- Example: 'Azure:GlobalAdministrator', 'O365:HelpDesk,Compliance'. Etc, you get to define the names and associate those with scripts to put people in the proper role groups effectively controlling the membership of cloud groups with on-premises attributes.
I hope these ideas have helped.
Brian KronbergMicrosoft
My number one recommendation to customers for preparing for AAD Connect is to look at your AD data like a SQL database owner. Don't let there be any junk, make sure all your attributes are programmatically verified (i.e., if there is a rule affecting an attribute, ensure all object conform to that rule. Ex: all users must have a Department set and normalized to one of the allowed values), and of course get rid of any conditions which must use OU filtering and replace them with attribute filtering. Example. Don't put all contractors in an OU, Azure doesn't have OUs, instead set an attribute on a user to define them as internal, external, contractor, seasonal, intern, etc. so you can tell who people are when they are all synchronized to Azure into the same OU. And of course, fix all IDFIX errors ahead of time.
I have used the following.
1. Reserve three extension attributes, they don't have to be the same as mine.
- ExtensionAttribute1:
- Enter 'NoSync' if the user does not sync to Azure. Configure this in AAD Connect to not sync these object that meet this filter.
- Enter 'DoesNotMigrate' if the mailbox does not move to O365. Use this filtering when looking for mailboxes that are left on-premises. An example would be service accounts that have to be on-premises because they send too much email for throttling policies.
- Enter 'Postpone: <date>' if the mailbox cannot migrate until a future date
- ExtensionAttribute2:
- Use for licensing. This can be a single entry, string of characters, or a bitwise number. Whatever you need for your environment. You can then set up AAD Connect transforms to put people in O365 licensing groups based on this information. Example: 'O365E5;TeamsConferencing;Visio;Project;NoYammer'
- ExtensionAttribute3:
- Similar to Attribute2 but used for Admin group memberships
- Example: 'Azure:GlobalAdministrator', 'O365:HelpDesk,Compliance'. Etc, you get to define the names and associate those with scripts to put people in the proper role groups effectively controlling the membership of cloud groups with on-premises attributes.
I hope these ideas have helped.
Brian Kronberg - how about On-prem admins - should they be synced to the AAD or should they be "cloud-only" identities
- Brian Kronberg
Taen keren, security best practices of course will say to separate your admin accounts to limit risk if one credential is somehow compromised. But then again, that is exactly why we also highly recommend forcing multi-factor authentication for all admin accounts. So, this is a decision for your organization to make. Require alternate credentials for on-premises versus cloud, or share a credential and enforce MFA on it. If admins are using the web-based GUI, it is not that difficult having multiple credentials, just a little pain. However, where it really gets difficult is automation via PowerShell scripting. There is no "good" way to enforce MFA and automate scripting because it requires you to store your password credential in a file which defeats the purpose of MFA.
So, I'm sorry, but I don't have an easy answer for you but I hope this explanation helps.
I doubt there are many organizations that have restructured AD just for the sake of configuring AAD Connect. Run the IDFix tool to clean up any errors, then simply use filters to get just the objects you want to sync.
VasilMichev - I doubt that too - but still, MS must have som BP/Recommendations - as they have the Categorize/group users and assign license on those groups?
- The only thing we did to prep our AD before syncing to O365 was to clean up all our various OUs. Over the years new items were created in places they shouldn't have been. So we got all the users in a users OU, DLs in their own OU, contractors in their own OU, etc. This simply made it easier going forward and got everyone on the same page where things should be created. I think in a nutshell, organize your AD in the way it works for your organization. I think that is the key.
