Echec relation d'approbation + SID History non géré

[rthomas]

Bonjour,
Je souhaite mettre en place une relation d'approbation entre 2 forêts et j'ai une erreur à la création pour laquelle je ne trouve aucune info de débogage.

Contexte (Windows Server 2012R2) :
Forêt A.loc/Domaine A.loc relation externe bidirectionnelle avec Forêt B.loc / Domaine B.loc (fonctionne parfaitement, pas de domaines enfants dans les 2 forêts)

Je souhaite créer une relation de forêt entre la Forêt A.loc et la Forêt C.loc. J'ai donc sur le DC du domaine A.loc comme sur celui du Domaine C.loc, au niveau DNS, défini des redirecteurs conditionnels en rapport avec
le domaine cible, de façon à ce que les 2 DCs se voient.

Ennsuite, depuis le DC du domaine A.loc, je suis passé par l'assistant relation d'approbation en spécifiant les éléments suivants :

nom de forêt : c.loc
type : approbation de forêt
direction : bidirectionnelle
sens : ce domaine et le domaine spécifié
nom user /mdp domaine spécifié renseigné
authentification pour toutes les ressources de la forêt (X2)

Résultat : relation d'approbation n'a pu être créée car l'erreur suivante s'est produite : L'opération a échouée. L'erreur était : Impossible de créer un fichier déjà existant.

Je ne sais pas si des fichiers logs donnent plus d'infos maius je n'ai rien trouvé de probant dans l'observateur d'évènement.

[kelux]

Hello,

1. Il y a 3 forêts pour résumer ? A, B et C ?

2.a. Comment ont été installées ces domaines / serveurs ?
2.b. Est ce que les machines ont été clonées ?

3. Quels sont les SIDs des domaines A,B et C ?

La piste : ça sent le clone quelque part où les SIDs sont identiques.

@+

[rthomas]

Bonjour et merci pour ce retour.

Ce sont en effet 3 VMs. Le DC A (prod) est issue d'une installation classique. Les DCs B (prod) et C (Test) sont issus d'un même modèle Vmware (VM Windows Server 2012 R2 en Workgroup avec les dernières MAJ).

J'ai comparé les SIDs et effectivement les SIDs des DCs B et C sont identiques. Dans l'urgence j'ai certainement oublié de demander la génération d'un nouveau SID durant le clonage

Le plus propre est sans doute de recréer la VM, étant au début de ma démarche.

Pour info ma démarche est la suivante :

3 forêts existantes A1,A2,A3 qui migrent vers une forêt B, avec l'utilisation d'ADMT que je n'ai jamais utilisé jusque là. Plutôt que de faire l'essai sur A1 et B qui sont tous deux utilisés en Prod (C héberge déjà notamment des nouveaux comptes users et des partages), je fais l'essai entre A1 et C.

Merci en tout cas de m'avoir aidé sur ce point là, j'aurais dû percuter sur le message "fichier existant".

[kelux]

En effet il est plus sage de repartir from scratch pour la dernière forêt.

@+

[rthomas]

Bonjour,

Ma relation d'approbation est maintenant fonctionnelle ( merci kelux).
J'ai pu mettre en place L'outil ADMT de migration sur un serveur membre du domaine C

Ensuite j'ai utilisé comme cobaye un pc (pc1/user1) authentifié sur le domaine A1 avec accès à des ressources partgés sur le domaine A1.
Avec ADMT j'ai dans l'ordre migré un des groupes dont user1 est membre, ensuite j'ai migré le compte utilisateur user1 ( le compte migré contient bien dans l'attribut SID History son acien SID du domaine A1).

Pour finir j'ai migré le compte d'ordinateur pc1. Un assistant se charge ensuite d'installer un agent le pc1, celui-ci va modifier le rattachement au domaine tout en faisant en sorte que le compte utilisateur retrouve ses petits ( partages,éléments de bureau, fond d'écran, la totale quoi !). Puis le pc redémarre automatiquement.

J'utilise mon compte user1 avec le mot de passe habituel, en spécifiant cependant le domaine de connexion "nom de domaine\user".
L'utilisateur est correctement authentifié. Tous les éléments personnels du compte sont là, j'accède bien aux ressources du nouveau domaine.

Seul problème, et pas des moindres, je récupère un gentil "accès refusé" dès que je tente d'accéder à mes anciens partages réseau.

Dans ce cas de figure 2 paramètres influent sur le comportement de la relation d'approbation et j'avoue ne pas clairement faire la différence entre /quarantine et /enableSidHistory ( gérés depuis la commande netdom). Je pense que c'est l'un de ces paramètres qui pose problème mais les infos que je peux lire à ce sujet sur le net se contredisent parfois.
Je n'ai trouvé par exemple nulle part l'info expliquant quel était le fonctionnement de ces 2 paramètres selon que se trouve dans un relation de forêt ou relation externe.

Merci de votre aide

[rthomas]

Après avoir parcouru plusieurs posts sur le sujet, voici le constat :

Quand je tente d'accéder à une ressource "domaine source" depuis un Pc migré (SID History présent), j'ai un message "accès refusé". Cette erreur est présente dans le journal de sécurité, echec de l'audit evenement 4675 " Des SID ont été filtrés".

Quand je consulte l'état du filtrage SID de ma relation d'approbation ( approbation de forêt) avec la commande suivante :

netdom trust dom_source /domaine:dom_cible /enablesidhistory

j'ai le message suivant : L'historique des SID est désactivé pour cette approbation. L'opération s'est bien déroulée.

Quand j'essaie d'agir sur le paramètre enablesidhistory, le message en retour est le même. La syntaxe utilisée, lancée depuis un invite de commande exécuté en tant qu'administrateur, est la suivante :

netdom trust dom_source /domaine:dom_cible /enablesidhistory:Yes /userD:admin_source /passwordD:mdp_admin_source

Le test avec No pour enablesidhistory renvoie également le même message.

Je précise enfin que j'ai fait cette commande depuis le DC du domaine source.