How to set up LDAP properly in 9.3?

[Ling Ho]

Hi, I had LDAP working properly as of Nov 20. But a few days ago while setting up 9.3 STABLE on a different domain, I can't get LDAP to work anymore. When going to set permission, I don't my ldap user and group.

I went back to the machine running the Beta version, updating it to STABLE, and now it also stop working.

I don't see any errors in /var/log/messages, and my slapd log seems to indicate properly connection.

These are my LDAP settings:
Hostname: 192.168.50.110
Base DN: dc=4thbl
Allow Anonumous Binding: checked
User Suffix: ou=People
Group Suffix: ou=Group
Encryiption mode: off
LDAP timeout= 20
DNS timeout=10
idmap backend: ldap
Enabled: checked.

I can do a ldapsearch -x from the command line and works.
But getent passwd doesn't show my ldap user.

This is how sssd.conf looks like:

[sssd]
config_file_version = 2
full_name_format = %2$s\%1$s
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
services = nss,pam
domains = 192

[nss]
[pam]
[domain/192]
description = 192
enumerate = true
cache_credentials = true
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_schema = rfc2307bis
ldap_force_upper_case_realm = true
use_fully_qualified_names = false
ldap_uri = ldap://192.168.50.110
ldap_search_base = dc=4thbl
ldap_user_search_base = ou=People,dc=4thbl
ldap_group_search_base = ou=Group,dc=4thbl
ldap_default_bind_dn = None
ldap_default_authtok_type = password
ldap_default_authtok = None

These is nothing written in /var/log/sssd

This is my slapd log. I only have one group and user configured right now.

Dec 13 12:06:07 psns1 slapd[12554]: conn=2105 fd=11 ACCEPT from IP=192.168.50.121:12136 (IP=0.0.0.0:389)
Dec 13 12:06:07 psns1 slapd[12554]: conn=2105 op=0 BIND dn="" method=128
Dec 13 12:06:07 psns1 slapd[12554]: conn=2105 op=0 RESULT tag=97 err=0 text=
Dec 13 12:06:07 psns1 slapd[12554]: conn=2105 op=1 SRCH base="ou=People,dc=4thbl" scope=2 deref=0 filter="(&(|(objectClass=person)(objectClass=posixAccount)(objectClass=account))(uid=*))"
Dec 13 12:06:07 psns1 slapd[12554]: conn=2105 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Dec 13 12:06:07 psns1 slapd[12554]: conn=2105 op=2 UNBIND
Dec 13 12:06:07 psns1 slapd[12554]: conn=2105 fd=11 closed
Dec 13 12:06:07 psns1 slapd[12554]: conn=2106 fd=11 ACCEPT from IP=192.168.50.121:50290 (IP=0.0.0.0:389)
Dec 13 12:06:07 psns1 slapd[12554]: conn=2106 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Dec 13 12:06:07 psns1 slapd[12554]: conn=2106 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN
Dec 13 12:06:07 psns1 slapd[12554]: conn=2106 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
Dec 13 12:06:07 psns1 slapd[12554]: conn=2106 op=1 do_bind: invalid dn (None)
Dec 13 12:06:07 psns1 slapd[12554]: conn=2106 op=1 RESULT tag=97 err=34 text=invalid DN
Dec 13 12:06:07 psns1 slapd[12554]: conn=2106 op=2 UNBIND
Dec 13 12:06:07 psns1 slapd[12554]: conn=2106 fd=11 closed
Dec 13 12:06:07 psns1 slapd[12554]: conn=2107 fd=11 ACCEPT from IP=192.168.50.121:55931 (IP=0.0.0.0:389)
Dec 13 12:06:07 psns1 slapd[12554]: conn=2107 op=0 BIND dn="" method=128
Dec 13 12:06:07 psns1 slapd[12554]: conn=2107 op=0 RESULT tag=97 err=0 text=
Dec 13 12:06:07 psns1 slapd[12554]: conn=2107 op=1 SRCH base="ou=Group,dc=4thbl" scope=2 deref=0 filter="(&(|(objectClass=posixGroup)(?objectClass=group))(gidNumber=*))"
Dec 13 12:06:07 psns1 slapd[12554]: conn=2107 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Dec 13 12:06:07 psns1 slapd[12554]: conn=2107 op=2 UNBIND
Dec 13 12:06:07 psns1 slapd[12554]: conn=2107 fd=11 closed

 

[Ling Ho]

I found out from the slapd log that there is actually a problem. When doing the search for root DSE (attr=* altServer ...), I see a do_bind:invalid dn (None). Looks like sssd is forcing a non-anonymous bind if auth_provider is set to ldap. Even though I really just to use ldap for id, and not authentication. Since I don't have root Bind DN and Bind password set up, the DN became "None" as set by FreeeNAS in /etc/local/sssd/sssd.conf which is an invalid DN. I don't know enough about ldap and sssd to tell if this is a FreeNAS bug, but the combination I used won't work.

So I went ahead an configure Kerberos properly, both on the freenas box, and on the ldap server. After few hours of digging around, finally I see my ldap user and group appear under Change Permissions!