Bonjour,
ce que vous décrivez est un comportement attendu lorsque l’on active l’authentification sélective dans une relation de fiducie inter‑forêts. Dès que cette option est activée, les utilisateurs du domaine apprenant doivent explicitement recevoir le droit « Autorisé à s’authentifier » sur les objets ordinateurs du domaine cible. Sans ce droit, même s’ils disposent des ACL correctes sur les ressources, l’authentification est bloquée en amont.
La méthode correcte pour gérer cela à grande échelle n’est pas de modifier manuellement chaque compte utilisateur, mais d’utiliser des groupes de sécurité. Vous devez créer un groupe global dans le domaine apprenant, y placer les utilisateurs autorisés, puis attribuer à ce groupe le droit « Allowed to Authenticate » sur les ordinateurs ou serveurs du domaine cible. Cela se fait via la console Active Directory Users and Computers (ADUC) ou par PowerShell avec dsacls ou Set-ADComputer. Par exemple, dsacls "CN=Server1,OU=Servers,DC=domain,DC=com" /G domain\GroupName:CA;Allowed to Authenticate permet d’accorder le droit au groupe sur un serveur donné.
Dans les environnements de grande taille, il est recommandé d’automatiser cette délégation avec PowerShell en parcourant les OU contenant les serveurs et en appliquant le droit au groupe autorisé. Cela garantit une gestion centralisée et évite la modification individuelle des ACL utilisateur.
En résumé, le processus correct est de travailler par groupes de sécurité et d’appliquer le droit « Autorisé à s’authentifier » sur les objets ordinateurs du domaine cible, soit via ADUC, soit via PowerShell/dsacls. C’est la méthode supportée et scalable pour maintenir la sécurité tout en respectant l’authentification sélective.
Domic Vo.