Archives de catégorie : RODC

Le RODC en image (republication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

Read Only Domain Controller, une nouveauté de Windows Server 2008 qui permet de mettre en place un contrôleur de domaine qui présente la particularité de ne pouvoir répliquer de manière unidirectionnelle depuis le site central. Ce mode de fonctionnement permet de réduire les problèmes de réplication dans les architectures complexes et de limiter les informations répliquées vers ce contrôleur de domaine (très utile ce cas de vol!).

Le RODC pour qui?

Le premier scénario de mise en œuvre du RODC, c’est le Branch Office. Pour ces sites distants, on hésitait toujours à positionner un contrôleur de domaine, ne sachant pas si la sécurité serait assurée (qui a dit que le contrôleur de domaine est dans un placard à balais?). Le scénario de déploiement complet serait même RODC + Bitlocker sur un socle Windows Server 2008 Core.

Les limitations

Globalement l’approche est bonne, il faut juste tenir compte d’un certain nombre d’incompatibilités notoires documentées dans la KB944043 ou bien sur le site Technet au sujet des problématiques identifiées de déploiement.

Pré-requis?
  • Une extension de schéma Windows Server 2008 : ForestPrep
  • Une préparation de domaine Windows Server 2008 : DomainPrep
  • Une préparation spécifique RODC : RodcPpep
  • Au moins un contrôleur de domaine Windows Server 2008 avec lequel il pourra dialoguer (perso, je recommande deux DC pour le failover)
  • Pour la localisation du RDOC attention à ne pas placer notre RODC dans un site Active Directory contenant déjà un contrôleur de domaine “Writable” du même domaine, tel que documenté dans la rubrique “Site with Multiple Domain Controllers
  • Ne pas demander à Exchange 2007 d’utiliser ce Global Catalog, il va de lui même l’esquiver!
La mise en œuvre sur Core?

C’est le scénario le plus intéressant. Si en plus on y ajoute la délégation d’installation et d’administration, c’est presque Byzance.

Configuration réseau & raccord au domaine.

Core, c’est pas parlant du tout, on va donc y aller “step by step”. La configuration du nom du serveur qui va devenir RODC à l’aide de la ligne de commande suivante :

0

Pour la configuration réseau, le couteau suisse NETSH.EXE est fait pour cela. Il faut juste savoir avec quelle interface on va configurer :

1

Maintenant que l’on dispose de l’identifiant de l’interface, on peu s’attaquer à la ligne de commande à rallonge :

2

La configuration du client DNS histoire de pouvoir joindre le domaine :

3

Oui, je sais IPV6 est toujours présent! Mais passons au plat de résistance, à savoir la mise en œuvre du RODC. DCPROMO.EXE est déjà présent, pas la peine de tenter d’installer le rôle, c’est pas recommandé! Par contre, sans interface graphique, l’installation s’effectue soit en ligne de commande, soit à l’aide d’un fichier de réponse automatisé. Etant donné que l’on désire suivre les bonnes pratiques, commençons par pré-créer notre futur serveur RDOC dans l’annuaire Active Directory :

4

L’assistant existe, alors utilisons le. Objectif, pré-créer le compte dans l’annuaire Active Directory. De cette manière, on s’assure du respect de la charte de nommage de nos contrôleurs de domaine :

5

Les rappels habituels, …

6

Pour faire simple, je suis connecté en tant que “Admins du domaine”. je sais c’est “Mal”.

7

Spécifions le nom de notre futur contrôleur de domaine (il est impératif que notre futur contrôleur de domaine porte ce nom) :

8

Autant placer notre futur contrôleur de domaine dans le site Active Directory Approprié (pourvu qu’un ait bien créé le site et le sous-réseau associé au préalable, …) :

9

Notre contrôleur de domaine sera tout à fait basique sinon qu’il sera RODC. La bonne pratique est de conserver ces serveurs DNS et Global Catalog :

10

Le processus nous autorise de déléguer l’installation et l’exploitation de notre RODC, autant ne pas s’en priver :

11

Au final, il nous autorise à exporter la configuration dans un fichier de commande. C’est très pratique car l’assistant DCPromo est assez pointilleux. Mais bon, on est en mode “Core”, on va tout faire le ligne de commande, donc passons notre chemin  (on est des guerriers de la ligne de commande ou pas?) :

12

C’est fini pour la partie graphique (overdose):

13

On peut constater la présence du compte ordinateur du futur RODC, il n’est pas encore utilisable :

14

Revenons à notre interface de l’âge de pierre et tentons de convaincre DCPROMO d’accepter tous les paramètres :

15

Qui a dit qu’il n’y a pas d’interface graphique sous “Core”. Allez donc voir un peu ce qu’il est possible de faire (NOTEPAD.EXE, REGEDT32.EXE, TIMEDATE.CPL, …). Etant donné que je n’ai pas donné la réponse dans la ligne de commande kilométrique, il faut bien le saisir ce mot de passe :

16

Et le miracle s’accomplit progressivement :

17

Le dernier paramètre de ma ligne de commande permet de se rendre compte de l’impact de IPV6 non configuré sur un contrôleur de domaine :

18

Cela permet aussi de reconfigurer le client DNS préféré  de l’interface réseau pour respecter les règles de configuration DNS d’un contrôleur de domaine :

19

Même punition mais pour configurer un client DNS additionnel pour le failover :

20

Reste plus qu’à redémarrer. Coté console d’administration, on constate que le compte ordinateur est bien activé et que c’est bien un contrôleur de domaine “ReadOnly” :

21

Des subtilités à voir?, plein,  on peut commencer par la gestion des mots de passe stockés sur le RODC et ceux automatiquement refusés (très instructifs) :

22

Ou alors l’aspect délégation d’administration de ce contrôleur de domaine :

23

Ou encore le fait qu’un objet de réplication a bien été créé pour mettre en place la réplication :

24

Mais que cette réplication n’est qu’unidirectionnelle :

25

Voila pour le RODC, il reste encore une subtilité sur le filtrage des attributs répliqués, histoire d’affiner la sécurité de notre contrôleur de domaine, mais l’essentiel est fait.

BenoîtS – Simple by Design

Quelques subtilités autour de LastLogon

La question revenant très souvent, il faut clarifier la chose. Le sujet traine depuis Windows NT 4.0 et évolue selon les systèmes d’exploitation. On commencera donc par un peu d’histoire (voire même pré-histoire) pour arriver à des systèmes d’exploitation plus récents.

La théorie

Depuis Windows NT 4.0, il est possible d’utiliser l’attribut “LastLogon” pour déterminer quand l’utilisateur s’authentifie. Problème, cet attribut n’est pas répliqué entre les contrôleurs de domaine. Conséquence, il faut interroger tous les contrôleurs de domaine pour déterminer la date de dernière ouverture de session de l’utilisateur.

Avec l’arrivée de Windows Server 2003, on disposait de l’attribut “LastLogonTimeStamp”. Dès lors que le mode de domaine est configuré à Windows Server 2003″, le contenu de l’attribut est répliqué entre les contrôleurs de domaine. Pour éviter tout problème de réplication excessive, Microsoft a limité l’usage de cet attribut pour les ouvertures de sessions interactives NTLM ou Kerberos. C’est donc déjà mieux.

Avec Windows Server 2008, c’est bien mieux car on dispose de nouveaux attributs :

  • La dernière ouverture de session interactive : « msDS-LastSuccessfulInteractiveLogonTime« 
  • Le dernier échec à l’ouverture de session interactive : « msDS-LastFailedInteractiveLogonTime« 
  • Le nombre total d’échecs à l’ouverture de session interactive :
  • Le nombre d’échecs à l’ouverture de session interactive : « msDS-FailedInteractiveLogonCount« 
  • Le nombre total d’échecs à l’ouverture de session interactive depuis la dernière réussite : « msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon« Tous sont répliqués entre les contrôleurs de domaine.

    Pour exploiter ces attributs, encore faut-il que le mode de domaine soit Windows Server 2008. Voila pour l’aspect théorique. Passons maintenant à la pratique. Pour le coté serveur, c’est bien Windows Server 2008. Pour le client, c’est Windows VISTA au minimum.

La pratique

Coté contrôleur de domaine, il faut activer le paramètre “Display Information about previous logons during user logon”. Le plus simple étant de le positionner dans la stratégie de groupe “Default Domain Controller Policy”. L’activation du paramètre va autoriser l’enregistrement de l’information dans l’annuaire Active Directory :

LOGON0

Coté client, c’est le même paramètre mais pour autoriser l’affichage des informations.Pour faire simple, il est positionné dans la stratégie de groupe “Default Domain Policy”.

LOGON1

  • Le résultat
  • Voila ce qui apparait une fois que l’utilisateur s’authentifie pour la première fois sur le domaine :

LOGON2

 

Et voila ce que l’utilisateur constate si on a tenté d’ouvrir sa session sans connaître son mot de passe :

LOGON3

Un billet sans invite de commande MS-DOS avec une ligne de commande illisible? Nan, pas possible. Affichons tous les attributs de mon utilisateur nouvellement authentifié avec un bon vieux DSQUERY.EXE (présent depuis Windows Server 2003) :

LOGON4

L’exécution de la commande fait apparaître nos nouveaux attributs. Reste plus qu’à interpréter leur contenu. Le nombre représente le temps écoulé depuis le premier janvier 1601 exprimé avec 100 nano secondes comme unité de mesure. Si l’attribut est à “0”, cela signifie que l’utilisateur ne s’est pas authentifié.

Subtilité des RODC

Lors qu’un utilisateur s’authentifie auprès d’un contrôleur de domaine de type RODC, la mise à jour ne peut s’effectuer localement. Elle s’effectue donc auprès du contrôleur de domaine le plus proche pour être ensuite répliquée vers le RODC.

 

BenoîtS – Simple and Secure by Design (j’insiste sur le Secure)

Quelques subtilités autour du RODC

Le sujet m’ayant occupé ces temps-ci, j’ai décidé d’en faire un post. Pour la mise en œuvre à proprement parlé, je vous renvoie au billet “Le RODC en image”. Par contre, il manquait un certain nombre d’informations.

 

L’importance de la stratégie de mot de passe

Dans le premier billet, il y a une problématique qui n’avait pas été abordée, à savoir l’importance de la mise en cache des mots de passe. Chaque RODC dispose d’une stratégie de mot de passe qui lui est propre. Donc attention à configurer la stratégie de chaque RODC déployé. Dans ces stratégies on constaté qu’un certain nombre de groupes, les comptes qui en sont membres pourront avoir leur mot de passe répliqué ou non :

RODC1_POLICY

La première surprise c’est qu’un certain nombre de groupes sont positionnés en “Deny”. Cela signifie que pour eux, pas de mise en cache possible. Le RODC est donc obligé de relayer le ticket Kerberos vers un véritable contrôleur de domaine. Encore faut-il qu’il n’y ait pas de défaillance réseau. Après, on remarque deux groupes au noms évocateurs :

  • Allowed RODC Password Replication Group
  • Denied RODC Password Replication Group

L’avantage de ces deux groupes est qu’ils sont utilisés dans chaque stratégie de RODC. On dispose donc d’un moyen global pour gérer la mise en cache.

Attention aux comptes ordinateurs

La mise en cache des comptes concerne aussi bien les comptes utilisateurs que les comptes ordinateurs. Pour que le processus d’authentification Kerberos puisse fonctionner, il est nécessaire que l’ordinateur émette un “Kerberos authentication service request (KRB_AS_REQ)”. C’est grâce à ce ticket que le poste de travail pourra soumettre la demande d’authentification de l’utilisateur pourra être traitée. Si le RODC ne dispose pas des informations nécessaires, la demande de ticket est retransmise à un véritable contrôleur de domaine. Ce ne sera donc pas le RODC qui va authentifier le compte ordinateur :

AUTHENT0

Les deux commandes NLTEST.EXE nous confirment bien que mon poste de travail dépend bien du site Branch1 (contenant un RODC) mais que la demande d’authentification a été traitée par mon contrôleur de domaine central. On peut le vérifier en consultant la liste des comptes authentifiés par le serveur RODC1 :

AUTHENT1

 

Ainsi que la liste des comptes pour lesquels, le mot de passe est bien stocké localement. Le compte de notre ordinateur et notre utilisateurs n’y sont pas :

AUTHENT2

Pour preuve, la demande d’authentification de la station ci-dessous n’a pas été retrouvée sur le serveur RODC1 mais bien sur le contrôleur de domaine central.

AUTHENT3

Idem pour l’authentification de l’utilisateur de la station de travail. Conclusion, il est essentiel de bien configurer la stratégie de mise en cache des mot de passe de chaque RODC pour éviter que ceux-ci soient utilisés comme de simple relais d’authentification. Lorsque cette stratégie de mise en cache est bien configurée, l’authentification est réellement réalisée par le RODC. Pour cela, il faut penser à :

  • Positionner le compte ordinateur dans le groupe “Allowed RODC Password Replication Group” (Idéalement créer un groupe de sécurité global qui sera lui même positionné comme membre du groupe).
  • Pré-peupler le RODC avec les comptes ordinateurs

Le résultat fait qu’on est maintenant bien capable de s’authentifier sur le RODC1 :

RODOCOK

 

Attention à la défaillance WAN

Selon la stratégie de réplication de mot de passe par défaut, les mots de passe des comptes “Administrateurs” ne sont pas répliqués sur un RODC. Question, que va t’il se passer si on tente de s’authentifier avec un compte de ce type sur un contrôleur de domaine RODC? La réponse est simple :

LOGON_FAILED

Comme le RODC ne dispose pas en cache des informations nécessaires à l’authentification (il dispose bien du compte mais pas de son mot de passe), il doit retransmettre la demande de ticket Kerberos à un autre contrôleur de domaine. Or si le réseau est défaillant, cela n’est pas possible.

Pour adresser cette problématique, il ne faut pas modifier la stratégie de réplication de mot de passe du RODC pour autoriser la réplication des mots de passe des comptes “administrateurs” mais créer un groupe de sécurité global auquel on va déléguer l’administration des serveurs RODC.  C’est bien mieux en terme de sécurité.

 

Cas évènement 5723 sur les RODC

Cet évènement indique que le compte ordinateur n’a pu établir une session avec le RODC car celui-ci ne dispose pas de son mot de passe. On trouve cet évènement dans le journal “Système” du RODC :

AUTHENT7

Cette problématique intervient par exemple dans les cas des postes nomades qui se déplacent d’un site à l’autre. Il indique que le RODC du nouveau site n’a pas l’information nécessaire pour l’authentification. Il l’a donc demandée auprès d’un autre contrôleur de domaine pour réaliser l’authentification. Pourtant, l’authentification a bien été réalisée localement :

RODC2

Comme indiqué dans le détail de l’évènement, la problématique n’est pas critique.

 

Cohabitation DC W2K8 et RODC

Pour des raisons de sécurité, il n’est pas recommander de placer un RODC d’un domaine dans un site contenant déjà un contrôleur de domaine classique. En cas de compromission du RODC, le contrôleur de domaine risque d’être compromis par ce que le RODC utilise un compte krbtgt, qui est utilisé pour signer ou crypter les demandes de ticket. La compromission du ticket du RODC peut permettre d’accéder à celui du contrôleur de domaine.

Cohabitation avec des contrôleurs de domaine Windows 2003

Les contrôleurs de domaine Windows 2003 ne reconnaissant pas les RODC comme de véritables contrôleurs. De ce fait, pour eux, il n’y a pas de contrôleur de domaine dans ces sites. Le comportement par défaut est donc de mettre en place les enregistrements DNS nécessaires pour réaliser l’autosite-coverage. Ce comportement entraine donc que le RODC risque de ne pas être utilisé pour l’authentification. La solution à cette problématique peut être de migrer ces contrôleurs de domaine vers Windows Server 2008 ou de désactiver la fonctionnalité Autosite-Coverage.

La KB de compatibilité

Dans un certain nombre de cas, les systèmes d’exploitation clients de type Windows XP et Windows 2003 peuvent avoir quelques difficultés avec le RODC. La KB944043 référence ces problématique et propose un correctif pour ces systèmes d’exploitation.

La compromission d’un RODC

Si un RODC vient à être dérobé, il ne contient que les mots de passe en cache. Microsoft recommande la suppression du compte ordinateur correspondant au RODC. Pas de problème, supprimons le compte ordinateur.

DELETE0

Immédiatement, la console d’administration nous demande quels types de comptes on désire réinitialiser comme illustré ci-dessous :

DELETE1

Dans la capture d’écran ci-dessus, on pourrait penser que seuls les comptes utilisateurs seront initialisés. Et bien non, pas de bol, cela ne se passera pas comme cela. La fiche KB968292 indique que l’assistant ne sait pas faire la différence entre un compte utilisateur et un compte ordinateur. Il réinitialise donc tout ce qui a été mis en cache. Heureusement, un correctif est disponible (Pas intégré au SP2, désolé).

Pour aller plus loin

Le RODC est un sujet complexe. La meilleur source d’information à ce sujet, c’est encore le blog de l’équipe en charge d’Active Directory :

Le dernier article est plus qu’intéressant puisqu’il fait encore une fois référence à la KB944043. Pas de migration sans ce correctif installé sur les postes.

 

mais aussi sur le Technet : Read-Only Domain Controller Planning and Deployment Guide. Dans l’annexe A qui fait le point sur le comportement des clients dans différentes situation lorsqu’ils sont face à un RODC.

Conclusion

Le RODC est une très belle avancée en matière de sécurité. Reste encore à ce que les postes de travail mais surtout les applications savent exploiter correctement ce nouveau type de contrôleur de domaine. Exchange 2007 est un mauvais élève. Il recherche exclusivement des serveur Global Catalog qui ne sont pas des RODC.

 

BenoîtS – Simple and Secure By Design