Three ways to use Microsoft Active Directory for NetApp ONTAP cluster admin logins

In NetApp ONTAP, a cluster administrator user can log into a cluster either via CLI or the System Manager GUI to manage resources. The user can either be a locally created user (such as the default “admin” user) or it can be a user hosted in a centralized name services server, such as Microsoft Active Directory for ease of use.

Active Directory generally provides Windows users and groups, which can leverage Kerberos authentication for user logins. But Active Directory can also be configured to act as a UNIX identity provider via LDAP. ONTAP is able to use either method to allow cluster logins to occur with centralized users.

First, some general information about each method.

* Can also use Global Catalog ports if UNIX LDAP attributes are replicated to the GC

Method #1: Cluster logins using Windows domain users via a domain tunnel

This is probably the easiest way to get AD users to work as cluster administrators, as there’s nothing extra to do on the Windows server.

For the NetApp ONTAP server, this requires something called a “domain tunnel,” which allows the cluster SVM to piggy back off of the AD domain configuration of another SVM in the cluster to provide the ability to login using Windows users. The downside of this method is that you need an SMB server configured in the environment. While this doesn’t require a license when using just for login access, it does still require things like access to create and modify domain objects (usually with a domain administrator). In many cases, the storage team doesn’t have AD domain access, and in some cases, the domain services team does not want the storage system added to the domain.

Once a domain tunnel is created, Windows users (or users that are members of a group) can log in to a cluster as an administrator.

So, the basic steps are:

• Create an SMB server in a data SVM (if one is not created already)
• Create a domain tunnel to that data SVM
• Create security logins with the “domain” authentication method for the application methods you want to use (ie, SSH, ONTAPI for REST API, HTTP for System Manager)

In my environment, I have a domain tunnel and these are the commands I used to create a security login for a group of users:

security login create -user-or-group-name "NTAP\ONTAP logins" -application ssh -authentication-method domain
security login create -user-or-group-name "NTAP\ONTAP logins" -application ontapi -authentication-method domain
security login create -user-or-group-name "NTAP\ONTAP logins" -application http -authentication-method domain

I can check my user login’s group membership with the following command from the data SVM:

set advanced; access-check authentication show-creds -vserver [SVM] -win-name test

When I do that, I can see that user is a member of the ONTAP login group:

Windows Membership:
  NTAP\ONTAP logins (Windows Domain group)

login as: NTAP\test
Pre-authentication banner message from server:
| Access restricted to authorized users
End of banner message from server
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server
This is your first recorded login.
cluster::>

And the user can also login to System Manager:

Pros: Simple to configure, no additional steps on the AD server; authentication is passed using encryption
Cons: Requires an SMB machine object in the AD domain

Method #2: Microsoft AD with UNIX LDAP users + password fields

If domain tunnels aren’t an option, then another option is to leverage the native UNIX LDAP user and group functionality in Active Directory.

While UNIX attributes (such as uid, uidNumber, gidNumber, etc.) are available by default on AD objects, they don’t get automatically populated. You can either manually populate these or use a third-party application such as Centrify to do this.

For details on configuring AD to use UNIX users and groups, see:

TR-4835: How to configure LDAP in ONTAP

However, for ONTAP cluster logins, Microsoft Server for NIS is needed to provide password synchronization between Windows and UNIX users. When this is installed and configured, password changes to Windows users will be synced up with the unixUserPassword field on the account.

If using LDAP for cluster logins, then the following are the basic steps:

• Install Server for NIS (if not already installed) and configure it for password synchronization *or* manually hash/set the password in the unixUserPassword attribute (not recommended)
• Configure LDAP users in AD (if not already configured) using the UNIX attributes tab
• Change the password on the user to sync up the unixUserPassword (you can set the same password) *or* manually hash/set the attribute (not recommended)
• Change the unixUserPassword searchFlags attribute in ADSI from “Confidential” to 0 (Confidential prevents ONTAP from reading the password field)
• Create an LDAP client associated with the cluster SVM with the MS-AD-BIS default schema
• Test LDAP connectivity and user/group lookups
• Configure the cluster’s nsswitch database for passwd and group to use LDAP
• Create security login groups or users with the “nsswitch” authentication method
• Test logins

Sample AD Server for NIS configuration

Enable password synchronization:

Configure users with UNIX attributes:

Optional: set password encryption hash

• AD defaults to “crypt”
• Crypt is recommended, but ONTAP can use either for password hashing
• Hash changes with each password reset, even if password remains the same

Sample password hashing with md5 (Password = P@ssw0rd):

Sample password hashing with crypt (Password = P@ssw0rd):

unixUser object searchFlag setting (from ADSI):

When the value is the default of 128 (CONFIDENTIAL), this is what ONTAP sees for the user when querying for the password:

cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username test
  (vserver services name-service getxxbyyy getpwbyname)
pw_name: test
pw_passwd:
pw_uid: 12345
pw_gid: 10000
pw_gecos: test
pw_dir: /home/test
pw_shell: /bin/sh

As a result, logins will fail because ONTAP can’t “see” the password, since AD is hiding it.

When the value is 0 (not set), ONTAP can see the hashed password and allows logins to authenticate:

cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username test
  (vserver services name-service getxxbyyy getpwbyname)
pw_name: test
pw_passwd: $1$2mj3zzzz$vQB1oPmgJ4O8v83yraDB/1
pw_uid: 12345
pw_gid: 10000
pw_gecos: test
pw_dir: /home/test
pw_shell: /bin/sh

To create a security login for an LDAP user:

security login modify -user-or-group-name [username] -application ssh -authentication-method nsswitch 

To create a security login for an LDAP group, add the is-ns-switch-group=yes option and ensure that the ns-switch database is set to use LDAP,files for both passwd and group:

security login modify -user-or-group-name [groupname] -application ssh -authentication-method nsswitch -is-ns-switch-group yes

Pros: Centralized users in LDAP, no need for SMB server tunnel
Cons: Complex, requires Server for NIS installation for best results, password hash is passed visibly over the wire (unless LDAPS is used), ADSI edit is needed to change password visibility

Method #3: Windows AD LDAP with Fast bind

Starting in ONTAP 9.11.1, ONTAP introduced “Fast bind” functionality for LDAP, which leverages the password of the user requesting access rather than needing to do an LDAP query to populate the password. When using fast bind, no special password hashing or schema changes are required on the LDAP server.

The basic setup steps are:

• Configure LDAP users/groups in AD (if not already configured)
• Create an LDAP client associated with the cluster SVM with the MS-AD-BIS default schema; LDAPS or Start-TLS required
• Test LDAP connectivity and user/group lookups
• Configure the cluster’s nsswitch database for passwd and group to use LDAP
• Create security login groups or users with the “nsswitch” authentication method
• Test logins

Pros: Simple, encrypts passwords over the wire (encrypted LDAP is required)
Cons: Need ONTAP 9.11.1 or later

Sample LDAP client configuration for fast bind:

Client Configuration Name: AD-LDAP-LOGIN
                         LDAP Server List: x.x.x.x
            (DEPRECATED)-LDAP Server List: -
                  Active Directory Domain: -
       Preferred Active Directory Servers: -
         Restrict discovery to site scope: false
Bind Using the Vserver's CIFS Credentials: false
                          Schema Template: MS-AD-BIS
                         LDAP Server Port: 636
                      Query Timeout (sec): 3
        Minimum Bind Authentication Level: sasl
                           Bind DN (User): username
                                  Base DN: DC=domain,DC=local
                        Base Search Scope: subtree
                                  User DN: -
                        User Search Scope: subtree
                                 Group DN: -
                       Group Search Scope: subtree
                              Netgroup DN: -
                    Netgroup Search Scope: subtree
               Vserver Owns Configuration: true
      Use start-tls Over LDAP Connections: false
           Enable Netgroup-By-Host Lookup: false
                      Netgroup-By-Host DN: -
                   Netgroup-By-Host Scope: subtree
                  Client Session Security: none
                    LDAP Referral Chasing: false
                  Group Membership Filter:
                         Is LDAPS Enabled: true
                      Try Channel Binding: true

Sample command for security login creation with fast bind:

security login create -user-or-group-name [username] -application [ssh|ontapi|http] -authentication-method nsswitch -role admin -is-ldap-fastbind yes