Existant

Considérez le cas suivant :

Vous gérez un domaine Français appelé france.pm.net et un autre domaine (même forêt ou via trust de forêt) appelé japon.pn.net.
Vous disposez d’un environnement de qualité, sur votre architecture ESX de la mort Hyper-V/SCVMM hyper bien montée et appelée (dommage !) qualité.france.pm.net.

Des relations d’approbations existent entre :

  • Qualité et France
  • France et Japon

Dans le cadre de la recette d’un projet X, des utilisateurs métiers du domaine japon doivent pouvoir accéder à l’environnement de qualité.

Problèmes rencontrés

Sans trop vous poser de question, vous créez un trust entre les domaines Qualité et Japon :



Et là, c’est le drame : les logins, passwords et GPO sont bons. Vous n'avez pas oublié la partie firewall, vous ne vous êtes pas trompé de GMT, l'heure est bonne, tous les ports demandés ont été ouverts, la RSSI n'a pas tiqué... et pourtant l’authentification échoue entre Japon et Qualité. D'ailleurs Si un admin de Japon tente d’ouvrir une console DSA vers Qualité, le seul message obtenu ressemble à ça :

Windows cannot connect to the new domain because:
The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

De nombreux avertissements apparaissent aussi (reproductible lors d’un gpupdate par exemple) de type :

Event Type:      Warning
Event Source:    LSASRV
Event Category:  SPNEGO (Negotiator)
Event ID:        40960
Date:            5/23/2011
Time:            10:13:31 AM
User:            N/A
Computer:        QPMNET01
Description:
The Security System detected an authentication error for the server ldap/JPMNET01.japon.pm.net.  The failure code from authentication protocol Kerberos was "The name or SID of the domain specified is inconsistent with the trust information for that domain.
(0xc000019b)".

Dans le cas d’approbations sélectives (et parfois pas), vous rencontrez aussi des messages de type :

Logon Failure: The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.

Les relations d’approbation (ou trusts) de forêt intègrent un concept intéressant (pensez Kerberos) de routage de suffixes (Name Suffixe Routing). Il s’agit de l’onglet dans les propriétés de trust que l’on va le plus rarement voir

Lorsqu’un trust est créé, une route de suffixe de nom correspondante est ajoutée dynamiquement de chaque côté de la relation. Celle-ci est créée sous la forme *.nom_de_la_forêt. L’intérêt de ce procédé est de permettre une circulation dynamique et transparente des authentifications entre les forêts.

Dans notre cas et du fait de l’historique, une route appelée *.france.pm.net a été créée en même temps que l’approbation France ßà japon. Ainsi, lorsqu’un utilisateur cherche à s’authentifier et que son compte n’existe pas dans le domaine local, la route est utilisée pour diriger le processus d’authentification vers le domaine racine de la forêt adéquate

Dans la plupart des environnements ce fonctionnement est valable par défaut et ne pose pas de problème, sauf que notre cas évidemment :)

Correction du problème

Dans le cas où deux forêts résident dans le même espace de nom DNS et que la racine de l’arborescence dns (dans notre cas France.pm.net, mais les conséquences seraient identiques / pires si le domaine AD racine s’appelait pm.net), il est nécessaire de configurer ce fameux onglet Name Suffix Routing afin que le trafic d’authentification soit redirigé vers la bonne forêt.

Pour se faire, des exclusions sont à ajouter, un peu de la même manière que les délégations conditionnelles sous DNS.

Dans notre cas, le but est de spécifier à la forêt japon de ne pas router le trafic vers France.pm.net lorsque l’on veut atteindre qualite.france.pm.net, c’est donc sur un DC japonais que l’on va créer les exceptions.

Pour se faire, dans l’onglet Name Suffix Routing, sélectionner la route créée puis faire Edit.
Ajouter ensuite le suffixe de nom complet à exclure du routage vers France.pm.net. Dans notre cas donc qualite.fr.pm.net

Et voilà ! Plus de warning ou d’erreur, plein de GPO / GPP qui s’appliquent. Ça vaut bien un café non ?

Et pour les curieux qui souhaiteraient aller plus loin dans le fonctionnement du mécanisme, rendez-vous sur Technet