Office 365 und SharePoint Benutzerprofile
Microsoft Office 365 verwendet Azure Active Directory um alle Unternehmens-Daten dort zu speichern. Mit einem Office 365 Abonnement besitzt man also automatisch auch ein eigenes Active Directory in der Cloud. Dieses beinhaltet Benutzer, Gruppen, Lizenzen, Metainformationen und vieles mehr. Mit Tools wie DirSync und ADFS können eigene lokale Active Directories (AD) automatisiert in die Cloud kopiert werden.
Aus historischen Gründen besitzt SharePoint (SP) jedoch eigene Benutzer-Informationen und holt diese nicht aus dem lokalen AD bzw. nicht aus dem Azure Active Directory (AAD) sondern aus den eigenen SP-Benutzerprofilen, den SharePoint User Profile Services (die in einer SP-eigenen SQL Datenbank gespeichert werden).
Somit hat Microsoft eine (One-Way) Synchronisation zwischen AAD und dem SP User Profile Service gebaut, damit die wichtigsten Benutzerdaten von AAD in die SharePoint Online (SPO) Benutzerprofile transferiert werden.
Dieser Artikel zeigt die Unterschiede und informiert über den Synchronisations-Vorgang.
Warum zwei Benutzerprofile?
Technisch gesehen ist ein Benutzerprofile eine Sammlung von Eigenschaften (Properties), die einen bestimmten Benutzer beschreiben, wie etwa der UserPrincipalName (welcher für das Login in Office 365 verwendet wird), Vorname, Zuname, Telefonnummer und so weiter.
In Active Directory sind manche Benutzereigenschaften aus den SharePoint User Profiles jedoch nicht vorhanden – und umgekehrt. Somit gleichen sich die beiden Benutzerprofile nicht, sie besitzen nur wenige gleiche und einige ähnliche Eigenschaften.
Wie oben erwähnt liegt die Ursache in der Geschichte der beiden Verzeichnisdienste. Währen das AD seit Windows NT nach und nach erweitert wurde (und immer wichtiger für Identity Management wird), gilt das Gleiche für die SP Benutzerprofile: Sie wurden nach und nach ergänzt.
In der Cloud-Welt von Office 365 bedeutet das, dass wir für SPO mit zwei unterschiedlichen Benutzerprofilen arbeiten müssen. Einige Benutzer-Eigenschaften werden jedoch von AAD nach SPO übertragen. Vielleicht werden die SP Benutzerprofile über kurz oder lang in AAD integriert werden, das würde Sinn machen. Aktuell ist es aber nicht so, es gibt diese beiden Benutzer-Speicherorte.
Going Hybrid
Viele Unternehmen verwenden Hybrid-Szenarien um ihr lokales Active Directory (AD) in die Microsoft Cloud (AAD) zu transportieren. Der Vorteil für Endbenutzer liegt darin, dass sie mit ihrer Unternehmens-Identität auch Office 365 Dienste wie Exchange, SharePoint und Lync verwenden können und Single-Sign-On (SSO) möglich wird.
Als Tools für Hybrid stehen DirSync, ADFS und FIM zur Verfügung. In vielen Fällen ist DirSync eine gute Wahl, weil es einfach zu verwenden ist und keine großartige eigene Server Infrastruktur erfordert.
Damit können bestimmte Objekte und Benutzerinformationen aus dem lokalen AD in die Cloud nach AAD transportiert werden. Somit ist DirSync gerade für KMUs eine tolle Sync-Lösung die wir oft einsetzen.
Dieser Weg ist jedoch eine Einbahnstraße von AD nach AAD.
Informationen aus AAD können umgekehrt nicht in das lokale AD zurückgeschrieben werden.
Mit der Passwort Sync Option wird auch das Benutzerkennwort übertragen. Damit kann sich der User mit seinem gewohnten Kennwort genauso an Cloud-Diensten anmelden wie Ressourcen im eigenen LAN verwenden.
Passwort Sync bedeutet, das bereits im lokalen AD ge-hashte Kennwort wird nochmals gehasht und dieses doppelt gehashte Kennwort wird in die Cloud synchronisiert. Das Kennwort ist also niemals sichtbar und nicht wiederherstellbar – und “noch sicherer” in der Cloud als im eigenen lokalen AD. Beim Login wird das eingegebene Kennwort ebenfalls zweimal ge-hasht und mit dem gespeicherten Kennwort verglichen. Ist es ident, war das Login erfolgreich. Der Benutzer profitiert davon und kann sich mit seinen gewohnten (lokalen) Login und Kennwort anmelden.
Wenn das Kennwort lokal geändert wird, erfolgt die Synchronisation mit DirSync in die Cloud nach nur einer Minute. Änderungen im Benutzerprofil werden im Regelfall alle 3 Stunden übertragen. Mehr Informationen über AD-Sync finden Sie im TechNet: Plan for directory synchronization for Office 365.
Arbeiten mit Office 365
Wenn Sie sich die Unterschiede im Detail ansehen wollen, können Sie ein bestehendes oder ein kostenfreies 30-Tage-Testkonto in Office 365 anlegen. Damit kann dann in Ruhe (mit oder ohne DirSync) getestet werden.
Nach der Anmeldung im Office 365 Portal legt man dort (im AAD) ein paar Testuser und eine SharePoint-Site an.
Was wird zwischen AAD und SPO synchronisiert?
Im Office 365 Portal kann jederzeit im Admin-Menü zwischen den Produktbereichen umgeschaltet werden. Der Screenshot zeigt das Office 365 admin center mit den Menüs für die beiden Bereiche und die Benutzer-Verwaltung.
Im SharePoint admin center ist die Benutzerverwaltung in user profiles und dort im Link Manage User Profiles zu finden.
Hier folgt der User Profile Manager und zeigt eine leere Liste. Wir suchen nun nach einem bestimmten Benutzer und wählen Edit My Profile aus dem Listenmenü. Der Benutzer wird in der Form “i:0#.f|membership|m.smith@o365demo2015.onmicrosoft.com” angezeigt.
Hinweis: Es kann einige Minuten bis zu einigen Stunden dauern, bis alle User aus AAD (Office 365) in den SharePoint User Profilen sichtbar sind (s.u.).
Der SPO Konto-Name
Der Benutzername in SPO besteht aus mehreren Teilen wie hier gezeigt:
i:0#.f|membership|m.smith@o365demo2015.onmicrosoft.com
Dies ist der ganze Login-Name. Seit SharePoint 2010 wird Claims Based Authentication verwendet.
Die Tabelle zeigt die Bedeutung des zerlegten Login-Strings.
| i: | ist die claim identity. “i” steht für "identity Claim” |
| 0 | für zukünftige Claim-Typen reserviert, in SPO dzt. immer 0 |
| #. | ist der Claim-Typ (# für Logon, 5 für E-Mail, – für Rolle, + für Gruppe, % für Farm und ! für Identity Provider) |
| f | ist der Aussteller Code (issuer code) für das Token (w = Windows, s = lokaler STS, m = Membership, r = Role, t = Trusted STS, p = Personal, c = Claim Provider, f = Forms) |
| membership|m.smith… | ist der Claim und beginnt mit dem Namen des Ausstellers gefolgt vom eigentlichen Login Namen |
Wir sehen also SPO arbeitet mit Forms Authentication und benötigt für das Login den vollen Konto-Namen mit all diesen Informationen.
Bearbeiten des SPO-Benutzerkontos
Haben Sie bereits das kleine Icon links von den einzelnen Felder bemerkt? Dies erscheint bei Feldern wie Account name, First Name, Last name, etc.? Umgekehrt fehlen diese Icons bei anderen Feldern wie Job Title, Department, About me, etc.
Diese Icons sind Indikator dafür, welche Felder aus dem AAD nach SPO synchronisiert werden.
Benutzer-Eigenschaften wie Job Title, Department, About me sind somit nur in SPO sichtbar und kommen nicht aus dem AAD. Es kann eine Zeit dauern, bis alle Felder aus AAD in SPO befüllt werden, siehe unten.
Exchange Eigenschaften
Natürlich gibt es auch Benutzer-Eigenschaften in Exchange Online. Diese sind jedoch nicht im AAD oder in den SPO Benutzerprofilen sichtbar.
Auch in Exchange gibt es gemeinsame Eigenschaften wie UPN, FirstName, LastName, etc. Eigene Eigenschaften (“custom Attributes”) sind aber – in den Verwaltungsseiten von Office 365 - nur innerhalb von Exchange Online sichtbar. Die gemeinsamen Eigenschaften in AAD und Exchange sind ident, wie etwa der folgende Screenshot mit einigen Felder aus dem Office 365 Benutzerkonto zeigt.
Benutzerprofil in SPO ändern
Ein Benutzerprofil in SPO kann so geändert werden:
- Der Tenant-Admin verwendet den User Profile Manager und bearbeitet Benutzerprofile wie oben:
https://[tenant]-admin.sharepoint.com/_layouts/15/tenantprofileadmin/ProfMngr.aspx - Der Benutzer selbst ändert seine eigenen Daten in seinem Benutzerprofil:
https://[tenant]-my.sharepoint.com/PersonImmersive.aspx
- Mit einer App (siehe codefest.at)
Die Richtung der SPO Synchronisierung
Wie oben beschrieben funktioniert die Synchronisation als Einbahnstraße: Von AAD nach SPO.
Dieser Vorgang erfolgt in Office 365 automatisch (und muss nicht konfiguriert werden).
Das komplette Abbild zeigt nun den Synchronisationsvorgang aus dem eigenen AD mit DirSync ins AAD und von dort in die SPO User Profiles.
Bildquelle und Beschreibung siehe Manage SharePoint Online user profiles from the SharePoint admin center.
Wann erfolgt die Synchronisation?
In Office 365 kann diese automatische Synchronisation (zwischen AAD und SPO) nicht selbst gestartet oder gesteuert werden, sie passiert ... irgendwann. Microsoft legt sich nicht genau fest (siehe hier), sie schreiben nur sinngemäß, dass die Synchronisation zu mindestens alle 24 Stunden erfolgt.
“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.”. Genauso in “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.”
Somit kann der Sync-Vorgang mal rascher und mal später erfolgen. Meine persönlichen Erfahrungen reichen von etwa 15 Minuten bis zu einigen Stunden, bis Benutzerobjekte und ihre Eigenschaften von Office 365 in SPO auftauchen.
Wenn die Synchronisierung auch nach 24 Stunden und über 2 Tage nicht erfolgt (siehe Issue with profile Sync in SharePoint online) hilft nur einen Case bei Microsoft zu eröffnen, um das zu reparieren.
Welche Benutzer-Eigenschaften werden synchronisiert?
Microsoft liefert im TechNet eine Liste der Benutzer-Eigenschaften, die von AAD nach SPO User Profiles synchronisiert werden: TechNet: Default user profile property mappings in SharePoint Server 2013
Hier ist die Liste der 21 User Properties mit ihren Namen – wenn Microsoft Active Directory verwendet wird.
| User profile property (SPO) | AD DS attribute (AAD) |
| SPS-DistinguishedName | dn |
| SID | objectSid |
| Manager | manager |
| PreferredName | displayName |
| FirstName | givenName |
| LastName | sn |
| SPS-PhoneticDisplayName | msDS-PhoneticDisplayName |
| SPS-PhoneticFirstName | msDS-PhoneticFirstName |
| SPS-PhoneticLastName | msDS-PhoneticLastName |
| WorkPhone | telephoneNumber |
| WorkEmail | Mail/proxyAddress |
| Office | physicalDeliveryOfficeName |
| SPS-JobTitle | title |
| Department | department |
| UserName | sAMAccountName |
| PublicSiteRedirect | wWWHomePage |
| SPS-ProxyAddresses | proxyAddresses |
| SPS-SourceObjectDN | msDS-SourceObjectDN |
| SPS-ClaimID | <specific to connection> |
| SPS-ClaimProviderID | <specific to connection> |
| SPS-ClaimProviderType | <specific to connection> |
In anderen Directory Systemen wie Novell, Tivoli, etc. gibt es weniger User Properties und das Mapping sieht etwas anders aus, da die Feldnamen in den Fremdsystemen anders heißen. Die Beschreibung dafür finden Sie hier.
Welche Benutzer-Eigenschaften sind in den SPO User Profiles vorhanden?
Natürlich ist es genauso wichtig zu wissen, welche User Properties auf der SPO vorhanden sind. Hier ist die Liste der 60 Benutzer-Eigenschaften mit ihren Datentypen aus TechNet: Default user profile properties (SharePoint Server 2010):
| Use profile property | Display name | User profile service data type |
| AboutMe | About me | HTML |
| AccountName | Account name | Person |
| ADGuid | Active Directory Id | binary |
| Assistant | Assistant | Person |
| CellPhone | Mobile phone | string (single-value) |
| Department | Department | string (single-value) |
| Fax | Fax | string (single-value) |
| FirstName | First name | string (single-value) |
| HomePhone | Home phone | string (single-value |
| LastName | Last name | string (single-value) |
| Manager | Manager | Person |
| Office | Office | string (single-value) |
| PersonalSpace | Personal site | URL |
| PictureURL | Picture | URL |
| PreferredName | Name | string (single-value) |
| PublicSiteRedirect | Public site redirect | URL |
| QuickLinks | Quick links | string (single-value) |
| SID | SID | binary |
| 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-DisplayOrder | Display Order | integer |
| SPS-DistinguishedName | Distinguished Name | string (single-value) |
| SPS-DontSuggestList | Don't Suggest List | Person |
| SPS-Dotted-line | Dotted-line Manager | Person |
| SPS-EmailOptin | Email Notifications | integer |
| SPS-HireDate | Hire date | date |
| SPS-Interests | Interests | string (multi-value) |
| 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-MemberOf | MemberOf | string (multi-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-Peers | Peers | string (single-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-SavedSID | Saved SID | binary |
| SPS-School | Schools | string (multi-value) |
| SPS-SipAddress | SIP Address | string (single-value) |
| SPS-Skills | Skills | string (multi-value) |
| SPS-SourceObjectDN | Source Object Distinguished Name | string (multi-value) |
| SPS-StatusNotes | Status Message | string (single-value) |
| SPS-TimeZone | Time Zone | time zone |
| Title | Title | string (single-value) |
| UserName | User name | string (single-value) |
| UserProfile_GUID | Id | unique identifier |
| WebSite | Web site | URL |
| WorkEmail | Work e-mail | |
| 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).
Security Groups
Nicht zu vergessen sind die Sicherheitsgruppen. Diese können im AAD (im Office 365 Portal wie auch im Azure Portal, wenn verbunden) definiert werden und Benutzer als Mitglieder hinzugefügt werden…
Natürlich sind diese Security Groups auch in SharePoint bekannt und können verwendet werden, etwa als Mitglieder einer SPO Site. Der People Picker kennt auch die synchronisierten Security Groups (und natürlich alle User). Das Beispiel zeigt die Sicherheitsgruppe “SharePoint” aus dem synchronisierten AAD in SPO.
Die Verwendung von Security Groups ist auch eine best practice um Zugriffsrechte in einer SPO Site zu setzen. (Bitte NICHT einzelne Benutzer verwenden, das führt nach kurzer Zeit oft zu Problemen mit der Nachvollziehbarkeit und der Sicherheit…)
Warum ist das Alles wichtig?
Das Verständnis für die Details der Benutzer-Synchronization hilft, Lösungen zu entwerfen, wo spezifische Benutzerinformationen wie etwa Business units, locations, department o.ä. in den Office 365 Diensten weiterverwendet werden können, sei es in SPO selbst, in Apps oder in eigenen Systemen, die Daten aus dem AAD verwenden.
Nachdem einige Benutzer-Eigenschaften automatisch zwischen AAD und SPO synchronisiert werden, können Benutzerinformationen, die im Unternehmen wichtig sind, in diese (synchronisierten) Felder gespeichert werden. Selbst wenn die Feldnamen vielleicht nicht perfekt passen, bringt es viele Vorteile, diese zu verwenden, denn schließlich ist das ein bereits “eingebauter” Weg – ganz ohne eigne Apps oder Synchronisierungstools.
Somit ist die Verwendung der vorhandenen Benutzer-Felder auch unsere Empfehlung.
In DirSync können die Mappings (Zuweisungen der Felder) leicht konfiguriert werden.
Beispiele für Mappings
Hier habe ich einige Beispiele für Feld-Mappings in existierende Benutzer-Eigenschaften angeführt:
| User Information | AD property | SPO user property |
| Business unit | division | department |
| Jobrole | title | SPS-JobTitle |
| Shop Number | physicalDeliveryOfficeName | Office |
| Role | manager | Manager |
Bei Verwendung von DirSync können die Felder individuell zugewiesen werden, so kann etwa das AD-Feld “extensionAttribute1” in das AAD Feld “manager” zugewiesen werden usw. Zwischen AAD und SPO können keine eigenen Mappings durchgeführt werden.
Umwege
Natürlich können Benutzer-Eigenschaften auch automatisiert in das AAD und in die SPO User Profiles geschrieben werden – mit eigenen Apps.
Das AAD kann auch umgangen werden. Benutzer-Daten können direkt in die SPO User Profiles geschrieben werden.
Dabei gehen zwar viele Vorteile der zentralen Benutzerverwaltung im eigenen (A)AD verloren, aber in manchen Szenarien kann das Sinn machen, etwa für Benutzerdaten aus einem Fremdsystem wie einer HR-Lösung o.ä. Hierzu finden Sie in Kürze einen eigenen Developer-Artikel in unserem MSDN-Schwesternblog codefest.at wo dieser Vorgang gezeigt wird.
Fazit
Die automatische Benutzer-Synchronisation zwischen AAD und SPO User Profiles ist out-of-the-box in Office 365 vorhanden und kann zum Weiter-Transport von Benutzer-spezifischen Informationen genutzt werden.
Vorhandene Felder können unternehmenswichtige Daten wie Adressen, Telefonnummern, Geschäftsstelle, Kostenstelle und ähnliche Informationen eines Benutzers speichern um diese in SPO (oder Apps) weiter zu verwenden.
Wir sehen, dass die Bedeutung eines zentralen Active Directory Systems für das moderne Identitäts-Management immer wichtiger wird. Beginnen wir, diese Vorteile der (Cloud-) Dienste – gerade im Unternehmens-Umfeld mit den Synchronisationstools - zu nutzen und davon zu profitieren!