LDAP

[elllectrum]

Hi!
Is there any plan to implement LDAP in HFS? I would like to assign permissions to catalogs and directories using groups from Active Directory.

[rejetto]

hi, #181
basically nothing has changed, as i'm still in a previous phase of the project, so you'll not see this in the next 3 months for sure.
Not unless someone else works on that.

[eidyev]

It would be good to include support for obtaining users from LDAP using ActiveDirectory and/or OpenLDAP. A simple variant is that the application tries to log in against an LDAP server and if it authenticates correctly, the user is created in the database locally. The integration with LDAP allows the application to be used in business and home environments with multiple users using centralized credentials, which is very convenient for users.

[rejetto]

yesterday i've found a good time to work on it, and i have this experimental plugin that is both synchronizing and logging in against an LDAP server. It won't work with the next version of HFS (0.56), but the one after that.
I surely need someone to test it, but not today. First I must finish 0.56.

[elllectrum]

I'm ready to test

[eidyev]

me too, i have an openldap server localy on my home network

[rejetto]

is it necessary to import groups or accounts is enough?

[rejetto]

i've been spending hours on the matter and i'm still quite confused.
apparently ldap world is filled with variants.
also i've only found one accessible server for testing, and with a lot of struggle i've came up with one myself, that produced more doubts than answers.
it may help a lot to know what you expect as configuration parameters from my software.
i expect a no, but do you think it's possible to have a read-only access to your ldap server? it may help. in case, detail privately [email protected] .

[elllectrum]

Unfortunately, there is no way to provide access to the server, since this is a corporate server.

[rejetto]

ok, what about the configuration parameters?

[elllectrum]

Regarding the configuration parameters, I would suggest the following key settings:
LDAP server address (e.g., ldap://corp.example.com:389).
Base DN (e.g., dc=corp,dc=example,dc=com).
Bind DN and password for server authentication (if required).
User search filter (e.g., (objectClass=user)).
Attributes for mapping:
User login (e.g., sAMAccountName for Active Directory).
User groups (e.g., memberOf).
Group filter (e.g., (objectClass=group)), to enable access control based on group membership.

Support for groups is indeed critical, as in corporate environments, access to resources is often granted based on group membership (e.g., granting access to a directory only for members of the legal department).

[elllectrum]

I just wanted to add that implementing LDAP support in HFS would significantly increase the product's appeal, especially for corporate environments. LDAP integration is one of the key factors for enterprise-grade software, as it allows seamless user management and access control through centralized authentication systems like Active Directory or OpenLDAP.

Many organizations rely on LDAP for managing user permissions, and without it, they often have to look for alternative solutions. By adding LDAP support, HFS would become a much more attractive option for businesses, potentially expanding its user base and popularity.

Thank you again for your efforts on this—it’s a highly anticipated feature!

[rejetto]

would it be a good idea to automatically discover the user login field, by using the first one available from this list? sAMAccountName, uid, cn

[elllectrum]

Automatically detecting the login field from a prioritized list (sAMAccountName, uid, cn) could simplify setup for many users, especially those unfamiliar with LDAP attributes. However, there are a few considerations:

sAMAccountName is specific to Active Directory, while uid is common in OpenLDAP. Defaulting to the first available might work, but could lead to unexpected behavior if attributes overlap (e.g., cn might not be unique).
Some environments may use non-standard attributes. Adding a configurable fallback option (e.g., letting users manually specify the field if auto-detection fails) would make the feature more robust.
If implemented, logging which field was chosen during auto-detection would help users debug issues (e.g., "Using uid for login since sAMAccountName was not found").