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.

Mire jutottal?

En Apache Directory Studio-t hasznalok kliens gyanant, na meg persze ldap-utils-t. nis-t lecsereltem rfc2307bis-re, betoltottem a memberof overlay-t es a kovetkezoket tapasztalom:

Letrehozom a kocsmat:

dn: cn=kocsma,ou=Groups,dc=example,dc=hu
cn: kocsma
objectClass: groupOfNames
objectClass: top

Majd Joskat:

dn: uid=joska,ou=People,dc=example,dc=hu
uid: joska
sn: joska
cn: joska
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

Es Joskat berakom a kocsmaba:

dn: cn=kocsma,ou=Groups,dc=example,dc=hu
member: uid=joska,ou=People,dc=example,dc=hu
cn: kocsma
objectClass: groupOfNames
objectClass: top

Ezen a ponton Apache DS-ben megjelenik a memberof attribute Joskanal, es az ldapsearch is megtalalja:

ldapsearch -x -b "dc=example,dc=hu" -H ldapi:/// "(&(objectClass=InetOrgPerson)(memberof=cn=kocsma,ou=Groups,dc=example,dc=hu))"

# joska, People, example.hu
dn: uid=joska,ou=People,dc=example,dc=hu
uid: joska
sn: joska
cn: joska
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

 

Eddig minden OK.

Most hozzuk letre Pistat:

# pista, People, example.hu
dn: uid=pista,ou=People,dc=example,dc=hu
uid: pista
uidNumber: 500
homeDirectory: /home/pista
gidNumber: 500
sn: pista
cn: pista
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: posixAccount

Na most Pista nemileg szofisztikaltabb, ugyanis -Joskaval ellentetben- nem csak inetOrgPerson hanem posixAccount is.

Betesszuk Pistat is a kocsmaba:

# kocsma, Groups, example.hu
dn: cn=kocsma,ou=Groups,dc=example,dc=hu
member: uid=joska,ou=People,dc=example,dc=hu
member: uid=pista,ou=People,dc=example,dc=hu
objectClass: groupOfNames
objectClass: top
cn: kocsma

Es bar az ldapsearch megtalalja:

ldapsearch -x -b "dc=example,dc=hu" -H ldapi:/// "(&(objectClass=InetOrgPerson)(memberof=cn=kocsma,ou=Groups,dc=example,dc=hu))"

# joska, People, example.hu
dn: uid=joska,ou=People,dc=example,dc=hu
uid: joska
sn: joska
cn: joska
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

# pista, People, example.hu
dn: uid=pista,ou=People,dc=example,dc=hu
uid: pista
uidNumber: 500
homeDirectory: /home/pista
gidNumber: 500
sn: pista
cn: pista
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: posixAccount

az Apache DS csak a 10. frissites es 2. ujrainditas utan volt hajlando megjeleniteni a memberof attribute-ot.

Ugyanez ment visszafele is. Ha kidobom Pistat a kocsmabol, apache DS meg jo ideig azt hazudja, hogy ott van (listazza a memberof-ot a kocsma csoporttal). Erdekes modon Joskat mindig jol mutatta.

Konkluzio 1: Mindig ellenorizd ldapsearch-csel is hogy mi a helyzet.
Konkluzio 2: Halal az LDAP-ra! Hasznalj SSO-t, mondjuk keycloak-ot. 1 ora alatt osszehoztam nextcloud-dal.

Konkluzio 2-ig jutottam én is, használja, akinek két anyja van. szuper, hogy ennyire univerzális, de többek között emiatt is használhatatlan. ezzel biztos sokan vitatkoznak, én műkedvelőként arra jutottam, hogy inkább egy mailserver, mint ez :)

a harmadik OS-re felhúzott ötödik DS klón telepítése után, miután mindegyikben ugyanazt az inkonzisztens viselkedést tapasztaltam, félretettem az egészet, kényelmi fejlesztés lett volna, nem létkérdés, annyit nem ért, hogy megegye az életemet. közben bizakodtam, hogy nem teljesen egyedi az igény, hogy usereknek központilag biztosítsak egyedi hozzáféréseket hálózati szolgáltatásokhoz, és majdcsak szembejön erre valami modern, használható, legalább de facto szabványként használható megoldás, amit illeszteni tudok minél több szolgáltatáshoz. máris utánanézek az SSO-nak és a Keycloak-nak, köszönöm a tippet.

A kc nem biztos, hogy tud majd neked csoport a csoportban jellegű dolgot (pistike elsődleges csoportja a g1, ezen kívül benne van a g2 meg g3 csoportban. A g3 hiába van benne a g4-ben - pistike nem kapja meg a g4 jogait) , erre figyelni kell.

Én megnézném a FreeIPA-t, bár a kettő nem azonos célra készült.

nem kell nekem szerintem csoport a csoportban, a cél első körben nagyon egyszerű: aki tagja A csoportnak, hozzáfér A szolgáltatáshoz, aki B-nek, B-hez, stb.

FreeIPA-t néztem, tetszett is, de az eredeti LDAP kérdés szempontjából (csoportból kiveszem a member sort, userben bentmarad a memberOf sor) ugyanazt produkálta.

IPA esetén _nem_ turkálod az LDAP-ot, hanem berakod a csoportba, kiveszed a csoportból. És neekm ilyet nem produkált, hogy jozsika ki lett véve az ssh_to_b07 csoportból (amely csoport hbac rule-lal be volt ebgedve ssh-n a b07 gépre), és annak ellenére be tudott jelentkezni a b07-re ssh-n. Mindaz, ami PAM-os, az teljesen korrekten begyógyítható volt IPA-ba.

A helyzet az, hogy az a normális, hogy az LDAP-ot authentikációs adatbázisként használó program illeszkedik az adottnak tekinthető LDAP-sémához. Azaz nem te hekkeled bele a memberOf támogatást az LDAP-odba, hanem fordítva, a programot kell bekonfigurálni, hogy képes legyen a csoportok irányából megtalálni a member attribútumokat.

Az utobbi par napban eleg sokat olvastam meg teszteltem LDAP temaban, mert sajnos ma meg megkerulhetetlen. Tobbszor is belefutottam ehhez hasonlo felvetesbe.

Pl Most be kell kotnom egy LDAP-ot Keycloak moge, mert a Nexus repo manager (free verzioja) nem tamogat SSO-t. Abba a problemaba futottam bele, hogy ha letrehozok egy uj felhasznalot Keycloak-ban, akkor ugyan szepen letrehozza a felhasznalot LDAP-ban is, de a jelszot clear text-kent tarolja.

Valaki nyitott erre egy ticketet a keycloak bug tracker-ben, es eleinte ugy tunt, hogy lesz valtozas es csak a jelszo hash-t adjak at az LDAP-nak. De aztan a fejlesztok nagyon gyorsan meggyoztek magukat, hogy ez nem az o dolguk, ezt LDAP oldalon kell megoldani. A menobb cuccok ezt ugyis csinaljak alapbol (Windows AD, FreeIPA) a tobbibe meg megoldhato (ApacheDS, OpenLDAP).

Nem ertek egyet veluk. Az LDAP szervert egy alapvetoen buta, egyszeru cucckent kellene kezelni. Mentse el amit kap, adja vissza amit kerdeznek. De funkciokat vegrehajtani meg adatot transzformalni szerintem nem feladata.

Ugyanez igaz a memberof funkciora is. Csak hat ugye baromi kenyelmes egyetlen user attributumot vizsgalni a csoportok helyett az app oldalon.
Habar azt is hozza kell tenni, hogy ha jol tudom, akkor a memberof-ra van valami optimalizacio igy sok meg nagy csoportok eseten gyorsabb a memberof mint csoportokba nezegetni.

elméletben igazad van, de a gyakorlatban egyik cuccnak sem vagyok fejlesztője, hogy ezt ilyen egyszerűen megtehetném. több, véleményem szerint általánosan használt szolgáltatáshoz (Nextcloud, Postfix, Rocketchat, Wekan, ki tudja mi merül még fel) szeretnék illeszteni valamilyen használható, központi user management alkalmazást, hogy ne szolgáltatásonként kelljen menedzselni (létrehozni / törölni / hozzáféréseket, jogosultságokat, jelszót, kvótát állítani stb.) a felhasználókat. mielőtt belevágtam, az LDAP tűnt erre az ipari szabványnak. bevallom, nem derült ki, a többi szolgáltatás mennyire drótozható össze az LDAP-pal vért izzadás nélkül, mert legelső kísérletre, már a Nextcloud esetén belefutottam az itt ismertetett problémába.

továbbra is furcsa nekem, hogy nincs erre valami, legalább de facto szabványként használható, kigyúrt, jól használható megoldás. feltéve, hogy tényleg nincs.

A kc egy értelmes (nem openldap) backenddel? Tudok olyanról, ahol a kc "mögé" egy AD van "bekötve", ott történik az userek/csoportok elsődleges kezelése, a kc meg egy "glue" az alkalmazásokban definiált jogosultsághalmazok (szerepkör) és az AD között. És ahogy hallottam, csak a group a groupban "nem megy".

most éppen Keycloak + FreeIPA leírásokat olvasgatok. egyelőre nem világos, kell-e mindenképpen valamiyen DS backend a Keycloak mögé, mit nyerek vele, vagy esetleg nélkülözhetetlen. mert feleslegesen nem szopatnám magam, ha azt a minimál igényt, amire nekem kell, a Keycloak is megoldja önállóan. hacsak nem tenne lehetővé hosszabbtávon olyan megoldásokat is, amelyek hasznosak számomra is, de erről még egyelőre nem találtam hasznos infót.

>És ahogy hallottam, csak a group a groupban "nem megy"

Inkabb ugy mondanam, hogy problemas. Openid-vel meg nem probalkoztam, SAML es nextcloud tapasztalatom van ezen a teren.

A KC is tamogatja a csoport a csoportban felallast, a kerdes csak az, hogy ezt az info hogyan adja at a kliensnek es hogy az tudja-e ertelmezni azt. Amikor egy felhasznalo bejelentkezik KC-vel, a kliens megkap(hat)ja a felhasznalohoz tartozo csoport tagsagokat is egy attributumban. Az allithato, hogy ez milyen formaban legyen atkuldve, jelenleg 2 opcio van.

- Csak azon csoportneveket amikben valoban tag a felhasznalo. Ez egy egyszeru felsorolast eredmenyez, mint "csoport3","csoport4" es nem ad infot arrol, ha mondjuk "csoport4" tagja "csoport2"-nek

- Atadja a csoportok teljes eleresi utvonalat. Szinten felsorolas, de igy nez ki: "/csoport1/csoport3","/csoport2/csoport4" Ez azt jelenti, hogy az adott felhasznalo tagja csoport3-nak es csoport4-nek, csoport4 tagja csoport2-nek, csoport3 tagja csoport1-nek. Ilyen modon a kliens minden infot megkap.

A problema csak az, hogy pl a Nextcloud nem tudja ertelmezni a "/csoport1/csoport3" stringet, egyszeru nevkent kezeli es beteszi a felhasznolt egy csoportba, amit ugy hivnak, hogy "/csoport1/csoport3"

Nem tudom, hogy itt ki a hunyo, vagy van-e hunyo egyaltalan. Nem tudom, hogy valahol definialva van-e, hogy hogyan is kellene atadni a csoport a csoportban infot, es ha igen, akkor melyik oldal az, amelyik nem illeszkedik ehhez.

Ez oké, a kérdés az, hogy ha az user AD-ból jön, és van neki AD-ban közvetlen csoportja, meg indirekt (tehát user tagja csoport, csoport tagja másikcsoport) tagsága, azzal hogyan boldogul. Mondjuk engem nem igazán érint ez a kérdés, de ki tudja, mit hoz a jövő...