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 Welcome to Apache Directory Studio — Apache Directory
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:

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

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.


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é »

Bonjour,

Si vous avez besoin d’utiliser le REMOTE_USER, il y a une méthode qui nécessite un peu de code.
Tout d’abord, il faut savoir qu’en fonction de votre logiciel SSO (Authelia, Synology, etc) le header à utiliser peut être différent.
L’avantage d’un SSO plutôt que LDAP, c’est qu’une fois le navigateur lancé et authentifiée pour 1 applications, pas besoin de se loguer dans la 2eme. Un cookie de session est conservé afin de fournir un token d’autorisation pour toutes les applications se connectant au SSO. Et le tout est configurable (délai de session, ban après X échec, et certains SSO propose d’être un Master OIDC.

Voici comment cela se passe :
Afin de se connecter avec un SSO, il faut que la requête vers le site soit interceptée puis redirigée vers la page d’authentification du SSO

1°) Avec l’adresse IP tel que https://ton-jeedom.atoi/ (pour te connecté à ton instance), la requête va être intercepter par un proxy (dans mon cas c’est Traefik) afin de me rediriger vers le login de mon SSO (Authelia dont le sous domaine commence par auth.jeedom_nia_nia.nia)

2°) Après avoir entrer le mot de passe, le SSO va créer des en-tête HTTP (dans le cas de authelia Remote-User, Remote-Email, Remote-Name, etc…) et les transmettre à la vraie page de Jeedom, le tout en passant par le proxy

3°) Jeedom va recevoir les en-têtes HTTP. Si lors de la tentative de connexion, la case REMOTE_USER est cochée, que l’en-tête est trouvé et contient un utilisateur existant, alors Jeedom créer une session active, et l’utilisateur est connecté.

Voici pour le principe
Maintenant les soucis :

1°) LDAP et un SSO non rien en commun excepté une connexion du SSO à LDAP pour savoir si un utilisateur à les droit. Une section dédiée dans la page de configuration devrait être créée. et non pas se trouver dans la section LDAP.

2°) Il faut connaitre le header envoyé par son propre SSO. Dans le cas d’Authelia + Traefik, je reçois un en-tête HTTP_REMOTE_USER ($_SERVER['HTTP_REMOTE_USER]) et non pas un REMOTE_USER. Mais il faut un endroit où le configurer.

Cela implique la modification de 2 fichiers, et l’ajout d’une entrée en BDD
SSO Jeedom 1

Cette nouvelle entrée de BD est configurée via la page de configuration « Configurer Entête HTTP ».


Comportement :
Si l’utilisateur se connecte avec le SSO, et qu’il n’existe pas dans Jeedom. La page de connexion standard se lance
Si l’utilisateur est créé dans Jeedom, et qu’il a les droit nécessaires (non banni, etc…) l’application ne passe pas par la page de login de Jeedom et l’utilisateur est directement connecté après la page du SSO


Pour ces raisons, je prépare une modification que je vais soumettre à l’équipe de Jeedom qui prévois ces modifications. Si vous souhaité tester, (et si Jeedom le permet), je peux vous envoyer en test les 2 fichiers modifiés.


Prochaine étape, si j’ai le temps. Se servir des autres header pour afficher le Nom, utiliser l’adresse mail, et récupérer les groupes de l’utilisateur.

J’espère que cela sera utile.

Amicalement.

Sylvain

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.