web-dev-qa-db-fra.com

Ajoutez de nouveaux serveurs à Server Manager, obtenez l'erreur Kerberos 0x80090322

Je confecte un environnement Windows Lab. Il possède un contrôleur de domaine Win2012R2 (SRV001) et j'aimerais ajouter un autre serveur Win2012R2 au domaine (SRV003). En fait, tout va bien. J'ai donné au nouveau serveur une adresse IP statique dans le même sous-réseau que le DC, l'a signalé sur le serveur DNS droit et ajouté le serveur au domaine.

Toutefois, lorsque j'ajoute le nouveau serveur au gestionnaire de serveur, je reçois une erreur de Kerberos: 0x80090322. J'ai un message d'erreur assez long que je posterai ci-dessous. J'ai fait des tests et j'ai découvert que je suis en mesure de configurer une session de PowerShell distante sur le serveur à l'aide de l'authentification Kerberos:

$s = New-PSSession -ComputerName srv003 -Authentication Kerberos
$s | Enter-PSSession

Aucun problème ici. L'Iran Enable-PSRemoting Sur le serveur distant, pas de problèmes aussi.

Pourquoi le gestionnaire de serveur n'a-t-il pas comme mon nouveau serveur? Surtout car il est possible de configurer un PowerShell distant à l'aide du même gestionnaire de protocole Server se plaint.

Le message d'erreur appartenant au code d'erreur 0x80090322:

Actualisation de la configuration a échoué avec l'erreur suivante: Les métadonnées n'ont pas pu être récupérées à partir du serveur, en raison de l'erreur suivante: WinRM ne peut pas traiter la demande. L'erreur suivante avec Errorcode 0x80090322 s'est produite lors de l'utilisation de Kerberos Authentification: une erreur de sécurité inconnue eu lieu. Les causes possibles sont :

  1. Le nom d'utilisateur ou le mot de passe spécifié sont invalides.
  2. Kerberos est utilisé lorsqu'aucune méthode d'authentification et aucun nom d'utilisateur n'est spécifié.
  3. Kerberos accepte les noms d'utilisateur du domaine, mais pas les noms d'utilisateur locaux.
  4. le nom du capital de service (SPN) pour le nom de l'ordinateur et le port distants n'existe pas.
  5. le client et les ordinateurs distants sont dans différents domaines et il n'y a aucune confiance entre les deux domaines.

Après avoir vérifié les problèmes ci-dessus, essayez ce qui suit :

  1. Vérifiez le visualiseur d'événements pour les événements liés à l'authentification.
  2. Modifiez la méthode d'authentification; Ajoutez l'ordinateur de destination au paramètre de configuration TrustedHosts WinRM ou utilisez le transport HTTPS. Notez que les ordinateurs de la liste TrusteDhosts peuvent ne pas être authentifiés.
  3. Pour plus d'informations sur la configuration WinRM, exécutez la commande suivante: WinRM Aide Config.

Pour repousser les éléments numérotés dans le message d'erreur:

  1. J'utilise un compte administrateur de domaine pour le faire.
  2. Je ne sais pas comment modifier ceci dans le gestionnaire de serveur afin que je suppose que la valeur par défaut devrait le faire.
  3. Je cours dans le domaine, Démarrer le gestionnaire de serveurs en tant qu'administrateur de domaine.
  4. Le serveur a réellement les SPN suivants que je n'ai pas touché:
    1. DFSR-12F9A27C-BF97-4787-9364-D31B6C55EB04/SRV003.RWWWILDEN01.LOCAL
    2. ConditionsRV/SRV003
    3. TERMSRV/SRV003.RWWWILDEN01.LOCAL
    4. WSMAN/SRV003
    5. Wsman/srv003.rwwilden01.Local
    6. Restreintkrbhost/srv003
    7. Hôte/srv003
    8. RestreintKrbhost/srv003.Rwwilden01.Local
    9. Host/srv003.rwwilden01.Local
  5. Les deux ordinateurs sont dans le même domaine.
  6. Aucun événement sur la machine cliente.
  7. Cela ne devrait pas être nécessaire de le faire.
active-directorywindows-server-2012kerberoswindows
6
rwwilden

Ok, je l'ai finalement compris. J'ai pris un autre bon regard sur le journal des événements du serveur distant. Il contenait une erreur avec le texte d'erreur suivant:

le client Kerberos a reçu a krb_ap_err_modified Erreur du serveur SRV003. Le nom de la cible utilisée était http/srv003.rwwilden01.local. Cela indique que le serveur cible a échoué à déchiffrer le billet fourni par le Client. Cela peut se produire lorsque le nom principal du serveur cible (SPN) est enregistré sur un compte autre que le compte utilisé par le service cible. Assurez-vous que la cible SPN n'est enregistrée que sur le compte utilisé par le serveur. Cette erreur peut également se produire Si le mot de passe du compte de service cible est différent de ce qui est configuré sur le centre de distribution de Kerberos pour ce service cible. Assurez-vous que le service sur le serveur et le KDC sont configurés pour utiliser le même mot de passe. Si le nom du serveur n'est pas totalement qualifié. et le domaine cible (rwwilden01.local) est différent du domaine client (Rwwilden01.local), vérifiez s'il y a des comptes de serveur nommés identiques dans ces deux domaines ou utilisez le nom complet pour identifier le serveur.

Il est apparu que j'avais ajouté un compte de service géré une semaine plus tôt avec SPN HTTP/srv003.rwwilden.local. Je ne sais pas pourquoi Server Manager tente d'abord ce nom cible, mais apparemment cela ne fonctionne pas. A du sens puisque ce spn a peu à voir avec le serveur réel.

Après avoir supprimé le compte de service, tout a commencé à travailler comme je l'ai voulu.

5
rwwilden

J'ai eu ce problème il n'y a pas si longtemps, je suis dirigé vers le coupable en utilisant l'outil "SetSpn". J'ai une meilleure compréhension des SPNS en lisant cet article: http://support.microsoft.com/default.aspx?scide=kb ;en-us ;92965

3
Simon L

Avait la même erreur et a essayé de nombreuses solutions différentes. Celui qui a aidé était d'utiliser adresse IPv4 explicite au lieu de nom de domaine.

2
Sergey Mudrov

Cela peut arriver quand il y a duplicate serviceprincipalnames, qui est un scénario valide mais confuse malheureusement WinRM.

Par exemple, envisagez un compte de service 'AppPoolAccount' and Server 'MyWebServer', les deux objets d'Active Directory auront une propriété Serviceprincipalname contenant la même chaîne 'http/mywebserver'. Le servicePrincipipalname sur Mywebebserver sera légèrement différent car ce sera 'http/mwewebebverver: 5985

La présence de (proches) en double servicePrinciPalnames causera l'échec de WinRM avec l'erreur de Kerberos dans la question.

Pour contourner le problème, vous pouvez dire à Invoke-Commandement d'inclure le port lorsqu'il recherche le serviceprincipalname, comme celui-ci:

### Tell WinRM to include the port in the SPN
Invoke-Command -ComputerName myWebServer -ScriptBlock {Get-Process} -SessionOption (New-PSSessionOption -IncludePortInSPN)
0
Craig - MSFT

Dans mon cas, j'ai eu un http/sps enregistré dans un objet appartenant à NON le serveur. Cependant, je n'ai pas pu trouver ce qui le possédait car l'outil SetSpn.exe ne vous montre pas quel conteneur (ou objet) possède le SPN. J'ai utilisé le script PowerShell suivant pour trouver le propriétaire de SPN. Après avoir supprimé le SPN et le recréé avec le serveur en tant que propriétaire (à l'aide de l'outil SetSpn.exe), j'ai attendu 30 minutes pour que tous les DCS se synchronisent, puis cela a fonctionné.

# Source / credit:
# https://social.technet.Microsoft.com/wiki/contents/articles/18996.active-directory-powershell-script-to-list-all-spns-used.aspx

Clear-Host
$Search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$Search.Filter="(servicePrincipalName=*)"

## You can use this to filter for OU's:
## $Results = $Search.FindAll() | ?{ $_.Path -like '*OU=whatever,DC=whatever,DC=whatever*' }
$Results=$Search.FindAll()

foreach($Result in $Results ) {
  $UserEntry=$Result.GetDirectoryEntry()
  Write-Host "Object Name = " $UserEntry.name -BackgroundColor "yellow" -ForegroundColor "black"
  Write-Host "DN      =      "  $UserEntry.distinguishedName
  Write-Host "Object Cat. = "  $UserEntry.objectCategory
  Write-Host "servicePrincipalNames"

  $i=1
  foreach($SPN in $UserEntry.servicePrincipalName ) {
    Write-Host "SPN(" $i ")   =      " $SPN
    $i++
  }

  Write-Host ""
}
0
Slogmeister Extraordinaire