Hi,
I just upgraded our seafile cluster from Pro 5.1.8 to 6.0.8 on Scientific Linux 7.3. The ldap authentication doesn’t work anymore. I am trying for hours without success.
I didn’t change the ccnet.conf file. The test “./pro/pro.py ldapsync --test” works fine, but the user authentication doesn’t work. The ldap server always shows an TLS negotiation error. I also tried to delete the seafile ldap libs, without success.
Please, can you help me? Out users are waiting to work.
Thanks.
Small update: our seafile clients (Windows, Apps) can connect to the server, meanwhile. But the web interface (nginx) cannot authenticate ldap users.
This worked before the upgrade. Any ideas, what could be wrong? We didn’t change the nginx configuration.
I’d have a look at the Seafile logs if their is any additional information why this could be the case.
In ccnet.log is logged:
[03/21/17 20:50:25] user-mgr.c(393): ldap_bind failed for user cn=admin…: Can’t contact LDAP server.
[03/21/17 20:50:25] user-mgr.c(494): Ldap init and bind failed using cn=admin…on server ldaps://ldap.xyz:636.
when a user tries to authenticate using the web interface. The ldap server logs “TLS negotiation failed”.
As I said, I tried to run seafile without the provided ldap libraries as described in the server manual. This also didn’t work. I don’t understand, why the seafile clients can authenticate against “https://myseafile”, while nginx can not.
You could try to install the packages openldap and nss-util (assuming they have the same names in Fedora).
(https://manual.seafile.com/deploy/using_ldap.html#using-tls-connection-to-ldapad-server)
Already connected client still use the old token saved locally.
I suggest you downgrade to 5.1, and perform test on a testing server.
As a temporary solution I configured one of our ldap servers without tls. Now people can login and work until we find a secure solution.
But why does the “pro.py ldapsync --test” can connect via tls? The test seems to be useless if the connection works, but seafile doesn’t.
I downgraded our test system to 5.1.8, but seafile doesn’t work anymore. The same error. My guess is, that our seafile servers would have run into the same problem after the next reboot. There was a big system upgrade for Scientific Linux 7.3, where lots of system libraries have been upgraded (openssl, nss, python).
As a test, I made a fresh install of seafile pro 6.0.8 on our test system under Scientific Linux 7.3. The same problem.
My ccnet.conf looks like this:
[LDAP]
HOST = ldaps://ldapserver.xyz:636
BASE = ou=people,dc=mydomain,dc=de
USER_DN = cn=admin,ou=admins
PASSWORD = secret
FILTER = services=seafile
LOGIN_ATTR = edupersonprincipalname
When I try to authenticate an ldap account, ccnet logs this:
[03/23/17 09:43:46] user-mgr.c(393): ldap_bind failed for user cn=admin,ou=admins: Can't contact LDAP server.
[03/23/17 09:43:46] user-mgr.c(791): Ldap init and bind failed using cn=admin,ou=admins: secret on server ldaps://ldapserver.xyz:636.
[03/23/17 09:43:46] user-mgr.c(1441): Cannot find user ymuster@mydomain.de in LDAP.
When I call the ldapsync script, the connection works:
# pro/pro.py ldapsync --test
[03/23/2017 09:50:40] [DEBUG] Try to connect ldap server ldaps://ldapserver.xyz:636.
[03/23/2017 09:50:40] [DEBUG] Connect ldap server [ldaps://ldapserver.xyz:636] success with user_dn [cn=admin,ou=admins] password [*****].
[03/23/2017 09:50:40] [DEBUG] Try to search login attribute [edupersonprincipalname].
[03/23/2017 09:50:40] [DEBUG] Using filter [services=seafile].
[03/23/2017 09:50:40] [DEBUG] Search result from dn [ou=people,dc=mydomain,dc=de], and try to print ten records:
[03/23/2017 09:50:41] [DEBUG] uid=ymuster,ou=people,dc=mydomain,dc=de: {'eduPersonPrincipalName': ['ymuster@mydomain.de']}
...
I also tried to delete the ldap libraries from seafile/libs (libldap, liblber, libsasl) without success. When I connect to the ldap server without tls, everything is fine and ymuster can log in.
Have you installed them using your package manager?
I think they were pre-installed with the distribution. They belong to the standard packages openldap and cyrus-sasl-lib.
The only difference that I see is, that seafile has been compiled with openssl-1.0.0, while SL 7.3 uses openssl-1.0.1e.
I had this same problem. I looked through the most recent updates to my system and after a bit of trial and error downgrading nspr fixed things for me.
You might have to do some combination other than mine before it will work for you. For me “yum downgrade nspr nss nss-util nss-sysinit” worked.
If you successfully downgrade to nspr 4.11.0-1.el7_2 I believe things should start working for you again.
I’m new here so I don’t know how to bring this up with the Seafile team, but it would be cool if this bug got fixed so I could follow distro updates for nspr.
What linux system and version do you use?
I tried this on my test system and it really works. Thanks for finding this out. But I won’t do this on our production systems. There might be some unwanted side effects. I will wait until the seafile developers have found an official solution.
To verify the solution I ran “yum update” again. This updated the following packages:
Aktualisieren : nspr-4.13.1-1.0.el7_3.x86_64 1/22
Aktualisieren : nss-util-3.28.2-1.1.el7_3.x86_64 2/22
Aktualisieren : nss-sysinit-3.28.2-1.6.el7_3.x86_64 3/22
Aktualisieren : nss-3.28.2-1.6.el7_3.x86_64 4/22
Aktualisieren : nspr-devel-4.13.1-1.0.el7_3.x86_64 5/22
Aktualisieren : nspr-4.13.1-1.0.el7_3.i686 6/22
Aktualisieren : nss-util-devel-3.28.2-1.1.el7_3.x86_64 7/22
Aktualisieren : nss-devel-3.28.2-1.6.el7_3.x86_64 8/22
Aktualisieren : nss-tools-3.28.2-1.6.el7_3.x86_64 9/22
Aktualisieren : nss-util-3.28.2-1.1.el7_3.i686 10/22
Aktualisieren : nss-3.28.2-1.6.el7_3.i686
I restarted seafile and seahub. Now ldap users can not log in anymore using TLS.
@daniel.pan I’m using CentOS 7.3 and seafile-pro-server-5.0.4
Roughly the same OS as @Xaver_Muster, but an older Seafile.
Hi,
are you working on this? There was another big update on Scientific Linux 7.3. I tried Seafile Pro 6.0.12 without success. Still no authentication with LDAPS.
Hi,
With 6.0.9 (community) on CentOS 7 (but probably host operating system is not so important), ldap works. ldaps does not.
ldapsearch on ldaps works.
Even ./pro.py ldapsync --test (I downloaded pro version to check it) works with ldaps !!
Looking with tshark, connection seafile ->ldaps server starts, packets are only SYN, SYN ACK,…FIN. Done. Connection dropped.
Nothing more.
Finish.
End.
Any hope that someone can work on such a basic bug? … without a downgrade to previous and probably bugged, system libraries?
Thank you all
Hi,
Have you remove the bundled libraries as stated in the documentation? On CentOS 7 it should work.