Archives de catégorie : Windows 2003

Une histoire de mot de passe AD

Cela fait quelques années que je conçoit et dépanne des infrastructures d’annuaire Active Directory (pour donner une idée, j’ai commencé avec NT 4.0). On pourrait croire que c’est une routine et bien non, on a toujours quelque chose à apprendre de chaque projet de mise en œuvre ou de migration.

 

Le changement de mot de passe dans AD

Lorsqu’un utilisateur change son mot de passe dans l’AD depuis son poste de travail, cette information est immédiatement transmise au contrôleur de domaine hébergeant le rôle de PDCE. Le but est de pouvoir traiter l’authentification de l’utilisateur avec son nouveau mot de passe alors que ce dernier n’est pas nécessairement répliqué sur tous les contrôleurs dans le domaine. Donc normalement, lorsqu’un utilisateur change son mot de passe, il peut immédiatement l’utiliser pour s’authentifier.

 

Question, peut-il encore utiliser l’ancien?

Voila une bonne question. Du point de vue de l’authentification d’un utilisateur au niveau de la mire d’authentification Windows, la réponse est non. Par contre pour les accès réseaux, c’est une autre histoire. Dans le cas de mon dernier projet, mon client constatait qu’après avoir changé son mot de passe sur un contrôleur de domaine, il était toujours possible d’établir une connexion LDAP authentifiée avec l’ancien mot de passe. Le comportement était reproductible pendant une période de temps d’environ une heure. Voila déjà pas mal d’informations pour qualifier la problématique rencontrée.

 

Ce comportement est du à une fonctionnalité qui a été introduite avec le Service Pack 1 de Windows 2003. Celle-ci est documenté par la KB906305. L’utilisateur est effectivement capable d’utiliser son ancien mot de passe mais uniquement pour les accès réseaux. Ce comportement permet aux utilisateurs connectés de ne pas être bloqué, c’est surtout intéressant pour les comptes de services utilisés par des processus distribués. Sans cette fonctionnalité, changer un mot de passe de compte de service peut s’avérer complexe car tous les services devront être arrêtés et reconfigurés.

 

Selon la KB906305, cela ne concerne que les accès réseau effectués en NTLM. On peut même ajouter les accès LDAP/LDAPS, ce qui était le cas de mon client, dont les contrôleurs de domaine installés avec la dernière génération de systèmes d’exploitation Microsoft. La période pendant laquelle il est possible d’utiliser les deux mots de passe est d’une heure. C’est une clé de registre qui doit impérativement être configurée sur tous les contrôleurs de domaine.

 

Est-ce une faille de sécurité?

Du point de vue de la KB906305, non. Seul l’utilisateur qui a changé son mot de passe connait à la fois son mot de passe actuel et son ancien mot de passe.  Dans certains environnements, où la sécurité doit être renforcée, il peut être tentant de réduire la durée de vie pendant laquelle l’ancien mot de passe est utilisable. Si une telle exigence existe, c’est peut être qu’il y a un besoin d’authentification forte des utilisateurs, que ceux-ci se connecte depuis les réseaux de l’entreprise ou depuis l’extérieur.

 

Conclusion

On a effectivement toujours quelque chose à apprendre. C’est une fonctionnalité que je pensais bien connaitre mais je ne pensais pas qu’elle puisse aussi s’appliquer au contexte de mon client.

 

Benoits – Simple and Secure by Design but Business compliant

Single labels domains et applications Microsoft

Lors de la conception d’une infrastructure Active Directory, une erreur à éviter, c’est de créer une forêt dite “single label”, ce qui signifie sans Top Level Domain. Cette approche était plus ou moins autorisée, avec des conséquences plus ou moins identifiées selon les produits. La KB2269838 résume parfaitement les problèmes de compatibilité pour les différents cas face aux produits Microsoft :

  • Single labels domaine
  • Disjointed Namespaces
  • Discontiguous Namespaces

 

L’approche “Simple by Design” est donc plus que recommandée. Cela évitera les déconvenues. Donc “.Local” ou “.Lan” comme TLD, cela évitera bon nombre de problèmes.

 

Au passage, c’est mon 200ème billet sur ce blog, donc champagne et retour aux zerg! [|-)]

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Cluster et Teaming réseau : Etat des lieux

Qui dit cluster applicatif Microsoft, dit haute disponibilité. Lors de la conception d’une infrastructure en cluster, on passe pas mal de temps sur les SPOF (Single point of failure) pour en minimiser l’importance. Les interfaces réseaux représentent un SPOF de première importance.

 

Pour adresser cette problématique, le teaming de cartes réseau semble être la réponse la plus appropriée. Cependant, chaque constructeur implémente le Teaming à sa manière. Pour cette raison, Microsoft ne supporte pas le Teaming en tant que tel, c’est donc à la charge du constructeur. Pourtant, Microsoft tolère et même autorise son usage. Si on se réfère à la KB254101 :

  • Le teaming de cartes réseau privée n’est pas supporté sous Windows 2003 SP2
  • Le teaming de cartes réseau publique est toléré mais pas recommandé sous Windows 2003 SP2
  • Le teaming de cartes réseau est pleinement supporté pour Windows 2008 et Windows 2008 R2 quelque soit le type d’interface.

 

Avec les clusters Hyper-V et le stockage iSCSI, le nombre d’interfaces réseaux sur nos serveurs va vite grimper à au moins six si on considère un seul réseau publique.

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Cycle de support de Windows 2000/2003

Le sujet fait toujours débat, mais tout arrive un jour (même Windows NT 4.0 est passé par là fin 2003). Tous les produits de Microsoft suivent un cycle de support identique. Il faut donc se préparer à abandonner certains systèmes d’exploitation.

 

On a beau dire, Windows 2000 a fait son temps. La date est proche (13 Juillet 2010). Il faut donc se préparer à migrer ces serveurs “résiduels”. Attention, migrer ne veut pas dire virtualiser. Il faudra bien migrer sauf si vos applications ne supportent pas un système d’exploitation plus récent (Windows 2003).

 

A la même date, ce sera la fin de la période principale de support de Windows Server 2003 et Windows 2003 R2. C’est moins critique car on a encore cinq ans. Pendant cette période de support étendue :

  • Microsoft continuera à fournir des correctifs de sécurité

  • Nous auront toujours accès à la base de connaissances

  • Les correctifs ne concernant pas la sécurité ne seront disponibles qu’aux clients ayant souscrits au programme EHS (Extended Hotfix Support)

Concernant Windows Server 2003. Microsoft a fait savoir qu’il n’y aura pas de Service Pack 3. Conclusion, il faut très rapidement entamer la migration des applications hébergées sous Windows 2000 et commencer à réfléchir au cas de Windows Server 2003. Il y a la problématique du système d’exploitation mais aussi des applications qu’il faudra bien réfléchir  : Virtualiszation or not is the question.

 

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

Problème de Sid-Filtering avec Windows Server 2008

Pour ce billet, un cas concret rencontré par un de mes collègues sur notre projet actuel. Un scénario de migration inter-forêt. Dans la mise en œuvre, dès que les domaines “source” et “destination” sont interconnectés, on continue en désactivant le filtrage de SID (Actif par défaut depuis Windows 2000 SP3) pour bénéficier de la fonctionnalité Sid-History. Pour rappel, la commande NETDOM.EXE ressemble à cela et elle fonctionne très bien :

NETDOMW2K3

Le premier blanc correspond au nom du domaine “destination” et le second au nom du domaine “source”. On constate que la commande fonctionne bien lorsqu’elle est exécutée sous Windows Server 2003.

Maintenant, essayons sous Windows Server 2008, plus précisément une édition localisée “française” :

NETDOM0

C’est étrange, que l’on demande d’activer ou désactiver le filtrage de SID, on obtient la même réponse : “Le filtrage des SID est activé pour cette approbation”. Et en plus tout s’est bien passé? Déjà cela ne ressemble plus beaucoup à ce qu’on obtenait sous Windows Server 2003.

Quelques recherches plus tard (Merci François L de MCS), on tombe sur la KB969030 qui comme son titre nous l’indique rapporte que “Some Netdom commands do not work correctly in localized versions of Windows Server 2008”. Nan pas possible? Si on teste la solution proposée, cela ne change pas grand chose à notre problème :

NETDOM1

Par contre, si on utilise “Oui” et “Non” à la place de “Yes” et “No” pour le paramètre “Quarantine”, là, on retrouve un comportement normal :

NETDOM2

Un grand merci à mon collègue Yassine B pour avoir identifié cette problématique et la solution qui va avec.

 

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

La KB “détail” pour PRA Active Directory

Dans le cas d’un PRA Active Directory, si on positionne des contrôleurs “normalement” des contrôleurs de domaine sur le site de secours, on s’attend à ce que les systèmes d’exploitation Windows XP/2003 les utilisent lors du passage en “secours”. Et bien, c’est un peu plus compliqué que cela, …

 

Sous Windows XP/2003, le système d’exploitation va identifier une liste des contrôleurs de domaine potentiels lors du démarrage. De cette liste, il ne va en retenir qu’un seul (et il va garder sa tête celui-là). En plus, cette information ne sera mis à jour que dans deux cas :

  • Le système d’exploitation est redémarré

  • Que le contrôleur de domaine en cache ne réponde plus (Quickening)

 

S’il faut redémarrer un Datacenter pour que nos systèmes d’exploitation Windows 2003 puissent utiliser de nouveau un contrôleur de domaine, le temps de reprise va en être considérablement allongé. On peut aussi attendre qu’il le découvrent par lui même.

 

Pour le nombre de contrôleur de domaine mis en cache, c’est la faute à la fonction “DsGetDcName”. Avec un peu de recherches, on découvre qu’il est possible de forcer manuellement l’actualisation de ce cache avec la commande suivante :

nltest /dsgetdc:Nom du domaine DNS /force

Heureusement, cette problématique est maintenant résolue avec la KB939252. Elle s’applique aussi-bien à Windows XP que Windows Server 2003. Elle permet d’introduire une actualisation automatique du cache cache toutes les douze heures. Il est même possible de choisir sa propre périodicité d’actualisation avec la clé de registre DWORD suivante:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

\Netlogon\Parameters\ForceRediscoveryInterval

 

Note : La valeur est exprimée en secondes.

 

Benoît – Simple and Secure by Design (J’insiste sur le Secure)

L’enregistrement DNAME

Lors de mon dernier article sur le RODC, j’ai fait référence à un certain nombre d’incompatibilités de celui-ci avec les systèmes d’exploitation de version antérieure. Cependant, j’en ai oublié une, la plus sournoise.

Elle concerne l’utilisation du nouveau type d’enregistrement DName supporté par Windows Server 2008. Pour le résumer, DName est l’équivalent de CName mais pour les domaines DNS (Pour les motivés, il existe aussi la version longue, sous forme de RFC).

Sur la papier, l’enregistrement DName n’est ni plus ni moins qu’un nouveau type d’enregistrement DNS. Normalement, cela devrait pas poser de problème. Mais, un serveur DNS Windows 2003 ne supporte pas les enregistrements DName, à moins de s’attarder sur la KB920162.

Conclusion : Toujours prendre le temps d’étudier son déploiement de Windows Server 2008 avant de courir tête baissée dans le mur.

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

Echéance de support Windows 2003

Le support des produits Microsoft est régit par un ensemble de règles présentées ici. Windows 2003 n’échappe pas à ces règles, plus précisément, son Service Pack 1. Selon les informations disponibles pour cette version de Windows, celui-ci arrive bientôt au terme de sa période de support, plus précisément le 14 Avril 2009.

 

A cette date, il n’y aura plus de correctifs de sécurité pour le Service pack 1. Pensez donc à mettre à jour vos serveurs pour pouvoir bénéficier des dernières mises à jour. D’un point de vue technique, le Service Pack 2 de Windows 2003 n’introduit pas autant de changements que son prédécesseur. La transition en est donc facilitée.

 

BenoîtS – Simple and Secure by Design

Impossible de supprimer un Sid-History pour raison de sécurité

Dans un projet de migration Active Directory, il est nécessaire d’établir un lien entre le compte utilisateur du domaine “source” avec un compte utilisateur dans le domaine “cible” de migration.

Pour établir le lien entre les deux, on dispose de l’attribut “Sid-History. Lorsque l’utilisateur du domaine “cible” accède à une ressource dans le domaine “source” de la migration, celui-ci se présente sous son identité du domaine “source”. C’est de cette manière qu’on peut préserver l’accès aux ressources pendant la migration.

Maintenant si on associe un mauvais utilisateur dans le Sid-History, on pourrait croire qu’il suffit simplement de supprimer l”information à l’aide de la console ADSIEDIT.MSC. Depuis Windows 2003, la réponse sera invariablement :

DENIED

Accès refusé, même si on utilise un compte administrateur. Pourtant, pour ceux qui comme moi ont réalisé des migration NT4 vers Windows 2000 se souviennent que cela ne posait pas de problème. Pourquoi?

La première raison, c’est que depuis Windows 2003, la manipulation de l’attribut Sid-History passe nécessairement par une nouvelle API : DsAddSidHistory. La seconde raison, c’est que la console d’administration ne réalise pas la bonne opération.

L’API : DsAddSidHistory a été introduite pour parer à une problématique d’élévation de privilèges lors de la migration. Prenons un utilisateur d’un domaine “cible” de migration” capable de modifier son propre attribut Sid-History (je l’avoue c’est assez rare). Il peut s’associer le SID d’un utilisateur dans le domaine “source” (tant que celui-ci n’est pas encore associé à un autre utilisateur du domaine “cible”). Donc, un simple utilisateur peut se faire passer pour un administrateur du domaine “source”.  Voila donc le pourquoi de l’API.

Maintenant, question comment corriger l’association d’un mauvais SID à un utilisateur. La console ne réalisant qu’une opération LDAP UPDATE et non LDAP DELETE, c’est donc vers le scripting qu’il faut se tourner. La réponse se trouve dans la KB295758 qui propose une solution en Vbscript qui réalise une opération “DELETE” :

vArray = oDirObject.GetEx(« sIDHistory »)

For Each vSid in vArray

oDirObject.PutEx ADS_PROPERTY_DELETE, « sIDHistory », array(vSid)

oDirObject.SetInfo

Next

Avec un peu de développement, il est possible de rechercher à quel utilisateur correspond le SID dans le domaine source. Encore faut-il être capable de manipuler les SID en VbScript, ce qui n’est pas une sinécure.

Benoîts – Simple and Secure by Design