Archives de catégorie : Windows XP

Subtilité ADMT et Windows 2008 R2

ADMT, ca fait longtemps que je le pratique (NT4 vers Windows 2000). A force, on ne réfléchit même plus et on déroule.  L’outil n’a pas vraiment changé, donc j’ai déroulé jusqu’à tenter de migrer mon premier poste de travail Windows XP, avec une surprise :

“ERR3:7075 Failed to change domain affiliation, hr=800704f1 The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.”

 

Après quelques recherches, je confirme, ADMT n’a pas beaucoup changé. Pour corriger cette problématique, il faut réactiver les algorithmes cryptographiques de Windows NT 4.0 : KB942564. Ceux-ci sont désactivés depuis Windows 2008 pour des raisons évidentes de sécurité. Conclusion, l’agent ADMT n’a donc pas beaucoup changé, je confirme, …

 

J’ai pas eu le temps de tester mais il semble que cette problématique ait été adressée dans le pack de mise à jour RODC Compatibility Pack pour Windows XP. De mon point de vue, c’est effectivement une alternative plus intéressante que de dégrader la sécurité du système d’information. Encore faut-il pouvoir déployer cette mise à jour avant la migration.

 

Benoits – Simple and Secure by Design but Business compliant.

Echéance de support Windows XP

Après Windows 2003, c’est maintenant le tour de Windows XP d’atteindre l’âge de raison, sa fin de période de support principale. Cela interviendra le 14 Avril 2009. A partir de cette date, seuls les correctifs de sécurité seront proposés par Microsoft jusqu’au 08 Avril 2014.

 

On peut dire que Windows XP aura vécu bien plus longtemps que prévu.

 

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