Authentification LDAP

[klaurancy]

Bonjour,

Suite à la nouvelle version de Dynfi Manager en 25.0, j'ai essayé de paramétrer l'authentification LDAP mais sans succès.
Est ce qu'il serait possible d'avoir un avis/conseil à ce sujet ?
Est ce que Dynfi Manager s'authentifie à l'aide du NTLM ? Ce protocole est bloqué par sécurité sur notre AD, le problème vient peut être de là...

A savoir:

- fichier de conf (essais en 389 ou 636 = résultat idem):

# This is DynFi? Manager configuration file.
# This file must follow properties format: https://en.wikipedia.org/wiki/.properties.
# Run `dynfi help` or visit http://dynfi.com for more help.

ipAndPort=0.0.0.0:9090
useHttps=true
mongoClientUri=mongodb://localhost
mongoDatabase=dynfidb

# Parametres Authentification LDAP

# Serveur

ldapHost=ADRESSE_AD
ldapPort=389
ldapUseSSL=false

# User Binddn

ldapSystemUser=DN_user_binddn
ldapSystemPassword=MDP_user_binddn


# Recherche Users

ldapUserSearchBaseDn=OU=users_dynfi,dc=domain,dc=dom
ldapUserSearchAttribute=cn
ldapUserNameAttribute=cn
ldapUserEmailAttribute=mail

# Recherche Groups

ldapGroupSearchBaseDn=OU=group_dynfi,dc=domain,dc=dom
ldapGroupSearchAttribute=member
ldapGroupSearchAttributeFormat=CN={0},OU=users_dynfi,dc=domain,dc=dom
ldapGroupNameAttribute=cn
ldapDefaultDeviceGroup=ALL

- les requêtes ldapsearch aboutissent bien, que ce soit en ldap ou ldaps:

ldapsearch -LLL -H ldap://IPad -x -W -D "user_binddn " -b "OU_users_dynfi,dc=domain,dc=dom" "(sAMAccountName=user_test)"

- Pas d'erreur apparente dans les logs de Dynfi
- Les rôles dans Dynfi ont été paramétrés avec le même nom que les groupes dans l'AD
- Nous voyons bien les requêtes LDAP transiter avec un tcpdump

Cdlt,

[astojanowski]

Hello,
Thank you for asking.

DynFi Manager doesn't use NTLM - this shouldn't be problem.

Your config looks ok, but as usual with LDAP, small detail may be the cause. Let's do a few tests. I assume that you try to login as user_test to DFM and it doesn't let you in (login form turns red, no messages).

1. When you start (restart) DynFi Manager, one of the first lines (just after a series of com.dynfi.cli.StartCommand) in dynfi.log (/var/log/dynfi/dynfi.log) should be something like this:

Code: Select all

com.dynfi.di.ShiroModule [ShiroModule.java:68] - LDAP configured at LDAP://local.open.ldap:389. SSL is DISABLED. DFM looks for LDAP users in: uid={0},ou=people,dc=dyn,dc=fi

Can you see it? It confirms DFM uses your config, it doesn't yet mean it's able to connect.

2. Did you run the ldapsearch example on the machine DFM runs on? Does it work? I'm thinking: maybe DFM can't read AD or ports are blocked. Let's make sure DFM can reach your AD on LDAP ports.

3. Could you try running ldapsearch from the machine with DFM, with exactly the same parameters you have in DFM conf? It may sound silly, but we've solved lots of issues this way. In the example from the post I can see:
- -b "OU_users_dynfi,dc=domain,dc=dom" ; Is OU_users_dynfi a typo? for -b use exactly the value of ldapUserSearchBaseDn in the DFM conf
- Please make sure -D "user_binddn" is exactly the value of ldapSystemUser, then pass the value of ldapSystemPassword when ldapsearch asks for password
- Instead of "(sAMAccountName=user_test)" use the value of ldapUserSearchAttribute - "(cn=user_test)" Does it work?
- -H ldap://IPad please make sure ldapseach works with port 389 and your AD doesn't force SSL (port 636)

4. Ad 389 vs 636 port: Please make sure your AD accepts non SSL connections. If AD forces SSL (port 636), you may have to import the certificate into your JRE keystore (it depends on the type of the cert you have in AD; self-signed maybe? DFM can't trust the cert?). If there's an issue with certificate, DFM should complain in dynfi.log.

5. When you try to login to DFM observe dynfi.log. If there's no error in the logs - we're rather interested in general (AD not reachable, ports, etc) issues or ldapUserSearch part of the conf.

6. In the log, when you try to log in, DFM may complain about groups (e.g. "User was correctly authenticated, but DFM couldn't get user groups from LDAP. It may be an issue with missing/incorrect ldapGroup* or ldapSystem* properties in DFM config. Please consult DynFi Manager documentation."). This indicates that user search works, and ldapGroupSearch* settings may be the reason.

Please, let me know the results of these tests. If they don't provide any hints, please send your dynfi.log to our support account.

Regards,
Adam

[klaurancy]

Hello,

Thanks for your quick response. I'll check your suggestions.

Regards

[klaurancy]

Hello,

I succeeded, but we can't connect with the "sAMAccountName," only with the "cn."
I tried changing the ldapUserSearchAttribute parameter to sAMAccountName, but without success. In the created DYNFI groups, members appear with their "cn," which may be the reason. Is there an additional parameter to filter differently ?

Regards

[astojanowski]

Hello,
I think the problem with "sAMAccountName" comes from the way DFM uses ldapUserSearchAttribute & ldapUserSearchBaseDn in user auth. It uses these two params in a way similar to ldapsearch's -D option. So, if dynfi.conf looks like this:

Code: Select all

ldapUserSearchBaseDn=OU_users_dynfi,dc=domain,dc=dom
ldapUserSearchAttribute=sAMAccountName
ldapUserNameAttribute=cn
(...)

It means something like:

Code: Select all

ldapsearch -H ldap://address -x -W -D "sAMAccountName={username},OU_users_dynfi,dc=domain,dc=dom" -b "OU_users_dynfi,dc=domain,dc=dom" "(cn=username)"

So if you could successfuly run the above then sAMAccountName should work.

It's not related to groups. Groups can use cn or any other param for membership, without impact on user auth.

[klaurancy]

Hello,

Thanks for your response.

The ldap request with ldapsearch are ok with cn or sAMAcconutName, but the log attemps on the authentication portal (attachment) are impossible with the sAMAccountName.
I have tried various settings with ldapUserSearchAttribute and ldapUserNameAttribute (=> sAMAccountName) but without success, only attribute "cn" worlk well on the authentication portal. Even in the user list when we are logged in Dynfi, it's the "cn" that appears.

Sorry but I don't know if I'm clear in my explanation and I can't put confidential information in this post, but I remain available if you need further information.

Thanks for your help.

Regards