Kürzlich bin ich auf einen seltsamen Autorisierungsfehler gestoßen, als ich versuchte, Active Directory Rights Management Services (AD RMS) für einen Exchange 2010-Server vor Ort zu aktivieren, und dachte, dass die Welt von meiner Erfahrung bei der Lösung des Problems profitieren könnte.
Nachdem ich alle entsprechenden Voraussetzungen für die Aktivierung von AD RMS in Exchange erfüllt hatte, einschließlich der Gewährung der entsprechenden Berechtigungen für die Gruppe Exchange Servers in der Datei ServerCertification.asmx und der Aktivierung der AD RMS-Superuser-Funktionalität mithilfe einer Gruppe, die den entsprechenden Exchange-Benutzer enthält, erhielt ich dennoch einen Autorisierungsfehler, als ich die PowerShell command ausführte, um AD RMS für Exchange tatsächlich zu aktivieren (Set-IRMConfiguration -InternalLicensingEnabled $True):
Die Anfrage schlug mit dem HTTP-Status 401: Unauthorized fehl. ---> Es konnten keine Server-Informationen von https://rms.example.com/_wmcs/certification/server.asmx abgerufen werden.
+ CategoryInfo : InvalidOperation: (:) [Set-IRMConfiguration], Exception
+ FullyQualifiedErrorId : F08D1A6C,Microsoft.Exchange.Management.RightsManagement.SetIRMConfiguration
Ich habe im Ereignisprotokoll auf dem Exchange-Server nach weiteren Informationen gesucht, aber nichts Brauchbares gefunden. Ich überprüfte die Anwendungs- und Systemereignisprotokolle auf dem AD RMS-Server, aber auch hier fand ich nichts Brauchbares. Ich aktivierte das Debugging auf dem AD RMS-Server und versuchte, die command zu öffnen, während ich die Debug-Ausgabe überprüfte. Wieder nichts Brauchbares. Ich dachte, es könnte sich um ein Problem mit der integrierten Authentifizierung handeln (nachdem ich vor kurzem auf einen offensichtlichen Fehler mit AD RMS und der integrierten Authentifizierung gestoßen war, der sich auf Internet Explorer 9 bezog), also spielte ich ein wenig mit diesen Einstellungen herum, aber auch hier nichts. Schließlich fand ich den Schlüssel, der mich in die richtige Richtung wies. Im Sicherheitsprotokoll (auch bekannt als Audit-Ereignisprotokoll) des AD RMS-Servers (wer verbringt schon viel Zeit damit, sich das Audit-Ereignisprotokoll anzusehen?) fand ich eine Instanz dieser Meldung für jeden Set-IRMConfiguration command Versuch:
Log Name: Sicherheit
Quelle: Microsoft-Windows-Security-Auditing
Datum: 4/29/2013 10:26:18 AM
Ereignis-ID: 4625
Aufgabenkategorie: Anmeldung
Ebene: Informationen
Schlüsselwörter: Audit-Fehlschlag
Benutzer: N/A
Rechner: rms.beispiel.de
Beschreibung:
Ein Konto konnte sich nicht anmelden.
Thema:
Sicherheits-ID: NULL SID
Kontoname: -
Kontodomäne: -
Anmelde-ID: 0x0
Anmeldeart: 3
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: EXCHANGE$
Kontodomäne: EXAMPLE
Fehlerinformationen:
Fehlerursache: Unbekannter Benutzername oder falsches Passwort.
Status: 0xc000006d
Unter-Status: 0xc000006a
Prozess-Informationen:
Prozess-ID des Aufrufers: 0x0
Name des aufrufenden Prozesses: -
Netzwerk-Informationen:
Name der Arbeitsstation: EXCHANGE
Quell-Netzwerkadresse: 10.9.8.5
Quell-Port: 30957
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: NtLmSsp
Authentifizierungspaket: NTLM
Durchgeleitete Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
Dieses Ereignis wird erzeugt, wenn eine Anmeldeanforderung fehlschlägt. Es wird auf dem Computer erzeugt, auf dem
Zugriff versucht wurde.
Die Betreff-Felder geben das Konto auf dem lokalen System an, das die Anmeldung angefordert hat.
In der Regel ist dies ein Dienst wie der Serverdienst oder ein lokaler Prozess wie
Winlogon.exe oder Services.exe.
Das Feld Anmeldetyp gibt die Art der Anmeldung an, die angefordert wurde. Die gebräuchlichsten Typen
sind 2 (interaktiv) und 3 (Netzwerk).
Die Felder Prozessinformationen geben an, welches Konto und welcher Prozess im System die Anmeldung
die Anmeldung.
Die Felder "Netzwerkinformationen" zeigen an, von wo aus eine Fernanmeldung angefordert wurde.
Der Name der Arbeitsstation ist nicht immer verfügbar und kann in einigen Fällen leer bleiben.
Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen über diese spezielle
Anmeldeanforderung.
- Die Felder Transited Services zeigen an, welche Zwischendienste an dieser
dieser Anmeldeanforderung beteiligt waren.
- Paketname gibt an, welches Unterprotokoll unter den NTLM-Protokollen verwendet wurde.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Dieser Wert ist 0
wenn kein Sitzungsschlüssel angefordert wurde.
Was bedeutet das? Diese Meldung besagt, dass mein AD RMS-Server den Benutzernamen oder das Kennwort des Maschinenkontos meines Exchange-Servers nicht mag. Der AD RMS-Server und der Exchange-Server sind jedoch mit derselben AD-Domäne verbunden, und keiner der beiden erzeugt Ereignisprotokollmeldungen, die darauf hinweisen, dass es ein Problem mit dem Maschinenkonto oder dem Kennwort gibt.
Ich verwende also ADSI Edit, um den Verlauf der Kennwortänderungen auf dem Maschinenkonto des Exchange-Servers zu überprüfen, und stelle fest, dass die Anzahl der falschen Kennwörter für dieses Konto auf drei gestiegen ist. Das Problem liegt also eindeutig beim Passwort. Ich hole das nltest-Tool heraus und führe einige Befehle auf dem Exchange-Server aus, um zu sehen, was los ist. Dabei werden keine Probleme festgestellt, aber ich beschließe, das Kennwort für das Maschinenkonto trotzdem zu ändern.
In einer erweiterten Eingabeaufforderung command (eigentlich meine erweiterte PowerShell-Sitzung) auf dem Exchange-Server führe ich aus:
nltest /sc_change_pwd:beispiel.de
Und dann versuche ich mein Set-IRMConfiguration command erneut. Und voilà! Es funktioniert perfekt.
Wie es dazu kam, dass das Kennwort für das Maschinenkonto des Exchange-Servers in einem Zustand war, in dem AD und der Exchange-Server selbst anscheinend damit zufrieden waren, AD RMS aber nicht, bleibt ein Rätsel.
