LDAP Authentication for cluster administration - SASL/Keberos bind auth with FreeIPA/RH IdM

[JonathanAlexander]

Greetings,

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?  

[JonathanAlexander]

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:

 install -type server-ca -vserver netapp -cert-name testauthority

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

                                  Vserver: netapp
                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
**         (KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN)
  [    50] Unable to start LDAPS: (null)
  [    50] Unable to connect to LDAP (NIS & Name Mapping) service on
           freeipa.example.com
  [    50] No servers available for LDAP_NIS_AND_NAME_MAPPING,
           vserver: -1, domain: .
  [    50] Unable to make a connection (LDAP (NIS & Name Mapping):),
           result: 6940
Error: command failed: The LDAP client configuration "IdMsasl" for Vservers "netapp" is an invalid
       configuration.

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

                  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.

[JonathanAlexander]

reporting back here, it seems that the SASL ldap bind has had no bearing on the security login users that have set the nsswitch authentication method.

Using the getxxbyyy command to query for the password it returns no password... 

netapp::vserver services name-service getxxbyyy*> getpwbyuid -userID 1369800001                               pw_name: testuser1                                                                                            pw_passwd: 
pw_uid: 1369800001
pw_gid: 1369800001
pw_gecos: 
pw_dir: 
pw_shell: /bin/sh

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.  

any help or suggestions are appreciated

[JonathanAlexander · Accepted solution]

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. 

[tahmad]

Thank you @JonathanAlexander for sharing the solution.

[VladimirBarancok]

is there really a solution to this issue ? 

We hit the same issue with Ontap 9.7.

We expect that first theres gonna be lookup users using ‘lookup bind’ (and this works) and then LDAP user login attempt to perform a secure bind with that users name and password.

Because as far as i can tell Ontap pretty much requires an Ldap admin user account (as thats the only user thats allowed to see password hashes) and this is no-go.

We’ve reached out to Netapp via our local support techs (in Germany) but so far no word on whether they will update Ldap client.

This is really unorthodox  Ldap implementation as we onboraded number of systems to Ldap (from RHEL to Vmware to Veeam) and Netapp is the only system with this requirement.

[VladimirBarancok]

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)