Problems with LDAP Authentication using FreeIPA

Help / Discuss
#1

Hey everyone,

I am having trouble using LDAP for user authentication. I am using LDAP via FreeIPA 4.5 and the following settings:

xwiki.authentication.authclass=org.xwiki.contrib.ldap.XWikiLDAPAuthServiceImpl
xwiki.authentication.ldap=1
xwiki.authentication.ldap.trylocal=1
xwiki.authentication.ldap.server=master.ipa.corp.de
xwiki.authentication.ldap.port=389

xwiki.authentication.ldap.bind_DN=uid={0},cn=accounts,cn=users,dc=ipa,dc=corp,dc=de
xwiki.authentication.ldap.bind_pass={1}
#xwiki.authentication.ldap.base_DN=dc=ipa,dc=corp,dc=de
#xwiki.authentication.ldap.UID_attr=uid

The last two lines are obviously disabled, there was no difference with them enabled.

The corresponding catalina log during login is attached. log.txt (9.5 KB)

Any help to resolve this issue is greatly appreciated.

#2

According to your log the authenticator can access the (a) LDAP server just fine but the provided login/pass is wrong. Maybe the pattern you indicated in xwiki.authentication.ldap.bind_DN is not the right one. You might want to try with a LDAP client (you have some examples listed on http://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/Authenticator/#HLDAPclients).

#3

You are definitely right about the bind_DN, I have corrected this and used the principal and password of a proper bind user. The ability to login was verified using Softerra LDAP Browser.

xwiki.authentication.ldap.bind_DN=uid=service-xwiki,cn=sysaccounts,cn=etc,dc=ipa,dc=corp,dc=de

Unfortunately the error message appears to be unchanged. I have tried logins using the bind user and my personal account. The attached log is from the latter. log2.txt (11.1 KB)

The bind account and regular user accounts are in completely differently groups on my server, if this is relevant (cn=sysaccounts,cn=etc vs. cn=accounts,cn=users).

#4

Well that’s not what the log you pasted indicated, from what I see in it you indicted uid=service-gitlab,cn=sysaccounts,cn=etc,dc=ipa,dc=corp,dc=de. Wrong log ?

It’s not a problem but it does not go this far anyway.

#5

No, this is correct. I haven’t got around to create a bind user for xwiki and was using the one for gitlab insted. I messed up in my previous post :tired_face:

#6

I have kept trying to solve this issue by trying different LDAP configurations. However, the error message did not change.

Is there anything else I should try to solve this issue?

#7

Unfortunately I couldn’t solve this issue yet, and given the lack of the replies it appears to be a difficult problem :frowning:

I will be on the lookout for a different wiki software, as LDAP is a crucial feature for me.

#8

Hi,

sorry to hear that you want to leave. This problem is actually pretty easy and clear, the error indicates that your username or password is wrong.
You could try using a different ldap client to verify your settings. You need to experiment until you succeed to bind with simple bind.

rbr

#9

What @rbr says. Try using Apache Directory Service and connect to your ldap server using the same credentials.

Until you get your connection strings correct, you are going to have problems. What is the correct setting? That depends entirely on your ldap server and schema. I had exactly the same problem which I eventually solved by getting my settings correct.

In particular, did you get the following settings correct?
LDAP LOGIN MATCHING
LDAP PASSWORD MATCHING
LDAP BASE DN
LDAP UID ATTRIBUTE NAME
LDAP USER FIELDS MAPPING

#10

Hi,

so I felt curious because I could not believe that it’s not possible to get xwiki LDAP authentication running with FreeIPA, and guess what: It works!

So that’s what I did:

  1. Install new ubuntu 16.04 VM

  2. Install FreeIPA version 4.3.1-0ubuntu1 from ubuntu repos

  3. Install xwiki 10.5 (I chose this version, should not matter)

  4. Install Ldap Authenticator v9.2.5 (latest) extension

  5. Create service user following this documentation: My account is called ldapreader and has password secret123, the dn is uid=ldapreader,cn=sysaccounts,cn=etc,dc=intranet,dc=example,dc=com.
    The dc part is altered, to protect the innocent. :wink:

  6. Added the following configuration to xwiki.cfg (this is more or less the minimum config):
    xwiki.authentication.authclass=org.xwiki.contrib.ldap.XWikiLDAPAuthServiceImpl xwiki.authentication.ldap=1 xwiki.authentication.ldap.trylocal=1 xwiki.authentication.ldap.server=ipa-test.intranet.example.com xwiki.authentication.ldap.port=389 xwiki.authentication.ldap.bind_DN=uid=ldapreader,cn=sysaccounts,cn=etc,dc=intranet,dc=example,dc=com
    xwiki.authentication.ldap.bind_pass=secret123 xwiki.authentication.ldap.base_DN=dc=intranet,dc=example,dc=com xwiki.authentication.ldap.UID_attr=uid

  7. Done!

@foobar798: I hope that helps, else your are back to a wrong password.

Good luck!

rbr

#11

To be fair, getting the connection strings right with LDAP can be a bit of a pain to get right if you don’t understand LDAP, or your LDAP schema is weird (I’m 2 for 2 here)

It took me just under two hours to get my all my settings correct. Without the detailed debug logging, I never would have gotten it configured.

I think if I had to do it again, It’d take me just as long because I invoked voodoo and various animal sacrifices towards the end.

(that’s not an xwiki problem - it’s a problem with LDAPs “design by committee” feature set)

#12

Agreed. That’s the reason why I implemented the freeipa connection. I wanted to show that it’s doable and that xwiki, freeipa and all the java stuff in between is capable, which I hoped for, but were not sure. With ldap you never know :wink:.
I wanted to reassure @foobar798, that he will not hit a dead end ultimately.
And I shared the complete necessary config to get it going.

Unfortunately the two things that are the hardest to get right (binddn and bindpassword) are the ones that you can’t help with. And the error we see here is exactly related to these two.

According to this thread the solution may have been to throw all the special characters out of the password, but we just don’t know.
This is the absolute worst case because everything looks correct, yet some encoding hiccups will cause your info to be rejected.

#13

That was my first thought on reading that reply, hence my question as to the special characters used. Might be worth testing once we know just to see if we can break the ldap authentication.

#14

The freeipa server is available, so I’ll have a look into this. I bet it’s “§” again, this bugger already cost me a lot of time debugging.