I- Introduction

1.1 Quelques infos

Pourquoi plusieurs stratégies de mot de passe?
Dans Windows Server 2008, vous pouvez donc utiliser des FGPP (fine-grained password policies) pour définir de multiples stratégies de mot de passe sur un même domaine.  Cette fonctionnalité permet par exemple d’augmenter le niveau de sécurité de certains comptes utilisateurs aux privilèges élevés, ou ayant accès à des données très sensibles. Dans d’autres cas, cette fonction est intéressante si certains comptes de services doivent se synchroniser avec des domaines Windows et autres annuaires LDAP disposant d’une stratégie de mots de passe différente de celle du domaine actuel.

N stratégies de mot de passe, comment ça marche ?

Afin de stocker les FGPP, Windows Server 2008 a vu son schéma mis à jour. Deux nouvelles classes d’objets sont donc apparues, Les classes Password Settings Container et Password Settings.

Pour faire simple, la classe Password Settings Container (PSC) est créée par défaut sous le conteneur System du domaine. Elle stocke les objets Password Settings (PSO) pour ce domaine. Il n’est bien sur pas possible de renommer, déplacer ou supprimer son conteneur.

1.2 Définition d'un scénario

Avant de configurer ces nouvelles stratégies, il convient de définir une structure correcte permettant de l’exploiter. Gardez toujours en tête que ça n’est pas la partie technique qui est difficile à mettre en place, mais bien la préparation (Etape aussi appelé : je nettoie mon domaine pour qu’il ne soit plus apte à passer dans une émission de télé réalité…)

Maintenant que vos utilisateurs, groupes et OU ont une cohérence, il faut maintenant définir un scénario par rapport à la nature de votre boite elle-même. Combien de stratégies différentes avez-vous besoin ? Pour quel type d’utilisateurs ?...

Un scénario typique inclurait 3 à 4 stratégies de ce type (attention, ça n’est pas LE scénario best practices, juste un exemple. Donc pas d’injures) :

·         Une stratégie de mots de passe pour les administrateurs (ex : 16 caractères, expiration tous les 20 jours)

·         Une stratégie pour les utilisateurs simples (ex : 8 caractères, expiration tous les 120 jours)

·         Une stratégie pour les utilisateurs sensibles (ex : 16 caractères, expiration tous les 30 jours

·         -éventuellement- Une stratégie pour les comptes de service ( ex : 32 caractères, pas d’expiration)

Tirer partie de votre structure de groupes existante est aussi crucial. Comment avez-vous créé vos groupes, avez-vous un groupe dédié aux Administrateurs ? Un groupe pour tous les utilisateurs SAUF les administrateurs ? Un groupe dédié à l’accès aux ressources critiques ? Le but est bien sur d’adapter votre infrastructure de groupes aux PSO, sous peine d’avoir des résultats…. Surprenants.


Attention
 : Les PSO, contrairement à des GPO classiques ne s’appliquent pas directement aux OU !

Si vos utilisateurs sont gérés pas OU et non par groupe, vous allez donc me détester ;)

Promis, je n’y suis pour rien.

Vous allez donc passer par ce qu’on appellera des « shadow groups » (oui, c’est très côté obscure, je sais). Un shadow group est en fait un simple groupe global que vous allez mapper à une OU, afin d’y appliquer votre PSO. Evidemment, sachant que l’opération est manuelle, vous devrez mettre à jour le groupe à chaque déplacement de ou vers l’OU en question. vous me détestez deux fois maintenant… Toutefois, gardez en tête d’une part que Windows 2008 peut gérer des taches planifiées basées sur des évènements, et de l’autre que le scripting c’est bien 
J Les deux mélangés devrait vous permettre d’automatiser correctement les gestions de shadow groups.

 

1.3 Prérequis à la mise en place de PSO

Niveau fonctionnel de domaine

Pour activer cette fonctionnalité, il faut impérativement que le niveau du domaine soir « Windows Server 2008 ». Faites une dernière bise aux DC 2003 qui trainent et upgradez votre infra.

Par défaut, seuls les membres du groupe Admin. Du domaine peut créer des PSOs. Les droits nécessaires pour créer des PSOs sont les suivants :

·         Créer et supprimer des permissions sur les enfants pour les objets Password Settings Container.

·         Permission d’Ecriture sur les objets PSO.

Pour déléguer les droits sur les PSO, il faut d’une part donner les droits su-cités et de l’autre le droit de lecture sur la classe PSO du schéma au groupe adéquat.

 

Cibles

Les FGPP ne s’appliquent qu’aux objets utilisateurs, inetOrgPerson et groupes. Ni aux OU, ni aux ordinateurs.

 

Filtres de mots de passe

Les FGPP n’interfèrent pas avec un éventuel password filter mis en place sur le domaine. Votre DLL historique forçant l’utilisation des mots clés papa et maman dans chaque mot de passe utilisateur est donc sauvé J

 

PSO exceptionnelle

Bien que je ne le recommande pas –pour ma part, je trouve que ça autorise le travail de cochon…-  il vous est possible de spécifier une PSO uniquement à un utilisateur, tandis que son groupe d’appartenance en dispose d’une autre. Un PSO linké en direct à un utilisateur prends le pas sur toute autre PSO de niveau supérieur.

 

II- Création d'une PSO par ADSIEDIT

Adsiedit permet de voir quasiment tous les objets et attributs de la foret. Il faut bien sur être admin du domaine ou assimilé pour suivre cette procédure, à moins que vous n’ayez déjà délégué les droits sur les PSO.

1-     Lancez Adsiedit (je suppose que vous bindez déjà sur le bon domaine)

2-     Double cliquez sur le nom du domaine, puis sur CN=System

3-     Sélectionnez CN=Password Settings Container (tous les PSO déjà créés apparaissent)

4-     Faite un clique droit puis nouveau et Objet.

5-     Dans la boite de dialogue, sous le champ Selectionner une classe, cliquez sur msDS-PasswordSettings, puis choisissez suivant.

6-     Dans Valeur, entrez le nom de la PSO puis, suivant.

7-     Entrez ensuite les valeurs appropriées pour tous les attributs concernés.

a.     Pour désactiver les paramètres de vérouillage de compte, spécifiez la valeur 0 à l’attribut msDS-LockoutThreshold

b.    Pour éviter les erreurs de création, utilisez obligatoirement l’Adsiedit de Windows 2008, et utilisez le format j:hh:mm:ss

8-     Les attributs utilisables sont disponibles dans le tableau ci-dessous :

Nom de l’attribut

Description

Scope de valeurs

msDS-PasswordSettingsPrecedence

Password Settings

Supérieur à 0

msDS-PasswordReversibleEncryptionEnabled

Encryption réversible

FALSE / TRUE (toujours mettre FALSE)

msDS-PasswordHistoryLength

Taille de l’historique des mots de passe

0 à 1024

msDS-PasswordComplexityEnabled

Complexité des mots de passe

FALSE / TRUE

(par défaut : TRUE)

msDS-MinimumPasswordLength

Nombre minimum  de caractères d’un mot de passe

0 à 255

msDS-MinimumPasswordAge

Age minimum du mot de passe

- Aucun

- 00:00:00:00 à la valeur  msDS-MaximumPasswordAge

msDS-MaximumPasswordAge

Age maximum du mot de passe

- Jamais

- Valeur msDS-MinimumPasswordAge à jamais

- msDS-MaximumPasswordAge

msDS-LockoutThreshold

Vérouillage des comptes

0 à 65535

msDS-LockoutObservationWindow

Fenêtre d’observation des comptes vérouillés

- Aucune

- 00:00:00:01à la valeur msDS-LockoutDuration

msDS-LockoutDuration

Durée de vérouillage des comptes

- Aucune

- Jamais

- msDS-Valeur LockoutObservationWindow value à jamais

msDS-PSOAppliesTo

Liens aux objets pour lesquels ce PSO s’applique

0 ou plusieurs DN d’utilisateurs ou groupes


Facultatif :

9-     Au dernier écran, cliquez sur plus d’attributs

10-  Dans le menu : sélectionnez quelle propriété voir, cliquez sur Optionnel ou les deux.

11-  Dans le menu : sélectionnez la propriété à voir, sélectionnez msDS-PSOAppliesTo.

12-  Entrez les distinguished names des utilisateurs ou groupes pourt lesquels la PSO doit être appliquée, puis faite ajouter

III- Gestion des PSO

3.1 Liaisons d’une PSO aux utilisateurs et groupes

Cette fois ci plus de adsiedit, on retourne sur cette bonne vieille console utilisateurs et ordinateurs, assurez vous simplement que la vue « fonctionnalités avancées » est activée.

 

1-     Dans la console dsa, sélectionnez le conteneur Password Settings (dans System)

2-     Dans la fenêtre de droite, faites un clique droit sur la PSO que vous avez créé, puis propriétés.

3-     Dans l’onglet Editeur d’Attributs, selectionnez msDS-PsoAppliesTo et faites «éditer ».

4-     Dans l’éditeur, entrez le DN des utilisateurs / groupes pour lesquels appliquer la PSO, puis faites OK

 

3.2 Suppression d'une PSO

Retour à ADSIEDIT, mais cette fois-ci :

 

1-     Lancez Adsiedit

2-     Double cliquez sur le nom du domaine, puis sur CN=System

3-     Sélectionnez CN=Password Settings (tous les PSO déjà créés apparaissent)

4-     Faites un clique droit sur la PSO concernées puis faites supprimer.

 

3.3 Modification d’une PSO

1-     Dans la console dsa (plus d’adsiedit), sélectionnez le conteneur Password Settings (dans System)

2-     Dans la fenêtre de droite, faites un clique droit sur la PSO que vous avez créé, puis propriétés.

3-     Sélectionnez l’onglet éditeur d’attributs.

4-     Sélectionnez les attributs à voir ou à modifier, puis choisissez voir ou éditer.

IV- Conclusion

Pour terminer ce guide, je me devais de vous parler d’un outil gratuit et pourtant extraordinaire, qui vous évitera de passer par de l’ADSIEDIT à tout bout de champs.

Specops Password Policy basic est donc un utilitaire gratuit, qui vous permettra de créer vos PSO graphiquement, sans vous embêter avec les syntaxes ldap et les datations de PSO. Vous trouverez l’utilitaire ici :

 

Voilà, j’espère que ce petit how-to vous aura donné envie découvrir un peu plus cette nouvelle gestion des mots de passe dans un domaine AD.

Je continuerai bien sur à vous parler des nouveautés d’Active Directory 2008 dans les prochains guides.