Delegating rights to the account that starts Kontivo

The exact rights the tool needs, in the directory and on the home folder share.

Kontivo 3, for Active Directory (ComptesAD.exe) · October 2026 · back to the user guide.

1. Why a delegated account

Kontivo acts in the directory with the Windows account that starts it. A “Domain Admins” account works, but a handling error would then have rights over the whole domain. A delegated account only has rights on the three folders (OUs) chosen in the settings: the users folder, the departed accounts folder and the directory groups folder. Even in case of error, it cannot touch anything else.

The tool needs no administrator rights on the computer: it only listens on the computer itself (address 127.0.0.1) and stores its data in C:\ProgramData\ComptesAD, which a standard user can create.

2. Create the account and its group

Give the rights to a group, then put the account in this group: you will be able to change accounts without redoing the delegation. In the examples, the domain is called DEMO (demo.local):

a global security group, for example GG-ComptesAD;
a user account, for example adm-comptes, a member of this group, with a long password, stored outside the folders of the managed users;
this account must not be a member of any administrative group.

In the commands below, replace the OU names with those of your directory (the examples use the names proposed by the tool, People, Leavers and Groups, under a parent OU Organization):

Users OU               OU=People,OU=Organization,DC=demo,DC=local
Departed accounts OU   OU=Leavers,OU=Organization,DC=demo,DC=local
Groups OU              OU=Groups,OU=Organization,DC=demo,DC=local

Create these three OUs first (with “Active Directory Users and Computers”, or in the tool's settings with an account that has the right to do so): the delegated account cannot create an OU outside the users folder.

3. The rights, folder by folder

Where	Rights	Why
Users OU (including sub-OUs)	Create and delete user objects; create organizational unit objects; on descendant users: read and write all properties, delete, reset password.	Create the accounts and the group OUs, move users between groups (move), set the temporary passwords.
Departed accounts OU	Create and delete user objects; on descendant users: read and write all properties, delete. “Delete subtree” only if error 8213 (“The account contains objects”) appears.	Receive the departed accounts, delete them after the period, bring them back.
Groups OU	Create and delete group objects; on descendant groups: read and write all properties (including `member`, `adminDescription` and `info`).	Create the directory groups, change their members, maintain the `ComptesAD-Etat` state group.
Modify permissions	Only for the “remove protection from accidental deletion” option, on the users of the users OU and the departed accounts OU; and, optionally, on the users OU itself so that the tool can protect the group OUs it creates (see below).	Move or delete a protected account; protect the group OUs created.
Home folder share	Modify on the root of the share (see § 6), only if the “Create the folder on the share and give the user permissions” option is checked (it is checked by default as soon as a path template is filled in).	Create each user's folder, create `_archives` and rename the folders to archive into it.

Moving an account (change of group, leaving, return) requires “delete” on the account itself and “create child” on the destination OU. The “delete” right on the users of the users OU is necessary: when the group OUs created by the tool are protected from accidental deletion, this protection sets on their parent OU a deny of “delete child objects”, which would prevent moving an account stored directly in the users OU (user waiting for a group).

The group OUs created by the delegated account

The tool creates each group OU in two stages: first the OU, without protection, then, in a separate step, the protection from accidental deletion. Setting this protection modifies the permissions of the users OU (the deny described above), which the delegation in this document does not allow. If the right is missing, the OU is still created and the operation is successful, with this note in the log: “OU created, but protection from accidental deletion was not set (missing the ‘modify permissions’ right on the parent OU): an administrator can set it in Active Directory Users and Computers (Object tab of the OU).” Two ways to proceed afterward:

leave the group OUs unprotected (they only contain managed user accounts, and the tool recreates them if needed), or protect them manually with an administrator account;
or give the delegated group “Modify permissions” on the users OU only (not on its sub-OUs), which is a broad right, to be weighed with the domain administrator:
```
dsacls "OU=People,OU=Organization,DC=demo,DC=local" /G "DEMO\GG-ComptesAD:WD"
```

The first run on a test OU (user guide, § 6) shows which of the two cases occurs in your directory.

For everything else, the tool only reads, with the read rights that every domain account has by default: the list of usernames in the domain (to avoid duplicates), the password policies, the domain controllers.

4. Granting the rights with dsacls

dsacls is installed with the Active Directory tools (RSAT) and on domain controllers. Type these commands in a command prompt opened with a “Domain Admins” account. /I:T applies the right to the OU and to everything it contains, /I:S only to the objects it contains.

Users OU

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

Departed accounts OU

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

Only if a deletion fails with error 8213 (“The account contains objects”):

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

Groups OU

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

Optional: remove protection from accidental deletion

Only if you want to use the “Remove protection” option (settings, “Advanced” panel, or preview button):

dsacls "OU=People,OU=Organization,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:WD;;user"
dsacls "OU=Leavers,OU=Organization,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:WD;;user"

These commands follow the tool's design; they have not yet been run on a real domain. Check them during the first run on a test OU (user guide, § 6). In particular, the name of the Reset Password extended right remains to be confirmed on a domain controller in a language other than English. If a command is refused, the Delegation of Control Wizard (below) gives the same result.

5. Granting the rights with the Delegation of Control Wizard

In “Active Directory Users and Computers”, right-click the OU, Delegate Control…, add the GG-ComptesAD group, then choose Create a custom task to delegate. The labels below may vary slightly depending on the version of Windows.

Users OU (two passes of the wizard)

First pass: Only the following objects in the folder, check User objects, then Create selected objects in this folder and Delete selected objects in this folder. On the next page, under General: Read All Properties, Write All Properties, Delete, Reset Password.
Second pass: Only the following objects in the folder, check Organizational Unit objects and Create selected objects in this folder; next page: no additional permission is needed (check Read if needed).

Departed accounts OU

One pass, like the first pass for the users OU, without “Reset Password”.

Groups OU

One pass: Group objects, create and delete; permissions Read All Properties and Write All Properties.

After the wizard, check the result: right-click the OU, Properties, Security tab, Advanced (the Security tab only appears with View > Advanced Features). The rights on users must apply to “Descendant User objects”, and the creation rights to the sub-OUs as well.

6. The home folder share

If a path template is filled in in the settings (for example \\srv-fichiers\people$\{sam}), the “Create the folder on the share and give the user permissions” check box is checked by default. For each new user, the tool:

creates the folder \\srv-fichiers\people$\lea.martin, if it does not exist (an existing folder is never modified);
gives the user, by their SID, the chosen permission on this folder and its contents: “Modify” (default) or “Full control”;
when the account is permanently deleted, if archiving is chosen, creates \\srv-fichiers\people$\_archives if needed and renames the folder into it (_archives\lea.martin_2027-10-05). Nothing is erased, and the folder's permissions do not change.

Prepare the share in one go: ComptesAD.exe -PreparerPartage

The share is prepared on the file server (preferably not on the domain controller), only once, by an administrator of that server. Copy ComptesAD.exe to it (for example to C:\ComptesAD), then type, in a command prompt or PowerShell window opened as administrator:

C:\ComptesAD\ComptesAD.exe -PreparerPartage -Dossier D:\People -Partage people$ -GroupeDelegue DEMO\GG-ComptesAD

Without parameters, a small window asks for the folder, the share name, the delegated group and, optionally, the users' group, with a Check button (nothing is changed) and a Prepare button. The preparation does the following, in this order:

it creates the D:\People folder if it is missing;
it sets the NTFS permissions of the root, disabling inheritance from the disk:
- SYSTEM and Administrators: “Full control”;
- the delegated group (GG-ComptesAD): “Modify”, on this folder, subfolders and files;
- the users: “Traverse folder” and “List folder”, on this folder only, so that they can reach their own folder without seeing the others'. By default “Authenticated Users”; add -GroupeEleves DEMO\People-All if the users have their own group;
- CREATOR OWNER: nothing.
Any other permission set manually on the root is removed, and the report names it (the window asks for confirmation first);
it creates the share people$ (the “$” hides it from network browsing) with these share permissions: Administrators “Full Control”, Authenticated Users “Change”; the detailed permissions remain those of NTFS. If the share already exists on this folder, only its permissions are corrected; if it exists on another folder, nothing is done: choose another name;
it enables access-based enumeration: when opening \\srv-fichiers\people$, each user only sees their own folder;
it displays the template to paste into the Kontivo settings, “Home folder” block, “Folder path template” field: \\srv-fichiers.demo.local\people$\{sam} (full DNS name of the server).

Each line of the report starts with [OK] (already in place), [DONE], [TO DO] (check only), [WARNING] or [REFUSED]: the preparation can be run again safely, and what is already in place is never redone. To check only, add -LectureSeule. In a script, the report is written to the error output (UTF-8) and the exit code is 0 (ready), 1 (refusal or error), 2 (parameters) or 3 (check: some items need correcting).

It refuses, without changing anything: an account without active administrator rights on the server (open the prompt “as administrator”); a folder on a network drive or a share (run the preparation on the server that hosts the disk, with its local path); the root of a disk or a Windows folder; an invalid or reserved share name (C$, ADMIN$…); a group that cannot be found (check DOMAIN\name, and that the server is a member of the domain); a delegated group that is too broad (“Domain Users”, “Authenticated Users”…): it would receive the right to modify all the users' folders.

The delegated account creates each user's folder and becomes its owner, which allows it to give the user their permission there. The _archives subfolder only inherits the permissions of SYSTEM, the Administrators and the delegated group: users cannot enter it.

Manually, if you prefer

Permissions to give to the GG-ComptesAD group:

Share permissions: at least “Change” (or “Full Control” for Everyone, if you manage permissions through NTFS only, which is common);
NTFS permissions on the root folder of the share: “Modify”, applied to “This folder, subfolders and files”. On the file server, for example:

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

If the tool reports “Folder created, but the user's permission could not be granted”, also give the group the “Change permissions” right on the root, then manually give the missing permission to the user concerned (the tool never modifies a folder that already exists). The users' permissions on the root remain the ones you set (usually: traverse the folder, without seeing the others'); check that they cannot enter _archives.

Creating and archiving folders on a real share, and preparing the share itself, are items of the acceptance test on a real server: do the first trial with a test OU and a few fictitious accounts.

If a Group Policy (Folder Redirection) already creates the users' folders, clear the check box in the settings: the tool will then only fill in the account attributes (path and drive letter), and no permission on the share is needed.

7. On the computer

The delegated account must be able to sign in on the administration computer (this is the case by default for a domain user on a workstation; it is not the case by default on a domain controller).
It must be able to read the tool's folder: start the tool once with this account, and have an administrator of the computer type the icacls command it displays, in a command prompt or PowerShell window opened as administrator (see the user guide, § 3.3). The data folder that the tool then creates (C:\ProgramData\ComptesAD) belongs to this account: one account per data folder.
No local administrator rights are needed to use the tool, and nothing needs to be installed: RSAT has not been needed since version 2. ComptesAD.exe talks to the directory over signed and encrypted LDAP (Kerberos, otherwise NTLM), on port 389 of the domain controller.

8. Checking

Start the tool with the delegated account, in read-only mode: runas /user:DEMO\adm-comptes "C:\ComptesAD\ComptesAD.exe -LectureSeule".
In the settings, step 1, the check must display “✓ Your account can create accounts in ‘Organization › People’”, the same for “Organization › Leavers”, and “✓ Your account can create groups in ‘Organization › Groups’” (the full path of each OU is displayed: check that these are indeed the delegated OUs, since the tool prefilled them based on their names).
The preview must not display “Your account cannot create accounts in…”.
On the file server, C:\ComptesAD\ComptesAD.exe -PreparerPartage -Dossier D:\People -Partage people$ -GroupeDelegue DEMO\GG-ComptesAD -LectureSeule must end with “everything is already in place”.
The first real run is done on a test OU, with a few fictitious accounts. The “Insufficient rights” error during a run indicates the right that is missing for the operation concerned.

The tool does not check the sub-OUs one by one: a right removed manually on a group OU only shows up during the run (“Insufficient rights”).

Kontivo 3, for Active Directory · rights taken from § 10.9 of the tool's design; share preparation: § 15.2 of the V2 design · Active Directory is a trademark of Microsoft.