Fórumok
Udv!
Ilyen strukturaban vannak a csoportok megadva windowsos AD-ben:
ou=Groups,ou=company,dc=domain,dc=com
- ou=Tech
- cn=Test
- ou=Engineer
- cn=foo_admins
- cn=foo_devs
- ou=Command Center
- cn=bar_admins
- cn=bar_users
- ou=Operation
- ou=Sales
- cn=ize
- ou=Management
- cn=csigabiga
- ou=Misc
- ...
ez sajna adott, nincs lehetoseg modositani.
Linuxon olyan ldap search filter keresek, ami visszaadja a ou=tech es ou=operation alatti ossze csoportot, barmilyen melyen is van. (es ne a Misc kizarasaval, mert ott meg van 5 masik amit ki kene zarni)
probaltam netet bujni, AI-t kerdezni, de nem segitett. BaseDN: ou=Groups,ou=company,dc=domain,dc=com
Valakinek van otlete?
Hozzászólások
(&(|(ou=Operation,ou=Groups,o=company,dc=domain,dc=com)(ou=Operation,ou=Groups,o=company,dc=domain,dc=com))(objectclass=group))
persze fogalmam sincs hogy az AD-ban a group-oknak mi az objectclassa, szoval ez csak amolyan pszeudokod
ezzel probalkoztam en is (teszt keppen kiirva a teljes CN=....), de nem akarta az igazsagot:
ldapsearch -x -h 192.168.1.1-b.... -b 'OU=Groups,OU=company,DC=domain,DC=com' -s sub '(&(objectclass=group)(CN=Test,OU=Tech,OU=Groups,OU=company,DC=domain,DC=com))'
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
tuti hogy van objectclass=group? Mert a cn=test az tuti letezik a fa szerint amit beraktal.
En megneznem "es" nelkul csak a cn=test-re meg csak az objectclass=group-ra kulon-kulon is. Ha az objectclass groupra visszaadja a cn=test-et is akkor nem ertem, ha nem adja akkor az lesza gond :D
A kerdes meg, hogy a bind dn-ed tuti kepes olvasni ezt a fat es az attributumokat?
igen, readonly user elvileg mindent lat, az Apache Directory Studio-val latom is a dolgokat, ezert tudom milyen a struktura.
raadasul ha a filternek kozvetlenul a cn-et adom meg, akkor visszakapom: '(&(objectclass=group)(CN=Test))'
Ha viszont barmi mast is megadok pl '(&(objectclass=group)(CN=Test,OU=Tech))' , akkor mar nem talal semmit. igy van az ldap magic, vagy az AD keres mashogy.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
<ert a filter rossz. Mincs olyan objecktumod hogy ou=test, ou=tech. Helyesen ahogy fent irtam is:
(&(objectclass=group)(|(ou=test)(ou=tech)))
Azaz ou=tech VAGY ou=test ES objectlass=group.
Ott a VAGY jel (pipe) a ket objecktum kozott es a logikai kifejezest meg zarojelezni kell, hogy eloszor azt ertekelje ki es ne sorban ertekeljen
Sehol nem is mondta, hogy van ilyen, ő mindig is cn=Test, ou=Tech-re keresett rá, ami van is (lásd a fát és a kommentjeit).
Jah igen, beneztem. De a lenyeg a lenyeg, hogy igy mukdonie kell: (&(objectclass=group)(|(ou=Tech)(ou=Operation))) Kell az a "VAGY"
Lent leirtam peldaban, hogy DN-re keresve is mukodnie kell (bar en openldap-ot dobtam fel gyorsan tesztnek)
Legalább annyit dönts el, hogy melyik a helyes:
OU=Groups,OU=company,....
vagy pedig
OU=Groups,O=company
Mert ebben a hozzászólásban Organizational Unit, a kezdő leírásban pedig Organization a Company. Márpedig OU =/= O.
Szóval csak elírás volt valamelyik bejegyzésben, vagy tényleg hibás kérést küldtél?
(Az már csak hab a tortán, hogy szerintem rusnya megadás, hogy DC is van meg OU / O is. Valamiért úgy rémlik, vagy egyik, vagy másik a "szép". De mint írtad, a felépítésre nincs ráhatásod, szóval ez csak olyan morgolódás.)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
eliras, javitottam. OU=company
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Itt neked a -b(ase)-t kellene, hogy kétfélét tudj megadni, de olyan nincs. Két search op. nem jó (az egyik -b ou=tech, ..., a másik -b ou=operation,...)? Mert ha pl. postfix csoporthoz kell, az össze tudja szedni a map-ot két .cf-ből is.
Nem kell ket base. Egy bas kell az teteje. Utana az kell amit irtam. "group=objectlass ES (ou=test VAGY ou=tech)" Azaz minden ami vagy tech vagy test es meg objectclass tipus is
És ez működik is? Mert az ou=xxx az nem egy attributuma a keresett objektumoknak, hanem a helye, filterben nem sokat ér.
Egy ilyen filter, hogy ou=Operation,ou=Groups,o=company,dc=domain,dc=com semmit sem csinál, legfeljebb ha az lenne, hogy distinguishedName=ou=Operation,ou=Groups,o=company,dc=domain,dc=com, akkor az magát az OU-t jelenti, nem a benne levő objektumokat. Olyan nincs a filter RFC-ben sem, hogy a szülő konténerre szűrj.
Még ha működne, hogy distinguishedName=*,ou=Operation,ou=Groups,o=company,dc=domain,dc=com, de ez nem működik.
AD-ben mukodine kellene. De igazad van kell ele a distinguishedName. Az entryDN-el nem probaltam. De ennek is mukodnie kellene: https://docs.oracle.com/cd/E19623-01/820-6173/def-extensible-match-sear…
UPDATE:
Nalam mukodik (ket fele keppen is, az egyik kimonoddtan az entryDN virtualis attributumra):
Őőő ez nem sokat bizonyít, lehozta az ldapeditorst meg az ldapviewerst, de az eredeti kérdező az ezek alatti bejegyzésekre lenne kíváncsi. Neked ezek alatt nyilván nincs semmi, de akkor egy olyan queryt mutass, ami mondjuk az ou=groups meg az ou=people (ha van olyan, de lehet akármi más) alatt hozza le a bejegyzéseket.
Tippre akkor a groups és people közös szülőjét kéne megadni baseDN-nek, nem?
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Igen, de akkor keresni fog a groups-al és people-al egy szinten levő konténerekben (könyvtárban, ou-ban, mappában, kinek mi a szimpatikus), amit a kérdező pont nem szeretne.
Ezért mondom, hogy szerintem ez nem megoldható 1 queryvel.
Oke, akkor neked van igazad jo? Mondjuk lehet en baszok el akkor valamit de nagyon
Ez a faszsag nekem kihoz mindent amit a kerdezo akart
Ez már tényleg hasonlít.
AD-ban egy ilyen filter: 'cn:dn:=Computers' viszont lehozza magát a Computerst, és semmit alatta (azaz a dn-ben mintha nem támogatna substring keresést).
A te filteredben az ou: az elején vajon kell? Nem elég csak:
igen, ilyenekkel en is probalkoztam, de nem jott ossze. Anynit sikerult kiasnom az internetbol, hogy AD-nel a DN-t tartalmazo mezoknel nem tamogatott a wildcard kereses:
Lehet ez a ou:dn:=Tech is tulkepp egy wildcard kereses, es ezert nem megy. :/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Lehet ez a ou:dn:=Tech is tulkepp egy wildcard kereses, es ezert nem megy. :/
Igen, utánanéztem, ez azt jelenti, hogy vagy az ou=Tech, vagy a dn-ben bárhol van Tech (úgyhogy a Technocolra is egyezne elvileg). És AD-ban meg pont nem lehet dn-re ilyet, szóval a kérdező továbbra is meg van lőve.
Akkor ugy nez ki hogy az AD-ben nem lehet ja. (Mondjuk az Ad az amugy is egy specialis cimtar, kb semmiben sem koveti az RFC-ket.)
Szerintem el kell engedni az ldapsearch-ot es az Ad-hoz a jo kis powershell-t kell hasznalni.
Reddit-en valamiilyesmit talaltma, de fogalmam sincs jo e mert kb eletemben nem lattam powershellt :D
sajna AD adott, masra valtas nem opcio.
ldapsearch csak a "teszteles" kellett, vegen keycloak group synchez csak egy ldap filter mezo van, igy a powershell/barmi kulso hasznalata nem lehetseges.
ha tenyleg nem tud olyat, akkor a "megoldas" (hogy noveljuk az entropiat) az AD-ben csinalunk egy kulon ou=TechOperation es oda vesszuk fel a cn-eket :/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Mondjuk ezt azért ne futtasd le egy nagyobb címtárra, ahol tízezres vagy százezres nagyságrendben vannak userek, mert ugye ez azt csinálja, hogy mindent áthoz kliensre, és aztán ott szűr.
mondtam hogy nem ertek a powershellhez :D
Ezt ldapsearch-el is megcsinálhatod, lehozod az összes ou-t, aztán kiszűröd belőle lokálisan, ami nem kell. A powershell nem okosítja fel az AD szervert.
bottal sem piszkalnam a powershellt, szoval en tuti nem inditanek semmi ilyesmit :D