Als kleiner Gastkommentar darf ich heute mal über das Thema DirSync bloggen. Nachdem mich vor kurzem bei einem Kunden das Problem ereilt hat, will ich das mal mit dem Rest der Welt teilen.
Man stelle sich vor, Martina Grom hat einen Kunden davon überzeugt dass er unbedingt Office 365 braucht und dafür natürlich DirSync und ADFS für Single Sign on. Sonst macht das ganze ja keinen Spass. Jetzt wird das brav alles supa installiert und nach ca. 1-2 Wochen hört DirSync einfach auf zu funktionieren. Der Service liefert einen Logonfehler beim Starten. Wie jeder weiss wird beim Setup von DirSync ein “Enterprise Admin” als Service Account angegeben um alle notwendigen Informationen syncen zu können. Dummerweise wird dieser Account aber nicht verwendet um auch den Service zu betreiben. Es wird nämlich ein lokaler Serviceaccount angelegt der mit dem Recht “Logon as a Service” ausgestattet wird.
Jetzt gibts mit dem Serviceaccount ein simples Problem. Es ist ein lokaler Account und manche Kunden steuern ihre “Logon as a Service” Rechte per Policy auf Domain level. Warum? Naja – für unterschiedliche Software Verteilungstools oder auch Monitoring Tools kann es Sinnvoll sein einen Account dieses Recht für alle Server zu geben.
Jetzt steht man vor dem Dilemma. Nach dem Restart startet der Service nicht mehr, weil der Serviceaccount durch die Policy weggeworfen wurde. Den lokalen Account in eine DomainPolicy zu geben ist zwar grundsätzlich möglich (über Umwege und sehr hässlich) macht aber auch kein schönes Bild. Warum dann also nicht einfach den lokalen Serviceaccount durch einen Domainaccount tauschen? Naja – weils da ein paar Dinge zu beachten gibt die ich heute erzählen will:
Fangen wir an:
Services Stoppen
Folgende beiden Services müssen gestoppt werden:
- - “Forefront Identity Manager Synchronization Service”
- - “Windows Azure Active Directory Sync Service”
Lokale Berechtigungen
Der Serviceaccount benötigt “Logon as a Service“ Rechte auf dem lokalen Server.
SQL Service Berechtigungen
In der lokalen SQL Instanz genannt „MSONLINE“ gibt es eine Datenbank auf die der Serviceaccount als DBO definiert werden muss. Leider ist per Default kein SQL Management Studio installiert. Das SQL Management Studio Express (Free!) kann unter folgendem Link heruntergeladen werden:
http://www.microsoft.com/en-us/download/details.aspx?id=29062
(Filename: ENU\x64\SQLManagementStudio_x64_ENU.exe)
Nach der Installation einfach das Management Studio aufrufen und auf die Lokale MSONLINE Instanze verbinden: (<Hostname>\MSONLINE)
Danach wird der neue ServiceAccount als Login angelegt und auf die FIMSynchronizationService Datenbank als DB_Owner berechtigt.
Encryption Keys
Die Passwörter des FIM sind verschlüsselt mit den Credentials des alten Service Accounts. Damit ergibt sich das Problem das wir diese Encryption Keys nicht recovern können da wir das Passwort des original Serviceaccounts nicht kennen. Damit der Service aber funktioniert müssen diese mit dem zukünftigen Service Account verschlüsselt werden. Das Tool dafür ist unter folgenden Pfad zu finden:
“C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\Bin\miiskmu.exe”
Nach Aufruf muss die option “Abandon key set (requires service to be stopped)“ ausgewählt werden.
Eintragen des neuen Service Accounts damit dieser für die Verschlüsselung verwendet werden kann.
Das generierte Key set wird danach exportiert und in einem File gespeichert. Der FIM Service wird danach automatisch gestartet um neue Keys zu generieren.
MIIS Client Rechte
Nachdem die Encryption Keys sämtliche Passwörter geschützt haben und durch den wechsel verloren gegangen sind, muss man alle notwendigen Passwörter neu eintragen. Dafür den MIIS Client aufrufen unter:
„C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe“
Dort ist im Bereich der Management Agents der ServiceAccount für den Directory Access einzutragen. Falls noch unbekannt – Passwort einfach resetten (Der User liegt im BuiltIn Container der Domain) und hier eintragen.
Zweiter Step ist auf dem TargetWebService und der ServiceAccount für den Access für die Office 365 Wolke. Auch hier ist das Passwort entsprechend nachzutragen und falls unbekannt zu resetten.
Damit sollte alles notwendige getan sein damit die Synchronisation wieder funktioniert. Abschliessend einfach eine Powershell aufrufen das PS Snapin laden und die Synchronisation anstossen.
PS C:\>
PS C:\> Add-PSSnapin Coexistence-Configuration
PS C:\> Start-OnlineCoexistenceSync
PS C:\>
Im MIIS Client kann dies entsprechend kontrolliert werden:
Dort sollten die Synchronisation Status auf Success stehen.
Damit – viel Spass damit und bei Fragen gern jederzeit her damit!
LG Christoph
Source: https://blog.atwork.at/post/DirSync-Serviceaccount-tauschen