ldapsearch filter

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

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.)

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.

É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):

$ ldapsearch -x -H ldap://192.168.39.3:1389 -D "cn=admin,dc=k8s,dc=local" -b "dc=k8s,dc=local" -w adminpwd  -s sub '(&(objectclass=groupofnames)(|(cn:dn:=ldapeditors)(entryDN:distinguishedNameMatch:=cn=ldapviewers,ou=groups,dc=k8s,dc=local)))' cn 
# extended LDIF
#
# LDAPv3
# base <dc=k8s,dc=local> with scope subtree
# filter: (&(objectclass=groupofnames)(|(cn:dn:=ldapeditors)(entryDN:distinguishedNameMatch:=cn=ldapviewers,ou=groups,dc=k8s,dc=local)))
# requesting: cn 
#

# ldapeditors, groups, k8s.local
dn: cn=ldapeditors,ou=groups,dc=k8s,dc=local
cn: ldapeditors

# ldapviewers, groups, k8s.local
dn: cn=ldapviewers,ou=groups,dc=k8s,dc=local
cn: ldapviewers

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Őőő 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.

Oke, akkor neked van igazad jo? Mondjuk lehet en baszok el akkor valamit de nagyon

$ ldapsearch -x -H ldap://192.168.39.3:1389 -D "cn=admin,dc=k8s,dc=local" -b "dc=k8s,dc=local" -w adminpwd  -s sub '(&(objectclass=groupofnames)(|(ou:dn:=Tech)(ou:dn:=Operation)))' cn 
# extended LDIF
#
# LDAPv3
# base <dc=k8s,dc=local> with scope subtree
# filter: (&(objectclass=groupofnames)(|(ou:dn:=Tech)(ou:dn:=Operation)))
# requesting: cn 
#

# Test, Tech, groups, k8s.local
dn: cn=Test,ou=Tech,ou=groups,dc=k8s,dc=local
cn: Test

# foo_admins, Engineer, Tech, groups, k8s.local
dn: cn=foo_admins,ou=Engineer,ou=Tech,ou=groups,dc=k8s,dc=local
cn: foo_admins

# foo_devs, Engineer, Tech, groups, k8s.local
dn: cn=foo_devs,ou=Engineer,ou=Tech,ou=groups,dc=k8s,dc=local
cn: foo_devs

# bar_admins, Command Center, Tech, groups, k8s.local
dn: cn=bar_admins,ou=Command Center,ou=Tech,ou=groups,dc=k8s,dc=local
cn: bar_admins

# bar_users, Command Center, Tech, groups, k8s.local
dn: cn=bar_users,ou=Command Center,ou=Tech,ou=groups,dc=k8s,dc=local
cn: bar_users

# ize, Sales, Operation, groups, k8s.local
dn: cn=ize,ou=Sales,ou=Operation,ou=groups,dc=k8s,dc=local
cn: ize

# csigabiga, Management, Operation, groups, k8s.local
dn: cn=csigabiga,ou=Management,ou=Operation,ou=groups,dc=k8s,dc=local
cn: csigabiga

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 7

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:

'(&(objectclass=groupofnames)(|(dn:=Tech)(dn:=Operation)))'

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:

The wildcard character "*" is allowed, except when the <AD Attribute> is a DN attribute. Examples of DN attributes are distinguishedName, manager, directReports, member, and memberOf.

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 

Get-ADUser -Filter * -Properties DistinguishedName | Where-Object {$_.DistinguishedName -like '*Functional_Accounts*'}

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!