Recently I encountered an odd authorization error while trying to enable Active Directory Rights Management Services (AD RMS) for an on premise Exchange 2010 server and thought the world might benefit from my experience in resolving the issue.
After completing all the appropriate prerequisites for enabling AD RMS in Exchange, including granting appropriate permissions for the Exchange Servers group on the ServerCertification.asmx file and enabling the AD RMS Super Users functionality using a group containing the appropriate Exchange user, still when I executed the PowerShell command to actually turn on AD RMS for Exchange (Set-IRMConfiguration -InternalLicensingEnabled $True) I received an authorization error:
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 I looked in the event log on the Exchange server for more information, but found nothing useful. I checked the Application and System event logs on the AD RMS server, but again, nothing useful. I enabled debugging on the AD RMS server and attempted the command while reviewing the debug output. Again nothing useful. I thought it might be an issue with integrated authentication (having recently run across an apparent bug with AD RMS and integrated authentication that related to Internet Explorer 9), so I played around with those settings for a bit, but nothing there. Finally I found the key that pointed me in the right direction. In the Security (aka audit) event log on the AD RMS server (who spends much time looking at the audit event log?) I found an instance of this for each Set-IRMConfiguration command attempt:
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. What? This message is telling me that my AD RMS server doesn’t like my Exchange server’s machine account username or password. But, the AD RMS server and the Exchange server are joined to the same AD domain and neither is producing event log messages indicating that there is a problem with the machine account or password.
So, I use ADSI Edit to check out the password change history on the Exchange server’s machine account and note that the bad password count for this account is up to three. Clearly it’s the password that’s the issue. I break out the nltest tool and run some commands on the Exchange server to see what’s up. This doesn’t reveal any problems, but I decide to force a machine account password change anyway.
In an elevated command prompt (actually my elevated PowerShell session) on the Exchange server I run:
nltest /sc_change_pwd:example.com
And then I try my Set-IRMConfiguration command again. Et voilà! It works perfectly.
How the Exchange server’s machine account password came to be in a state where AD and the Exchange server itself were apparently both happy with it but AD RMS was not remains a mystery.
