A critical factor in the successful deployment of Microsoft Cloud Identity components is getting your on-premises Active Directory in order. Customers I work with generally have little problems getting AADConnect and\or AD FS deployed, but sometimes do miss some of the required directory remediation to ensure the deployment goes smoothly. For this reason I thought I'd put together some quick pointers that will help towards a successful deployment.
IDFix - is a handy tool that reports on the remediation required with your Active Directory. It will flag issues with data within the directory and provide a report that show's what needs to be remediated (and the tool has the option to do the changes for you). IDFix will flag issues with:
- Duplicate objects
- Attribute issues - Unsupported characters, spaces, length etc.
- UPN issues
- Blank\Null attributes
The goal of IDFix is to make the synchronisation process successful first time. It's better to fix these issues upfront rather than have to trawl though lots of errors after synchronisation has taken place. The tool and guidance can be located here.
User Principle Name (UPN) - Is the log on that is recommended for use with Microsoft Cloud Services. If you look at an user's AD account you will notice they have a samaccountname and a UPN as "user logon name".
The samaccountname is the one user's generally use to log on to desktops etc and takes the format of "contoso\user", whereas the UPN takes the format of "email@example.com". The implicit UPN your user's have today will depend on the name given to the AD DS Forest upon creation. To allow user's to log on to Microsoft Cloud Services the "@domain.com" portion of the UPN needs to be an internet routable namespace. If it's not...don't worry lots of customer's have the same issue, but it does mean that you will need to add a UPN suffix to the AD Forest and ensure all user's are updated to reflect this new UPN namespace. See here for more information. (When changing UPN's for user's you will need to check that they aren't using UPN for log on to other systems...changing their UPN could break access to systems if you don't manage it carefully)
Domains - As we have discussed the UPN is the recommended log on for your user's. e.g "firstname.lastname@example.org" and to ensure a successful deployment you'll need to add the domain you use for your UPN into Azure AD (before you enable synchronisation).
You will also need to add all additional domains that will be used for authentication and e-mail (Office 365). This is a very simple task and just requires you to add the domain in Azure AD and verify the domain by adding a DNS record in the public facing DNS Zone. See here.
Define Filtering Rules - While you are remediating your directory it makes sense to review what you do and don't want to synchronise to Azure AD. As I discuss here you can filter objects from being synchronised to Azure AD by selecting an attribute, AD domain or Organisational Unit but only do so if there is a clear security\policy reason to do so. Typically customer's only filter things like service, disabled accounts as there is generally no value to having them in Azure AD.
User Communications - While the technical aspects of preparing your directory for Microsoft Cloud Identity are very important, the success of deployment is also down to user communications. As user's will be using UPN to log into Microsoft Cloud Services they need to know what credentials to enter and when. Spend some time in producing quality communications so user's are clear on what they will see and what credentials they need to enter.
I will be adding more posts on getting started with Microsoft Cloud Identity so follow me if you would like to get updates.