OpenLDAP memberOf overlay csak félig működik

Fórumok

sziasztok,

egy Ubuntu 18.04-re telepítettem slapd-t (@(#) $OpenLDAP: slapd  (Ubuntu) (Aug  8 2019 18:08:36) $). disclaimer: kezdő vagyok LDAP-ban. a cél első közelítésben mindössze annyi, hogy usereket szeretnék csoprtokba sorolni, és aszerint adni hozzáféréseket hálózati szolgáltatásokhoz, hogy az adott user tagja-e a vonatkozó csoportnak.

kezelőfelületnek az LdapCherry-t választottam (https://github.com/kakwa/ldapcherry), ez nagyjából pont erre van kitalálva. ez a csoportokat a "member" attribútumon keresztül kezeli, így a csoportok a groupOfNames objectClass-szal lettek definiálva:

dn: cn=cloud,ou=groups,dc=example,dc=org
objectClass: groupOfNames
cn: cloud
member: uid=test.user,ou=people,dc=example,dc=org
member: uid=aaa,ou=people,dc=example,dc=org
structuralObjectClass: groupOfNames
entryUUID: ...
creatorsName: cn=admin,dc=example,dc=org
createTimestamp: 20191203004205Z
entryCSN: 20191204001721.894079Z#000000#000#000000
modifiersName: cn=admin,dc=example,dc=org
modifyTimestamp: 20191204001721Z

rögtön az első szolgáltatás (cloud) a memberOf user attribútumon keresztül szűri a elhasználókat, így jutottam el a memberOf overlay telepítéséig. ez elvileg sikerült is, így néznek ki a vonatkozó config bejegyzések:

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}memberof.la
structuralObjectClass: olcModuleList
entryUUID: ...
creatorsName: cn=config
createTimestamp: 20191201152221Z
entryCSN: 20191203214644.047665Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20191203214644Z
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
structuralObjectClass: olcMemberOf
entryUUID: ...
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20191203225212Z
entryCSN: 20191203225212.258200Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20191203225212Z

ha LdapCherry-ben beteszek egy usert egy csoportba, szépen megkapja a user a megfelelő memberOf attribútumot:

dn: uid=aaa,ou=people,dc=example,dc=org
cn: aaa
title: aaa
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: inetOrgPerson
loginShell: /bin/false
userPassword:: YWFhYUFBMTE=
uidNumber: 9999
gidNumber: 10000
sn: aaa
homeDirectory: /dev/null
mail: aaa@aaa.com
uid: aaa
structuralObjectClass: inetOrgPerson
entryUUID: ...
creatorsName: cn=admin,dc=example,dc=org
createTimestamp: 20191204001721Z
entryCSN: 20191204001721.873952Z#000000#000#000000
modifyTimestamp: 20191204001721Z
memberOf: cn=cloud,ou=groups,dc=example,dc=org
modifiersName: cn=admin,dc=example,dc=org

a probléma, hogy ha viszont kiveszem a csoportból, onnan eltűnik a vonatkozó member attribútum, de a usernél továbbra is megmarad a memberOf, vagyis hiába veszem ki a csoportból, ugyanúgy hozzáfér a szolgáltatáshoz. nagyon úgy tűnik, hogy a memberOf overlay csak az egyik irányban működik.

- mi lehet ennek az oka?
- lehet-e az az ok, hogy az overlay betöltésnél úgylátszik bénáztam, és 3 bejegyzés is van:

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}memberof.la
structuralObjectClass: olcModuleList
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}memberof
structuralObjectClass: olcModuleList
dn: cn=module{2},cn=config
objectClass: olcModuleList
cn: module{2}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}memberof
structuralObjectClass: olcModuleList

- megoldhatja-e a problémát, ha törlöm az {1} és {2} bejegyzéseket?
- betöltésnél mi a helyes modul elnevezés, "memberof" vagy "memberof.la"? a leírás amit találtam, használta a .la-t, de az eleve betöltött modulnál (back_mdb) nincs, a leírásban ott is van.
- okozhatja-e ez (az .la ottléte vagy hiánya) a problémát?

elnézést a hosszú nyitásért, de úgy vettem észre, ezen a területen különösen sokminden múlik a részleteken, ezért szerettem volna minél precízebben felvázolni a problémát. előre is köszönök minden segítséget!

Hozzászólások

- töröltem az {1} és {2} bejegyzéseket, semmi nem változott.
- észrevettem, hogy ha törlök egy usert, nem tűnnek el a member sorai a csoportjaiból. ez mondjuk a működés szempontjából közömbös, de azért fura. nem tudom, mennyire elvárt viselkedés, konfigurációs hiba vagy bug.

Jo lenne látni a cloud szolgáltatás search paramétereit. 

Mi a search DN?

Mi a filter?

Mi a mapped attribute?

A tobbit nem is ertem, mert egyszeruen sima ldap objektumokkal kell mennie. Nem kell ehhez mindenféle csillivilli bolondság. :D

nem pontosan értem, a kérdéseid hogyan függnek össze a problémával, de ez valószínűleg a képzetlenségemből fakad.

- a search DN alatt sajnos nem tudom, mit kell érteni.
- a filter ez: (&(|(objectclass=inetOrgPerson))(|(memberof=cn=cloud,ou=groups,dc=example,dc=org)))
- a mapped attribute-ot sajnos szintén nem tudom értelmezni.

minden általam olvasott leírás egybehangzóan azt írja, hogy a member - memberOf attribútumok szinkronban tartását a memberof overlay végzi (erre való, semmi másra), ennek hiányában a memberOf attribútumok létre sem jönnek.

The memberof overlay updates an attribute (by default memberOf) whenever changes occur to the membership attribute (by default member) of entries of the objectclass (by default groupOfNames) configured to trigger updates.

https://tylersguides.com/guides/openldap-memberof-overlay/
https://www.openldap.org/doc/admin24/overlays.html
https://www.adimian.com/blog/2014/10/how-to-enable-memberof-using-openl…

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

nagyon köszönöm a segítő szándékot, de az az érzésem, hogy rossz irányba indultál el, nem ez a probléma. de először a válaszok:

- a termék egy Nextcloud, de érzésem szerint ez irreleváns.
- auth esetén van egy (uid=%uid), de a probléma nem a loginnel van.
- az önmagával való VAGY gondolom a Nextcloud script trehánysága, ami a filtert dinamikusan összerakja a paraméterekből, és esetemben csak egy van. de ez csak tipp, nem jártam utána.

a termék a korábban megadott filterrel szűri, mely userek jogosultak bejelentkezni a termékbe:
(&(|(objectclass=inetOrgPerson))(|(memberof=cn=cloud,ou=groups,dc=example,dc=org)))

a probléma, hogy memberof alapján szűr, ami viszont nem konzisztens, mert ha kiveszem a user member sorát a group-ból, megmarad a memberOf sor a userben. ez OpenLDAP probléma, nem Nextcloud.

szerintem abban az egy esetben lehetne releváns a Nextcloud, ha rá lehetne venni, hogy a megadott group member sorai alapján szűrje a usereket. de jelenlegi ismereteim szerint ldap query-vel nem tudok attribútumokat lekérdezni.

Ennek pedig mukodnie kellene (nalam megy is...). Mutasd mar meg, hogy nez ki egy ldapmodify eredmenye a csoporthoz hozzaadas ill. elvetel utan (mind a csoport, mind a user objektum erdekel). Meg lehet emelni a slapd loglevelt, hogy lasd, pontosan mit is csinal a hatterben, de nem lesz konnyu olvasmany az eredmenye...

alaphelyzet:

dn: cn=cloud,ou=groups,dc=example,dc=org
objectClass: groupOfNames
cn: cloud
member: uid=admin,ou=people,dc=example,dc=org
structuralObjectClass: groupOfNames
entryUUID: 741cc3ae-ab09-1039-9b1f-b9c51378c4f9
creatorsName: cn=admin,dc=example,dc=org
createTimestamp: 20191204174423Z
entryCSN: 20191204184110.396372Z#000000#000#000000
modifyTimestamp: 20191204184110Z
modifiersName: cn=admin,dc=example,dc=org
dn: uid=aaa,ou=people,dc=example,dc=org
cn: aaa
title: aaa
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: inetOrgPerson
loginShell: /bin/false
userPassword:: YWFhQUFBMTE=
uidNumber: 9999
gidNumber: 10000
sn: aaa
homeDirectory: /dev/null
mail: aaa@aaa.com
uid: aaa
structuralObjectClass: inetOrgPerson
entryUUID: 83eeedb2-abd0-1039-9b6e-316626915f02
creatorsName: cn=admin,dc=example,dc=org
createTimestamp: 20191205172920Z
entryCSN: 20191205172920.252801Z#000000#000#000000
modifiersName: cn=admin,dc=example,dc=org
modifyTimestamp: 20191205172920Z

hozzáadva:

dn: cn=cloud,ou=groups,dc=example,dc=org
objectClass: groupOfNames
cn: cloud
member: uid=admin,ou=people,dc=example,dc=org
member: uid=aaa,ou=people,dc=example,dc=org
structuralObjectClass: groupOfNames
entryUUID: 741cc3ae-ab09-1039-9b1f-b9c51378c4f9
creatorsName: cn=admin,dc=example,dc=org
createTimestamp: 20191204174423Z
entryCSN: 20191205173104.233083Z#000000#000#000000
modifiersName: cn=admin,dc=example,dc=org
modifyTimestamp: 20191205173104Z
dn: uid=aaa,ou=people,dc=example,dc=org
cn: aaa
title: aaa
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: inetOrgPerson
loginShell: /bin/false
userPassword:: YWFhQUFBMTE=
uidNumber: 9999
gidNumber: 10000
sn: aaa
homeDirectory: /dev/null
mail: aaa@aaa.com
structuralObjectClass: inetOrgPerson
entryUUID: 83eeedb2-abd0-1039-9b6e-316626915f02
creatorsName: cn=admin,dc=example,dc=org
createTimestamp: 20191205172920Z
uid: aaa
entryCSN: 20191205173104.223038Z#000000#000#000000
modifyTimestamp: 20191205173104Z
memberOf: cn=cloud,ou=groups,dc=example,dc=org
modifiersName: cn=admin,dc=example,dc=org

elvéve:

dn: cn=cloud,ou=groups,dc=example,dc=org
objectClass: groupOfNames
cn: cloud
member: uid=admin,ou=people,dc=example,dc=org
structuralObjectClass: groupOfNames
entryUUID: 741cc3ae-ab09-1039-9b1f-b9c51378c4f9
creatorsName: cn=admin,dc=example,dc=org
createTimestamp: 20191204174423Z
entryCSN: 20191205173104.233083Z#000000#000#000000
modifyTimestamp: 20191205173104Z
modifiersName: cn=admin,dc=example,dc=org
dn: uid=aaa,ou=people,dc=example,dc=org
cn: aaa
title: aaa
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: inetOrgPerson
loginShell: /bin/false
userPassword:: YWFhQUFBMTE=
uidNumber: 9999
gidNumber: 10000
sn: aaa
homeDirectory: /dev/null
mail: aaa@aaa.com
structuralObjectClass: inetOrgPerson
entryUUID: 83eeedb2-abd0-1039-9b6e-316626915f02
creatorsName: cn=admin,dc=example,dc=org
createTimestamp: 20191205172920Z
memberOf: cn=cloud,ou=groups,dc=example,dc=org
uid: aaa
entryCSN: 20191205173459.443899Z#000000#000#000000
modifiersName: cn=admin,dc=example,dc=org
modifyTimestamp: 20191205173459Z

Gondolkodtal esetleg egy igazi cimtaron is? Mondjuk nem az openldap, hanem 389ds vagy barmi ami a netscape directory server-re alapul? Ott van MemberOf plugin ami bizony mukodik mar vagy husz eve :D

En ahol lehet sosem hasznalok openldap-ot production rendszeren, mert kb. messze van mindentol amit production ready-nek mondanek. Vicces volt, amikor vagy 10 ev utan behoztak vegre a cn=config-ot...es azt is hogy. De ez messzire vezetne. Szoval probalj ki egy 389ds-t is szerintem. 

Amugy meg ezek a nagyszeru vizualis tool-ok altalaban semmiben nem segitenek csak eltakarjak a problemat. Inkabb irj egy usermanager.sh-t amiben lesz add, del, add_to_group, del_from_group es szepen lefutnak az ldapmodify-k. Akkor nem kell egy bugos felig kesz software alig mukodo reszere tamaszkodnod.

bevallom, minél jobban elmélyedek az OpenLDAP-ban, annál jobban rühellem. egészen elképesztően körülményes a felépítése, a használata, nincs hozzá normális gui, amikor pedig azt olvastam a hivatalos doksiban, hogy jelen állás szerint nem lehet config schema-t törölni, mert túl bonyolult lenne az implementációja, de ha gondolom, törölgessek file-okat a config folderből, és ha szerencsém van, nem omlik össze az egész, ha meg nincs, akkor "kaput", és nincs más hátra, mint "sepuku", gondoltam ezt azt... cserébe nem világos, milyen extra előnyökkel jár a használata.

eredetileg azért választottam, mert open source, és szinte minden támogatja, ami címtárt használ. de most már nagyon érdekelne, milyen más alternatívák léteznek, amik open source és lehet hozzájuk illeszteni széles körben mindenfélét (felhő, email, chat, stb.). utánanézek a 389ds-nek, illetve érdekelnének a tapasztalatok, ki mit javasol a nyitó posztban leírt feladatra. samba 4 AD-vel mennyire járnék jól?

Hat en eleg sokat dolgoztam cimtarakkal. Ugy ertem ne mopenldap-pal :D

En nagyon megszerettem/szeretem. De soha nem hasznaltam GUI-t.

Ahol lehet tertozkodom a relacios adatbazistol. Nehez benne a many-many kapcsolatot megcsinalni meg az oroklodest, stb.. Inkabb noSQL es graphdb. Nekem az egesz relacios adatbazis buzlik kicsit. Egyszeruen eletidegen a szervezodese. :D (Nekem) 

(bar annyira nem is ertek hozza, mint mondjuk a cimtarakhoz es a nosql adatbazisokhoz, bar azokbol is inkabb a columnar és document store-okkal dolgoztam es belenyaltam a graph tipusuakba kicsit)

Sajnos az OpenLDAP inkabb csak jatszos kis butus semmiseg, mint valoban hasznalhato alternativa. En arra szoktam hasznalni, hogy ldapsearch es ldapmodify parancsokat oktassak vele (bevezetes a cimtar technologiaba). De kb. ennyi.  

próbálgattam debug módban. ahogy írtad, d=1 és d=3 módban értelmezhetetlenül sok a kimenet, de d=2 módban már majdnem olvasható... nem találtam semmi hasznosat, egyedül ezt:

5de96eb9 conn=1000 op=1: memberof_value_modify DN="cn=cloud,ou=groups,dc=example,dc=org" add member="uid=aaa,ou=people,dc=example,dc=org" failed err=20

a furcsa, hogy ez van akkor is, amikor hozzáadom a usert a grouphoz - ebben az esetben még lehetne az a magyarázat, hogy létezik már a memberOf (nem törlődött ugyebár) - de ez van akkor is, amikor kiveszem...

Nekem tovabbra is csont nelkul mukodik ez az OpenLDAP-pal. Ennyi a schema konfigom:

include: file:///etc/ldap/schema/core.ldif
include: file:///etc/ldap/schema/cosine.ldif
include: file:///etc/ldap/schema/inetorgperson.ldif
include: file:///etc/ldap/schema/rfc2307bis1.ldif

egyetlen hdb backend, azon ennyi az overlay konfig:

dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: memberof
olcMemberOfRefInt: TRUE

es pocc-roff

nálam nis van rfc2307bis1 helyett, ez jött a telepítéssel. ez lehet oka a problémának?

dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcBackend={0}mdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}mdb,cn=config
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config

Az rfc2307bis1.ldif resze az openldap forrasnak, onnan megszerezheto, masold be a /etc/ldap/schema konyvtarba a tobbiek melle. Uti a NIS-t, szoval csak az egyikuk lehet behuzva. Utolag azert maceras kicserelni, mert a benne definialt objectclass-ek mar hasznalatban vannak, es tudja a rak, hogy mukodik az adatbazis backend lelkivilaga, igy en a nullarol kezdenem, amig nem kell migracioval bajlodni. Leallitanam a slapd-t, az aktualis konfigot (slapcat -b cn=config parancs kimenete) elmentenem egy fileba. Az adatokat (slapcat kimenete) egy masikba. Ezek LDIF formatumuak, meg kell oket szabaditani az operativ attributumoktol (pl. structuralobjectclass, modifier, entry*, ...). A cn=config alatti schemak definicioi helyere include file:///etc/ldap/schema/<schemanev.ldif> sorok keruljenek, kicsit rovidebb lesz igy, cserebe ha hiba van valahol, akkor a slapadd altal hivatkozott sorszamnal figyelembe kell venni az include-olt fileok sorait is.

Backupolni a meglevo dolgokat: /etc/ldap/slapd.d ill. /var/lib/ldap tartalma, utana eltuntetni a jelenlegi tartalmukat. LDAP szerver konfiguralasa:

slapadd -b "cn=config" -F /etc/ldap/slapd.d -l <configfile/ldif>

ha ez sikeres, akkor slapcat -b "cn=config" kimenetet nezegesd, latsz-e valami turpissagot. Amig nem okes a dolog, akkor javits a konfigfileban, torold az /etc/ldap/slapd.d/ tartalmat, es ujra slapadd. Ha mar jonak latszik a konfig, akkor korrigald az /etc/ldap/slapd.d es a /var/lib/ldap alatti jogosultsagokat (rootkent dolgozol, mig a slapd openldap-kent fut majd). slapd elindit, es innentol ldapadd -dal visszatoltheted a korabban elmentett adatokat (user, group OU-k, stb.).

Szerkesztve: 2019. 12. 08., v - 10:04

találtam egy ilyet: https://hup.hu/node/138162

itt arra jut a topiknyitó, hogy inetOrgPerson-ban nem lehet memberof attribútum. ez mennyire valid? nálam bekerül, ez némileg ellentmond az állításnak...

Sima natúr LDAP az erősen sajtreszelős szerintem, de te tudod... (burkolt felíratkozás)

Ha PAM-ba drótozható szolgáltatásaid vannak, akkor FreeIPA és sssd a barátod szerintem - én legalábbis azzal ugranék neki. Azzal nem csak az usereket tudod csoportokba rendezni, hanem a szolgáltatásokat, illetve a hsotokat is, ami azért kellően megkönnyíti a user - host - szolgáltatás összerendelések kialakítását - ha jól csinálod meg az elején a csoportokat :-) (Ha nem, akkor közben is simán lehet csoportok között tologatni az entitásokat anélkül, hogy az LDAP-fával kéne foglalkoznod akárhol is).

Bónuszként ssh publikus kulcsok, sudo szabályok, ssl-es szolgáltatások tanusítványai is kezelhetőek vele.

Mi lett a megoldás?
Kipróbáltál másik, ajánlott ldap-t?

létrehoztam teszt usereket, csoportokat, elkezdtem vele játszani. egyelőre nem tudom, hogyan tudom listázni az objektumokat (ami slapd esetén a slapcat). a web ui elég kényelmes és átlátható, tetszik elsőre.

a nextcloud ugyanazt mondja, nem talál memberOf attribútumot, letiltja a szűrést a csoportokra. memberOf plugin telepítésére/bekapcsolására nem nagyon találtam még leírást, csak arra utalást, hogy alapból telepítve van.

kb ugyanott tartok, mint eddig.

Ha neked mindenképp memberOF kell a NextCloud miatt, akkor muß lesz naturella vanilla LDAP-ot adni neki - merthogy az IPA az csak a legmélyén az, "kifelé" meg nem - ergo az LDAP-fát nagyon-nagyon nem illik közvetlenül piszkálni (egy-két speciális kivételtől eltekintve). A miértre a választ szerintem te is meglátod, ha "sima" LDAP-ként elkezded nézegetni.

A problémád meg, jelenleg, ha jól értem, "NextCloud integration with FreeIPA Server": https://www.freeipa.org/page/Owncloud_Authentication_against_FreeIPA (Az Owncloud ne zavarjon, ugyanaz pepitában)

A továbbiakban meg a Google egész jó barát lehet egyébként - ezt én is így találtam meg :-)

gugliztam rengeteget, hidd el, ezt is olvastam. nem világos, hogy benézte a szerző, vagy 7-es owncloud idején még így volt, de ez:

  • Group filter (it depends on which user group you want allow to access owncloud)

a 17-es nextcloudban már nem igaz, azt lehet ott megadni, mely csoportok jöjjenek át nextcloud csoportnak, nem azt, hogy mely csoport userei usernek.

Most nem nagyion ertem, de te ragaszkodsz ahhoz, hogy az infrastrukturat reszeld ala az woncloud-nak es nem fordita? Mert a group filter akar az is lehetne hogy (&(objecclass=kukutyim)(|(szemeszine=green)(hajaszine=szoke))(valamiattributum=ezatuti)). 

Nem lehet atirni a lekerdezest???? Akkor ezt a termeket messzire kerulnom kell.

 

En csinalnek egy schema-t ami nekem kell, abban lenne olyan, hogy szerviz es boolean, aztan mindenkihez hozzaadnam, aztan "owncloud: true", ahol kell, es akkor a filter csak siman az lenne, hogy "az ou=people alatt keress olyat, ahol az owncloud=true".

semmihez nem ragaszkodom, azt szeretném, ha működne, és minél több szolgáltatáshoz tudnám használni. át lehet írni Nextcloudban a lekérdezést, de mivel jelenleg nincs semmilyen attribútum a userben, ami a csoporttagságára utalna, ezzel nem vagyok beljebb.

ahogyan a korábbi posztokban részletesen kifejtettem, nem akarok folyamatosan kézzel turkálni az LDAP-ban, pont a kényelem a fő cél, és hogy ne csak IT-s tudjon menedzselni. tehát mindenképpen olyan megoldást keresek, amit konfigurálás után egy kényelmes gui-val lehet használni.

ebből eddig kettőt próbáltam, az LdapCherry-t, ez member attribútumokat pakol a group-okba, slussz. ezen segítene a memberOf overlay, ami ha jól működne, megoldaná a memberOf alapú lekérdezés problémát, amit a Nextcloud "gyárilag" használ erre. de nem működik jól nekem.

a másik a FreeIPA web ui, erről meg azt sem tudom még, milyen attribútumokat használ a csoportkezeléshez (uniqueMember?..), csak azt, hogy alapbeállításokkal ez sem használ memberOf-ot a userekhez. ami ugye szintén megoldaná a problémámat.

a speckó schema valóban lehetne jó megoldás, amennyiben minden szolgáltatásban tudok kézzel írni LDAP query-t (nem tudom, ez mennyire általános...), illetve van olyan gui, amivel ezeket a custom attribútumokat kényelmesen tudom állítani. illetve abban nem vagyok biztos, hogy a jelenlegi tudásom elég a saját user schema létrehozásához.

Tehát mindenképp LDAP kell neked a *cloud-hoz... Hasonló volt az IPA-Dokuwiki összereszelése anno, mert ez utóbbi szimpla LDAP-ot képes csak kezelni. Ennek a leírása: https://www.dokuwiki.org/plugin:authldap:ipa  ennek a példakonfignak az alapján talán menni fog.

A FreeIPA nem egy webes frontend egy mezitlábas ldap-hoz, hanem egy ldap backend-re épülő Identiy+Policy+Audit rendszer, megspékelve kerberos és saját CA-s dolgokkal. 
Mindezt úgy, hogy azért az LDAP-ba direktbe bekérdezve is tudsz felhasználót azonosítani, illetve jogosultságot ellenőrizni, bár, mint írtam, ez csak egy opcionális lehetőség.

Jo lenne tudni, most eppen hol tartasz, mert fogalmam sincs, miert nem megy nalad az a konfiguracio, amit korabban javasoltam. Amikor definialsz egy uj containert, akkor megadsz egy objectclass listat is, pl. egy unix user hozzaadasakor valahogy igy:

objectclass: top
objectclass: posixAccount
objectclass: shadowAccount
objectclass: inetOrgPerson

a posixAccount-nal vannak kvazi az /etc/passwd mezoi attributumkent definialva, a shadowAccount felel meg az /etc/shadow-nak. Viszont ezek nem STRUCTURAL-ok, ezert kell egy ilyen is, ebben az esetben az inetOrgPerson - nem tudom, valasz-e a kerdesedre, oszinten szolva nem is tudtam ertelmezni a kerdest.

pont ugyanott tartok, ahol eddig. annyi változott, hogy a nis schemát lecseréltem rfc2307bis-re, de ettől semmi nem változott a memberOf működését illetően.

azt szertném még kipróbálni, hogy mi van akkor ha a usernek ezek az objectClass-ai vannak:

objectclass: top
objectclass: posixAccount
objectclass: inetOrgPerson
objectClass: inetUser

de ha csak simán beírom a usert leíró ldif-be, syntax error-t kapok, és igazából az lenne a jó, ha minden új userhez automatikusan hozzáadódna ez az objectClass, mert gui-ból szeretném hosszútávon létrehozni őket, gombnyomással.