Resolver + Disabled Accounts + Existing Tokens

This is more of a question to confirm how users and resolvers function when a user may be transient within a resolver.

For example, we would like to ensure that an ActiveDirectory/LDAP account that is disabled will not be able to login via tokens. I have added the search (!(UserAccountControl:1.2.840.113556.1.4.803:=2)) to ignore disabled accounts.

Process flow:

  1. User is assigned tokens
  2. User account in AD is disabled
    a. While user is disabled, two-factor authentications fail
  3. User account is re-enabled
    a. Two-factor authentications begin working agian

Since this is working as I want it to, I wanted to confirm this is expected behavior and will not change in the future. If a user is temporarily removed from a resolver, do the tokens stay in their existing state or is there a backgroup janitorial job that will delete them at some point?

Hopefully this isn’t too confusing.

Good question, I think the documentation could provide a better overview of this.

There should be more in 4.1 and 4.2.
Some hints can be found here:

How you have done it is right.

When a user is assigned a token, the link to the user is saved in the token database with the userid. The userid is an identifier to find the user in a resolver. This id can vary from resolver to resolver.
As long as the token is not used, this assignment is not touched. No janitorial task.

So during authentication

  1. the user provides his username.
  2. Then privacyIDEA uses the resolvers to find a userid for this username.
  3. With the information resolvername, userid and realm privacyIDEA can now find the tokens for this user in the token database.
  4. It will now iterate over these found tokens, if some of the tokens make sense and match.

Of course, if you avoid finding the user by disabling the user, removing the user from a group or what ever depending on your filter, privacyIDEA of course will get no tuple (resolvername, userid) and will not continue the authentication process. It will already break in step 2. and not even search for tokens, since it does not know, how.
However, the token still exists untouched.

Awesome! Thank you for the information. That makes me feel more comfortable about implementing the “block” for disabled users. My fear was that their tokens could/would disappear and a new enrollment would be required.

1 Like