LDAP Resolver and Policy Matching Issue – User Not Found

1

Hello PrivacyIDEA community,

I’m trying to configure PrivacyIDEA to authenticate users from our Active Directory using an LDAP resolver, but I’m running into an issue where the policy does not seem to match, and authentication fails.

Configuration details:

  • LDAP Resolver

    • LoginName Attribute: sAMAccountName

    • Search Filter: (sAMAccountName=%s)

    • Search Filter for User Groups: (memberOf=*)

  • LDAP configuration has been verified: I can perform successful queries using ldapsearch. I have tested the base DN and filters in multiple ways to make them as general as possible.

  • PrivacyIDEA version: 3.12.1

  • Realm: example-realm

  • Policy: AllowAllTOTP

Observed behavior:

  • When I send a test authentication request via curl, PrivacyIDEA responds that the user does not exist.

  • Debug logs indicate that no policies match the user or resolver:

Policies after matching user=exampleuser: []
Policies after matching resolver=: []
Policies after matching pinode=localnode: []
Policies after matching the user_agent=curl: []
Policies after matching client=127.0.0.1: []
Trying to match policy for action "passOnNoUser". Policies: ['AllowAllTOTP']

  • The LDAP resolver is correctly returning user objects for ldapsearch.

  • The policy is active, assigned to the correct realm, and associated with a resolver.

Problem:
Despite having a working LDAP resolver and an active policy, the user is not matched and authentication fails.

Has anyone seen similar behavior? Could this be related to how the policy matches the LDAP resolver or the user_agent?

Any guidance or suggestions would be greatly appreciated.

2
  1. Your are talking about `ldapsearch`. But do you actually See users in privacyIDEA?
  2. What does your Policy actually look like?
  3. Your problem description is not clear: “The user is not matched?” What do you mean by that? What does actually happen?
  4. What kind of auth request are you sending and what is the response?
3

Hi @Cornelinux

I’m trying to authenticate AD users (username + password + MFA token) from Active Directory using PrivacyIDEA 3.12.1.
The final goal is to integrate PrivacyIDEA with FreeRADIUS, but first I’m testing locally with:

curl http://127.0.0.1/validate/check \
  -d "user=example_user@example_realm" \
  -d "pass=ADpassword123456"

Current status

  • LDAP resolver configuration works now (after apply (sAMAccountName=*) — I can see AD users in the Users tab.

  • My resolver parameters:

    • Loginname Attribute: sAMAccountName

    • Search Filter: (sAMAccountName=*)

    • Search Filter for User Groups: (memberOf=*)

    • GROUPNAMEATTR: cn

    • The resolver is attached to the correct realm (example_realm).

  • LDAP connectivity was verified using ldapsearch successfully in the local console.

Problem

When trying to simulate the the authentication with curl, I receive:

{
  "detail": {
    "message": "The user has no tokens assigned"
  },
  "result": {
    "authentication": "REJECT",
    "status": true,
    "value": false
  }
}

However, the user does have a valid TOTP token assigned in PrivacyIDEA, and the token is clearly linked to the same realm as the user.

If I try validating only the OTP value directly, for example:

curl http://127.0.0.1/validate/check -d "user=testing2_user" -d "pass=898756"

I get the same error ("The user has no tokens assigned"), but from the PrivacyIDEA web interface I can successfully validate the token for this user. If I test the password+token form the web I get ("wrong OTP pin"),

4

Did you ever take a look at the audit log?

This shows you in detail how privacyIDEA interprest the request, that it receives.

I am not familiar with curl parameters. May this is an issue.

The user might not be located in the default realm.

Also, check your policies!
Always take a look at the audit log in the webui. This tells you what exactly is happening!

Then we can stop guessing.

(Did I tell you, that you should take a look at the audit log)

5

@cornelinux

I found that even if a user generates their own TOTP token from the PrivacyIDEA GUI, the token isn’t properly associated with the user until an admin manually “unassigns” and then “assigns” it again from the admin interface.

image
image1068×189 10.8 KB

I discovered this while checking from the pi-manager shell.
At first, when listing the user’s tokens, I got an empty list:

from privacyidea.lib.user import User
u = User("example_user", realm="example_realm")

from privacyidea.lib.token import get_tokens
tokens = get_tokens(user=u)
print(tokens)
# []

After I re-assigned the token from the admin account, I ran the same commands and obtained a valid token object:

print(u.info)
# {'fullname': 'Example User', 'surname': 'User', 'givenname': 'Example',
#  'username': 'example_user', 'email': 'example.user@example.com', 'phone': '', 'mobile': []}

tokens = get_tokens(user=u)
print(tokens)
# [<class 'privacyidea.lib.tokens.totptoken.TotpTokenClass'> {... 'serial': 'TOTP000123AB', 'tokentype': 'totp', 'active': True, ...}]

So it seems that self-enrolled tokens are not immediately linked in the database, and an admin-level reassignment is required for the system to recognize them.

After this, the error even the “wrong otp pin“ changed for “Invalid comparison in the token conditions of policy 'AllowAllTOTP’“ from the GUI.

image
image1094×722 39.4 KB

The audit log show same error.

image
image739×345 27.6 KB

6

Finally, I deleted the additional condition, and it is working now!

Thanks @cornelinux

1 Like