TechNet Team Blog Austria

Informationen und News abseits der offiziellen TechNet vom TechNet Team Blog Austria

Office 365 und SharePoint Benutzerprofile

Office 365 und SharePoint Benutzerprofile

  • Comments 4
  • Likes

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.

image_thumb6

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.

image_thumb9

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.

image_thumb37

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.

image_thumb18

Im SharePoint admin center  ist die Benutzerverwaltung in user profiles und dort im Link Manage User Profiles zu finden.

image_thumb27

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.

image_thumb52

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.

image_thumb33

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.

image_thumb41

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.

image_thumb45

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
    image_thumb49
  • 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.

Diagram showing how an on-premises Active Directory uses DirSync to feed profile information to the Office 365 Directory Service, which in turns feeds the SharePoint Online profile

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 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…

image_thumb21

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.

image_thumb24

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.

image

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!

Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment