we have an instance of PrivacyIDEA 2.23.3 which uses an LDAP Resolver with the preset setup to fetch users form our Microsoft Domain.
After upgrading to v3.3, the LDAP Authentication stops working.
If we test the LDAP resolver, it passes the tests fetching the users from AD, but when a user tries to login the authentication fails.
From the log it seems that it fails to bind through the ‘objectGUID’ of the user:
[2020-04-30 13:33:40,486][1256][140445537838848][INFO][privacyidea.lib.user:233] user u'test' found in resolver u'domain.local'
[2020-04-30 13:33:40,486][1256][140445537838848][INFO][privacyidea.lib.user:234] userid resolved to u'9c869e1f-3973-48e5-8952-111006feae87'
[2020-04-30 13:33:40,487][1256][140445537838848][INFO][privacyidea.lib.user:360] User u'test' from realm u'realm' tries to authenticate
[2020-04-30 13:33:40,490][1256][140445537838848][INFO][privacyidea.lib.resolvers.LDAPIdResolver:466] The filter u'(&(sAMAccountName=*)(objectClass=person)(objectGUID=\\1f\\9e\\86\\9c\\73\\39\\e5\\48\\89\\52\\11\\10\\06\\fe\\ae\\87))' returned no DN.
[2020-04-30 13:33:40,490][1256][140445537838848][WARNING][privacyidea.lib.resolvers.LDAPIdResolver:354] failed to check password for u'9c869e1f-3973-48e5-8952-111006feae87'/'': Exception('No valid user. Empty bind_user.',)
[2020-04-30 13:33:40,491][1256][140445537838848][INFO][privacyidea.lib.user:371] user User(login=u'test', realm=u'realm', resolver=u'domain.local') failed to authenticate.
If we use ‘sAMAccountName’ as ‘UID Type’, the authentication succeds, but we loose token<->user relationship (i.e. users don’t have any token associated to them).
We fixed this with a script that updates user_id field in tokenuser table by replacing objectGUIDs with sAMAccountNames and it seems to work, but I don’t feel at ease with this solution and would prefer using a “standard” setup. Moreover I would like to know why it fails…
PrivacyIDEA 2.23.3 runs on RHEL 7.8 with python 2.7.5-88 and MariaDB 10.1.29-3.
We have defined one realm ‘realm’ and one LDAP resolver ‘domain.local’.
LDAP resolver ‘dmain.local’ queries our domain controller with LDAPS:// URIs and binds though a dedicated user.
Loginname Attribute, Search Filter, Attribute mapping, Multivalue Attributes and UID Type are set as per “Preset Active Directory” (namely UID Tpye is set to ‘objectGUID’).
We have a policy with a ‘passtrough:userstore’ authentication mode to let user authenticate to AD.
Everything works as expected, users can log in with their AD username and password, enroll new tokens, ecc.
When we upgrade to PrivacyIDEA 3.3 (cloned machine, everything else is as stated above), login stops working.
Debug log reveals that now LDAP resolver can’t get the DN for domain users searching for their objectGUID, so LDAP can’t bind users and authentication fails.
If we change UID Type in LDAP resolver from ‘objectGUID’ to ‘sAMAccountName’, everything is fine and users can login with their AD username and password.
We have captured the LDAP traffic between PI and Domain Controller, and it looks like after the upgrade PI searches for the objectGUID using an escaped string to represent the GUID, while before the upgrade the GUID is represented as a byte sequence:
Before update (this is the wireshark way of decoding of the protocol):
I think know this is a problem with ldap3.
So probably you have installed privacyIDEA in a nonofficial way. privacyIDEA 3.3 requires the python module ldap3==2.6.1.
Install the python modules in accordance to requirements.txt and everything will be fine!
We followed the Upgrading procedure from the documentation, using privacyidea-pip-update to upgrade PrivacyIDEA and its dependencies… I double checked with pip show ldap3 and it reports that we have version 2.7 installed…
Could this be the problem? Does PI require exactly version 2.6.1 or any versiongreater than 2.6.1?
As I said we simply run the privacyidea-pip-update command…
OK, just for the record we think that ldap3 2.7 was installed by privacyidea-pip-update from version 2.23.3, which doesn’t use requirements.txt but simply does a pip install --update for each installed package and then updates privacyidea.
Maybe it’s worth mentioning the issue in the update documentation…
)