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.
utóbbit a refint overlay telepítése megoldotta. az eredeti probléma továbbra is fennáll.
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.
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:
hozzáadva:
elvéve:
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.
dupla
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:
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...
par eve lattam valami hasonlot, amit akkor az auditlog overlay okozott. A refint overlay helyett nem probalnad ki inkabb a memberof refint parameteret bekapcsolni? Az overlay-ek, es a sorrendjuk szepen be tut kavarni itt-ott.
be van:
én azt hittem, emiatt kell a refint overlay is. mármint hogy ez meghívja azt.
Privat implementaciot hasznal a memberof overlay, nem kell a masik. Anelkul mar oke? Nem latom a memberof overlay forrasaban, mi okozhatna a hibat, amivel kuzdesz.
anélkül sem oké sajnos, azért tettem fel, hátha megoldja, de nem. előtte is ugyanez volt.
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
az számíthat, hogy hdb vagy mdb? ha kiszeded a member-t a group-ból, eltűnik a memberOf a user-ből?
mdb-vel is mukodik, es igen, konzisztens, nem marad ott folosleges memberOf. Jopar eve hasznalok OpenLDAP-ot, mar eszrevettem volna, ha gond lenne vele.
nálam nis van rfc2307bis1 helyett, ez jött a telepítéssel. ez lehet oka a problémának?
Eppen a csoportok kezeleseben van erdemi elteres a ketto kozott. groupOfNames eseten a NIS nem jatszik, 2307bis kell.
igen, én is találtam erre utaló jeleket. szerzek akárhonnan egy ldif-et, és betolom? nis-t ki kell szedni? ha igen, hogyan?
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.).
megcsináltam, rfc2307bis van nis helyett. a probléma továbbra is pont ugyanúgy fennáll.
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)
egyetértek. javaslat?
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?
nincs még megoldás. FreeIPA-t próbálok telepíteni ubuntu-ba, de elsőre elhasalt az install. találtam róla hibajegyet, valami ubuntu specifikus tomcat hiba, a fejlesztőknek nincs ideje foglalkozni a problémával...
Tessék rendes OS-re rakni, vagy beletörődni, hogy LDAP-ot kell mélylélektanilag matatnod...
értettem! épp most megy fel CentOS-ra, majd megírom, itt mi nem működik... :)
:-D
felment, működni látszik, megy a webes felület, ami benne van, az jónak tűnik. nem volt még időm rápróbálni a memberkedésre, amint eljutok odáig, megírom a tapasztalatokat.
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:
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.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/…
Itt érdemes elolvasni a memberof plugin részt. A FreeIPA-ban is 389ds/fedorads/redhatds/hivd_aminek_akarod_de_ez_nestacep_directory_server van.
elolvastam. utolsó reménysugárként az inetUser objectClass-t szeretném alapértelmezetté tenni a userek részére, de nem tudom, hogyan. egyelőre nem találtam számomra használható leírást.
sima ldapmodify? Vagy managedTemplate?
Ha meg a felületen, akkor mondjuk a phpldapadmin tud olyat, hogy custom templatet csinalsz mondjuk a usernek es ott beallitod, hogy az inetuser objectclass is benne legyen az objectclassok kozott.
Ilyen LDAP-turkászást IPA alatti fában ne csinálj, mert nagyszerűen össze lehet vele kuszálni a működését. Ha ez kell, akkor sajna goto 10, és tisztán ldap-pal kell sajtreszelőznöd...
bocsánat, nem voltam egyértelmű, visszatértem közben az ubuntus openldap-hoz, azt próbálom reszelni, nem a FreeIPA-t. szóval a kérdés, hogy hogyan tudok openldap-ban default objectClass-t hozzáadni a user schema-hoz, konkrétan inetUser-t.
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:
Majd Joskat:
Es Joskat berakom a kocsmaba:
Ezen a ponton Apache DS-ben megjelenik a memberof attribute Joskanal, es az ldapsearch is megtalalja:
Eddig minden OK.
Most hozzuk letre Pistat:
Na most Pista nemileg szofisztikaltabb, ugyanis -Joskaval ellentetben- nem csak inetOrgPerson hanem posixAccount is.
Betesszuk Pistat is a kocsmaba:
Es bar az ldapsearch megtalalja:
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.
A kc esetén nem ez az egyetlen "nem a mi dolgunk" jelleggel elintézett igény/javaslat...
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ő...