Rėsolu - Configuration Synology directory Server ad sur jeedom

bonjour à tous,

Je suis passé de Synology ldap server qui fonctionnait tres bien avec mon jeedom sur virtual machine manager, à Synoloy directory server qui ne fonctionne pas .

je recois une erreur dans http.error :
PHP Warning: ldap_bind(): Unable to bind to server: Strong(er) authentication required in /var/www/html/core/class/user.class.php on line 132, refer…

lorsque je teste la connexion.

je ne vois pas bien d’où vient ce soucis, mes identifiants de connections à l’ad fonctionnent ailleurs.Quelqu’un a t’il reussi à faire fonctionner synology directory server sur jeedom. ?

Autre chose, ou puis-je trouver des logs plus détaillés en ssh ?

Merci pour tous,

Personne ? :wink:

Salut

Personne car tu es le seul à voir toutes les infos :

  • le message parle d’un souci niveau de sécurisation
  • la ligne 132 du fichier est la source de l’erreur

Mais sans info sur la version de ton jeedom, impossible de trouver la bonne ligne…
A tout hasard, en V4 il y a

		if (ldap_bind($ad, config::byKey('ldap:username'), config::byKey('ldap:password'))) {

Bref ça voudrait dire que ton config user/password coté jeedom n’est pas bonne et ne permet pas de te connecter au ldap avant ensuite de vérifier le compte utilisateur

Merci pour ton retour. et pardon pour le manque d’infos…

je tourne en jeedom v3.3.52

J’ai tester mes identifiant avec une soft pour interroger mon ad et ils sont ok, j’ai donc utilisé les meme avec mon jeedom. j’ai essayé plusieurs facon de me connecter mais rien n’y fait.

Avant je tournais avec synology ldap server, je n’avais pas de soucis. donc ma question est est-ce compatible avec Synology Directory server ?

Merci pour tout.

Le ldap, c’est un standard protocolaire donc la compatibilité n’est pas vraiment la piste la plus probable de l’erreur.
La c’est typiquement une erreur de négociation entre jeedom et le syno
Vérifie bien la configuration :

  • ip et port ldap 389 ou ldaps 636
  • user / password
  • validation des certificats si ldaps par rapport au noms de serveurs

Et faire un comparaison entre le nouveau syno et l’ancien : ldaps tous les deux ? certificats différents ? Même critères de sécurisation ?

Vu le peu d’utilisateurs d’un ldap, il faut creuser partout car pas possible de reproduire ça facilement.

Nous avions déjà évoqué le cas lors d’un précédent échange : ldap (grand nombre d’utilisateurs) et jeedom (accès à l’interface au vip seulement) ça ne me semble pas une stratégie adéquate

synology domaine controller fonctionne en ldap 389 d’apres la docs, je pense donc qu’il n’y a donc pas de certificat, mais je peux me tromper. Comment puis-je vérifier les certificats?

Sais-tu si je peux activer des logs plus poussés ? ne pas juste me fier à http.error ?

Si je souhaite mettre le ldap en place, c’est d’une part pour avoir un seul compte utilisateur pour tout et peut-etre tester le SSO (etape suivante). La fonction est la donc voila :wink:

Merci pour ton aide,

Pour compléter, j’ai activer la connection HTTPS sur jeedom avec un certificat letsencrypt. Mon syno possède aussi un certificat letsencrypt, tout fonctionne bien.

Bonjour,
Suite à vos discussions, j’ai monté un petit labo pour vérifier la connexion LDAP vers un syno avec Directory Server activé.
Je teste une connexion à partir d’un client windows sur lequel j’ai installé Softerra LDAP Administrator.
Pour pouvoir me connecter au Syno DS, je dois effectuer une « strong authentication ».
J’ai donc spécifié dans credentials que je devais utiliser le mécanisme « GSS Negociate », comme user: %Domain%\%samaccountname% et le mot de passe.
Dans ces conditions, je sais me connecter au DS du Syno.

Il y a par contre une différence par rapport à un Microsoft AD server sur lequel la connexion avec le mécanisme simple est possible.
Là, pour le user, il faut soit le DN (cn=%user%,cn=users,dc=%domain%,dc=%country%, soit le samaccountname et le mot de passe. Les mots entre %xxx% sont à remplacer par leur valeur

Pour en revenir à la connexion à partir de Jeedom, il faudrait vérifier dans le code, s’il est possible de se connecter en « GSS Negociate ».

@gsc: Quand tu dis que tu a tester avec un soft pour valider tes identifiants. As tu testé avec un véritable client ldap ou avec un client AD ? Si, ce n’est pas indiscret, avec quel soft as tu testé ?

Salut,

C’est effectivement différent entre ldap et ad car les attributs ne portent pas les même noms mais restent compatibles… Quand le filtre est écrit en dur, il faut forcement corriger.

Concernant les outils de gestions AD, perso j’aime bien Apache Directory Studio https://directory.apache.org/studio/
Gratuit à la différence de celui de Softerra . Le seul point négatif que je lui trouve c’est sa limite par défaut à 1000 items… C’est parfois un peu court

Bonjour Henribi,

Merci pour ta réponse, je sais pas trop ou fouiller dans le code pour trouver GSS Negociate.

J’ai tester avec une machine Windows 10 que j’ai connecté au domaine et avec l’application ADExplorer. un outil que j’ai trouvé pour interroger l’ad.

N’hésites pas si tu progresse dans tes recherches :wink:

Merci et bonne soirée,

Bonjour,
J’ai continué mes recherches. La solution Synology Active Directory Server est basée sur la solution Samba.
Dons un rapide recherche sur Samba Active Directory amène ceci:image

Si on suit le lien au niveau du point 3.1.2 What does LDAP_Bind Stronger Authentication required …
image

Ceci signifie qu’un simple LDAP_BIND n’est pas supporté.
C’est cette fonction qui est utilisée dans le code au niveau de core/class/user.class.php

J’ai modifié la configuration de samba sur synology.
J’ai ajouté dans le fichier /etc/smb.conf dans global le paramêtre « ldap server require strong auth = no »
Après un restart du Synology, j’ai pu me connecter en ldap simple.
Comme user, j’ai donné un DN (cn=USER,cn=users,dc=DOMAIN,dc=COUNTRY)
Les mots en majuscule sont à remplacer par tes valeurs.

ATTENTION: Cette modification affecte le fonctionnement du Synology en tant que AD server.
Je n’ai aucune idée des conséquences. Je ne peux être tenu responsable des éventuelles conséquences.

Bonjour henribi,

J’ai modifié le fichier /etc/samba/smb.conf comme tu l’as indiqué, reboot du nas et effectivement j’arrive à me connecter à mon ad avec un utilisateur domain admin, j’ai pas mis de filtre. Cette partie fonctionne.

Par contre je n’arrive a me connecter avec un utilisateur de mon ad dans la meme OU, j’ai essayé domain\samacountname et samacountname mais je n’y arrive pas.

j’ai essayé de me connecter avec le compte domaine admin, le meme que pour la connection a l’ad, ca ne marche pas. Je lui ai mis tous les droits possible, toujours pas.

Je vais continuer mon investigation.

En tout cas merci pour ton aide et tes tests.

Voici la configuration LDAP dans mon Jeedom.
Toutes les informations sont d’un domaine de test.
image
Lukaku est un utilisateur normal. Le seul groupe auquel il appartient est « Domain Users »

Suite bientôt. J’ai perdu l’accès à Jeedom

Dans ta db config il y a une ldap enable il faut le passer à 0 pour revenir à une authentification classique.

Je pense que ton utilisateur doit avoir le droit de lire la’d pour permettre aux utilisateurs domain users de se connecter.

Pas de problème pour récupérer la connexion vers Jeedom. J’ai utilisé la même méthode.
Par contre, il faut également effectuer les modifications dans le code décrite par Nikk0 dans les posts 22 et 23. Voir le lien ci-dessous.
https://community.jeedom.com/t/configuration-ldap/10131/22
Avec cette config, j’ai des utilisateurs du Synology Active Directory servser qui se connectent.

pour moi aussi ca fonctionne, merci pour ton aide.

J’ai activer le sso sur mon nas, ca fonctionne parfaitement, je vois que dans la config ldap de jeedom il y a une case remote user. tu as une idée de commence ca se configure ?

Non, pas la moindre.
Dans la DB, on trouve sso:allowremoteuser.
C’est utilisé dans core/php/authentification.php
Tel que je le comprends. Une autre machine effectue un renvoi de session vers Jeedom en ayant indiqué la valeur REMOTE_USER=xxxx dans un header (lequel ?). Si l’utilisateur existe sur Jeedom, on l’utilise pour afficher Jeedom.
Cette option reste active même si LDAP est désactivé. Dans l’état actuel, ce n’est pas à utiliser.
Je n’ai pas trouvé plus.

Peux-tu penser à indiquer « solutionné »