LDAP Unauthorized login possible


I set up LDAP on my XWIKI using the following configs:
Inside the organizational unit there are multiple groups and for now only one group has a single member. Yet all users in ou=users,dc=auth,dc=...,dc=com are able to login. Why does the base DN not work as a login restriction? I also tried setting the base to dc=auth,dc=...,dc=com and the “restrict to group” to ou=users,dc=auth,dc=...,dc=com, but then no one can log in anymore.

Any ideas?

My guess is that the base DN comes only into play, if you search for user DNs. Your configuration actually constructs the user DN by specifying LDAP login matching with the variable CN={0},ou=…

So I could just leave the base DN blank and use the group restriction?
EDIT: Tried it and leaving the base empty works. Still the problem, that group restriction does not work. Unfortunately, my logging settings are not saved… When I restart the XWiki docker container, the logging options are reset to what they were before

Yes that should work. But I guess you have to specify the group with a DN too.

There is one restriction though: All of your users have to fit into the scheme that you provide in LDAP login matching.

The users are referenced inside the group’s memberUid attribute, so they can be in multiple groups. That’s why I can’t have a generic scheme for the login.
The structure looks like this: Screenshot%20from%202018-09-13%2013-35-00

Oh, I see… I got the logs to work.
- Found group [ou=ZCY,ou=groups,dc=auth,dc=...,dc=com] members [null]
It’s true that the organizational unit has no members, but the subgroups have…

Let’s get a little more general:

The ldap login flow is normally like this:

  1. A user provides username and password
  2. The application aquires the user’s DN
  3. The application logs in to the Directory using the user DN and the password, if this works, the user is authenticated

There are multiple ways to achieve Step 2:

  1. All your users are in the same ou and their DN is like this: CN=<username>, ou=abc,dc=xyz,dc=com: Then you just can construct the DN by using (in this case) LDAP login matching: CN={0}, ou=abc,dc=xyz,dc=com
  2. Your users are scattered: You bind with a known user DN and password (so called proxy user) and search for the actual users DN by specifying a query like userid={0} and limit the search scope to a certain “branch” in the directory by specifying a base DN. After you have retrieved the user DN you contine.

In most of the cases restrictions are only applied if you have a proxy user that can navigate/search the directory. So maybe that’s the case here too?
Also you may have to check if there is a way to configure the attribute for the group that holds the users, because that can be members for AD or uniquemembers or memberIds depending on your directory.
Maybe that’s your current problem?

The group restriction does not work against OUs! Because a OU has no members but children. You have to use an actual group (i.e. normally objectClass=group) for a group restriction to work.

Thanks, that was helpful. So there is basically no way of having login matching AND organizational group restriction… Then I’ll have to accept everyone for login and deny all access to wiki for the corresponding groups in the XWiki settings after mapping the ldap groups to XWiki groups. Or is there a more elegant way?

Or I could forget about Organizational Units and just use groups and subgroups only insted

That’s what the doc says:

    #-# The following kind of groups are supported:
    #-# * LDAP static groups (users/subgroups are listed statically in the group object)
    #-# * [Since 3.3M1] LDAP organization units (users/subgroups are sub object of the provided organization unit)
    #-# * [Since 3.3M1] LDAP filter (users/groups are object found in a search with the provided filter)
    # xwiki.authentication.ldap.user_group=cn=developers,ou=groups,o=MegaNova,c=US

So OUs with groups as children should work…

Interesting, didn’t know this. This seems to be a pretty special feature of xwiki.

I still think you will have to work with a proxy user for this to work though.

How is the user’s password verified then?

As I wrote above the proxy user is only used to get all the prerequisites from the directory to finally make a login attempt with the userDN and user password. And only if this login attempt succeeds the user gets access.
So the proxy user could be used to find out if the user is even eligible for a login attempt by checking group memberships or other criteria, like children of an OU.

Alright, thank you for your help and patience! I got it to work…

Great to hear. Would you mind sharing some details?

Do you now use group restrictions?
Do you use restrictions by OU?
Are you using a proxy user now, or still direct logins?
Do use a base DN?

Maybe you can share a screenshot of your configuration?


I use the proxy user to bind, have the OU users as a search base and use the OU ZCY as a group restriction for access. Also, I stopped using the GUI and now configure with xwiki.cfg. Much clearer what you actually set.

Very true. I’m happy that I’m not the only one thinking like this. Maybe I need to create some Improvements in Jira for this, because the UI is more getting in your way than supporting.