Office 365 uses Azure Active Directory for storing user information. Since SharePoint and SharePoint Online both have it´s own User Profile Service and User Store it was clear for Microsoft that some of the user properties have to be shared between these two storages.
So Microsoft built a synchronization – or at least an one way transport - between the Azure Active Directory (AAD) user objects and SharePoint Online (SPO) user profiles.
This article shows the actual state in SharePoint Online 2013 and covers the HowTo about this syncing processes.
Why two user storages?
Well, a user profile is the collection of user properties which describe a single user like UserPrincipalName (which is the login in Office 365), FirstName, LastName, WorkPhone and so on.
In Active Directory many user properties are different or simply not existent in SharePoint User Profiles and vice versa.
So the reason is simply historically. Both systems grew and developed. In the cloud world with Office 365 this means that we now have technically two user objects with two different user profiles – but “some properties” are transferred from AAD to SPO…
Many companies use hybrid scenarios to transport their local Active Directory (AD) into the cloud (AAD). This can be done with tools like DirSync or ADFS systems. The benefit is that end users can use their single identity also in Office 365 services like in Exchange, SharePoint and Lync. This is a great solution (which we deploy very often for customers).
In many cases DirSync is an excellent choice because it´s easy to use and doesn´t require a great server infrastructure. With that tool selected objects are copied from the local AD into the cloud AAD (to make it clear: but not vice versa).
If a user changes his password (with the password sync option on) it will be double hashed (which is not recoverable in any way) and copied into the AAD. Depending on the sync schedules this takes some time, but the user can work with his new password in Office 365. The same goes for other user properties changed in AD.
For more information about AD-Syncing see TechNet: Plan for directory synchronization for Office 365.
Playing around with Office 365
So let´s have a look into the user properties on each side. If you don´t have a Office 365 account for playing with, simply open a new free 30-day Office 365 tenant. Once this is done, use this tenant.
Now login as an administrator on the Office 365 portal and open browser tabs for the Office 365 users and the SharePoint users. Create some test users on the Office 365 side.
What is synchronized between AAD and SPO?
You can switch between the product admin site. This screenshot shows the Office 365 admin center with the menu for switching between the admin portals for each product.
In the SharePoint admin center open the user profiles and select Manage User Profiles.
The User Profile Manager follows and shows an empty list where you can search for specific users.
Search for any user and choose Edit My Profile. You can see the user account name in the form “i:firstname.lastname@example.org”.
Hint: It can take some minutes for all users to be available in SharePoint User Profiles…!
The SPO Account name
If your´re interested in the parts of the Account name…
This is the whole login name. SharePoint (since 2010) uses Claims Based Authentication. The table shows the meaning of the codes.
|i:||is the claim identity, the “i” stands for "identity" claim|
|0||reserved for future claim types|
|#.||is the claim type (# stands for Logon, 5 for e-mail, – for role, + for group, % for farm and ! for identity provider)|
|f||is the issuer code of the token (w = windows, s = local STS, m = membership, r = role, t = trusted STS, p = personal, c = claim provider, f = forms)|
|membership|m.smith…||is the claim value starting with the name of the issuer followed by the login name|
SPO works with the full account names.
Edit the user profile
Have you ever noticed the little icons on the left of the field names like Account name, First Name, Last name, etc.? At some fields these icons are missing, like Job Title, Department, About me, etc.
Those icons are the indicators which fields are copied from AAD to SPO!
So properties like Job Title, Department, About me are only visible in SPO and not coming from AAD.
It can take a while till all properties from AAD are visible in SPO user profile… see below.
Of course there are also user properties in Exchange. But you can´t see them in AAD or SPO.
There are common properties like UPN, FirstName, LastName, etc. Custom attributes are only visible within Exchange. The common properties are the same in AAD and Exchange, f.e. see this screenshot with some fields from the Office 365 user profile:
Profile change in SPO
Editing an user profile in SPO can happen in three ways:
- The admin uses the User Profile Manager and edits user properties as above:
- The user logs in and changes his properties:
- With an app (formerly known as program…). We´ll do that in the second part, but we need an Administrator to accomplish that for other users.
The direction of SPO syncing
As mentioned above: The “sync” process is a one way direction: From AAD to SPO.
This happens automatically in Office 365.
Here comes the complete picture for the syncing with DirSync from AD to AAD (and to SPO).
Picture Source and technical article see Manage SharePoint Online user profiles from the SharePoint admin center.
Can I start the synchronization and how often does it happen?
No. In Office 365 you cannot manually start the sync process between AAD and SPO.
This happens … sometimes. Microsoft isn´t very clear about that, they only state:
“SharePoint Online receives profile information from the Office 365 directory service during regularly scheduled one-way synchronization—which should occur at least every 24 hours.”
And: “Note: Automatic profile synchronization with the Office 365 directory service occurs at regular predetermined intervals. Changes may take up to 24 hours before they appear in a user’s profile.”
So you are dependant on that to happen. My personal experience goes from about 15 minutes after creating a user object in Office 365 to show up in SPO user profiles up to some hours.
If the syncing does not happen after 24 hours that´s … bad luck. See Issue with profile Sync in SharePoint online and open a case with Microsoft to fix that.
Which user properties are synced?
Kindly Microsoft delivers a list of the properties which are synced from AAD to SPO:
TechNet: Default user profile property mappings in SharePoint Server 2013
Here´s the list of the 21 properties with their names on each side when using Microsoft Active Directory.
|User profile property (SPO)||AD DS attribute (AAD)|
|SPS-ClaimID||<specific to connection>|
|SPS-ClaimProviderID||<specific to connection>|
|SPS-ClaimProviderType||<specific to connection>|
With other Directory systems (Novell, Tivoli, etc.) the mapping changes and there are much lesser properties. See the whole article here.
Which user properties are available in SPO user profiles?
It´s also interesting which user properties are available in SPO. Here´s the list of the 60 user properties inclusive data type taken from TechNet: Default user profile properties (SharePoint Server 2010):
|Use profile property||Display name||User profile service data type|
|ADGuid||Active Directory Id||binary|
|CellPhone||Mobile phone||string (single-value)|
|FirstName||First name||string (single-value)|
|HomePhone||Home phone||string (single-value|
|LastName||Last name||string (single-value)|
|PublicSiteRedirect||Public site redirect||URL|
|QuickLinks||Quick links||string (single-value)|
|SPS-Birthday||Birthday||date no year|
|SPS-ClaimID||Claim User Identifier||string (single-value)|
|SPS-ClaimProviderID||Claim Provider Identifier||string (single-value)|
|SPS-ClaimProviderType||Claim Provider Type||string (single-value)|
|SPS-DataSource||Data source||string (single-value)|
|SPS-DistinguishedName||Distinguished Name||string (single-value)|
|SPS-DontSuggestList||Don't Suggest List||Person|
|SPS-JobTitle||Job Title||string (single-value)|
|SPS-LastColleagueAdded||Last Colleague Added||date|
|SPS-LastKeywordAdded||Last Keyword Added||date|
|SPS-Location||Office Location||string (single-value)|
|SPS-MySiteUpgrade||My Site Upgrade||boolean|
|SPS-ObjectExists||Object Exists||string (single-value)|
|SPS-OWAUrl||Outlook Web Access URL||URL|
|SPS-PastProjects||Past projects||string (multi-value)|
|SPS-PhoneticDisplayName||Phonetic Display Name||string (single-value)|
|SPS-PhoneticFirstName||Phonetic First Name||string (single-value)|
|SPS-PhoneticLastName||Phonetic Last Name||string (single-value)|
|SPS-ProxyAddresses||Proxy addresses||string (multi-value)|
|SPS-ResourceSID||Resource Forest SID||binary|
|SPS-Responsibility||Ask Me About||string (multi-value)|
|SPS-SavedAccountName||Saved Account Name||string (single-value)|
|SPS-SipAddress||SIP Address||string (single-value)|
|SPS-SourceObjectDN||Source Object Distinguished Name||string (multi-value)|
|SPS-StatusNotes||Status Message||string (single-value)|
|SPS-TimeZone||Time Zone||time zone|
|UserName||User name||string (single-value)|
|WorkPhone||Work phone||string (single-value)|
I haven´t found the same list for SPO 2013, but it seems the properties are the same.
This list is important when setting values with an app (which we do later).
By the way: If you define security groups in AAD (f.e. with users as members)…
…you can of course use theses security groups in SharePoint (f.e. as members of a portal site) with the people picker. SPO knows the security groups (and of course the users).
This is also a best practice for defining security settings in SPO.
Why is this important?
Knowing how the synchronization happens helps for building scenarios with user information like f.i. business units, locations, department or similar important user data for SPO or Apps using AAD or SPO user profiles.
Since some user properties are automatically synced company specific user information should be put into these synced fields - even if their names maybe are not fitting perfectly, but that´s the “built-in way” without any apps doing sync-work.
So that´s what we often recommend because this is simple to configure in your own DirSync.
Here are some samples for mapping user information into existing fields:
|User Information||AD property||SPO user property|
With DirSync the field mapping can be done individually, f.i. AD field “extensionAttribute1” can be mapped to AAD field “manager” and so on. Between AAD and SPO user profiles you cannot configure any mappings.
Of course the AAD and the SPO user profile information can be written from an individual app (for SPO user profiles without the step of going thru AAD). That´s covered in part 2.
- SharePoint Online UserProfiles and the story about synchronizing with AAD–Part 1
- SharePoint Online UserProfiles and the story about synchronizing with AAD–Part 2