We have been able to follow TR-4835 to get our ONTAP cluster to successfully connect to FreeIPA LDAP using a simple bind in order to allow ldap users administer the cluster via ssh, and http. However using simple bind in production real world is not a feasible solution in regards to security of user passwords, so we must use SASL and or Kerberos bind to protect the user passwords and comply with IT security.
We have setup our FreeIPA IdM to support kerberos, and verified that we can connect to the LDAP server using Apache Directory Studio with the Authentication set to Kerberos GSSAPI, providing the kerberos Realm, and KDC host / port.
Using the same principle name in the ONTAP client configuration we are getting an invalid credentials error, but I suspect that isn't from the kerberos auth because we haven't specified a realm, kdc server or port.
4/30/2021 20:07:13 node-01 DEBUG secd.unexpectedFailure: vserver () Unexpected failure. Error: Validate the Ldap configuration procedure failed
[ 1 ms] Hostname found in Name Service Cache
[ 2] IP Address found in Name Service Cache
[ 2] Resolved LDAP servers: 192.168.23.12. Vserver: -1
[ 4] Failed to initiate Kerberos authentication. Trying NTLM.
[ 9] Unable to connect to LDAP (NIS & Name Mapping) service on freeipa.example.com (Error: Invalid credentials)
[ 9] No servers available for LDAP_NIS_AND_NAME_MAPPING, vserver: -1, domain: .
**[ 9] FAILURE: Unable to make a connection (LDAP (NIS & Name Mapping):), result: 6940
So next we tried to create a kerberos realm in ONTAP however there does not seem to be possible because the vserver is a cluster and not a data vserver
node::vserver nfs kerberos realm*> create -vserver ngdc -realm EXAMPLE.COM -kdc-vendor Other -kdc-ip 192.168.23.12 -kdc-port 88
Error: command failed: Only the data Vservers can own NFS Kerberos realms.
Do we need a data vserver to achieve our goal, even if NFS is not something we need just yet?
Circling back here I have been able to get the LDAPS/SASL/Keberos bind working.
First thing I did was issue a 3rd party certificate to my IdM server as the freeipa-install script gives it a self signed cert which I found was not supported by the ONTAP certificate module. Basically created my own test CA, generated a private key, and csr, then had the CA sign the csr to get the server.crt
Next I installed the CA.crt to the ONTAP vserver with with command:
Next I added my IdM server IP address as a dns server (this was actually done in the cluster setup).
Next I added my IdM server IP address as an ntp server. (after making sure nap/chronyd will listen for local network ntp requests)
create -server 192.168.23.12 -version auto
Next I created the client-config, I added my ldap server ip, base-dn, bind-dn, port (636), min-bind-level (sals), and session-security (sign).
netapp::vserver services name-service ldap client*> show -client-config IdMsasl
Client Configuration Name: IdMsasl
LDAP Server List: 192.168.23.12
(DEPRECATED)-LDAP Server List: -
Active Directory Domain: -
Preferred Active Directory Servers: -
Bind Using the Vserver's CIFS Credentials: false
Schema Template: RFC-2307
LDAP Server Port: 636
Query Timeout (sec): 3
Minimum Bind Authentication Level: sasl
Bind DN (User): admin@EXAMPLE.COM
Base DN: dc=example,dc=com
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: sign
LDAP Referral Chasing: false
Group Membership Filter:
Initially I added the wrong bind-dn and had specified the user-dn instead of the user principle name, but the error from the check command was able to help me understand what to correct, also it seems the kerberos auth was being initiated properly as well, even though it failed it was a new message that I had not seen previously.
netapp::vserver services name-service ldap*> modify -vserver netapp -client-config IdMsasl
Error: Validate the Ldap configuration procedure failed
[ 2 ms] Hostname found in Name Service Cache
[ 3] IP Address found in Name Service Cache
[ 3] Resolved LDAP servers: 192.168.23.12. Vserver: -1
**[ 50] FAILURE: Could not authenticate as
** 'users@EXAMPLE.COM': Unknown user
[ 50] Unable to start LDAPS: (null)
[ 50] Unable to connect to LDAP (NIS & Name Mapping) service on
[ 50] No servers available for LDAP_NIS_AND_NAME_MAPPING,
vserver: -1, domain: .
[ 50] Unable to make a connection (LDAP (NIS & Name Mapping):),
Error: command failed: The LDAP client configuration "IdMsasl" for Vservers "netapp" is an invalid
Once I correct the bind-dn to the user principle name I was able to run the check and see that we now have a valid connection and the ldap services are available
netapp::vserver services name-service ldap*> check -vserver netapp
Client Configuration Name: IdMsasl
LDAP Status: up
LDAP Status Details: Successfully connected to LDAP server "192.168.23.12".
LDAP DN Status Details: All the configured DNs are available.
I still need to add ldap to the nsswitch and create security logins, hopefully that goes well and netapp won't be looking for the userPassword field to perform auth.
So essentially we are back at square one, and have received the same results that we had when using simple bind with an admin account other than "cn=Directory Manager." It seems the SASL kerberos bind doesn't affect how the security login module attempts to authenticate ldap users.
After reviewing with our NetApp resident experts, this appears to be working as designed. IE the NetApp application is attempting to authenticate the users by validating their passwords match with what's in the directory (which includes hashing the user password and checking if it matches the userPassword hashed value), which is apparently a classic design from older LDAP systems that couldn't handle secure binds and proper secure hashing of the userPassword field. Today most all modern LDAP servers support some form of secure bind as well as more secure hashing algorithms.
We would be much more comfortable with allowing the securely bound LDAP server to handle the authentication, for example when an LDAP user attempts to login to the NetApp ONTAP management port NetApp just attempts to perform a secure bind with that users name and password and if succeeded is given a short lived login token or something that would allow them to be authenticated by NetApp.
The fewer things that have access to the userPassword field the better is my understanding here.
I will reply to myself here (as it seems Netapp will not 🙂 ) - i was able to on-board IQ Unified Manager into our LDAP for authentication without bind-dn user having ability to see -every- password in LDAP.
So it seems the LDAP implementation in Ontap is just relic from old days and IQ Unifid manager is a newer implementation.
There is no way the current Ontap implementation is in any way complainant with best security practices. For storage device to have a LDAP account that can see hash of -every-password- seems too much even for a lab environment (much less production)