Déléguer les droits au compte qui lance Kontivo

1. Pourquoi un compte délégué

Kontivo agit dans l'annuaire avec le compte Windows qui le lance. Un compte « Admins du domaine » fonctionne, mais une erreur de manipulation aurait alors des droits sur tout le domaine. Un compte délégué n'a de droits que sur les trois dossiers (OU) choisis dans les réglages : le dossier des utilisateurs, le dossier des comptes partis et le dossier des groupes de l'annuaire. Même en cas d'erreur, il ne peut toucher à rien d'autre.

L'outil n'a besoin d'aucun droit d'administrateur sur le poste : il n'écoute que sur l'ordinateur lui-même (adresse 127.0.0.1) et range ses données dans C:\ProgramData\ComptesAD, qu'un utilisateur peut créer.

2. Créer le compte et son groupe

Donnez les droits à un groupe, puis mettez le compte dans ce groupe : vous pourrez changer de compte sans refaire la délégation. Dans les exemples, le domaine s'appelle DEMO (demo.local) :

• un groupe de sécurité global, par exemple GG-ComptesAD ;
• un compte utilisateur, par exemple adm-comptes, membre de ce groupe, avec un mot de passe long, rangé hors des dossiers des utilisateurs gérés ;
• ce compte ne doit être membre d'aucun groupe d'administration.

Dans les commandes ci-dessous, remplacez les noms des OU par ceux de votre annuaire (les exemples reprennent les noms proposés par l'outil, Utilisateurs, Departs et Groupes, sous une OU parente Organisation) :

OU des utilisateurs    OU=Utilisateurs,OU=Organisation,DC=demo,DC=local
OU des comptes partis  OU=Departs,OU=Organisation,DC=demo,DC=local
OU des groupes         OU=Groupes,OU=Organisation,DC=demo,DC=local

Créez d'abord ces trois OU (avec « Utilisateurs et ordinateurs Active Directory », ou dans les réglages de l'outil avec un compte qui en a le droit) : le compte délégué ne peut pas créer une OU hors du dossier des utilisateurs.

3. Les droits, dossier par dossier

Déplacer un compte (changement de groupe, départ, retour) demande « supprimer » sur le compte lui-même et « créer un enfant » sur l'OU d'arrivée. Le droit « supprimer » sur les utilisateurs de l'OU des utilisateurs est nécessaire : quand les OU de groupe créées par l'outil sont protégées contre la suppression accidentelle, cette protection pose sur leur OU parente un refus de « supprimer des objets enfants », qui empêcherait de déplacer un compte rangé directement dans l'OU des utilisateurs (utilisateur en attente de groupe).

Les OU de groupe créées par le compte délégué

L'outil crée chaque OU de groupe en deux temps : d'abord l'OU, sans protection, puis, dans une étape séparée, la protection contre la suppression accidentelle. Poser cette protection modifie les autorisations de l'OU des utilisateurs (le refus décrit ci-dessus), ce que la délégation de ce document ne permet pas. Si le droit manque, l'OU est quand même créée et l'opération est réussie, avec cette note au journal : « OU créée, protection contre la suppression accidentelle non posée (droit « modifier les autorisations » manquant sur l'OU parente) : un administrateur peut la poser dans Utilisateurs et ordinateurs Active Directory (onglet Objet de l'OU). » Deux façons de faire ensuite :

• laisser les OU de groupe sans protection (elles ne contiennent que des comptes d'utilisateurs gérés, et l'outil les recrée au besoin), ou les protéger à la main avec un compte administrateur ;
• ou donner au groupe délégué « Modifier les autorisations » sur l'OU des utilisateurs seulement (pas sur ses sous-OU), ce qui est un droit large, à peser avec l'administrateur du domaine :

  dsacls "OU=Utilisateurs,OU=Organisation,DC=demo,DC=local" /G "DEMO\GG-ComptesAD:WD"

Le premier passage sur une OU de test (notice, § 6) montre lequel des deux cas se produit dans votre annuaire.

Pour tout le reste, l'outil se contente de lire, avec les droits de lecture que tout compte du domaine a par défaut : la liste des identifiants du domaine (pour éviter les doublons), les politiques de mots de passe, les contrôleurs.

4. Donner les droits avec dsacls

dsacls est installé avec les outils Active Directory (RSAT) et sur les contrôleurs de domaine. Tapez ces commandes dans une invite de commandes ouverte avec un compte « Admins du domaine ». /I:T applique le droit à l'OU et à tout ce qu'elle contient, /I:S seulement aux objets qu'elle contient.

OU des utilisateurs

dsacls "OU=Utilisateurs,OU=Organisation,DC=demo,DC=local" /I:T /G "DEMO\GG-ComptesAD:CCDC;user"
dsacls "OU=Utilisateurs,OU=Organisation,DC=demo,DC=local" /I:T /G "DEMO\GG-ComptesAD:CC;organizationalUnit"
dsacls "OU=Utilisateurs,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:RPWP;;user"
dsacls "OU=Utilisateurs,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:SD;;user"
dsacls "OU=Utilisateurs,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:CA;Reset Password;user"

OU des comptes partis

dsacls "OU=Departs,OU=Organisation,DC=demo,DC=local" /I:T /G "DEMO\GG-ComptesAD:CCDC;user"
dsacls "OU=Departs,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:RPWP;;user"
dsacls "OU=Departs,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:SD;;user"

Seulement si une suppression échoue avec l'erreur 8213 (« Le compte contient des objets ») :

dsacls "OU=Departs,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:DT;;user"

OU des groupes

dsacls "OU=Groupes,OU=Organisation,DC=demo,DC=local" /I:T /G "DEMO\GG-ComptesAD:CCDC;group"
dsacls "OU=Groupes,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:RPWP;;group"

Facultatif : retirer la protection contre la suppression accidentelle

Seulement si vous voulez utiliser l'option « Retirer la protection » (réglages, encart « Avancé », ou bouton de l'aperçu) :

dsacls "OU=Utilisateurs,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:WD;;user"
dsacls "OU=Departs,OU=Organisation,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:WD;;user"

5. Donner les droits avec l'assistant de délégation

Dans « Utilisateurs et ordinateurs Active Directory », clic droit sur l'OU, Délégation de contrôle…, ajoutez le groupe GG-ComptesAD, puis choisissez Créer une tâche personnalisée à déléguer. Les libellés ci-dessous peuvent varier légèrement selon la version de Windows.

OU des utilisateurs (deux passages de l'assistant)

1. Premier passage : Seulement des objets suivants dans le dossier, cochez Objets Utilisateur, puis Créer les objets sélectionnés dans ce dossier et Supprimer les objets sélectionnés dans ce dossier. Page suivante, dans Générales : Lire toutes les propriétés, Écrire toutes les propriétés, Supprimer, Réinitialiser le mot de passe.
2. Second passage : Seulement des objets suivants dans le dossier, cochez Objets Unité d'organisation et Créer les objets sélectionnés dans ce dossier ; page suivante : aucune autorisation de plus n'est nécessaire (cochez au besoin Lire).

OU des comptes partis

Un passage, comme le premier passage de l'OU des utilisateurs, sans « Réinitialiser le mot de passe ».

OU des groupes

Un passage : Objets Groupe, créer et supprimer ; autorisations Lire toutes les propriétés et Écrire toutes les propriétés.

Après l'assistant, contrôlez le résultat : clic droit sur l'OU, Propriétés, onglet Sécurité, Avancé (l'onglet Sécurité n'apparaît qu'avec Affichage > Fonctionnalités avancées). Les droits sur les utilisateurs doivent s'appliquer aux « objets Utilisateur descendants », ceux de création aux sous-OU aussi.

6. Le partage des dossiers personnels

Si un modèle de chemin est rempli dans les réglages (par exemple \\srv-fichiers\utilisateurs$\{sam}), la case « Créer le dossier sur le partage et donner les droits à l'utilisateur » est cochée d'office. Pour chaque nouvel utilisateur, l'outil :

1. crée le dossier \\srv-fichiers\utilisateurs$\lea.martin, s'il n'existe pas (un dossier existant n'est jamais modifié) ;
2. donne à l'utilisateur, par son SID, le droit choisi sur ce dossier et son contenu : « Modification » (par défaut) ou « Contrôle total » ;
3. à la suppression définitive du compte, si l'archivage est choisi, crée au besoin \\srv-fichiers\utilisateurs$\_archives et y renomme le dossier (_archives\lea.martin_2027-10-05). Rien n'est effacé, les droits du dossier ne changent pas.

Préparer le partage en une fois : ComptesAD.exe -PreparerPartage

Le partage se prépare sur le serveur de fichiers (de préférence pas sur le contrôleur de domaine), une seule fois, par un administrateur de ce serveur. Copiez-y ComptesAD.exe (par exemple dans C:\ComptesAD), puis tapez, dans une invite de commandes ou une fenêtre PowerShell ouvertes en administrateur :

C:\ComptesAD\ComptesAD.exe -PreparerPartage -Dossier D:\Utilisateurs -Partage utilisateurs$ -GroupeDelegue DEMO\GG-ComptesAD

Sans paramètre, une petite fenêtre demande le dossier, le nom du partage, le groupe délégué et, facultatif, le groupe des utilisateurs, avec un bouton Vérifier (rien n'est changé) et un bouton Préparer. La préparation fait, dans l'ordre :

1. elle crée le dossier D:\Utilisateurs s'il manque ;
2. elle pose les droits NTFS de la racine, en coupant l'héritage du disque :
   • SYSTEM et Administrateurs : « Contrôle total » ;
   • le groupe délégué (GG-ComptesAD) : « Modification », sur ce dossier, les sous-dossiers et les fichiers ;
   • les utilisateurs : « Parcourir le dossier » et « Liste du dossier », sur ce dossier seulement, pour atteindre leur propre dossier sans voir ceux des autres. Par défaut « Utilisateurs authentifiés » ; ajoutez -GroupeEleves DEMO\Utilisateurs-Tous si les utilisateurs ont leur groupe ;
   • CREATOR OWNER : rien.
   Tout autre droit posé à la main sur la racine est retiré, et le compte rendu le nomme (la fenêtre demande confirmation avant) ;
3. elle crée le partage utilisateurs$ (le « $ » le cache dans le voisinage réseau) avec ces autorisations de partage : Administrateurs « Contrôle total », Utilisateurs authentifiés « Modifier » ; les droits fins restent ceux de NTFS. S'il existe déjà sur ce dossier, seules ses autorisations sont corrigées ; s'il existe sur un autre dossier, rien n'est fait : choisissez un autre nom ;
4. elle active l'énumération basée sur l'accès : en ouvrant \\srv-fichiers\utilisateurs$, chaque utilisateur ne voit que son dossier ;
5. elle affiche le modèle à coller dans les réglages de Kontivo, bloc « Dossier personnel », champ « Modèle de chemin du dossier » : \\srv-fichiers.demo.local\utilisateurs$\{sam} (nom DNS complet du serveur).

Chaque ligne du compte rendu commence par [OK] (déjà en place), [FAIT], [A FAIRE] (en vérification seule), [ATTENTION] ou [REFUS] : la préparation se relance sans risque, ce qui est déjà en place n'est jamais refait. Pour seulement vérifier, ajoutez -LectureSeule. Dans un script, le compte rendu est écrit sur la sortie d'erreurs (UTF-8) et le code de sortie vaut 0 (prêt), 1 (refus ou erreur), 2 (paramètres) ou 3 (vérification : des points à corriger).

Elle refuse, sans rien changer : un compte sans droits d'administrateur actifs sur le serveur (lancez l'invite « en administrateur ») ; un dossier sur un lecteur réseau ou un partage (lancez la préparation sur le serveur qui porte le disque, avec son chemin local) ; la racine d'un disque ou un dossier de Windows ; un nom de partage invalide ou réservé (C$, ADMIN$…) ; un groupe introuvable (vérifiez DOMAINE\nom, et que le serveur est membre du domaine) ; un groupe délégué trop large (« Utilisateurs du domaine », « Utilisateurs authentifiés »…) : il recevrait le droit de modifier tous les dossiers des utilisateurs.

À la main, si vous préférez

Droits à donner au groupe GG-ComptesAD :

• Autorisations du partage : au moins « Modifier » (ou « Contrôle total » pour tout le monde, si vous gérez les droits uniquement par NTFS, ce qui est courant) ;
• Autorisations NTFS sur le dossier racine du partage : « Modification », appliquée à « Ce dossier, les sous-dossiers et les fichiers ». Sur le serveur de fichiers, par exemple :

icacls "D:\Utilisateurs" /grant "DEMO\GG-ComptesAD:(OI)(CI)M"

Si l'outil signale « Dossier créé, mais le droit de l'utilisateur n'a pas pu être donné », donnez en plus au groupe le droit « Modifier les autorisations » sur la racine, puis donnez à la main le droit manquant à l'utilisateur concerné (l'outil ne modifie jamais un dossier qui existe déjà). Les droits des utilisateurs sur la racine restent ceux que vous avez fixés (en général : parcourir le dossier, sans voir ceux des autres) ; vérifiez qu'ils ne peuvent pas entrer dans _archives.

Si une stratégie de groupe (redirection de dossiers) crée déjà les dossiers des utilisateurs, décochez la case dans les réglages : l'outil ne fera alors que remplir les attributs du compte (chemin et lettre du lecteur), et aucun droit sur le partage n'est nécessaire.

7. Sur le poste

• Le compte délégué doit pouvoir ouvrir une session sur le poste d'administration (c'est le cas par défaut pour un utilisateur du domaine sur un poste de travail ; ce n'est pas le cas par défaut sur un contrôleur de domaine).
• Il doit pouvoir lire le dossier de l'outil : lancez l'outil une première fois avec ce compte, et faites taper par un administrateur du poste la commande icacls qu'il affiche, dans une invite de commandes ou une fenêtre PowerShell ouvertes en administrateur (voir la notice, § 3.3). Le dossier de données que l'outil crée alors (C:\ProgramData\ComptesAD) appartient à ce compte : un seul compte par dossier de données.
• Aucun droit d'administrateur local n'est nécessaire pour utiliser l'outil, et rien n'est à installer : RSAT n'est plus nécessaire depuis la version 2. ComptesAD.exe parle à l'annuaire en LDAP signé et chiffré (Kerberos, sinon NTLM), sur le port 389 du contrôleur de domaine.

8. Vérifier

1. Lancez l'outil avec le compte délégué, en lecture seule : runas /user:DEMO\adm-comptes "C:\ComptesAD\ComptesAD.exe -LectureSeule".
2. Dans les réglages, étape 1, la vérification doit afficher « ✓ Votre compte peut créer des comptes dans « Organisation › Utilisateurs » », la même chose pour « Organisation › Departs », et « ✓ Votre compte peut créer des groupes dans « Organisation › Groupes » » (le chemin complet de chaque OU est affiché : vérifiez que ce sont bien les OU déléguées, l'outil les ayant pré-remplies d'après leur nom).
3. L'aperçu ne doit pas afficher « Votre compte ne peut pas créer de comptes dans… ».
4. Sur le serveur de fichiers, C:\ComptesAD\ComptesAD.exe -PreparerPartage -Dossier D:\Utilisateurs -Partage utilisateurs$ -GroupeDelegue DEMO\GG-ComptesAD -LectureSeule doit finir par « tout est déjà en place ».
5. La première vraie application se fait sur une OU de test, avec quelques comptes fictifs. L'erreur « Droits insuffisants » pendant une application indique le droit qui manque à l'opération concernée.

L'outil ne contrôle pas les sous-OU une à une : un droit retiré à la main sur une OU de groupe ne se voit qu'à l'application (« Droits insuffisants »).

Kontivo 3, pour Active Directory · droits tirés du § 10.9 de la conception de l'outil ; préparation du partage : § 15.2 de la conception de la V2 · Active Directory est une marque de Microsoft.