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.
NOTE: ONTAP 9.7P9 and later fix bug 1264152, so you won’t need to adjust the password hash:
https://mysupport.netapp.com/site/bugs-online/product/ONTAP/BURT/1264152
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.
NOTE: This is no longer needed if you run ONTAP 9.7P9 or later. Bug 1264152 is fixed.
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 in ONTAP versions prior to 9.7P9; bug 1264152 is fixed in later versions
- 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:
Why Is The Internet Broken? 