J'ai récemment rencontré une étrange erreur d'autorisation en essayant d'activer les services de gestion des droits d'Active Directory (AD RMS) pour un serveur Exchange 2010 sur site et j'ai pensé que le monde entier pourrait bénéficier de mon expérience dans la résolution du problème.
Après avoir rempli toutes les conditions préalables appropriées pour activer AD RMS dans Exchange, y compris l'octroi des autorisations appropriées pour le groupe Exchange Servers sur le fichier ServerCertification.asmx et l'activation de la fonctionnalité AD RMS Super Users à l'aide d'un groupe contenant l'utilisateur Exchange approprié, lorsque j'ai exécuté le PowerShell command pour activer AD RMS pour Exchange (Set-IRMConfiguration -InternalLicensingEnabled $True), j'ai reçu une erreur d'autorisation :
La demande a échoué avec le statut HTTP 401 : Non autorisé. ---> Échec de l'obtention des informations sur le serveur à partir de https://rms.example.com/_wmcs/certification/server.asmx.
+ CategoryInfo : InvalidOperation : ( :) [Set-IRMConfiguration], Exception
+ FullyQualifiedErrorId : F08D1A6C,Microsoft.Exchange.Management.RightsManagement.SetIRMConfiguration
J'ai consulté le journal des événements du serveur Exchange pour obtenir plus d'informations, mais je n'ai rien trouvé d'utile. J'ai vérifié les journaux des événements de l'application et du système sur le serveur AD RMS, mais là encore, rien d'utile. J'ai activé le débogage sur le serveur AD RMS et j'ai tenté d'accéder au site command tout en examinant la sortie du débogage. Là encore, rien d'utile. J'ai pensé qu'il pouvait s'agir d'un problème d'authentification intégrée (ayant récemment rencontré un bogue apparent avec AD RMS et l'authentification intégrée lié à Internet Explorer 9), j'ai donc joué un peu avec ces paramètres, mais rien n'a été fait. J'ai donc joué un peu avec ces paramètres, mais rien n'y faisait. Finalement, j'ai trouvé la clé qui m'a mis sur la bonne voie. Dans le journal des événements de sécurité (ou d'audit) du serveur AD RMS (qui passe beaucoup de temps à regarder le journal des événements d'audit ?), j'ai trouvé une instance de ceci pour chaque tentative de Set-IRMConfiguration command :
Nom du journal : Sécurité
Source : Microsoft-Windows-Security-Auditing
Date : 4/29/2013 10:26:18 AM
ID de l'événement : 4625
Catégorie de tâche : Connexion
Level (Niveau) : Information
Mots clés : Échec de l'audit
Utilisateur : N/A
Ordinateur : rms.example.com
Description :
Un compte n'a pas réussi à se connecter.
Sujet :
Identifiant de sécurité : NULL SID
Nom du compte : -
Domaine du compte : -
ID de connexion : 0x0
Type de connexion : 3
Compte pour lequel la connexion a échoué :
ID de sécurité : NULL SID
Nom du compte : EXCHANGE$
Domaine du compte : EXAMPLE
Informations sur l'échec :
Raison de l'échec : nom d'utilisateur inconnu ou mauvais mot de passe.
État : 0xc000006d
Sous-état : 0xc000006a
Informations sur le processus :
ID du processus appelant : 0x0
Nom du processus appelant : -
Informations sur le réseau :
Nom du poste de travail : EXCHANGE
Adresse du réseau source : 10.9.8.5
Port source : 30957
Informations détaillées sur l'authentification :
Processus de connexion : NtLmSsp
Paquet d'authentification : NTLM
Services transférés : -
Nom du paquet (NTLM uniquement) : -
Longueur de la clé : 0
Cet événement est généré lorsqu'une demande de connexion échoue. Il est généré sur l'ordinateur où l'accès a été tenté.
l'accès a été tenté.
Les champs Subject indiquent le compte du système local qui a demandé l'ouverture de session.
Il s'agit le plus souvent d'un service tel que le service Serveur, ou d'un processus local tel que
Winlogon.exe ou Services.exe.
Le champ Type de connexion indique le type de connexion demandé. Les types les plus courants
sont 2 (interactif) et 3 (réseau).
Les champs Informations sur le processus indiquent le compte et le processus du système qui a demandé la connexion.
la connexion.
Les champs d'information sur le réseau indiquent l'origine de la demande de connexion à distance.
Le nom du poste de travail n'est pas toujours disponible et peut être laissé vide dans certains cas.
Les champs d'informations sur l'authentification fournissent des informations détaillées sur cette demande de connexion spécifique.
spécifique.
- Les services transmis indiquent les services intermédiaires qui ont participé à cette demande de connexion.
à cette demande de connexion.
- Le nom du paquet indique le sous-protocole utilisé parmi les protocoles NTLM.
- Key length (longueur de la clé) indique la longueur de la clé de session générée. Cette valeur sera 0
si aucune clé de session n'a été demandée.
Qu'est-ce que c'est ? Ce message me dit que mon serveur AD RMS n'aime pas le nom d'utilisateur ou le mot de passe du compte machine de mon serveur Exchange. Mais le serveur AD RMS et le serveur Exchange sont reliés au même domaine AD et aucun des deux ne produit de messages de journal d'événements indiquant qu'il y a un problème avec le compte de machine ou le mot de passe.
J'utilise donc ADSI Edit pour vérifier l'historique des changements de mot de passe sur le compte machine du serveur Exchange et je constate que le nombre de mauvais mots de passe pour ce compte s'élève à trois. Il est clair que c'est le mot de passe qui pose problème. Je sors l'outil nltest et lance quelques commandes sur le serveur Exchange pour voir ce qu'il en est. Cela ne révèle aucun problème, mais je décide tout de même de forcer le changement de mot de passe du compte machine.
Dans une invite élevée command (en fait ma session PowerShell élevée) sur le serveur Exchange que j'exécute :
nltest /sc_change_pwd:example.com
Puis je réessaie mon Set-IRMConfiguration command . Et voilà ! Cela fonctionne parfaitement.
La façon dont le mot de passe du compte machine du serveur Exchange s'est retrouvé dans un état où AD et le serveur Exchange lui-même étaient apparemment satisfaits, mais où AD RMS ne l'était pas, reste un mystère.
