@FredB : normalement dans le filter. avec un truc du genre &(objectClass=user) ?

Il y a un exemple de code la : https://openclassrooms.com/forum/sujet/ ... ge-4648854

pour ce qui est de l'admin système, c'est vraiment dommage parce que c'est rien à faire (toujours limité par l'infra c'est dingue ^^)
tu sais qu'avec l'utilisateur qui va bien tu peux surement faire toi même la gestion des groupes

@+

Petite remarque suite à un soucis que l'on vient de résoudre pour un client multi-AD : le username est bien unique dans l'AD, mais du fait qu'il disposait de plusieurs entités avec chacune leur propre AD, on a eu des cas où un même username pouvait apparaître dans différents AD. On a donc complété celui-ci avec un contrôle sur le nom du domaine pour être sur d'avoir une chaine d'authentification unique.

Pas dit que tu rencontres ce genre de problème, mais comme on vient tout juste de traiter le cas, j'en profite pour le signaler

Merci moogli (encore toi )

Le UserName est effectivement unique donc cette solution me semble très bien. Pour les groupes AD c'était ma proposition initiale mais j'ai eu un refus de l'admin, qui ne souhaitent pas se rajouter des groupes dédiés à ce portail (ça aurait été tellement plus simple mais bon...)

Pour le ldap_search, j'ai vu un truc du genre :

$adServer = "bla.fr"; // connexion au serveur AD
$dc = "DC=bla, DC=fr";
$ldap = ldap_connect($adServer);
$username = $_POST['username'];
$password = $_POST['password'];
$ldaprdn = 'bla' . "\\" . $username;
ldap_set_option($ldap, LDAP_OPT_PROTOCOL_VERSION, 3); //
ldap_set_option($ldap, LDAP_OPT_REFERRALS, 0);
$bind = @ldap_bind($ldap, $ldaprdn, $password);
if ($bind) {
$filter="(sAMAccountName=$username)";
$result = ldap_search($ldap,$dc,$filter);
Mais je ne vois pas ou déclarer la variable correspondant au type User (histoire d'exclure tous les autres objets par ex)

salut,

Il te faut une info qui soit unique au sein du ldap et de la bae, du coup le samaccount / username n'important tant que tu es certain de l'unicité dans l'AD?

Ensuite pour la recherche de l'utilisateur tu passes les infos à ldap_search

Coté base tu peux avoir une table portail et une accesportail avec deux colonnes id_portail et clef utilisateur (enfin la chose unique qui viens de l'AD).
A la connexion de l'utilisateur tu récupères la liste des accès et l'utilise pour savoir si tu peux ou pas utiliser le portail. (si pas dans la liste accès refusé).

Pour ce qui est des droits d'accès, perso je me baserais plutôt sur des groupes AD, autant que ça serve a quelque chose et cela permet d'avoir un endroit unique de gestion des utilisateurs pour tout le SI ce qui n'est pas négligeable à l'utilisation

@+

En parallèle de mon autre topic, j'aurai besoin de lumières concernant Ldap_Connect et ses potes.

Idée de base : avoir un premier portail avec une authent' AD. Selon si l'utilisateur est dans telle ou telle liste (liste quoi doivent être définies en local ou dans la base MySQL mais pas dans une OU de l' AD), il aura du coup accès à différents modules.

En gros imaginons une liste admin en local qui aurait accès a tous les portails.
Une liste avec des gestionnaires qui auraient accès à certains portails
et par défaut, tous les autres comptes AD n'auraient aucun accès.

La ou je coince.. ce n'est pas sur le ldap_connect en tant que tel, mais plus sur la liaison ensuite avec des listes qui pourraient être situées dans la base MYSQL. Quel pourrait être le meilleur choix ? une comparaison du username ?

(autre question, comment au niveau du ldap l'inviter a chercher directement dans la bonne OU et surtout avec le bon type (a savoir users, et non computers ou autre)

Hope I'm clear