Month: February 2015
For those using SharePoint Online, you may have noticed that it does not provide the same home realm discovery that Exchange Online does, with Home Realm discovery meaning the services knows what domain/upn is being used and leveraging that authentication type for the user (Managed/Online versus Federated/ADFS). SharePoint Online support now supports Sign-In Acceleration, which allows SPO to understand whether a browsing user is a Federated user and send to https://login.microsoftonline.com, with a directive that instructs login.microsoftonline.com to then forward the authentication request on to their ADFS deployed endpoint (i.e. https://sts.contoso.com).
Note – To enable this for your Office 365 tenant, please log a support case for this request and they can fulfill your request!
Once auto-acceleration is enabled, the SPO authentication process works as follows:
- The user navigates to https://contoso.sharepoint.com in their web browser.
- SharePoint receives the request and detects that auto-acceleration is enabled for this tenant by leveraging the domain name in the domain.sharepoint.com URL being used to access SPO.
- The user is then sent to login.microsoftonline.com with extra information in the URL (a whr tag). This tag indicates to AAD that it is safe to accelerate the user directly to the ADFS endpoint, login.contoso.com.
- Once there, the user may enter their credentials and sign-in. In the case of domain-joined machines, the user will be signed in immediately based on browser settings for SSO.
This effectively allows SPO to provide home realm discovery and SSO for users, like Exchange Online does today and will make your SPO users much more happy, reducing the authentication prompts and requests for UPNs/Passwords.
For those admins who have been around the Microsoft Cloud Services, such as BPOS and Office 365 2010, you may remember the issue where DirSync takes a user object, takes it’s objectGUID, double-base-64 encodes it and sends to the cloud as a sourceAnchor. This sourceAnchor is used to flag the user as being synchronized by DirSync and managed by an on-premises Active Directory.
For those admins who are or have moved from one Active Directory Forest to another, the objectGUID changes while the online user maintains this old objectGUID/sourceAnchor. SO, what do you do to reconnect the cloud user with the new AD user? You leverage set-msolUser and set their -ImmutableID, which allows DirSync to hard-match (AD objectGUID == sourceAnchor) and take over management of this cloud object. If the sourceAnchor does not exist in the cloud, then DirSync does a soft-match, based on SMTP address(es) and if there is a match, DirSync takes over management. BUT in this particular scenario the sourceAnchor overrides a soft-match approach, which is why the –ImmutableID option must be used.
Steps to Set -ImmutableID
Allowing DirSync, AAD Sync, AAD Connect to Take Over Management
- Move user to new forest
- Take their ObjectGUID, found in Active Directory Users and Computers –> Advanced View –> Attribute Editor tab in user object Properties location OR use ADSIEdit and use this site to convert the “objectGUID” to a “sourceAnchor”, which will then be set to -ImmutableID.
- Use the Get/Set-MSOLUser –ImmutableID command to the converted GUID, done in the step above. Reference to command variables: https://msdn.microsoft.com/en-us/library/azure/dn194136.aspx
- Set-msoluser –Userprincipalname firstname.lastname@example.org–ImmutableID “xxxxxxxxx”
- Launch DirSync/Sync/Connect and allow it hard match on the user in the cloud and now this Office 365 user is under DirSync/Sync/Connect control.