One question I’ve seen asked a lot, but haven’t been able to find much information on, is how to configure a Linux LDAP server (in this case, FreeIPA on CentOS/RHEL) to interact with NetApp’s Data ONTAP software to allow users to login via SSH or the web browser. With Windows Active Directory, it’s fairly simple – you set up domain tunnels and that’s about it.

So, I finally decided to try and figure it out. If you want the quick and dirty summary, scroll to the bottom.

I set up a FreeIPA server (with DNS) on CentOS 8 using the following link:

https://kifarunix.com/install-and-setup-freeipa-server-on-centos-8/

Getting ONTAP to query LDAP for users and groups after it was set up was fairly straightforward.

First, I needed DNS configured to be able to discover the LDAP server.

cluster::*> dns show -vserver cluster Vserver: cluster Domains: centos-ldap.local Name Servers: 10.x.x.x Timeout (secs): 2 Maximum Attempts: 1 Is TLD Query Enabled?: true Require Source and Reply IPs to Match: true Require Packet Queries to Match: true

Then I tested name resolution:

cluster::*> getxxbyyy gethostbyname -node node1 -vserver cluster -hostname centos8-ipa.centos-ldap.local (vserver services name-service getxxbyyy gethostbyname) Host name: centos8-ipa.centos-ldap.local Canonical name: centos8-ipa.centos-ldap.local IPv4: 10.x.x.x

Here’s the LDAP client configuration I set up. Keep in mind that this one wasn’t the correct config:

cluster::*> ldap client show -client-config IDM Client Configuration Name: IDM LDAP Server List: 10.x.x.x (DEPRECATED)-LDAP Server List: - Active Directory Domain: - Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: false Schema Template: IPA LDAP Server Port: 389 Query Timeout (sec): 3 Minimum Bind Authentication Level: anonymous Bind DN (User): Base DN: dc=centos-ldap,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: false 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:

I wanted to make some changes to the schema, so I went ahead and created a custom schema based on the attributes of users and groups in the LDAP server.

cluster::*> ldap client schema show -schema IPA Schema Template: IPA Comment: RFC 2307 posixAccount Object Class: person RFC 2307 posixGroup Object Class: posixgroup RFC 2307 nisNetgroup Object Class: ipanisnetgroup RFC 2307 uid Attribute: uid RFC 2307 uidNumber Attribute: uidNumber RFC 2307 gidNumber Attribute: gidNumber RFC 2307 cn (for Groups) Attribute: cn RFC 2307 cn (for Netgroups) Attribute: cn RFC 2307 userPassword Attribute: userPassword RFC 2307 gecos Attribute: gecos RFC 2307 homeDirectory Attribute: homeDirectory RFC 2307 loginShell Attribute: loginShell RFC 2307 memberUid Attribute: member RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple Enable Support for Draft RFC 2307bis: true RFC 2307bis groupOfUniqueNames Object Class: posixgroup RFC 2307bis uniqueMember Attribute: member Data ONTAP Name Mapping windowsToUnix Object Class: posixAccount Data ONTAP Name Mapping windowsAccount Attribute: windowsAccount Data ONTAP Name Mapping windowsToUnix Attribute: windowsAccount No Domain Prefix for windowsToUnix Name Mapping: false Vserver Owns Schema: false Maximum groups supported when RFC 2307bis enabled: 256 RFC 2307 nisObject Object Class: ipahost RFC 2307 nisMapName Attribute: nisMapName RFC 2307 nisMapEntry Attribute: nisMapEntry

Then I ran LDAP create on the cluster SVM. If there is a configuration issue, this step will fail to prevent issues later:

cluster::> ldap create -vserver cluster -client-config IDM cluster::> ldap show -vserver cluster Vserver: cluster LDAP Client Configuration: IDM

LDAP check can verify the config:

cluster::> ldap check -vserver cluster Vserver: cluster Client Configuration Name: IDM LDAP Status: up LDAP Status Details: Successfully connected to LDAP server "10.x.x.x". LDAP DN Status Details: All the configured DNs are available.

And I modified the ns-switch to use files,ldap for passwd and group:

cluster::*> ns-switch show -vserver cluster -database passwd,group (vserver services name-service ns-switch show) Source Vserver Database Order --------------- ------------ --------- cluster group files,ldap cluster passwd files,ldap

After setting that up, I could query users using the getXXbyYY commands in advanced privilege:

cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) pw_name: idm-ldap pw_passwd: pw_uid: 1971600001 pw_gid: 1971600000 pw_gecos: pw_dir: pw_shell: /bin/sh cluster::*> getxxbyyy getgrlist -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getgrlist) pw_name: idm-ldap Groups: 1971600000 cluster::*> getxxbyyy getgrbyname -node node1 -vserver cluster -groupname admins (vserver services name-service getxxbyyy getgrbyname) name: admins gid: 1971600000 gr_mem:

Once I got LDAP user lookups working, I went ahead and created security logins for ssh, http and ontapi services for the idm-ldap user using nsswitch as the authentication method.

cluster::*> security login show -vserver cluster -user-or-group-name idm-ldap Vserver: cluster Second User/Group Authentication Acct Authentication Name Application Method Role Name Locked Method -------------- ----------- ------------- ---------------- ------ -------------- idm-ldap http nsswitch admin - none idm-ldap ontapi nsswitch admin - none idm-ldap ssh nsswitch admin - none

However, logins failed. I could see the (not very descriptive) error in the event log:

sshd.auth.loginDenied: message="Failed keyboard-interactive / pam for idm-ldap from 10.x.x.x port 58872 ssh2 "

I poked around logs for awhile but didn’t have any luck. Then, I pinged my NAS counterpart, Chris Hurley (@AverageGuyX) to see if he’d ever gotten this working before.

Luckily he had.

Turns out, there were three things going one. One I suspected to be an issue. The other two, I did not.

FreeIPA Schema – Compat vs. LDAP

So, unbeknownst to me, FreeIPA sets up two different LDAP DN trees for users. One is the normal LDAP portion. The other is for compatibility with NIS. I set the base DN to the top level of the tree, which was pulling from compat. The issue there? Compat doesn’t transfer the password hash, so there’s no way to properly authenticate. Here’s the output of the idm-ldap user. Note there is no userPassword entry in the compat entry:

# ldapsearch -D "cn=Directory Manager" -W -p 389 -h 10.193.67.222 -b "dc=centos-ldap,dc=local" -s sub "(uid=idm-ldap)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=centos-ldap,dc=local> with scope subtree # filter: (uid=idm-ldap) # requesting: ALL # # idm-ldap, users, compat, centos-ldap.local dn: uid=idm-ldap,cn=users,cn=compat,dc=centos-ldap,dc=local objectClass: posixAccount objectClass: ipaOverrideTarget objectClass: top gecos: IDM LDAP cn: IDM LDAP uidNumber: 1971600001 gidNumber: 1971600000 loginShell: /bin/sh homeDirectory: /home/idm-ldap ipaAnchorUUID:: OklQQTpjZW50b3MtbGRhcC5sb2NhbDowYzA2OGMxYS00N2EwLTExZWEtOWZhNS 0wMDUwNTY5ZWM0N2Q= uid: idm-ldap # idm-ldap, users, accounts, centos-ldap.local dn: uid=idm-ldap,cn=users,cn=accounts,dc=centos-ldap,dc=local givenName: IDM sn: LDAP uid: idm-ldap cn: IDM LDAP displayName: IDM LDAP initials: IL gecos: IDM LDAP krbPrincipalName: idm-ldap@CENTOS-LDAP.LOCAL gidNumber: 1971600000 userClass: user objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipauser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry objectClass: ipauserauthtypeclass loginShell: /bin/sh homeDirectory: /home/idm-ldap mail: idm-ldap@centos-ldap.local krbCanonicalName: idm-ldap@CENTOS-LDAP.LOCAL userPassword:: cGFzc3dvcmQ= ipaUniqueID: 0c068c1a-47a0-11ea-9fa5-0050569ec47d krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEOowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBBf V1MkWEtbaWJHIzUoPT8koUkwR6ADAgESoUAEPiAAyXz46+O9PYO29Jp9jtSsjzBmRfP807GukpwDF 4UuPueLD5N+alOaMeh32YUfBe4DsyRNWo17VMw4sE3UMFigGzAZoAMCAQShEgQQdkR6KVVIU3hZXn gnXSpQX6E5MDegAwIBEaEwBC4QANcX45dw98u/gynzQDKQ02dTvcOOp6uTE5wgJyzZZVaEON2l2hW Dow8i/2Fo uidNumber: 1971600001 krbPasswordExpiration: 20200206034103Z krbLastPwdChange: 20200206034103Z krbExtraData:: AALPijtecm9vdC9hZG1pbkBDRU5UT1MtTERBUC5MT0NBTAA= mepManagedEntry: cn=idm-ldap,cn=groups,cn=accounts,dc=centos-ldap,dc=local memberOf: cn=ipausers,cn=groups,cn=accounts,dc=centos-ldap,dc=local krbLastFailedAuth: 20200205022117Z krbLoginFailedCount: 0 krbTicketFlags: 128 ipaUserAuthType: password

To fix that, I just needed to set the user and group DN to filter where the LDAP users and groups are. Both users and groups live in cn=accounts,dc=centos-ldap,dc=local.

cluster::*> ldap client modify -client-config IDM -user-dn cn=accounts,dc=centos-ldap,dc=local -group-dn cn=accounts,dc=centos-ldap,dc=local

But there’s more… when that changes, we still can’t see the password hash.

cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) pw_name: idm-ldap pw_passwd: pw_uid: 1971600001 pw_gid: 1971600000 pw_gecos: pw_dir: pw_shell: /bin/sh

That’s because we’re not binding with a user that has permissions to see that field.

Directory Manager

In Linux LDAP servers, there’s a user called “Directory Manager” that has access to view everything in the schema – including userPassword fields. In my client config in ONTAP, I’m only binding as anonymous, which works fine for seeing basic user info. But for authentication, we need the password.

So, I set my bind-dn to “CN=Directory Manager,” min-bind-level to simple, and set the bind password.

If everything is set up properly, then the command works. If it’s not (such as the wrong bind DN) the command fails:

cluster::*> ldap client modify -client-config IDM -bind-dn "CN=Directory" -min-bind-level simple Error: Validate the Ldap configuration procedure failed [ 0 ms] Hostname found in Name Service Cache [ 1] IP Address found in Name Service Cache [ 1] Resolved LDAP servers: 10.x.x.x. Vserver: 9 [ 1] Failed to initiate Kerberos authentication. Trying NTLM. [ 2] Successfully connected to ip 10.x.x.x, port 389 using TCP [ 106] Unable to connect to LDAP (NIS & Name Mapping) service on centos8-ipa.centos-ldap.local (Error: Invalid credentials) [ 106] No servers available for LDAP_NIS_AND_NAME_MAPPING, vserver: 9, domain: . **[ 106] FAILURE: Unable to make a connection (LDAP (NIS & Name ** Mapping):), result: 6940 Error: command failed: The LDAP client configuration "IDM" for Vservers "NFS, cluster" is an invalid configuration.

This is because ONTAP runs a config validation to ensure we don’t get silent failures due to configuration errors.

When I use the correct user, it works fine:

cluster::*> ldap client modify -client-config IDM -bind-dn "CN=Directory Manager" -min-bind-level simple

Then you set the bind password for the user:

cluster::*> ldap client modify-bind-password -client-config IDM Please enter password: Confirm password:

This is the new (correct) LDAP client:

cluster::*> ldap client show -client-config IDM Client Configuration Name: IDM LDAP Server List: 10.x.x.x (DEPRECATED)-LDAP Server List: - Active Directory Domain: - Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: false Schema Template: IPA LDAP Server Port: 389 Query Timeout (sec): 3 Minimum Bind Authentication Level: simple Bind DN (User): CN=Directory Manager Base DN: dc=centos-ldap,dc=local Base Search Scope: subtree User DN: cn=accounts,dc=centos-ldap,dc=local User Search Scope: subtree Group DN: cn=accounts,dc=centos-ldap,dc=local Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: false 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:

However, when I try to query the user again, I get a new (unhelpful) error:

cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) Error: command failed: Failed to resolve ipa-user. Reason: Resource temporarily unavailable.

When I did a packet trace of the query, I could see the LDAP search succeed. It’s just that ONTAP couldn’t parse it.

However, I had suspicions of what this issue was – password hash length.

FreeIPA passwordStorageScheme

By default, FreeIPA uses a passwordStorageScheme of SSHA512, which is the most secure it offers. This is also the longest password it offers. You can view passwordStorageScheme with the following command:

# ldapsearch -D "cn=Directory Manager" -W -p 389 -h 10.x.x.x -b "cn=config" | grep passwordStorageScheme Enter LDAP Password: passwordStorageScheme: SSHA512

This is what a SSHA512 password hash looks like:

userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFGR0VIRXFsRjVVUUdFZFpzZFpZd3JGR3NtWkZ wWlM5VGE2eWtacTMways0YnRQWncyaFN1ZUdOajFhRXljcE13b05kcnZmVXFVRHVVWXByUytkbnh4 VFJrOFRNbDZkOE1LTzBEWVBSR0JzVXV0dkhkbG5SRkFzaUp5azlOQ1ptdVE4RzdLTk1XR1dKUDliT nFHV2Fsd3lSMkRMV1pKZjlJWlVYZncxRThIcFIwRDdSZzYvNlBZcGdzVUNDcFhBZGtnUFFyQUdTaE wybk9BbkpVS0NPNjVFNFd5OVVYbXFIL1JOMXVwcWw3bnhLRnI2MThidWpzM0lSdnQrWHUyYTRoQVZ Vc2tRV2Zna25ZWE1PRGhrd0Y3amJsMkpBZmR4dEdOMm84bE1NMFp5a1R1cEREVzU2ZnpieE9XYWN5 MEFLK3h0bzdPYzd1S0E0TURTZjR4NE82VTdOR0hZdW14WVZPb1UyaTVSWFUzemwyUnJFY2dnM2pFb Eh6QWJUbWpqUHVEYVRxak9nczFRZ3htalNiSDFuSlhZVTViaE9GVWl4K1hSekFVZnVpVTFk

So, I needed to a) change the passwordStorageScheme configuration and b) change the user password to reflect the new hash.

FreeIPA supports the following hashes:

CLEAR, CRYPT, CRYPT-MD5, CRYPT-SHA256, CRYPT-SHA512, MD5, PBKDF2_SHA256, SHA, SHA256, SHA384, SHA512, SMD5, SSHA, SSHA256, SSHA384, SSHA512

Essentially, each hash provides for different password hash lengths. The longer the hash length, the more secure the password is. Naturally, CLEAR means “clear text”. When we query a user with CLEAR hashing, we see the password:

cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) pw_name: idm-ldap pw_passwd: password pw_uid: 1971600001 pw_gid: 1971600000 pw_gecos: pw_dir: pw_shell: /bin/sh

If we use CRYPT or SHA, we can see what the hash type is. Note the difference in password lengths:

cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) pw_name: idm-ldap pw_passwd: {SSHA}/RRpyF9Jy34nzVBrQFEUmcb02JQu90OzExECMw== pw_uid: 1971600001 pw_gid: 1971600000 pw_gecos: pw_dir: pw_shell: /bin/sh cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) pw_name: idm-ldap pw_passwd: {SSHA256}mKI6H+9QTrnZG1EALfntPO0RXWlcQM1Icm2aLer+tObbNaHBG2EJdA== pw_uid: 1971600001 pw_gid: 1971600000 pw_gecos: pw_dir: pw_shell: /bin/sh cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) pw_name: idm-ldap pw_passwd: {crypt}$6$7r$Dtn1uNWpTsddL1XiocAP/o9bBPXMXrfTHtWcRlK.GLOeDaAnTYZaQ8XQfvmHedT/uR6r8BfMendCdH0NvDri.0 pw_uid: 1971600001 pw_gid: 1971600000 pw_gecos: pw_dir: pw_shell: /bin/sh cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) pw_name: idm-ldap pw_passwd: {MD5}X03MO1qnZdYdgyfeuILPmQ== pw_uid: 1971600001 pw_gid: 1971600000 pw_gecos: pw_dir: pw_shell: /bin/sh

However, ONTAP can currently only use the following hashes for user authentication:

CRYPT (all flavors)

SHA

SSHA

Other flavors (like CLEAR, MD5 SHA256, SHA512, SSHA512, etc) won’t allow authentication for logins. But using CRYPT-SHA512 works. And it’s a fairly secure password hash length.

To change the FreeIPA passwordStorageScheme, we use ldapmodify:

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h centos8-ipa -x Enter LDAP Password: dn: cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: CRYPT-SHA512 modifying entry "cn=config" # ldapsearch -D "cn=Directory Manager" -W -p 389 -h centos8-ipa -b "cn=config" | grep passwordStorageScheme Enter LDAP Password: passwordStorageScheme: CRYPT-SHA512

Then, we change the user password to gain the new hash. Here’s the new password hash:

userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFGR0VIRXFsRjVVUUdFZFpzZFpZd3JGR3NtWkZ wWlM5VGE2eWtacTMways0YnRQWncyaFN1ZUdOajFhRXljcE13b05kcnZmVXFVRHVVWXByUytkbnh4 VFJrOFRNbDZkOE1LTzBEWVBSR0JzVXV0dkhkbG5SRkFzaUp5azlOQ1ptdVE4RzdLTk1XR1dKUDliT nFHV2Fsd3lSMkRMV1pKZjlJWlVYZncxRThIcFIwRDdSZzYvNlBZcGdzVUNDcFhBZGtnUFFyQUdTaE wybk9BbkpVS0NPNjVFNFd5OVVYbXFIL1JOMXVwcWw3bnhLRnI2MThidWpzM0lSdnQrWHUyYTRoQVZ Vc2tRV2Zna25ZWE1PRGhrd0Y3amJsMkpBZmR4dEdOMm84bE1NMFp5a1R1cEREVzU2ZnpieE9XYWN5 MEFLK3h0bzdPYzd1S0E0TURTZjR4NE82VTdOR0hZdW14WVZPb1UyaTVSWFUzemwyUnJFY2dnM2pFb Eh6QWJUbWpqUHVEYVRxak9nczFRZ3htalNiSDFuSlhZVTViaE9GVWl4K1hSekFVZnVpVTFk

And ONTAP can see it (albeit truncated):

cluster::*> getxxbyyy getpwbyname -node node1 -vserver cluster -username idm-ldap (vserver services name-service getxxbyyy getpwbyname) pw_name: idm-ldap pw_passwd: {crypt}$6$Z7$P4yQSiVYP513mNeH2PJLqOPUSOxLyh/nGUWtFclPsEUj7tHU5y4eu6SRH1XijBgycZnAQHMCdpmJiKWFkajp40 pw_uid: 1971600001 pw_gid: 1971600000 pw_gecos: pw_dir: pw_shell: /bin/sh

But, most importantly, we can now login using the idm-ldap user:

# ssh idm-ldap@10.x.x.x Password: Last login time: 2/5/2020 23:48:55 cluster::> version NetApp Release 9.7X19: Thu Dec 05 11:10:30 UTC 2019

As a bonus, we can also login to System Manager with that user:

Configuring LDAP Groups for Login

When I posted this blog, Twitter user @ByyvO replied about his inability to get groups working. I took that as a challenge, so here’s how to get LDAP groups working.

First of all, LDAP group memberships must be able to be queried by ONTAP properly – meaning, all groups for the user should be able to be looked up. By default, ONTAP LDAP schemas use memberUid for group membership information. FreeIPA, however, uses “member” as the attribute. It also appears to use RFC-2307bis, which is why I build a custom schema to change the group membership attribute, as well as enabling BIS. (see the schema example in the summary section below)

On the LDAP server, I created a group named “ontap-ldap” and added idm-ldap (which was used to login originally) and ipa-user.

# ontap-ldap, groups, accounts, centos-ldap.local dn: cn=ontap-ldap,cn=groups,cn=accounts,dc=centos-ldap,dc=local cn: ontap-ldap objectClass: top objectClass: groupofnames objectClass: nestedgroup objectClass: ipausergroup objectClass: ipaobject objectClass: posixgroup ipaUniqueID: 08e4b70a-48ef-11ea-a914-0050569ec47d gidNumber: 1971600004 member: uid=idm-ldap,cn=users,cn=accounts,dc=centos-ldap,dc=local member: uid=ipa-user,cn=users,cn=accounts,dc=centos-ldap,dc=local

I checked if the cluster could resolve the group memberships for the ipa-user, and it could:

cluster::*> getxxbyyy getgrlist -node node1 -vserver cluster -username ipa-user (vserver services name-service getxxbyyy getgrlist) pw_name: ipa-user Groups: 1971600000 1971600004 cluster::*> getxxbyyy getgrbygid -node node1 -vserver cluster -groupID 1971600000 (vserver services name-service getxxbyyy getgrbygid) name: admins gid: 1971600000 gr_mem: admin uid=admin cn=users cn=accounts dc=centos-ldap dc=local cluster::*> getxxbyyy getgrbygid -node node1 -vserver cluster -groupID 1971600004 (vserver services name-service getxxbyyy getgrbygid) name: ontap-ldap gid: 1971600004 gr_mem: idm-ldap ipa-user uid=idm-ldap cn=users cn=accounts dc=centos-ldap dc=local uid=ipa-user cn=users cn=accounts dc=centos-ldap dc=local

Then, I created a security login entry for the ontap-ldap group on the cluster. In these commands I set -is-nsswitch-group to yes. If it’s set to “no” then ONTAP will treat the group name like a user – which won’t work.

I only created it for ssh and ontapi, as LDAP group auth isn’t supported yet for http:

cluster::*> security login create -user-or-group-name ontap-ldap -application ssh -authentication-method nsswitch -role admin -is-ns-switch-group yes -second-authentication-method none -vserver cluster cluster::*> security login create -user-or-group-name ontap-ldap -application ontapi -authentication-method nsswitch -role admin -is-ns-switch-group yes -second-authentication-method none -vserver cluster cluster::*> security login show -vserver cluster -user-or-group-name ontap-ldap -fields is-ns-switch-group vserver user-or-group-name application authentication-method remote-switch-ipaddress is-ns-switch-group --------------- ------------------ ----------- --------------------- ----------------------- ------------------ cluster ontap-ldap ontapi nsswitch - yes cluster ontap-ldap ssh nsswitch - yes

As you can see, there is no entry here for ipa-user:

cluster::*> security login show -vserver cluster -user-or-group-name ipa-user There are no entries matching your query.

Then, I try to login using the ipa-user. Works fine!

[root@centos8-ipa /]# ssh ipa-user@10.193.67.10 Password: This is your first recorded login. ontap9-tme-8040::> version NetApp Release 9.7X19: Thu Dec 05 11:10:30 UTC 2019

Summary

Just to consolidate the lessons above into an easier to read section, here are the steps to configure LDAP authentication with FreeIPA (or other Linux LDAP servers) to manage ONTAP.

Configure DNS on the cluster SVM

Copy an LDAP schema from the RFC-2307bis template to a new schema template and modify attributes as needed

Create an LDAP client that uses “CN=Directory Manager” for the bind-dn, simple authentication as the minimum bind level, filtering user and group DN to use LDAP users and not something like “compat”

Set the bind-dn password

Create/enable LDAP on the SVM

Run LDAP check

Modify ns-switch for passwd,group databases for the cluster SVM to use files,ldap

Ensure FreeIPA is using CRYPT, SHA or SSHA hashes for passwords

Run getXXbyYY commands to test user lookups

Create user logins with nsswitch authentication methods for the desired users

Test logins

This was the final LDAP client and schema configuration in my environment.

Schema

Schema Template: IPA Comment: RFC 2307 posixAccount Object Class: person RFC 2307 posixGroup Object Class: posixgroup RFC 2307 nisNetgroup Object Class: ipanisnetgroup RFC 2307 uid Attribute: uid RFC 2307 uidNumber Attribute: uidNumber RFC 2307 gidNumber Attribute: gidNumber RFC 2307 cn (for Groups) Attribute: cn RFC 2307 cn (for Netgroups) Attribute: cn RFC 2307 userPassword Attribute: userPassword RFC 2307 gecos Attribute: gecos RFC 2307 homeDirectory Attribute: homeDirectory RFC 2307 loginShell Attribute: loginShell RFC 2307 memberUid Attribute: member RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple Enable Support for Draft RFC 2307bis: true RFC 2307bis groupOfUniqueNames Object Class: posixgroup RFC 2307bis uniqueMember Attribute: member Data ONTAP Name Mapping windowsToUnix Object Class: posixAccount Data ONTAP Name Mapping windowsAccount Attribute: windowsAccount Data ONTAP Name Mapping windowsToUnix Attribute: windowsAccount No Domain Prefix for windowsToUnix Name Mapping: false Vserver Owns Schema: false RFC 2307 nisObject Object Class: ipahost RFC 2307 nisMapName Attribute: nisMapName RFC 2307 nisMapEntry Attribute: nisMapEntry

LDAP client

Client Configuration Name: IDM LDAP Server List: centos8-ipa.centos-ldap.local (DEPRECATED)-LDAP Server List: - Active Directory Domain: - Preferred Active Directory Servers: - Bind Using the Vserver's CIFS Credentials: false Schema Template: IPA LDAP Server Port: 389 Query Timeout (sec): 3 Minimum Bind Authentication Level: simple Bind DN (User): CN=Directory Manager Base DN: dc=centos-ldap,dc=local Base Search Scope: subtree User DN: cn=accounts,dc=centos-ldap,dc=local User Search Scope: subtree Group DN: cn=accounts,dc=centos-ldap,dc=local Group Search Scope: subtree Netgroup DN: - Netgroup Search Scope: subtree Vserver Owns Configuration: false 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: