How to: NetApp ONTAP LDAP logins using Windows AD (without UNIX identities)

NetApp ONTAP is NetApp’s flagship storage OS that can act as a data management toolkit for multiple protocols, including NAS, SAN and S3/object. Generally, administrators can login to the storage using a username/password combination stored locally on the system (or using SSH keys/REST auth tokens).

It is also possible to login to an ONTAP cluster using Active Directory by creating a domain tunnel, where you join an AD domain to a storage VM and then piggyback the cluster logins with that SMB server, as well as using LDAP with UNIX identities for cluster logins by way of LDAP fastbind.

Additionally, you could use Linux-based LDAP for authentication into the ONTAP cluster, such as what I covered a while back in this blog.

Configuring FreeIPA LDAP for ONTAP logins

So if I have these options already, what is the point of this blog?

What if I don’t want to add UNIX attributes to AD or use a domain tunnel?

In many cases, enterprise AD environments are very allergic to changes to their AD domains. In some cases, the requests are shot down before they get anywhere. So if your AD domain doesn’t have UNIX attributes set for Windows users (such as uid, uidNumber, gid, etc.) then you might not be able to get them added.

As for domain tunnels, they can work – provided you have administrator rights to add objects to the domain. If you already have an SMB server, even better! But in some cases, you don’t have an SMB server and you might be unable to get approval to add one – even for logins.

So while it looks like you might be stuck, you’re not. We can create an alternate configuration to allow Windows users without UNIX attributes populated (including the unixPassword attribute) by leveraging the LDAP attributes presented by default by Windows Active Directory.

What attributes can we use?

By default, a brand new Windows user will have the following attributes populated:

accountExpires                       : 9223372036854775807
AccountNotDelegated                  : False
AllowReversiblePasswordEncryption    : False
AuthenticationPolicy                 : {}
AuthenticationPolicySilo             : {}
BadLogonCount                        : 0
badPasswordTime                      : 0
badPwdCount                          : 0
CannotChangePassword                 : False
CanonicalName                        : NTAP.local/Users/winuser
Certificates                         : {}
CN                                   : winuser
codePage                             : 0
CompoundIdentitySupported            : {}
countryCode                          : 0
Created                              : 6/5/2025 10:22:39 AM
createTimeStamp                      : 6/5/2025 10:22:39 AM
DisplayName                          : winuser
DistinguishedName                    : CN=winuser,CN=Users,DC=NTAP,DC=local
DoesNotRequirePreAuth                : False
dSCorePropagationData                : {12/31/1600 7:00:00 PM}
Enabled                              : True
GivenName                            : winuser
HomedirRequired                      : False
instanceType                         : 4
KerberosEncryptionType               : {}
lastLogoff                           : 0
lastLogon                            : 0
LockedOut                            : False
logonCount                           : 0
MemberOf                             : {}
MNSLogonAccount                      : False
Modified                             : 6/5/2025 10:22:39 AM
modifyTimeStamp                      : 6/5/2025 10:22:39 AM
msDS-User-Account-Control-Computed   : 0
Name                                 : winuser
nTSecurityDescriptor                 : System.DirectoryServices.ActiveDirectorySecurity
ObjectCategory                       : CN=Person,CN=Schema,CN=Configuration,DC=NTAP,DC=local
ObjectClass                          : user
ObjectGUID                           : 7a43dd28-acaa-4f62-a332-0fd757e51ed3
objectSid                            : S-1-5-21-3552729481-4032800560-2279794651-34540
PasswordExpired                      : False
PasswordLastSet                      : 6/5/2025 10:22:39 AM
PasswordNeverExpires                 : True
PasswordNotRequired                  : False
PrimaryGroup                         : CN=Domain Users,CN=Users,DC=NTAP,DC=local
primaryGroupID                       : 513
PrincipalsAllowedToDelegateToAccount : {}
ProtectedFromAccidentalDeletion      : False
pwdLastSet                           : 133936069590314379
SamAccountName                       : winuser
sAMAccountType                       : 805306368
sDRightsEffective                    : 15
ServicePrincipalNames                : {}
SID                                  : S-1-5-21-3552729481-4032800560-2279794651-34540
SIDHistory                           : {}
SmartcardLogonRequired               : False
TrustedForDelegation                 : False
TrustedToAuthForDelegation           : False
UseDESKeyOnly                        : False
userAccountControl                   : 66048
userCertificate                      : {}
UserPrincipalName                    : [email protected]
uSNChanged                           : 5233298
uSNCreated                           : 5233289
whenChanged                          : 6/5/2025 10:22:39 AM
whenCreated                          : 6/5/2025 10:22:39 AM

Since we’re simply using the user to login (and not as a user for NAS access), we don’t care so much about the numeric IDs for UID and GID.

Unfortunately for this use case, ONTAP does.

ONTAP requires the ability to find the following attributes for an LDAP query for a user to work:

• Friendly username (usually “uid” in ONTAP LDAP schemas)
• User numeric ID (usually “uidNumber” in ONTAP LDAP schemas)
• Primary group ID (usually “gid” in ONTAP LDAP schemas)

Since Windows users don’t generally have uid, uidNumber and gid populated by default, we can get creative by using existing attributes. The following shows how we would map each attribute to one that Windows AD uses by default.

In ONTAP, to modify an LDAP schema, you need to copy an existing read-only schema template to a new read-writeable schema with the following command (I used the MS-AD-BIS schema template):

::*> ldap client schema copy -schema MS-AD-BIS -new-schema-name WIN-LOGIN

Then, modify the attributes on that schema to reflect what Windows has populated:

::*> ldap client schema modify -schema WIN-LOGIN -uid-attribute sAMAccountName -uid-number-attribute uSNCreated -gid-number-attribute primarygroupID

From there, apply the new schema to the LDAP client configuration. (If you haven’t already created one, see the documentation: https://docs.netapp.com/us-en/ontap/authentication/enable-nis-ldap-users-access-cluster-task.html)

Once that’s done, you should be able to use ONTAP CLI to query the Windows user for LDAP attributes (advanced privilege):

clustername::*> getxxbyyy getpwbyname -node node1 -vserver clustername -username winuser -use-cache false
(vserver services name-service getxxbyyy getpwbyname)
pw_name: winuser
pw_passwd:
pw_uid: 856540
pw_gid: 513
pw_gecos: winuser
pw_dir:
pw_shell:

If that works, then you can move on to the next step. If not, then you would need to troubleshoot why it can’t be found.

Look for the following common issues:

• Ns-switch must be set for “files,ldap” for passwd and group databases (ns-switch show)
• The LDAP client must be set up to allow binds as a CIFS server or as a user/password with any user that is a member of the AD domain. Binds are used for initial login to allow queries.
• If using a bind user (bind-dn), ensure the bind user password is set (ldap client modify-bind-password)
• The LDAP port is set to the proper port in your environment. (ldap client show)
• The LDAP base DN is set to the proper location. For larger AD environments, consider using user-dn filters to speed up searches. See TR-4835 for details.
• If LDAP searches are timing out, consider setting the query timeout to 10 seconds (the max; default is 3 seconds)

Creating a security login user

Now that LDAP is confirmed to be working and your users are showing up in LDAP queries, you can create a security login for the cluster SVM or a data SVM. The process for that is covered here:

https://docs.netapp.com/us-en/ontap-cli/security-login-create.html

You can create logins for SSH, REST API or System Manager access. In my lab, I created one for SSH and System Manager. Be sure to set “is-ldap-fastbind” to yes.

clustername::> security login create -user-or-group-name winuser -application ssh -authentication-method nsswitch -role admin -is-ldap-fastbind yes -vserver clustername
clustername::> security login create -user-or-group-name winuser -application http -authentication-method nsswitch -role admin -is-ldap-fastbind yes -vserver clustername

Once I did that, I was able to login to SSH as that user:

login as: winuser
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
Last login time: 6/5/2025 10:35:2

And System Manager:

That’s it! Simple as telling ONTAP to look for different attributes.

Can I log in using a group?

No, ONTAP only supports logins via user names, and each user must have a security login and defined role added to the ONTAP cluster.