Microsoft Dynamics CRM 2011 | UserGUID, ObjectSID & CRM Zugriff

Error_Message

Heute möchte ich Euch aus der Praxis den Zusammen-hang zwischen UserGUID und ObjectSID des Users erklären.

Hintergrund: Ein User wurde versehentlich komplett aus der Active Directory entfernt und dieses Konto soll wiederhergestellt werden.

Nachdem also im ActiveDirectory das neue Konto für den User angelegt ist, stellt sich heraus, das beim Zugriff auf Microsoft Dynamics CRM 2011 obige Fehlermeldung erscheint.

UA_ADSIEditmsc

Glücklicherweise gibt es Tools, wie ADSIEdit.msc, mit denen Domain-Administratoren an die ObjectSID und ObjectGUID eines Kontos herankommen.

Doch was tun, wenn man dieses Werkzeug nicht zur Verfügung hat?

UA_LDPExeEs gibt noch ldp.exe – ein kleines, aber feines Werkzeug, mit dem sich die ActiveDirectory Objekte einfach auslesen lassen.

Wir benötigen dabei “canonicalName, objectguid und objectsid.

Diese können wir uns für ein oder mehrere Objekte ausgeben lassen. Und glücklicherweise funktioniert bei diesem Werkzeug auch Copy & Paste, denn gerade bei GUIDs und SIDs schleicht sich schnell mal ein Tippfehler ein.

Was tun, wenn Ihr diese Informationen ausgelesen habt?

UA_SELECT_SUBIhr wisst, dass auf Datenbankebene zwei Datenbanken existieren.

Eure Organisationsdatenbank_MSCRM und eine MSCRM_CONFIG.

Wenn Ihr im SQL Management Studio die Abfrage:

SELECT SystemUserId, FullName, DomainName, ActiveDirectoryGuid FROM SystemUserBase WHERE FullName like ‘%Euer Name%

startet, bekommt Ihr in der Spalte ActiveDirectoryGuid eine Ausgabe, die Ihr mit der neuen objectguid abgleichen könnt. Mit einem Update Script könnt Ihr die GUID entsprechend anpassen. Ebenso solltet Ihr den Domain-Namen abgleichen, ob DOMAIN\Username tatsächlich dem korrekten Werten entspricht.

Nachdem Ihr diese Änderungen auf Datenbankebene – zuvor natürlich eine Sicherung anlegen – durchgeführt habt, führt Ihr ein iisreset in einer Eingabeaufforderung mit administrativen Rechten am CRM Server aus.

Anschließend versucht sich der Benutzer am System anzumelden und erhält

Error_Message

erneut diese Fehlermeldung. Ihr prüft, ob der Benutzer eine Rechterolle zugwiesen hat und auch, ob sonstige Einstellungen innerhalb des Benutzerformulars aus der ActiveDirectory “gezogen” wurden.

Doch alles hilft nichts. Eine Anmeldung ist nicht möglich.

Hintergrund: Die SID des Benutzers hat sich ebenfalls geändert. Doch wo hält Microsoft die SID für den User fest?

UA_SQLkomplett

Neben der SystemUserBase-Tabelle in der Organisation_MSCRM Datenbank, gibt es in der MSCRM_CONFIG Datenbank noch zwei Tabellen, auf die wir unseren Blick richten müssen.

Die 1. Tabelle ist SystemUserOrganizations.

Hier finden wir die Verbindung zwischen der CrmUserId und einer UserId.

Die 2. Tabelle ist SystemUserAuthentication.

Hier finden wir die Verbindung zwischen der UserId und der AuthInfo. In dieser Spalte wird die SID mit einem vorangestellten “W:” im Format

W:S-x-x-xx-xxxxxxxxx-xxxxxx-xxxx-xxx

vorgehalten.

Wenn wir auch diese ObjectSID entsprechend der ermittelten SID mit einem Update Script anpassen, stellen wir fest, dass sich der Benutzer im Anschluss auch wieder erfolgreich am CRM anmelden kann.

Anmerkung: Direkte Datenbank-Änderungen sind natürlich nur in absoluten Ausnahmefällen zu empfehlen. Im Zweifel sollte immer der Microsoft Support mit eingeschaltet werden.

 

 

Technorati Tags:

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s