Érthetetlen problémába ütköztem.
Van három AD csoport.
A csoportok mind Global és Security típusúak.
A gyökerük az AD-ben azonos (dc=valami,dc=cégnév,dc=sys) utána az első és a második egy ideig "együtt megy" és csak később válnak szét, a harmadik viszont rögtön elmegy teljesen másik ágra.
Kb. így:
cn=csoport1,ou=ou111,ou=11,ou=1,dc=valami,dc=cégnév,dc=sys
cn=csoport2,ou=ou112,ou=11,ou=1,dc=valami,dc=cégnév,dc=sys
cn=csoport3,ou=9,dc=nagyonmás,dc=mégvalami,dc=valami,dc=cégnév,dc=sys
Hozzáadtam a szervert az AD-hez.
Az /etc/ssh/sshd_config -ba felvettem a három csoport nevét:
AllowGroups "elso_csoport_neve" "masodik - csoportneve" "harmadik-csoport-neve"
Az eredmény az lett, hogy azok, akik az első és a második csoport tagjai, be tudnak ssh-zni, de amikor a harmadik csoport tagjai próbálkoznak, akkor a syslogba ez kerül:
sshd ... User ... from ... not allowed because none of user's groups are listed in AllowGroups
Már beszéltem az AD adminokkal meg mindenkivel, akivel tudtam, de senki nem lát lényegi különbséget a három csoport között.
Az a domain user, amivel beléptettem a gépet az AD-be tudja browse-olni a teljes fát, látja a csoportok tulajdonságait, stb.
A kollégák azt kérdezték, hogy egy ilyen linux vajon milyen user nevében és hogyan turkál az AD-ben a csoporttagságot keresve, de ezt én sem tudom.
Az AllowGroups-ban a csoportok sorrendje mindegy.
A kérdéses userek tagjai a csoportnak (net user /domain usernév)
Látott már valaki ilyet?
- 1172 megtekintés
Hozzászólások
Hogy éri el a domain infókat a gép, natív LDAP vagy winbind?
Ha LDAP-ot használsz, ellenőrizd, hogy global catalog-ot használsz-e (3268 porton figyel, az is egy sima LDAP, de a teljes erdőre vonatkozó infókat tartalmaz, a rendes LDAP szerver csak arra a domainre, amelyiknek a kontrollerjéhez csatlakozol). Ránézésre (a dc=nagyonmás miatt) az egy subdomain.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
winbind-dal
- A hozzászóláshoz be kell jelentkezni
Nem látok rá semmi opciót, úgyhogy tippre annak működnie kéne... ha be van kapcsolva a winbind enum groups (utána kapcsold ki, ha most nincs) és kiadsz egy getent group-ot, látszik a másik csoport? Esetleg [MÁSIKDOMAINNÉV]\\[Csoportnév] formában egy id-del le tudod kérdeni?
Egyáltalán jól gondolom, hogy aldomainről van szó? :)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Igen, a getent group-ra látszik az összes csoport.
Ez egy sima Windows -os domain, az LDAP fa így épül fel, ahogy a fenti mintában is mutattam.
Elvileg nincs subdomain. :)
- A hozzászóláshoz be kell jelentkezni
Egy "wbinfo -r"-rel le tudod kérni a nem működő user csoportjait? Szerepel benne a harmadik csoport/a harmadik csoport id-je?
Off-topic: Meg tudnád nézni a dc=mégvalami,dc=valami,dc=cégnév,dc=sys entry objectClass-ait? Kezd érdekelni, hogy mi az :) [dc attribja az MS-es doksik szerint csak Dns-Node, Dns-Zone és Domain objektumoknak lehet]
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
wbinfo -g latszik mind3 csoport?
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
- A hozzászóláshoz be kell jelentkezni
igen, látszik.
- A hozzászóláshoz be kell jelentkezni
Nincs veletlenul space a group neveben?
--
L
- A hozzászóláshoz be kell jelentkezni
id usernév paranccsal jók a csoporttagságok?
- A hozzászóláshoz be kell jelentkezni
igen, jók
- A hozzászóláshoz be kell jelentkezni
Ez csak itt elírás?
ou=9
Másik két csoportnál:pl. ou=ou111 és ou=ou112.
Fentebbiek alapján:ou=ou9.
- A hozzászóláshoz be kell jelentkezni
Ez itt most a példában direkt így van, hogy látszódjon a jó nagy eltérés a DN-ek között. :)
- A hozzászóláshoz be kell jelentkezni
Az előbb felhúztam egy zsír új szervert és bekötöttem ugyanúgy AD-be, mint ahogy a problémás gépet.
És tökéletesen működik mindhárom (és még bármelyik másik) AD group-pal az ssh.
Szégyen a futás, de mivel a kérdéses gép úgyis eléggé tákolt volt, ezért lesz helyette egy új CentOS 7 és remélhetőleg nem lesz semmi izgalom.
Köszi mindenki idejét, ez az eset is megy az X aktás polcra.
---
Tanulság az nincs, hacsak az nem, hogy itt a cégnél tényleg le kell zúzni a linuxos infrastruktúrát, mert ilyenek vannak:
- a gépek jó részén évek óta fennálló, teljes dependency hell
- az egyik VM-ben 24 CPU + jack the ripper (mi a francot akarhattak vele?)
- jellemző, hogy egy gépen van 2-3-4 IP, mindegyik más-más tartományból, "mert így biztos működik a routing"
- a hosts file-ok tele vannak írva (részben már nem létező hostokkal), hogy "biztosan működjön a névfeloldás"
Agyhalál.
- A hozzászóláshoz be kell jelentkezni