Autorisierungsfehler bei der Aktivierung von AD RMS für Exchange

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):

The request failed with HTTP status 401: Unauthorized. ---> Failed to get Server Info from https://rms.example.com/_wmcs/certification/server.asmx.
    + 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:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          4/29/2013 10:26:18 AM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      rms.example.com
Description:
An account failed to log on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		EXCHANGE$
	Account Domain:		EXAMPLE

Failure Information:
	Failure Reason:		Unknown user name or bad password.
	Status:			0xc000006d
	Sub Status:		0xc000006a

Process Information:
	Caller Process ID:	0x0
	Caller Process Name:	-

Network Information:
	Workstation Name:	EXCHANGE
	Source Network Address:	10.9.8.5
	Source Port:		30957

Detailed Authentication Information:
	Logon Process:		NtLmSsp
	Authentication Package:	NTLM
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where
access was attempted.

The Subject fields indicate the account on the local system which requested the logon.
This is most commonly a service such as the Server service, or a local process such as
Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types
are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested
the logon.

The Network Information fields indicate where a remote logon request originated.
Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific
logon request.
	- Transited services indicate which intermediate services have participated in
          this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0
          if no session key was requested.

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.