Hi guys,
I’m currently trying to setup a seafile server pro with ldap and saml authentication.
For saml I found the following docs:
- ADFS or SAML 2.0
- SAML 2.0 in version 10.0+
Unfortunately I can’t provide links (not allowed in a blog post), but both of them are found under Config → Authentication & Users → Single Sign On. The first one looks a bit mixed up. Could someone tell me which one is the correct instruction to follow?
As well I’m not quite sure how I should configure ldap/saml to get them both working with the UPN from active directory. So if someone could provide some valuable info about the saml mapping that would be great.
Thanks in advance!
Please check the following documents:
https://manual.seafile.com/latest/config/ldap_in_11.0_pro/
https://manual.seafile.com/latest/config/saml2_in_10.0/
Note, you should use the document for version 12.0. The version number is shown at the top of the document site:
Okay, I followed the instructions from these docs, but I’m encountering one issue when using SSO from an onprem adfs server: It doesn’t match the synced user from ldap and the new user created got only that strange username “ab01834dfcbf439ab94251208296cf4d”.
Following the config from seahub_settings.py:
LDAP_PROVIDER = 'ldap'
LDAP_LOGIN_ATTR = 'userPrincipalName'
LDAP_CONTACT_EMAIL_ATTR = 'userPrincipalName'
LDAP_USER_FIRST_NAME_ATTR = 'givenName'
LDAP_USER_LAST_NAME_ATTR = 'sn'
ENABLE_LDAP_USER_SYNC = True
LDAP_SYNC_INTERVAL = 10
LDAP_USER_OBJECT_CLASS = 'person'
LDAP_DEPT_ATTR = 'department'
LDAP_UID_ATTR = 'userPrincipalName'
LDAP_AUTO_REACTIVATE_USERS = False
USE_LDAP_SYNC_ONLY = True
ACTIVATE_USER_WHEN_IMPORT = False
ACTIVATE_AFTER_FIRST_LOGIN = False
DEACTIVE_USER_IF_NOTFOUND = True
ENABLE_ADFS_LOGIN = True
LOGIN_REDIRECT_URL = '/saml2/complete/'
SAML_ATTRIBUTE_MAPPING = {
'sn': ('user_last_name', ),
'givenName': ('user_first_name', ),
'userPrincipalName': ('uid', 'contact_email', ),
}
SAML_REMOTE_METADATA_URL = 'https://adfs.redacted.com/federationmetadata/2007-06/federationmetadata.xml'
What am I missing here?
@daniel.pan could you please take a look at my config and check where’s the error?
I know these cryptic user id are a feature (https://manual.seafile.com/12.0/upgrade/upgrade_notes_for_11.0.x/#change-of-user-identity) but is there no way how to map firstname, lastname and mail to be displayed correctly? If not, how do you know which whom you share a folder or smth?
@daniel.pan any news on this?
If you want us to investigate your problem with a remote session support (paid), please contact sales@seafile.com
Did you try setting the option
SSO_LDAP_USE_SAME_UID = True
It seems like it does not match the user.
If I login via ldap or sync the user beforehand the user is correct with name and mail contact, but if I try to auth with SAML a new user is created although it’s the same user. And for the SAML auth the user got the cryptic user id for mail and name.
Hello!
Out of curiosity, are you using AD? Looks like you have sync turned on as well. I know you had another question regarding mapping & proper display, but to your initial issue, I noticed in the docs this description for LDAP_UID_ATTR:
Attribute for Windows login name. If this is synchronized, users can also log in with their Windows login name. In AD, the attribute sAMAccountName can be used as UID_ATTR . The attribute will be stored as login_id in Seafile (in seahub_db.profile_profile table).
Of course, that value has to match the value of LDAP_LOGIN_ATTR. And I know sAMAccountName is in essence a domain-specific legacy data item meant for backwards compatibility, still I was curious as to its effect if those values were changed from userPrincipalName to sAMAccountName.
Hey,
yeah I’m using AD.
I had sync turned on as well, but currently I just want to use SAML for authentication and don’t use the ldap sync or auth option.
I’ve set LDAP_UID_ATTR & LDAP_LOGIN_ATTR to userPrincipalName and everything works great.
Got it!
Okay, then my next step would be checking the USE_LDAP_SYNC_ONLY option. Currently it is True, and if I’m right, that option - when enabled - means that LDAP is to be used only for synchronizing users & their attributes. In other words, they aren’t supposed to login with their LDAP creds, but rather via SSO. Could it be that we are trying to use LDAP credentials when you have already told Seafile not to use them for login?
To test, what if we change that configuration (and only that one) to False instead?
Also, this may be a quirk of Seafile. Check that comment, even though it isn’t AD-specific.
Hey @trifleneurotic,
sorry for the late response.
I’ll try and get back to you!
