Active Directory Permissions

Understanding this distinction makes the rest of this page straightforward. Most delegation mistakes come from granting a permission to the wrong one.

Some permissions below are held by the join account and some by the computer account. The Held By column identifies which.

This is the baseline. It covers a first-time join where Hammerspace creates the computer account itself, and it is enough for the join to complete, for Kerberos to be configured, and for the standard service principal names to be registered.

Why the baseline is this small. Because the join account creates the computer object, Active Directory automatically gives it control of that object. Setting the account password, recording the DNS host name, and registering the initial service principal names are all covered by that automatic control. As soon as the computer object is created by someone or something else, that automatic control no longer applies, and permissions must be delegated explicitly. That is the single idea behind most of the rows in the next table.

Alternative without delegation. Active Directory’s default "Add workstations to the domain" user right also allows a join, but the computer object is placed in the default Computers container and the number of objects an account may create is capped by the domain’s machine account quota. Sites that need the object in a specific organizational unit, or that will re-join over time, should use the delegation above instead.

Each row is additive on top of the baseline. Grant only the rows matching the capabilities the site will use.

Re-joining an existing computer account. Active Directory will not let one account change another account’s password without knowing the current password. Hammerspace does not know the existing computer account’s password, so it must be able to force a password reset. This is the Reset Password permission. It applies whenever the computer object was not created by the join account being used — most commonly when the AD team pre-creates the object in a controlled organizational unit, or when a different administrator performed the original join. The accompanying validated-write permissions let Hammerspace update the object’s DNS host name and service principal names, which the join account would otherwise have received automatically as the object’s creator.

Because a site usually cannot predict whether a re-join will one day be needed, granting this row up front is recommended. Without it, the join fails with an access-denied error, and the AD team must delete or reset the existing object before the join can succeed.

Leaving the domain. Leaving can either delete the computer account or leave it in place for a later re-join. Deleting it requires the delete permission. Keeping it requires nothing extra in the normal case. The one exception is a leave where administrator credentials are supplied and the computer account is missing the service principal name permission; Hammerspace then tries to restore that permission first so it can clean up all the service principal names.

DNS registration. After the join, Hammerspace registers DNS records for the SMB server name, the Anvil DNS name, and the configured or floating IP addresses. These registrations are made by the computer account, not by the administrator account used during the join, so the permissions apply to the computer account and to the DNS zone rather than to the organizational unit. In a zone using secure dynamic updates, an authenticated computer may create a new record and becomes its owner. If a record with the same name already exists and is owned by a different account, the update is refused even when every organizational unit permission is correct. Pre-created DNS records must therefore grant the Hammerspace computer account write access. This is one of the most commonly missed requirements.

Hammerspace recommends registering floating IPs, rather than static IPs, in these DNS records, so that a DSX node failure does not leave the name unreachable. An option in the Active Directory configuration keeps these DNS records in sync automatically as floating IPs are added or removed; when it is not selected, the DNS administrator must update the records manually after any such change.

Service principal names. NFS with Kerberos requires service principal names in Active Directory. Those that match the cluster’s computer account name are written by the computer account using a permission Active Directory grants to every computer for its own account, so they need no configuration.

Granting the baseline plus the pre-created and delete rows covers every join, re-join, and leave scenario without granting broad directory rights. On the organizational unit that will hold the Hammerspace computer object: