Home » Office 365 » Office 365 Single Sign On Gotchas (Green Field)

Office 365 Single Sign On Gotchas (Green Field)

It is important to understand before reading this article that it is not a guide on how to install ADFS, WAP and AADSync. I hope to be able to do this sometime in the near future. This article bullet points some of the gotchas I have experienced whilst implementing this in a green field deployment.

Scenario: Single AD forest and domain with no on premise Exchange deployment. A single Office 365 tenant has been deployed using a single publically routable domain name. Azure Active Directory Sync server has been deployed to synchronise identities between on premise and 365. ADFS farm with WAP deployed and Office 365 domain federated.

Gotcha #1: When accounts from the on premise Active Directory get synchronised with Office 365 the primary SMTP domain is set to the 365 tenant name of domain.onmicrosoft.com with their UPN address set as an additional SMTP address.

Reason: Normally in Exchange hybrid deployments the on-prem Exchange server policies win and when the accounts are synchronised the correct SMTP suffix is applied. In a green field with no Exchange you must set a couple of attributes on the AD user objects. These are the mail and proxyAddresses attributes.

In Office 365 you cannot assign a federated domain as the default domain in Office 365 or default SMTP domain. This is by design.

The mail attribute should contain the users email address (usually samAccountName@domain.com) in the proxyAddresses attribute this should be set as SMTP:samAccountName@domain.com. It is important to note that all proxy addresses domain suffixes should exist in Office 365 or there may be problems with user sync.

The main attribute for Office 365 is proxyaddresses. The mail attribute is used to aid the end user with Outlook autodiscover setup.

You can use PowerShell to modify the attributes like so:

Set-ADUser -Identity username -EmailAddress samAccountName@domain.com -Add @{proxyAddresses = "SMTP:samAccountName@domain.com"}

Gotcha #2: ADFS service will not start

Reason: This usually happens when the adfs service account does not have the permission to generate security audits.

To resolve this create a group policy and apply it to the ADFS servers only. Modify the following setting:

Computer Configuration/Security Settings/Local Policies/User Rights Assignment/Generate Security Audits

Add the adfs service account to the list. Be sure to also add NETWORK SERVICE and LOCAL SYSTEM accounts in to the list as well.

more to follow soon.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: