#8671 Synology DSM LDAP login fails after FreeIPA server is upgraded from 4.8.4 to 4.8.7
Closed: worksforme by rcritten. Opened by paulosv.

Issue

When using Synology's DSM configured with LDAP client, pointed to FreeIPA 4.8.4 (389-DS) instance, and the FreeIPA server is upgraded to 4.8.7, the login stops working. LDAP seems to bind successfully, but a particular subsequent query fails, which did not fail in 4.8.4.

I was unable to pinpoint a specific bugfix/change that triggered this regression, and the package versions 4.8.5 and 4.8.6 are now unavailable in the repositories.

Although LDAP bind with 389-DS using user's own credentials succeeds, the next query, which equals to this command, fails:

ldapsearch -D "uid=pavel.valach,cn=users,cn=compat,dc=example,dc=com" -W -s base -b "uid=pavel.valach,cn=users,cn=compat,dc=example,dc=com" '(objectClass=*)' 'distinguishedName'

With FreeIPA 4.8.4, this query returns a DN. With FreeIPA 4.8.7, this query fails with "not found". The query fails even with Directory Manager rights.

Steps to Reproduce

  1. Install FreeIPA server 4.8.4, enable ADTrust
  2. In Synology DSM, in settings, enable LDAP client with Profile "Open Directory"
  3. Attempt login with a LDAP user to the web interface, it should work
  4. Upgrade FreeIPA server to 4.8.7
  5. Attempt a login with a LDAP user to the web interface of DSM.

Actual behavior

The web UI login to DSM fails with "Username or password was incorrect."

Expected behavior

The web UI login succeeds.

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

Before upgrade:

ipa-server-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64
ipa-client-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64
389-ds-base-1.4.3.8-6.module_el8.3.0+604+ab7bf9cc.x86_64
pki-ca-10.8.3-2.module_el8.2.0+371+f5726439.noarch
krb5-server-1.17-18.el8.x86_64

After upgrade:

ipa-server-4.8.7-13.module_el8.3.0+606+1e8766d7.x86_64
ipa-client-4.8.7-13.module_el8.3.0+606+1e8766d7.x86_64
389-ds-base-1.4.3.8-6.module_el8.3.0+604+ab7bf9cc.x86_64
pki-ca-10.9.4-1.module_el8.3.0+500+458aeb54.noarch
krb5-server-1.18.2-5.el8.x86_64

Additional info

OS: CentOS Linux 8 (amd64) - LXC container hosted in Proxmox VE 6.3-3

Part of a /var/log/dirsrv/slapd-EXAMPLE-COM/access

[19/Jan/2021:18:06:38.895527855 +0100] conn=45 fd=142 slot=142 SSL connection from 192.168.88.9 to 192.168.88.42
[19/Jan/2021:18:06:38.899256962 +0100] conn=45 TLS1.2 128-bit AES-GCM
[19/Jan/2021:18:06:38.899503988 +0100] conn=45 op=0 BIND dn="uid=pavel.valach,cn=users,cn=compat,dc=example,dc=com" method=128 version=3
[19/Jan/2021:18:06:38.923716733 +0100] conn=45 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.003936235 optime=0.024221531 etime=0.028156473 dn="uid=pavel.valach,cn=users,cn=accounts,dc=example,dc=com"
[19/Jan/2021:18:06:38.924187533 +0100] conn=45 op=1 SRCH base="uid=pavel.valach,cn=users,cn=compat,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="distinguishedName"
[19/Jan/2021:18:06:38.924412890 +0100] conn=45 op=1 RESULT err=32 tag=101 nentries=0 wtime=0.000054976 optime=0.000228835 etime=0.000282387
[19/Jan/2021:18:06:38.924745308 +0100] conn=45 op=2 ABANDON targetop=NOTFOUND msgid=2
[19/Jan/2021:18:06:38.924823068 +0100] conn=45 op=3 UNBIND

(domain name anonymized)


Is anything logged to errors when this happens?

cn=compat is a virtual tree. Have you tried restarting dirsrv?

Nothing in the errors file at that specific time, and regarding to compat, there's this:

[19/Jan/2021:18:05:27.369494886 +0100] - ERR - schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds!
[19/Jan/2021:18:05:32.491664523 +0100] - ERR - schema-compat-plugin - Finished plugin initialization.

I have tried to restart dirsrv, and the whole ipa, with no effect.

This way of using schema compat is not supported.

Please change your setup to use primary tree, not the schema compat.

Just to clarify, we did not intentionally use the compat tree. For some reason, DSM decided to use the compat schema preferentially.
Nevertheless, I have disabled the compat schema and the DSM login started working. Thanks for that advice.

Metadata Update from @rcritten:
- Custom field affects_doc adjusted to on
- Custom field knownissue adjusted to on
- Issue close_status updated to: worksforme
- Issue status updated to: Closed (was: Open)

Metadata