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][INFO][privacyidea.lib.user:233] user u'test' found in resolver u'domain.local' [2020-04-30 13:33:40,486][INFO][privacyidea.lib.user:234] userid resolved to u'9c869e1f-3973-48e5-8952-111006feae87' [2020-04-30 13:33:40,487][INFO][privacyidea.lib.user:360] User u'test' from realm u'realm' tries to authenticate [2020-04-30 13:33:40,490][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][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][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…