How to Configure Delegation of Cluster Machine Accounts with Active Directory Users and Computers Snapin
- Abstract:
- Overview
- How to prepare you cluster for Eyeglass automated DR failover
- Key Design used by Eyeglass is proxy on failover SPN Management
- Summary of Permissions
- Automated Solution with Eyeglass Computer Object Level Method:
- Automated Solution with Eyeglass Organizational Unit (OU) Method:
- How to Use Active Directory Delegation of Control Wizard to Delegate Service Principal Name Permissions to the cluster
- Example of SPN in ADSIedit Tool
- How to check cluster SPN permissions are set correctly
Abstract:
In order to automate DR with SyncIQ and Eyeglass with Active Directory and SMB shares, its important to ensure Service Principal Names (SPN) are synchronized with the machine account used by the DR cluster. This technical note provides a methodology to restrict, the AD permissions needed for automated SPN management during failover, audit and remediation in Eyeglass
Overview
In order to automate DR with SyncIQ and Eyeglass with Active Directory and SMB shares, its important to ensure Service Principal Names (SPN) are synchronized with the machine account used by the DR cluster.
Service Principal Names are used by Kerberos authentication and machine accounts and an New SPN name pair is created each time a new SmartConnect Zone Alias is created.
Note: Superna Eyeglass only manages SPN related to HOST. SPNs related to HDFS or NFS are not updated and will need to be manually repaired post failover.
How to prepare you cluster for Eyeglass automated DR failover
Eyeglass will create SmartConnect Zone names and aliases required on your DR cluster automatically in advance of a DR failover. This is done by mapping Subnet on cluster A to Subnet on Cluster B in the Eyeglass UI and once set all new SmartConnect Zone's created or Alias on the Production cluster will be synced to the DR cluster network pool and subnet. It’s important to setup AD and your cluster in advance of failover to eliminate authentication issues due to missing SPN entries on the machine account.
Key Design used by Eyeglass is proxy on failover SPN Management
During failover SPN deletes must occur against the source cluster AD machine, but during a real DR event the source cluster is not reachable to issue SPN commands. Eyeglass solves this by issuing proxy SPN update commands to the DR cluster, but references the source cluster machine account name. This means that the Eyeglass can correct SPN entries on the source cluster even when it's not reachable.
Note: This proxy SPN management solution depends on the Delegation being done as stated below with an OU used for the cluster machine accounts and allowing each cluster to update the others SPN using ISI proxy commands.
Summary of Permissions
- Each cluster must have permissions to read and write to the SPN property of it's own computer object
- Each cluster must have permissions to read and write to the SPN property of the opposite cluster computer object
Automated Solution with Eyeglass Computer Object Level Method:
Use this method to restrict, at the object level, the AD permissions needed for automated SPN management during failover and audit and remediation features in Eyeglass. Recommended with a pair of clusters. Use the Organization Unit (OU) method described in the next section if more clusters objects are involved.
- Select the first cluster in the pair in Users and Computers snappin as administrator user. Select properties and security tab and then the “Advanced” button of the dialog box. See below:
- Click the add button on the Permissions window (see above)
- For Principal click select
- Then type “SELF” and check button and OK (see below)
- Scroll down the list of permissions and select read and write Service Principal Name (see below)
- Now we need to allow the other cluster machine account to access the SPN properties of the cluster machine account you have selected first . This is for failover of SPN proxy feature in Eyeglass that ensures SPN’s can be managed even if a cluster is not reachable. This is called Cross permissions delegation.
- Click the add button again but this time when selecting the principal to grant permissions, enter the “other” cluster in the replication pair in the dialog box. In the example below you can see the dialog box title is “CLUSTERA” but the principal selected for the grant is “CLUSTERB”. Find the same read and write properties for service principal name as done above and apply the permissions to the CLUSTERB machine account.
- The above steps ONLY applied object level permissions to one cluster and both clusters must have these permissions for automated failover and failback.
- REPEAT above steps again by select the 2nd cluster of the pair and apply two sets of permissions
- The Delegation permissions are now completed.
Automated Solution with Eyeglass Organizational Unit (OU) Method:
Use this method when more than one cluster pair is replicating. This method saves steps by doing the delegation once at the OU level versus at the object level. THis method is recommended with greater than 2 clusters to delegate.
To avoid Eyeglass requiring the administrator AD account to synchronize the SPN for production or DR clusters, the following one time steps MUST be executed:
- Using Active Directory Users and Computers Snap In admin tool, create an OU for the PowerScale cluster computer accounts.
- Move the cluster AD computer objects with drag and drop into the OU created above.
- Right click the and select Delegate Control (note this applies to all computers accounts in this folder or OU).
- Select the Delegation option.
- Follow screen shots below that assign the cluster permissions to read and write the service principal name.
