#7888 FreeIPA returns "invalid attribute request" error with SRCH base="(null)"
Opened 2 months ago by gehendra. Modified 2 months ago

Request for enhancement

As <persona, e.g.="" admin=""> , I want <what?> so that <why?>.

Issue

We have been using FreeIPA to authenticate users in a web application (Word Press). It was working perfectly in FreeIPA version 4.5.4. However, after upgrading to FreeIPA version 4.6.4, the authentication is broken with the following error:

[24/Mar/2019:11:15:09.476452749 +1100] conn=100609 op=0 BIND dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" method=128 version=3
[24/Mar/2019:11:15:09.478593570 +1100] conn=100609 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0003105696 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com"
[24/Mar/2019:11:15:09.481242654 +1100] conn=100609 op=1 SRCH base="(null)" scope=2 filter="(&(objectClass=*)(uid=qauser))", invalid attribute request

No changes were made in the web application. To confirm, I again tested the authentication on FreeIPA server version 4.5.4, this time it worked again.

What might have caused this? I am absolutely sure correct search base is provided.
Your help would be highly appreciated?

Steps to Reproduce

  1. Upgrade Free IPA 4.5.4 to 4.6.4
  2. Install MiniOrange plugin in Word Press
  3. Fill in the correct settings in Mini Orange
  4. Try to login using LDAP credentials in Word Press

Actual behavior

Login fails with following error
[24/Mar/2019:11:15:09.481242654 +1100] conn=100609 op=1 SRCH base="(null)" scope=2 filter="(&(objectClass=*)(uid=qauser))", invalid attribute request

Expected behavior

I was expecting to be able to login in Word Press without any error in Free IPA

Version/Release/Distribution

# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.6.4-10.el7.centos.3.x86_64
ipa-client-4.6.4-10.el7.centos.3.x86_64
389-ds-base-1.3.8.4-23.el7_6.x86_64
pki-ca-10.5.9-13.el7_6.noarch
krb5-server-1.15.1-37.el7_6.x86_64

Additional info:

[24/Mar/2019:11:15:09.476452749 +1100] conn=100609 op=0 BIND dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com" method=128 version=3
[24/Mar/2019:11:15:09.478593570 +1100] conn=100609 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0003105696 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com"
[24/Mar/2019:11:15:09.481242654 +1100] conn=100609 op=1 SRCH base="(null)" scope=2 filter="(&(objectClass=*)(uid=qauser))", invalid attribute request

Thank you.
Best
GA


It looks like your search request is wrong:

SRCH base="(null)" scope=2 filter="(&(objectClass=*)(uid=qauser))", invalid attribute request

Please notice base="(null)". Are you passing a NULL string to search base? The search base for user accounts should be cn=users,cn=accounts,dc=example,dc=com"

Hi Christian,
Thank you for your reply and looking at my issue.

I understand that the search base is null in the FreeIPA's log (/var/log/dirsrv/slapd-DIR-INTERSECT-ORG-AU/access), however, the client application is configured correctly to look for the user in cn=users,cn=accounts,dc=example,dc=com (I have changed the domain name here purposely for privacy).

What's interesting is, the client can authenticate with FreeIPA 4.5.4 but not 4.6.4 without any change in the client side. So, this behaviour has given me the confidence that the client is configured correctly.

Is there any aci/acl or other policy in FreeIPA server that would change (convert) the search base to null?

When upgrading FreeIPA from 4.5.4 to 4.6.4, I used CentOS 7's package manager (simply ran "yum update -y") and restarted the server.

Any help would be highly appreciated.

Thank you,
Best
GA

The /var/log/dirsrv/*/access file is the log file of the internal LDAP server, not the FreeIPA API log file. The log file stores informations about the queries that are made against the LDAP server instance. The log file shows (NULL) as a search base. This means the application is querying LDAP with an empty search base. The error message invalid attribute request indicates another LDAP protocol violation. 389-DS only emits that error message when the attribute list contains two or more empty attribute requests:

$ ldapsearch -b 'cn=users,cn=accounts,dc=ipa,dc=example' '(uid=admin)' '' ''
...
search: 4
result: 2 Protocol error
$ tail /var/log/dirsrv/slapd-IPA-EXAMPLE/access
...
[27/Mar/2019:12:07:36.637992688 +0100] conn=1296 op=2 RESULT err=0 tag=97 nentries=0 etime=0.0001965799 dn="uid=admin,cn=users,cn=accounts,dc=ipa,dc=example"
[27/Mar/2019:12:07:36.638746082 +0100] conn=1296 op=3 SRCH base="(null)" scope=2 filter="(uid=admin)", invalid attribute request
...

389-DS used to be more forgiving in the past. Recent versions handle LDAP protocol violations more strictly. The check was implemented in https://pagure.io/389-ds-base/issue/49969 about 5 months ago as a protection against a DoS vulnerablity. You have to fix your LDAP driver or application to send LDAP conform queries.

Login to comment on this ticket.

Metadata