LDAP connection problem with root DN limitation

Hello,

I installed seafile, which worked quite good. We decided to use users from our Active Directory. Unfortunately our AD is organized in a way that below root DN we created ou’s for all of our departments and user’s are located below each of these ou’s. Since all of our users should be able to use Seafile, we need to use our root DN as BASE DN within ccnet.conf.

Unfortunately this fails. After some troubleshooting we saw following bold face note in installation documentation: “You cannot use the root DN (e.g. dc=example,dc=com) as BASE.”

We don’t understand where this limitation comes from, since tools like ldapsearch have no problems finding all users starting the search in root DN.

Does anyone have an idea how to resolve our issue? We would like to find a solution which does not need to rebuild our active directory extensively.

Best regards

Heiko

What error message do you get in ccnet.log? What happens when the integration fails?

Hi Jonathan,

in ccnet.log I see:
[07/11/17 17:12:38] user-mgr.c(386): ldap_search user ‘mail=heiko.ploehn@example.com’ failed for base dc=exampe,dc=com: Operations error.
[07/11/17 17:12:38] user-mgr.c(387): Please check BASE setting in ccnet.conf.

Login Fails with wrong eMail or Password. Also resolving LDAP users after Login with some local admin account gives empty output.

It is not surprising since according to documentation it is not possible to use root dn as base dn.

Do you have an idea how to circumwent this Limitation?

best regards

Heiko

Hi @heikki

I think I found the cause of this limitation here: http://www.novell.com/support/kb/doc.php?id=7021021&add&title=Failed+Active+Directory+(AD)+authentication+-+LDAP+search+failed%2C+error+1+(Operations+error)

The “follow referral” option is set to ON by default according to LDAP library manual. We didn’t notice this before. Looks like we should set it to OFF in our code. We actually have an option to turn it on.

Hi Jonathan,

thank you for your answer. Do you have an idea, how I can solve my issue now?

Can I Change something within some scripts?
Will this behaviour be changed in future Releases?

best regards

Heiko

Hi,

There is no way to change the behavior right now I think. We’ll change the code in the next release.

Hi Jonathan,

I just installed 6.1.2 with hope that this issue is resolved. Unfortunately this seems not to be the case.

Do you know if the resolution will be implemented within 6.2?

best regards

Heiko

You can define multiple BASE statements in ccnet.conf, as described under “Advanced LDAP/AD Integration Options” in the server manual:

BASE = ou=OU1,dc=example,dc=com;ou=OU2,dc=example,dc=com

I’m not experienced with AD, but maybe you can define referral entries that point to your user entries:

ou=OU1,ou=users,dc=example,dc=com -> ou=OU1,dc=example,dc=com

Then you could use ou=users,dc=example,dc=com as BASE.

Or you can set up a meta directory server (with openldap, for example), that defines a virtual view to your AD.

Hi,

I didn’t find such referrals for active Directory. Moreover, at the moment we don’t want to Change our customer’s AD too much.

Therefore we already tried to insert an openldap as meta-directory, but this failed too. Somehow Seafile was able to figure out that the base of our customized openldap was in real the root dn of Active Directory.

best regards

Heiko

If you use a rewrite statement in your meta configuration, this should not happen.
We also use a meta directory. The original users of our ldap server are under ou=people,dc=example,dc=com. The meta directory has the suffix ou=campus,dc=example,dc=com. We defined the following olcDbRewrite statement:

suffixmassage "ou=uni,ou=campus,dc=example,dc=com" "ou=people,dc=example,dc=com"

If we search for uid=xmuster in the original server, we get the DN

uid=xmuster,ou=people,dc=example,dc=com

If we search for the user in the meta directory, we get:

uid=xmuster,ou=uni,ou=campus,dc=example,dc=com

So I wonder how seafile should find out the original suffix.

Hi,

This is implemented. It’ll be in next 6.1 update or 6.2 version.

This problem still exists in Seafile 8.0.4, I cannot use root DN, and this is silly way of implementing to a specific OU. I thought this was supposed to be fixed?

Also, even with correct OU provided direct to where the user is, it still fails with:

Cannot find user xxxxxxxxxx@xxxxxxxxxx in LDAP

Can you post your ccnet.conf also the related error messages?

The only errors in seafile.log generated when attempting to login with Active Directory is:

2021-05-18 21:36:04 ../common/user-mgr.c(1189): Cannot find user seafile@mydomain.com in LDAP.
2021-05-18 21:36:04 ../common/user-mgr.c(1189): Cannot find user seafile@mydomain.com in LDAP.

below ccnet.conf:

[LDAP]
HOST = ldap://192.168.1.2
BASE = DC=mydomain,DC=com
#BASE = OU=GLOBAL_USERS,DC=mydomain,DC=com
USER_DN = CN=Seafile,OU=GLOBAL_USERS,dc=mydomain,dc=com
PASSWORD = mypassword
LOGIN_ATTR = userPrincipleName
#FILTER = memberOf=CN=SeafileAccess,OU=GLOBAL_GROUPS,dc=mydomain,dc=com

as you can see from config, we have tried with root DN as well as setting the other basedn for a particular OU. As well as attempting to utilise a filter to check that authenticating users are a member of the SeafileAccess group or not. But none of it works, resulting in same error as previously posted.

As pointed out in the documentation:

  • BASE: The distinguished name (DN) of the search base when running queries against the directory server. If you want to use the root DN as search base (e.g. dc=example,dc=com), you need to add FOLLOW_REFERRALS = false to the configuration. The meaning of this option will be explained in following sections.

https://manual.seafile.com/deploy_pro/using_ldap_pro/

Like I said, if you see the commented ou=GLOBAL_USERS even when tried with that it didn’t work either. Since FOLLOW_REFERRALS from what you wrote is only needed when using the root DN, then why didn’t the other work when using a particular OU as the BASE?