Managing User Identities in ADFS

Windows Active Directory - Now MicroNow Micro’s Micah Linehan identifies common issues with identities in an ADFS environment and provides insight on how ADFS and directory synchronization actually work.

User Creations and Troubleshooting
User management after deploying ADFS can be more confusing to the direct staff and those who support it. For example,

  • Are the addresses stuck as .onmicrosoft.com and not switching?
  • Are staff unable to add in alternate email addresses?
  • What about directory synchronization errors?

It is amazing how simple process and workflow user account provisioning can remediate most of those issues. Here are a few things that can ease a lot of issues with user identities:

UPN Suffix
Forgetting to change the suffix when creating the account forces the creation of the user account, but it does not allow for the setup of users’ primary SMTP address or profile name to the domain. The UPN suffix is a core provisioning point for the initial creation and synchronization to Office 365. Alternatively, this should be one of the first steps in creating Office 365 ADFS and even directory synchronization to ensure the account properly pairs in Office 365. That creation should include changing the primary UPN to the target delivery domain for mail.

Email Attributes
By setting the email setting under the user general tab in Active Directory, the user accounts’ email address and identity will be tied into Office 365. Without this attribute, the primary SMTP won’t get created, and directory synchronization errors will occur when working with the object. The error generated will be seen as a duplicate entry even though the object is not a true duplicate. This all sounds simple; however this step is often missed.

Aliases
Email Aliases confuse a lot of people with a directory synchronized environment. But by following these steps, it can be relatively simple:

  1. Direct technical staff to add the aliases in Active Directory Attributes for Proxy Addresses.
  2. Verify that staff understand the correct syntax of primary email address.
  3. Ensure case sensitivity of the attributes.

The only final step is then forcing a directory sync. However, if not in a hurry, let it change on the natural schedule of directory sync.

How do Mail-enabled Security Groups Work?
Using a mail-enabled security group to synchronize to Active Directory is the best way to control a lot of permissions into Office 365 and specifically with SharePoint online. By setting up the groups properly and making sure permissions groups are added through the chain of systems, permissions and groupings can be managed similarly to having an on premise mailbox.

It’s important to note that a regular security group will not sync with Azure or Office 365. The best practice to getting an object to sync is by making it a mail-enabled security group. There are two steps required to properly configure this:

  1. The first is the most obvious—an email address.
  2. Secondly, by default, most security groups or even mail-enabled security groups in Active Directory will not create a display name attribute if converting. Even if making a new one, it is not a defined requirement. However, in Office 365, the display name is a requirement for these objects to sync and pair properly with the cloud identity to match. It may be worthwhile to hide the security groups from the GAL and identify what the access is for and the level of permissions in the group name.

Should Permissions Be Set in the Cloud or On Premise?
The easiest response to this is “Where would you normally modify permissions for a mailbox or user?” What most people tend to get caught up on is that even though the users are in the cloud and on exchange online, it is still exchange, just in another location. It’s not recommended to set a mailbox permission or modify a recipient policy in Active Directory, and with Office 365 that stays the same—after all, it is still exchange. The catch with this the email address aliases (discussed above). In a true exchange environment, IT staff would go to the ECP or shell, and add the attribute directly in exchange. These attributes are directly managed by the on premise Active Directory, and modifying them in exchange online is not possible. However, addresses that are not synced with Active Directory can be added to the object (i.e. .onmicrosoft.com addresses).

Can Part of the Organization Be on ADFS and the Rest on a Cloud Authentication?
Segregation of authentication isn’t really a recommended practice. Once the decision has been made to turn the environment into a full ADFS (SSO) environment, plan on having everyone operate as such. However, having an additional domain set as the username and primary SMTP will bypass the authentication, for example if set for single sign-on authentication with multiple domains enabled.

Having an object that is not synchronized with Directory Sync and a cloud object will not use the ADFS environment. Also, if an additional domain was not synchronized with Office 365 and simple in the cloud, that would not use ADFS (SSO), as there is nothing to authenticate against it. Alternatively, the domain that is being synced cannot be used on the objects that are in the cloud, even as an alias. The directory synchronization has essentially locked that domain for use—unless it is within the objects being synchronized.

If you’d like more information on ADFS, or you’re interested in Now Micro’s Microsoft consulting services, please click here.