Nem ismerem annyira az openldap-ot és értem, hogy automatikusan akarod a member es memberof attributomokat updatelni. De ennek semmi koze ahhoz, hogy mit ad vissza a kereses es azt hogy hasznalja a termek.
A search DN az a "root" objektum amitol keresel. Nalad kb akkor az ou=people kellene leygen, hogy ne a teljes fat kelljen bejarnia. De ha szepen van index-elve az attributum es bele is fer az index meretebe, akkor ezzel ugy sincs gond. Bar en akkor se jarnam be csak azert a fat, hogy egy embernek megnezzem a memberOf attributumat, ha az az ou=people alatt van.
A mapped attribute pedig az amit szeretnel hasznalni, hogy megfeleltetsd a bejelentkezett felahasznalo uid-janak. A fenti filter visszaad kb. akarhany objektumot teljes egeszeben. Csak futtas egy ldapsearch-ot es latni fogod, hogy visszadja az osszes objektumot, ami rendelkezik az inetorgperson objectclassal ES(&) van neki memberof attributoma ami egyenlo a fenti DN-el. Hogy minek oda az onmagaval valo VAGY(|), azt nem is ertem. :D
Szoval ez visszadja az objektumok osszes attributumat. Mondjuk 87 objektumot. Hogy dontod el, hogy a bejelnetkezett ember koztuk van e? Azt mondod, hogy a login_attribute==cn? És ha a cn benne van a listaban akkor o tuti benne van a cn=cloud groupban is.
De nem ismerem a termeket. Nem tudom mit csinal. Van olyan termek ami le-sync-eli a group-okat és usereket a searchbase es filter alapjan es magaban donti el, hogy a bejelentkezett user benne van e egy groupban. Van amelyik az AUTHENTICATED_USER nevet hasonlitja a cn-hez egy group listaban. stb, stb,
Pl. a login search filter filter lehet (cn=%s), ahol a termek behelyettesiti a %s helyere a beirt felhasznalonevet. stb. stb.
Szoval en lehet azt a filtert allitanam be itt, hogy (&(cn=%s)(objectclass=inetOrgPerson)(memberof=cn=cloud,ou=groups,dc=example,dc=org))
Mondjuk ahogy irtam jo lenne tudni a termek nevet es elolvasni a doksijat :D