Anyone using Red Hat Identity, Free IPA with FreeNAS 11

[corbello]

Thanks @amodos , with the 113u1 the krb5.keytab is back but i have some problem with the ldap service. and the nfsv4 integration. i reinstall a another server in 112u8 to compare.

 

[anodos]

Thanks @amodos , with the 113u1 the krb5.keytab is back but i have some problem with the ldap service. and the nfsv4 integration. i reinstall a another server in 112u8 to compare.

One thing that you may wish to check is output of getent passwd I vaguely recall that I needed to reconfigure nscld to look for a non-standard attribute in the ldap schema to determine users /groups to avoid duplicate entries.

 

[KrisBee]

@anodos Just to add that I should have checked both console and daemon log as the later shows this for FN11.3U1:

Code:

Feb 28 11:37:53 fn113u1 nslcd[988]: [0b1daf] <passwd="fn113u1\nobody"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Feb 28 11:37:53 fn113u1 nslcd[988]: [ca13fc] <passwd="FN113U1\nobody"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Feb 28 11:37:53 fn113u1 nslcd[988]: [e65e86] <passwd="FN113U1\NOBODY"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Feb 28 11:37:53 fn113u1 nslcd[988]: [48089a] <group/member="nobody"> no available LDAP server found: Server is unavailable
Feb 28 11:37:53 fn113u1 nslcd[988]: [48089a] <group/member="nobody"> no available LDAP server found: Server is unavailable
Feb 28 11:37:53 fn113u1 nslcd[988]: [2d312f] <group/member="nobody"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Feb 28 11:37:53 fn113u1 nslcd[988]: [2d312f] <group/member="nobody"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Feb 28 11:37:56 fn113u1 zfsd: ConnectToDevd: Connecting to devd.
Feb 28 11:37:56 fn113u1 zfsd: Connection to devd successful
Feb 28 11:38:35 fn113u1 collectd[1632]: plugin_load: plugin "syslog" successfully loaded.
Feb 28 11:38:35 fn113u1 collectd[1632]: plugin_load: plugin "threshold" successfully loaded.
Feb 28 11:38:35 fn113u1 collectd[1632]: plugin_load: plugin "zfs_arc" successfully loaded.
Feb 28 11:38:35 fn113u1 collectd[1632]: plugin_load: plugin "zfs_arc_v2" successfully loaded.
Feb 28 11:38:35 fn113u1 collectd[1632]: plugin_load: plugin "nfsstat" successfully loaded.
Feb 28 11:38:35 fn113u1 collectd[1632]: plugin_load: plugin "write_graphite" successfully loaded.
Feb 28 11:38:35 fn113u1 collectd[1632]: plugin_load: plugin "nut" successfully loaded.
Feb 28 11:38:35 fn113u1 collectd[1632]: type = syslog, key = LogLevel, value = err
Feb 28 11:38:41 fn113u1 nslcd[988]: [f878aa] <group/member="chris"> connected to LDAP server ldap://centos7ipa.mynet.local:389
root@fn113u1[/var/log]#

The ipa server logs confirms the correct krb5 tickets are issued.

After adding an ipa user a ds cache rebuild in FreeNAS a getent passwdresulted in duplicate entries:

Code:

patty:*:347800004:347800004:patty mac:/home/patty:
cburge:*:347800001:347800001:chris burge:/home/cburge:
admin:*:347800000:347800000:Administrator:/home/admin:
admin:*:347800000:347800000:Administrator:/home/admin:
cburge:*:347800001:347800001:chris burge:/home/cburge:
patty:*:347800004:347800004:patty mac:/home/patty:
root@fn113u1[/var/log]#

No joy with connecting to kerberos NFSV4 share, no nfs service ticket is issued to the client. I don't not how the switch from sssd to winbindd might impact ipa auth configs.

 

[anodos]

You need to change the nslcd.conf parameters (aux parameters under LDAP) to eliminate the duplicated entries. https://arthurdejong.org/nss-pam-ldapd/nslcd.conf.5 There are minor schema differences between FreeIPA LDAP and OpenLDAP defaults. You need to account for them. You can use `ldapsearch` to narrow it down. These and other minor differences are why FreeIPA isn't officially "supported" by the LDAP plugin. If I have time I will try to get a bare-bones FreeIPA one into 12.0.

 

[xenu]

Regarding duplicate getent entries: prefixing the base DN with "cn=compat" fixes this (cn=compat,dc=ipa,dc=mydomain,dc=com).

Compat tree is just that: a tree that returns data in a format
compatible with RFC2307 to clients that do not understand RFC2307bis. A
second use for the compat tree is to provide unified virtual tree for
clients that do not use SSSD so that both users from IPA and from
trusted Active Directory forests are accessible by such 'legacy'
clients. This second use case requires that you are using RFC2307 schema
in your client setup and that AD users are always fully qualified
(user ad domain).

source=https://www.redhat.com/archives/freeipa-users/2017-March/msg00167.html

 

[KrisBee]

@xenu Thanks for pointing out the use of base DN with "cn=compat" together with RFC2307 schema. My nfsv4 error was not noticing while changing configs I had left off the sec=krb5 on the individual FreeNAS nfs share config.

The LDAP webui form needs some TLC and could do with a reset button which not only disables nslcd and clears the nlscd conf file, but ensures all previous field values are cleared. Currently it's too easy to get stuck with a ""Simultaneous keytab and password authentication are not permitted." error even when fields are manually cleared on the webui form. The bind password field is one culprit. Currently a working and enabled LDPA config has to be re-enabled on re-booting FreeNAS.

YMMV, but what worked for me to get kerberised nfsv4 with a centos7 based ipa server and FreeNAS as a file server was:

1. Manually add FreeNAS host on the ipa server with associated dns A/PTR records.
2. Manually add a FreeNAS nfs service on the ipa server.
2. Copy ipa server ca crt and add ipa CA to FreeNAS.
3. On the ipa server, generate and copy to FreeNAS, both a host and nfs service keytab.
4. Point FreeNAS DNS to ipa server, set gateway as necessary.
5. Add and prefer a new NTP entry on FreeNAS pointing to ipa server.
6. Complete FreeNAS LDAP config with: hostname, prefix base DN with "cn=compat" and use schema RFC2307, enter kerberos REALM and select FreeNAS host principal and set encryption ON.

Things I didn't need:

1. A cert/key pair generated on the ipa server for the FreeNAS host and added to FreeNAS.
2. A specific ipa user/account to use for the bind DN (and kerberos principal.) See Edit below

I can't say this has been extensively tested, as this was more a "paper" exercise in a home setup rather than an actual requirement. Can't say if its good practice, but at least no ipa account passwords are stored in FreeNAS which would otherwise appear as clear text in /etc/local/nslcd.conf.

EDIT: After @anodos post a WIP fix for the LDAP config which addresses the bindpw field issue (see below), it became clear that you do need to enter a bind DN to avoid a slew of GSSAPI errors when FreeNAS boots up.

 

[anodos]

@xenu Thanks for pointing out the use of base DN with "cn=compat" together with RFC2307 schema. My nfsv4 error was not noticing while changing configs I had left off the sec=krb5 on the individual FreeNAS nfs share config.

The LDAP webui form needs some TLC and could do with a reset button which not only disables nslcd and clears the nlscd conf file, but ensures all previous field values are cleared. Currently it's too easy to get stuck with a ""Simultaneous keytab and password authentication are not permitted." error even when fields are manually cleared on the webui form.

I will make a change to just have the middleware automatically clear the bind credentials if this happens.

The bind password field is one culprit. Currently a working and enabled LDPA config has to be re-enabled on re-booting FreeNAS.

The code path to disable LDAP automatically is related to the ldap.started check. Because of the impact of a misconfigured LDAP service on other services, we run a validation check periodically on the config, and disable the service if it fails. If you're seeing this on reboot, try running the command midclt call ldap.started and see if it returns a validation error.

 

[KrisBee]

@anodos Not acted on your info yet, but I noticed if you save the FreeNAS config (SYSTEM > GENERAL) when you have a working LDAP config which contained no bind password the "ldap_bindpw" field in the directory_ldap table is not blank. Should it be?

That command just returns false after a re-boot:

Code:

root@fn113u1[~]#  midclt call ldap.started
False
root@fn113u1[~]#

If you then go striaght to the LDAP config and check enable and save you get the ""Simultaneous keytab and password authentication are not permitted" error. Which to my mind is because the "bindpw" field is not actually blank as it should be. The work around is to first type something in the bind password field and save the config. Then backspace over the bind passwrd field and save again The finally the config that was working before the re-boot can be enabled without error.

 

[anodos]

@anodos Not acted on your info yet, but I noticed if you save the FreeNAS config (SYSTEM > GENERAL) when you have a working LDAP config which contained no bind password the "ldap_bindpw" field in the directory_ldap table is not blank. Should it be?

Basically, it looks like the UI is making no provision to clear the bind password. I have a WIP fix for this here: https://raw.githubusercontent.com/f...4/src/middlewared/middlewared/plugins/ldap.py

Or you can run the command midclt call ldap.update '{"bindpw": ""}' which should nuke the password[/cmd]

That command just returns false after a re-boot:

Code:

root@fn113u1[~]#  midclt call ldap.started
False
root@fn113u1[~]#

What about before the reboot?

 

[KrisBee]

@anodos The midclt command didn't appear to clear the bindpw field?

Code:

root@fn113u1[~]#  midclt call ldap.update '{"bindpw": ""}'
{"id": 1, "hostname": ["centos7ipa.mynet.local"], "basedn": "cn=compat,dc=mynet,dc=local", "binddn": "", "bindpw": "                    ", "anonbind": false, "kerberos_realm": 1, "kerberos_principal": "host/fn113u1.mynet.local@MYNET.LOCAL", "ssl": "ON", "certificate": null, "validate_certificates": false, "disable_freenas_cache": false, "timeout": 10, "dns_timeout": 10, "idmap_backend": "LDAP", "has_samba_schema": false, "auxiliary_parameters": "", "schema": "RFC2307", "enable": false, "uri_list": ["ldaps://centos7ipa.mynet.local:636"]}
root@fn113u1[~]#

But your WIP fix cures the problem. On a re-boot the LDAP service remains enabled with:

Code:

root@fn113u1[~]#  midclt call ldap.started
True
root@fn113u1[~]#

Thanks for looking a this. Now the LDAP config webui is working , I need to correct my post #26.

 

[xenu]

Just wanted to add that with your patched ldap.py I am able to get a kerberos ticket again on bootup. midclt call ldap.started now shows True after boot and klist shows the kinit command ran where before it returned false and kinit had to be run manually. The "enabled" checkbox sticks now.

Only issue now is ldap.config still shows a stored bindpw. The update command does not clear it as @KrisBee already mentioned. Neither does it work by unsetting the value in the GUI and saving though it does not complain about bind password being set and using a kerberos principal anymore.

 

[krbyerdog]

I am still getting this on TrueNAS 12.0 release

Code:

GSSAPI Error: Miscellaneous failure (see text) or directory (open(/tmp/krb5cc_0): No such file or directory)

to fix it manually I ran

Code:

midclt call ldap.start

Why this doesn't work from the UI is a mystery, however running it will at least temporarily recover LDAP from a faulted state.

I suppose it would be possible to just run this every couple of hours as a cron job?

 

[anodos]

There's a bug in kerberos ticket renewal for LDAP in 12.0-RELEASE. Should be fixed in U1.