Blog de ILINFO

Trucs et astuces

Blog ILINFO Active DIrectory MIIS LDAP ADAM PCA PRA BCP DRP

Log in

Nettoyage des comptes inactifs de l'Active Directory

by Emmanuel Dreux juillet 08, 2009 23:03

Sans solution de provisionning et de workflow performant, le nombre de comptes utilisateurs inactifs dans l'Active Directory va vite devenir important.

Développement script ADSI

Sécurité ADSI : Liste Objets AD : Users, Groups, Computers, Utilisateurs, groupes, ordinateurs

Il s'agit d'utilisateurs qui ont quitté la société, de comptes utilisateurs qui ne sont plus utilisés ou de machines qui ont été recyclées mais dont les objets existent toujours dans l'AD.

disable accounts désactivation de comptes

Nettoyage comptes inactifs

Pour déterminer si un compte est toujours utilisé ou non, il existe deux moyens simples qui peuvent d'ailleurs être complémentaires et recupés ensembles.

Il s'agit par exemple de s'appuyer sur l'attribut LastLogonTimeStamp (à partir de Windows 2003) qui stocke la date de dernier logon du compte. Cet attribut est répliqué sur tous les dc du domaine.

La seconde données intéressante est la date de dernier changement de mot de passe. Une machine change son mot de passe tous les 30 jours. Si un ordinateur n'a pas changé son mot de passe depuis par exemple 60 ou 90 jours, il y a de fortes chances que cette machine n'existe plus sur le domaine.

Voici un ensemble de scriptsqui permet de générer la liste des utilisateurs et ordinateurs inactifs (stale accounts dans le jargon anglosaxon) et de réaliser le nettoyage (le script recensé désactive le compte et le déplace dans une OU de quarantaine. La date d'action et le chemin source de l'objets sont stockés dans des attributs inutilisés pour un éventuel retour arrière).

Développement script ADSI

Stale Accounts

Liste les objets Users, groups et computers de l'AD :

Développement script ADSI

Comptes inactifs, Comptes désactivés

Liste les comptes inactifs de l'AD

Liste les comptes désactivés de l'AD

Développement script ADSI nettoyage AD

LastLogonTimeStamp, Last Password Change

Désactive les comptes inactifs de l'AD

Soyez le premier à noter ce billet

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Active Directory

PRA : Restauration d'une forêt Active Directory

by Emmanuel Dreux mai 17, 2009 00:56

Blog PRA Active Directory

Forest Recovery

Lors d'un désastre Active Directory nécessitant une reconstruction complète de la forêt, la première chose à réaliser est de restaurer le service au plus vite, en l'occurence le service d'authentification.

Blog PRA Active Directory

Forest Recovery

Le minimum à réaliser consiste à réinstaller un DNS sur lequel va s'appuyer l'AD, un controleur de domaine du domaine racine, un controleur de domaine de chaque domaine enfant ainsi qu'un global catalogue. A ce stade, le service minimum est restauré, les étapes suivantes consistent reconstruire un DC dans chaque site puis remonter tous les DC, et remettre en place les rôles FSMO.

Pour que le service d'authentification soit complètement opérationnel, celà nécessite également dans la majorité des cas qu'un catalogue global soit accessible (cas d'une forêt en mode natif nécessitant un GC pour résoudre l'appartenance aux groupe universels).

Forest Recovery

Cependant, savez-vous que pour promoter un GC, le rôle FSMO Schema Master doit être accessible? Celà implique donc que le DC possédant ce rôle devrait être restauré avant toute tentative de restauration de GC. Si la sauvegarde de ce DC n'est pas accessible, il est possible de forcer ce rôle sur un DDC (Seizure). Cependant la seizure de ce rôle nécessite d'être dans le groupe Schema Owner.

PRA Active Directory

Chez un de mes clients, le scénario suivant est survenu: ils avaient retiré le compte Administrator du groupe Schema Owner. Après restauration du premier DC, première surprise, l'administrateur ne peut seizer ce rôle, ni modifier le contenu de ce groupe, ni même se loguer avec un compte possédant les droits puisqu'aucun GC n'est disponible. Comment faire alors pour installer le premier GC de la forêt?

Solution

1. Se placer dans le contexte LocalSystem du DC

Sur le serveur, ou dans une console système (mstsc /console), dans une invite de commande, lancez la commande at /interactive hh:mm cmd.exe hh:mm représentant l'heure actuelle+ 2 minutes.

2. Lancez adsiedit.msc dans le contexte système.

Lorsque l'invite de commande apparait dans le contexte système, tapez adsieedit.msc puis appuyez sur Entrée.

Chargez la partition schema puis modifiez manuellement le DC possédant le rôle Schema Master (Attribut FSMORoleOwner de CN=SCHEMA,CN=Configuration,DC=...)

Forest Recovery

 

Blog PRA Active Directory

La prise en compte est dynamique.

A ce stade, vous avez seizé le rôle Schema Master sur le DC que vous avez restauré sans pour autant appartenir au groupe qui donne cette autorisation.

 Maintenant que le rôle est assigné, vous pouvez promoter un GC.

Promotion du GC

Bien que tous les domaines ne soient pas encore restaurés, il est possible de  promoter un GC "vide". Normalement il ne s'annoncera comme GC seulement lorsqu'il aura réussi à répliquer une fois la partition de chaque domaine.

Il est cependant possible de changer ces contraintes en éditant la clé de registre

HKEY_LOCAL_MACHINE \ SYSTEM \ Current Control Set \ Services \ NTDS \ Parameters \ Global Catalog Partition Occupancy. En la positionnant à zéro, vous indiquez au système qu'il peut s'annoncer en tant que GC dès que 0 partitions sont disponibles.

Promotez maintenant votre GC, il s'annonce immédiatement en tant que GC bien qu'il ne possède que la partition de votre domaine.

Vérification:

Lancez LDP, cliquez sur Connect et laissez les entrées à vide, cliquez ensuite sur Bind et laissez les entrées à vide.

Vous êtes alors connecté au DC qui vous affiche alors ses  capacités.

Regardez la valeur de 'attribut :

                1> isGlobalCatalogReady: True;

 

 

 

Votre domaine racine est maintenant opérationnel et poss_de un premier GC. Ses utilisateurs peuvent désormais s'authentifier.

Vous pouvez maitenant restaurer un DC de chaque domaine pour restaurer les domaines un par un ou utiliser vos outils ou scripts de Forest Recovery pour dérouler la suite de votre PRA (Plan de reprise d'acitvité).

Soyez le premier à noter ce billet

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Active Directory | PRA

Problème restauration des comptes associés aux keytab

by Emmanuel Dreux avril 10, 2009 21:26

Contexte:

Un administrateur a mis en place une solution de SSO pour que des utilisateurs d'un domaine Active Directory puissent s'authentifer en Kerberos auprès d'applications JAVA ou aurpès d'applications hébergées sur des machines Unix ou Linux.

Dans ce contexte, des comptes SSO ont été crées dans l'Active Directory.
Il s'agit de comptes de service pour lesquels un keytab a été généré à l'aide de la commande Ktpass.exe (ktpass -princ 'value' -mappuser domain\svcaccount etc.)

Lors de l'éxécution de la commande, le mot de passe du compte de service est modifié et la clé de chiffrement contenue dans le keytab est dérivée du mot de passe.

Un numéro de version du mot de passe appelé kvno est également stocké dans le keytab. Il doit correspondre au numéro de version contenu dans les tickets générés par les KDC. Le KDC récupère le numéro de version depuis l'attribut msDS-KeyVersionNumber. Cet attribut msDS-KeyVersionNumber est un attribut construit (constructed attribute) dont la valeur est égale à une metadonnée de l'attribut UnicodePwd.

 

Problème:

Lors d'une restauration autoritaire (authoritative restore), la métadonnée de l'attribut UnicodePwd est incrémentée de 100 000.

Celà a une double conséquence:

1.  le msDS-KeyVersionNumber (= kvno) est également incrémenté de 100 000 et ne correspond donc plus au numéro de version stocké dans le keytab. En d'autres termes, celà invalide le keytab existant qu'il faut alors regénérer.

2. Le kvno est originellement codé sur 8 bit et accepte des valeus de 0 à 255. Les valeurs supérieures sont alors mal perçues selon les implémentations kerberos. L'implémentation MIT par exemple accepte des kvno > 255 alors que l'implémentation de Vintela (Quest) ne les accepte pas.

Dans un cas de PRA (plan de reprise d'activité, DRP en anglais), où il faut procéder à une restauration autoritaire d'annuaire, il faut alors regénérer tous les keytab des comptes SSO Kerberos Unix et les réinstaller dans chaque application. Si la stack kerberos n'accepte pas les kvno > 255, il faut alors supprimer tous les comptes SSO et les recréer.

 

Contournements:

Vintella accepte des keytab avec un kvno à -1 et dans ce cas ignore si les numéros de version ne correspondent pas (ce n'est pas applicable pour l'implémentation MIT).

Il est donc possible d'éditer les fichiers keytab existants avec un éditeur héxadécimal et de forcer la valeur kvno à FF.

Il est également possible de générer un keytab avec la valeur kvno à -1, pour cela utiliser l'option de ktpass /kvno 255.

 Finalement, il est possible de forcer l'active directory à revenir à la mode Windows 2000 c'est à dire ne jamais incrémenter le  msDS-KeyVersionNumber et lui forcer la valeur à 1 systématiquement.

Pour celà, il faut modifier au niveau de la forêt dans la partition configuration l'attribut dsheuristics.

voir http://support.microsoft.com/kb/870987/en-us

 

Demande de fix :

Une demande de fix (CDCR = Critical Design Change Request) a été formulée auprès de Microsoft.

Ce billet sera mis à jour lorsqu'un statut final sera apporté par Microsoft.

Actuellement noté 5.0 par 1 personne(s)

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

Active Directory | SSO