Windows Configuration de la connexion unique pour les clients Web dans plusieurs domaines Active Directory

Si votre environnement Windows inclut plusieurs domaines Active Directory, vous pouvez configurer la connexion unique Windows pour les clients Web afin qu'elle fonctionne dans plusieurs domaines. Il existe des critères et des recommandations supplémentaires pour cette configuration.

Critères d'accréditation Active Directory

Pourquoi et quand exécuter cette tâche

L'administrateur Windows doit utiliser le composant logiciel enfichable Domaines et approbations Active Directory pour configurer des relations d'accréditation au niveau des forêts entre les domaines. Les relations d'accréditation externes ne prennent pas en charge l'authentification Kerberos et ne peuvent pas être utilisées. Consultez la documentation de Microsoft pour obtenir des informations sur la configuration des relations d'accréditation.

Notez qu'un domaine parent accrédite implicitement un domaine enfant afin qu'aucune configuration d'accréditation ne soit requise entre les deux. Un domaine enfant est un domaine qui se situe un niveau en dessous d'un autre domaine dans la hiérarchie DNS. Par exemple, ventes.est.audimatique.com est un enfant de est.audimatique.com.

Les types d'accréditation de forêt pris en charges sont les suivants :

  • Accréditation de forêt Windows bidirectionnelle. Par exemple, s'il existe une accréditation bidirectionnelle entre les forêts A et B, leurs utilisateurs des deux forêts peuvent accéder aux serveurs de l'une ou l'autre.
  • Accréditation entrante bidirectionnelle pour une autre forêt. Par exemple, si la forêt A dispose d'une accréditation entrante pour la forêt B, les utilisateurs de la forêt A peuvent accéder aux serveurs de la forêt B. Les utilisateurs de la forêt B ne peuvent pas accéder à la forêt A, sauf si la forêt B dispose aussi de l'accréditation entrante pour la forêt A.
  • Accréditation sortante unidirectionnelle pour une autre forêt. Par exemple, si la forêt A dispose d'une accréditation sortante pour la forêt B, les utilisateurs de la forêt B peuvent accéder aux serveurs de la forêt A. Les utilisateurs de la forêt A ne peuvent pas accéder aux serveurs de la forêt B, sauf si la forêt B dispose aussi de l'accréditation sortante pour la forêt A.
  • Accréditation transitive. Si les utilisateurs de la forêt A peuvent accéder aux serveurs de la forêt B grâce à une accréditation, les utilisateurs d'un domaine enfant de la forêt A peuvent accéder aux serveurs de la forêt B si l'accréditation entre les forêts A et B est configurée en tant qu'accréditation transitive.

Pour savoir si des relations d'accréditation ont été établies pour vos domaines Active Directory :

Procédure

  1. Ouvrez l'utilitaire Domaines et approbations Active Directory dans le menu Outils d'administration.
  2. Cliquez avec le bouton droit de la souris sur votre domaine et sélectionnez Propriétés.
  3. Cliquez sur l'onglet Accréditation pour consulter la liste des domaines accrédités.

Synchronisation de l'horloge de l'ordinateur

Pourquoi et quand exécuter cette tâche

Les horloges des serveurs au sein des domaines et d'un domaine à l'autre doivent être aussi synchronisées que possible, car Kerberos (le mécanisme de sécurité sous-jacent de la connexion unique Windows pour les clients Web) est sensible à leur dérèglement. Corrigez ces dérèglements chaque fois que cela est possible. Si nécessaire, l'administrateur Windows peut exécuter les étapes suivantes pour augmenter la tolérance au dérèglement de l'horloge :

Procédure

  1. Ouvrez la console Gestion des stratégies de groupe (par exemple, sous Windows Server 2008, cliquez sur Démarrer > Exécuter, saisissez gpmc.msc et cliquez sur OK).
  2. Dans l'arborescence de la console, recherchez votre domaine et développez l'arborescence.
  3. Développez les objets de stratégie de groupe.
  4. Sous ces objets de stratégie de groupe, cliquez sur la stratégie Domaine par défaut (qui s'affiche ensuite). Dans l'onglet Paramètres de la stratégie Domaine par défaut, cliquez sur Paramètres de sécurité, Stratégies de comptes/Stratégie Kerberos.
  5. Cliquez deux fois sur Tolérance maximale pour la synchronisation de l'horloge de l'ordinateur pour éditer ce paramètre.

Configuration DNS requise

Etant donné que chaque domaine dispose d'une hiérarchie de noms distincte (par exemple, est.audimatique.com et ouest.audimatique.com), l'administrateur réseau doit configurer les zones de recherche DNS directe et inversée qui permettent aux ordinateurs de résoudre les noms d'un autre domaine.

Configuration requise pour le navigateur

Vous devez configurer les navigateurs de telle façon qu'ils autorisent la connexion unique Windows vers chaque domaine de destination Active Directory.

Domino® Configuration requise pour la recherche de noms avec

Chaque serveur Domino® doit pouvoir rechercher des noms Kerberos pour les utilisateurs de n'importe quel domaine Active Directory. Si les noms Kerberos des utilisateurs sont stockés dans plusieurs annuaires Domino®, l'administrateur Domino® doit configurer chaque serveur Domino® de façon à utiliser un catalogue d'annuaires ou une assistance d'annuaire pour rechercher les noms d'utilisateurs dans des annuaires Domino® secondaires. En revanche, si les noms Kerberos des utilisateurs sont résolus par l'assistance d'annuaire vers Active Directory, chaque serveur Domino® peut utiliser l'assistance d'annuaire pour rechercher des noms dans chacun des annuaires actifs dans lesquels les utilisateurs se trouvent.

Recommandation relative à la configuration de la connexion unique

Pourquoi et quand exécuter cette tâche

Une fois que la connexion unique Windows est établie pour un utilisateur, le serveur Domino® renvoie un jeton LTPA correspondant. Planifiez soigneusement le déploiement de la connexion unique, en vérifiant si les serveurs Domino® partagent la même configuration de connexion unique.

Par exemple, si vous définissez la configuration de la connexion unique des serveurs du domaine "est.audimatique.com" de telle façon qu'ils partagent les mêmes clés de connexion unique que les serveurs du domaine "ouest.audimatique.com", un serveur Est peut accepter un jeton LTPA créé par un serveur Ouest. Dans ce cas, les documents relatifs à la configuration de la connexion unique peuvent utiliser un domaine DNS tel que "audimatique.com".

Cependant, si les serveurs Est et Ouest ne partagent pas les mêmes clés de connexion unique, votre connexion unique est inefficace si vous utilisez un domaine DNS tel que "audimatique.com". Dans ce cas, adaptez votre domaine de connexion unique au domaine DNS Windows dans lequel il opère.

Exemple : configuration de connexion unique inefficace

L'exemple suivant illustre l'inefficacité d'un domaine de connexion unique général (audimatique.com) lorsque les serveurs situés sur ouest.audimatique.com et est.audimatique.com ne partagent pas de clés de connexion unique.

Procédure

  1. L'utilisateur s'authentifie sur le serveur dans est.renovations.com à l'aide de la connexion unique Windows. Le serveur Est crée le jeton LTPA de l'utilisateur à l'aide des clés de connexion unique du serveur Est. Le navigateur de l'utilisateur obtient un nouveau jeton LTPA à utiliser avec les domaines DNS de audimatique.com.
  2. L'utilisateur accède au serveur sur ouest.audimatique.com. Le navigateur envoie le jeton LTPA, qui a été configuré de façon à s'appliquer à tous les serveurs de audimatique.com. Le serveur de ouest.audimatique.com essaie de valider le jeton, sans succès, car il ne partage pas les clés de connexion unique avec les serveurs Est.
  3. Le serveur Ouest ne peut pas valider le jeton LTPA existant, il doit donc authentifier l'utilisateur à l'aide de la connexion unique Windows. Le serveur Ouest crée le jeton LTPA de l'utilisateur à l'aide des clés de connexion unique du serveur Ouest. Le navigateur de l'utilisateur obtient un nouveau jeton LTPA à utiliser avec les domaines DNS de audimatique.com. Le navigateur dispose à présent uniquement du jeton LTPA créé par le serveur Ouest, qui remplace le précédent.
  4. L'utilisateur accède à un serveur sur est.audimatique.com. Le navigateur envoie le jeton LTPA, qui a été configuré de façon à s'appliquer à tous les serveurs de audimatique.com. Le serveur Est essaie de valider le jeton, sans succès, car le serveur Ouest l'a créé en utilisant d'autres clés de connexion unique. L'utilisateur doit à nouveau être authentifié sur le serveur Est à l'aide de la connexion unique Windows. Une fois encore, le serveur Est remplace le jeton LTPA existant.

Résultats

Ce cycle qui consiste à utiliser de façon répétée la connexion unique Windows et à remplacer le jeton LTPA est totalement inefficace.

Exemple : configuration de connexion unique efficace

L'exemple suivant illustre comment l'utilisation de domaines de connexion unique personnalisés pour les domaines Windows est plus efficace lorsque les serveurs situés sur ouest.renovations.com et est.renovations.com ne partagent pas de clés de connexion unique.

Procédure

  1. L'utilisateur est authentifié auprès du serveur sur est.renovations.com et obtient le jeton LTPA à utiliser avec les domaines DNS east.renovations.com.
  2. L'utilisateur accède au serveur sur ouest.audimatique.com. Le navigateur n'envoie pas le jeton LTPA, qui est réservé aux serveurs Est.
  3. Le serveur Ouest doit authentifier l'utilisateur à l'aide de la connexion unique Windows. L'utilisateur obtient un second jeton LTPA à utiliser avec les domaines DNS de west.renovations.com.
  4. L'utilisateur accède au serveur sur east.renovations.com. Le navigateur envoie le premier jeton LTPA dont il dispose, qui a été configuré de façon à s'appliquer à tous les serveurs Est. Le serveur Est utilise le jeton LTPA pour identifier l'utilisateur.
  5. L'utilisateur accède au serveur sur west.renovations.com. Le navigateur envoie le second jeton LTPA dont il dispose, qui a été configuré de façon à s'appliquer à tous les serveurs Ouest. Le serveur Ouest utilise le jeton LTPA pour identifier l'utilisateur.