DR Configuration Guides

How to Configure Delegation of Cluster Machine Accounts with Active Directory Users and Computers Snapin

Home

    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

    1. Each cluster must have permissions to read and write to the SPN property of it's own computer object
    2. 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.

    1. 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:

    Screen Shot 2016-01-28 at 7.25.13 AM.png

    1. Click the add button on the Permissions window (see above)
    2. For Principal click select
    3. Then type “SELF” and check button and OK (see below)

    Screen Shot 2016-01-28 at 7.16.55 PM.png

    1. Scroll down the list of permissions and select read and write Service Principal Name (see below)
    2.  
    1. 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.
    2. 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.  

    Screen Shot 2016-01-28 at 4.03.10 PM.png

    1. The above steps ONLY applied object level permissions to one cluster and both clusters must have these permissions for automated failover and failback.
    2. REPEAT above steps again by select the 2nd cluster of the pair and apply two sets of permissions
    3. 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:

    1. Using Active Directory Users and Computers Snap In admin tool, create an OU for the PowerScale cluster computer accounts.

    Screen Shot 2016-01-21 at 2.32.35 PM.png

    1. Move the cluster AD computer objects with drag and drop into the OU created above.
    2. Right click the and select Delegate Control (note this applies to all computers accounts in this folder or OU).
    3. Select the Delegation option.

    Screen Shot 2016-01-21 at 3.09.50 PM.png

    1. Follow screen shots below that assign the cluster permissions to read and write the service principal name.

    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


    spn-delegation-check.gif





    © Superna Inc