Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Validate AD Cluster Delegation for SPN Failover and Failback

Introduction​

Failover requires the target cluster to have Active Directory permissions to manage Service Principal Names (SPNs) on the source cluster's AD machine account, and failback requires the reverse. This delegation is configured per the SPN delegation guide for each cluster's machine account. Use the test procedure below to validate that delegation is set up correctly before you need it for a real failover or failback — a common misconfiguration is delegating the wrong computer account.

If delegation is not set up correctly, failover or failback fails with one of:

  • An LDAP constraint violation
  • An LDAP permissions error

Locate the AD Machine Account Name​

Log in to the cluster as root and run:

isi auth ads list -v

This returns the machine account name registered in Active Directory for that cluster.

Test Methodology​

The full test covers four scenarios — a SELF test and a CROSS test, run from both the primary and DR cluster:

ScenarioRun fromTarget account
Primary SELFPrimary clusterPrimary cluster's own machine account
Primary CROSSPrimary clusterDR cluster's machine account
DR SELFDR clusterDR cluster's own machine account
DR CROSSDR clusterPrimary cluster's machine account

Each test creates a temporary SPN, verifies it was created, then deletes it and verifies the deletion — confirming the delegation actually grants add/remove permissions, not just read access.

note

These tests require two OneFS clusters joined to the same Active Directory domain. Commands below use isi_classic, available on OneFS 8.x.

SELF Test (run on the cluster you're testing)​

  1. Log in to the cluster using the eyeglass service account and confirm the identity:

    whoami

  2. Add a test SPN:

    sudo isi_classic auth ads spn add --machinecreds --spn=HOST/superna.test.spn --domain=<your-domain>

  3. Confirm the SPN was created:

    sudo isi_classic auth ads spn list --machinecreds --domain=<your-domain>

  4. Delete the test SPN:

    sudo isi_classic auth ads spn delete --machinecreds --spn=HOST/superna.test.spn --domain=<your-domain>

  5. Confirm the SPN was deleted by re-running the list command from step 3 — it should no longer appear.

CROSS Test (run on one cluster, targeting the other cluster's machine account)​

Use the same add/list/delete pattern as the SELF test, but add --account=<other-cluster-machine-account>$ (note the trailing $ after the account name) to target the other cluster's AD computer account instead of the local one:

sudo isi_classic auth ads spn add --machinecreds --account=<other-cluster-account>$ --spn=HOST/superna.test.spn --domain=<your-domain>
sudo isi_classic auth ads spn list --machinecreds --account=<other-cluster-account>$ --domain=<your-domain>
sudo isi_classic auth ads spn delete --machinecreds --account=<other-cluster-account>$ --spn=HOST/superna.test.spn --domain=<your-domain>

A successful CROSS test from the primary cluster (targeting the DR cluster's account) confirms the primary cluster is delegated to manage the DR cluster's SPNs — the permission needed for failover. Run the CROSS test from the DR cluster (targeting the primary cluster's account) to confirm the reverse delegation needed for failback.

Interpreting Results​

  • If the add/list/delete sequence succeeds in all four scenarios, AD delegation is correctly configured for both failover and failback.
  • If a CROSS test fails (SELF succeeds but CROSS does not), delegation was granted for the wrong computer account, or the delegation was not extended to the peer cluster's account at all — review the AD delegation configuration for the account referenced in the failed test.
  • If a SELF test fails, the cluster's own machine account does not have the base SPN management permission it needs — confirm the account used for delegation matches the account returned by isi auth ads list -v.

See Also​