Guides:Joining QuantaStor to Active Directory with a Pre-Created Computer Account

By Steve Umbehocker, CTO, OSNexus · Updated November 2, 2026

When a storage system joins Active Directory, it needs a computer account: an object in the directory that holds the machine's password and identity. By default, QuantaStor creates that object during the join, using the credentials you enter in the Join AD Domain dialog. That only works when the join account is allowed to create computer objects. Many AD sites don't allow that. In those domains an AD administrator pre-stages the computer object in an organizational unit (OU) they choose, then gives a less-privileged account only the rights it needs to join with that object. QuantaStor supports this model through the Use existing computer account (pre-created in AD) option. When the option is on, the join looks up the pre-created account and uses it where it is. If the account is missing, the join fails cleanly and creates nothing. A later leave never removes the object from the directory. This guide covers what the AD side needs to prepare, how to run the join from the web UI or CLI, HA pairs included, and how to read a failed join.

Why it matters

Giving a storage administrator Domain Admin rights, or the right to create computer objects anywhere in the domain, is something most security teams refuse. With a pre-created account, each team keeps its own job:

• The AD team decides the object's name, its OU, and the Group Policy that applies to it. They delegate rights on that one object only.
• The storage team joins nodes with an account that can't create, move or delete anything else in the directory.
• Auditors see computer objects that were created by a named directory administrator, in the OU where policy expects them.

Without the option, a join account that lacks create rights simply fails. The workarounds are worse: borrowing a privileged account for the join, or letting objects land in the default Computers container.

How it works

With Use existing computer account ticked, the join changes in four ways:

1. Lookup first. Before it writes any configuration, the join searches AD for a computer object whose account name matches the node's NetBIOS name. NetBIOS names are limited to 15 characters, so a longer hostname is matched on its first 15 characters, in upper case. If no object is found, the task stops with a message like No computer account named 'QS-NODE1' exists in Active Directory. Create it before joining, or clear the 'Use existing computer account' option to let the join create one. Nothing has been changed on the node at that point, so there is nothing to clean up.
2. The account stays in its OU. Any computer-account OU you enter is ignored, and the dialog greys out the OU field while the option is ticked. Moving an existing object into another OU needs rights a delegated account usually doesn't have, and it would undo the AD administrator's placement.
3. The object is never deleted or disabled. A normal leave deletes the computer account, or disables it if the account is kept. With the option on, neither Active Directory Leave nor the cleanup after a failed join touches the object in the directory. You can rejoin the node later without asking the AD team to recreate or re-enable it.
4. The rest of the join is the same. ID mapping, trusted domains, DNS registration and the KDC list all behave as described in Join AD Domain and Active Directory ID Mapping.

Credential checking

Whether or not the option is on, the join now checks credentials first. It obtains a Kerberos ticket for the join account. If the domain rejects the account or its password, the join stops right there. Typical causes are a wrong or expired password, an account that is locked or disabled, or an unknown user. The task reports the domain's own reason:

Error initializing kerberos with the domain: kinit: Password incorrect while getting
initial credentials. Please make sure that the domain user name and password are correct.

Every domain controller gives the same answer, and each retry with the same password counts as another bad logon. So a typo costs exactly one bad logon instead of several, and the join account is much less likely to hit the domain's lockout threshold. Other kinit failures, such as an unreachable KDC or clock skew, don't stop the join. The join carries on with its own DC discovery, and if it fails, the task shows the error the join command printed, not a generic message.

Design and sizing

Plan the AD objects before anyone opens the dialog:

Item	Guidance
Object name	The node's NetBIOS name, at most 15 characters. Use one object per node.
OU	Any OU the AD team chooses. QuantaStor leaves it there.
HA pairs	Pre-create an object for each node in the pair. Each node joins with its own account.
Join account	A standard user, delegated rights on the pre-created objects only. It does not need Domain Admin rights.
KDC	List several domain controllers, separated by commas, so the join doesn't depend on one DC.
ID mapping	Use RID or autorid when more than one appliance shares the domain, so UIDs match across nodes.

On the AD side, create the object with Active Directory Users and Computers or with New-ADComputer. Then delegate the join account the rights a domain join needs on that object. These typically include resetting the password and writing the DNS host name and service principal name. For example:

New-ADComputer -Name "QS-NODE1" -SamAccountName "QS-NODE1$" `
  -Path "OU=Storage,OU=Servers,DC=example,DC=com" -Enabled $true
New-ADComputer -Name "QS-NODE2" -SamAccountName "QS-NODE2$" `
  -Path "OU=Storage,OU=Servers,DC=example,DC=com" -Enabled $true

Setting it up

In the web UI, open Storage Management → Network Shares → Active Directory → Join AD Domain (toolbar), as described in Active Directory Join.

1. Select the storage system(s) to join. For an HA pair, join both nodes.
2. Enter the NetBIOS Domain, the DNS Realm and the KDC list.
3. Enter the delegated join account and its password.
4. Choose the ID mapping mode (see Active Directory Configuration).
5. Tick Use existing computer account (pre-created in AD). Leave the computer-account OU empty; the dialog disables it.
6. Start the join and watch the task. Its first step is the computer-account lookup.

The AD Account Settings tab, where the Domain, Realm and KDC fields, the ID Mapper and the delegated join account's Domain Admin and Password fields are entered

The Advanced Settings tab with Use existing computer account (pre-created in AD) ticked; note that the Organizational Unit field above it is greyed out

The same join from the QuantaStor CLI Command Reference:

qs share-join-domain --storage-system=qs-node1 --domain=EXAMPLE \
  --realm=example.com --kdc=dc1.example.com,dc2.example.com \
  --ad-admin=svc-qsjoin --ad-password='********' \
  --ad-use-existing-computer-account=true

Repeat for the second node of an HA pair. Its pool is configured as described in Create Storage Pool High-Availability Group.

Operating and testing

Test with one node before rolling out to all of them:

• Missing object: join a node whose object hasn't been created yet. The task should fail at the lookup with the "No computer account named …" message, and no new object should appear in AD.
• Happy path: create the object and join again. Then confirm that the task completed and that the object is still in its OU.
• Leave and rejoin: leave the domain and check that the object still exists and is still enabled. Rejoining should then work without any help from the AD team.

When a join fails, read the task message before you retry:

Task message	Meaning	Action
No computer account named '…' exists	The lookup found no matching object	Create the object, or check the name against the node's 15-character NetBIOS name
Could not look up the pre-created computer account	The directory search itself failed or timed out	Check DNS, the KDC list and DC reachability
Error initializing kerberos … user name and password	The domain refused the credentials	Fix the password. One bad logon has been spent, so don't retry blindly
Any other join error	The join command's own output	Read the reason it gives; check the delegated rights on the object

FAQ

Does the join account need Domain Admin rights?

No. With a pre-created computer account, the join account only needs the delegated rights on that object that a domain join uses. It never creates, moves or deletes anything else in the directory.

What happens if I enter an OU while the option is ticked?

The OU is ignored and the account stays where the AD administrator placed it. The web dialog disables the OU field as soon as the option is ticked, so the setting can't contradict itself.

Will leaving the domain delete the pre-created object?

No. With the option on, neither a leave nor the cleanup after a failed join deletes or disables the computer object. The node can rejoin later with the same object.

How do I join an HA pair this way?

Pre-create one computer object per node, each named after that node's NetBIOS name. Then join each node with the option ticked. Both nodes can sit in the same OU, and the same delegated account can join both.

Why did a wrong password not lock the join account?

The join checks the credentials with a single Kerberos request before anything else. It stops at the first refusal and doesn't retry against other domain controllers. A typo costs one bad logon, and the task names the real cause.

---

Part of the QuantaStor Guides series. For reference documentation, see the QuantaStor documentation.