Skip Navigation Links
 Tudástár cikkek 
 Konferenciaanyagok 
 Dokumentumok 
 NetAcademia Blog 

NetAcademia Blog

IE8 Accelerator Tudástár kereséshez   Kereső szolgáltatás Tudástár kereséshez
 


Csoport Stratégiák
- Venicz László -

 Feliratkozás Rss feed 2009. 11. 26. 21:56
Sziasztok.

A mai előadással kapcsolatban szeretném megosztani az én agymenésemet a csoportok kezeléséről. A tapasztalataimat egy 3 országon át húzódó, 6 tartományból álló erdőben szereztem, így azt gondolom láttam, s próbáltam egy két variációt.

Az alap probléma, hogy mindenki mindenhol szeretne mindenfélét csinálni, s nem érdeklik olyan mesék, hogy miért nem megy az egyik tartományból a másikba vagy vissza. Akkor is, ha fizikailag hol itt, hol ott dugdossa be a notebookját. Mennie kell! Ehhez tényleg érteni kell, mit lehet, melyik csoporttal csinálni. Hallottuk, hogy sokféleképpen lehet. Még az ajánlások is többfélék. Elmondom azt, ami nekünk bejött, s azt is miért.

A-G-DL-P

A: Szóval adott a felhasználó, vagyis az Accountja.
G: Ezt szépen beletesszük egy Global csoportba.
- Hol? Nem kérdés. Abban a tartományban ahol ő létezik. Máshol ugyanis nem tudnánk, hisz egy globális csoportnak csak az adott tartományból lehetnek tagjai.
- Kik a tagjai? Helyi tartományi felhasználók.
- Ki teszi be? Ki veszi ki? A felhasználó saját rendszergazdája. Előnye, hogy nem kell külön szervezési köröket futni, telefonálgatni, formanyomtatványokat küldözgetni, a tökkelütött „fejesekre” vagy épp a „beosztottakra” várni. No és persze nem felejtődik el, hisz lokálisan mégiscsak tudjuk, ha valaki már nem dolgozik a cégnél.
DL: A globális csoportokat beletesszük egy Domain Local csoportba.
- Hol? Nem kérdés, abban a tartományban ahol a jogosultságot (mentés, nyomtatás, file elérés, bármi) ki akarjuk osztani. Ha máshol hoznánk létre, nem tudnánk neki jogosultságot adni ebben a tartományban.
- Kik a tagjai? Global csoportok, tetszőleges tartományból.
- Ki teszi be? Ki veszi ki? Az erőforrás rendszergazdája. Logikus, hisz azért mégiscsak ő felel érte. Ő kell, hogy szabályozza a hozzáférést. No, de akkor hol itt az előny. Itt mégiscsak kell telefonálgatni. Igen. Egyszer! Amikor megtervezzed egy adott erőforráshoz milyen típusú felhasználók, melyik tartományból férjenek hozzá. Könyvelési adatok? Saját pénzügyes csoport, meg a felettes pénzügyes csoport. Meg a vezetők mondjuk mindkét tartományból. Kész. Nem változik a séma hetente!
P: Az előbbi DL csoportnak aztán szépen kiosztjuk a jogosultságokat (Permission). Neki, és csak neki! Bárki aki hozzá akar férni, csak itt kaphat jogot.
- Előny? Nem kell nyomozni, miért tud még mindig nyomtatni Gizike??? Csak azért mert tagja egy olyan Global csoportnak a saját tartomyányában (ez látszik az ő tulajdonságlapján!) ami benne van a „FélemeletiSzínesNyomtatóFelhasználói” Domain Local csoportnak az erőforrás tartományában (ez meg látszik a DL csoport members lapján!) . És pont. Nincs más lehetőség.

Az igazi nagy előnye egy ilyen rendszernek az átláthatóság. Az emberkéket G csoportokba gyűjtöd csak a saját tartományukban. Ott kezeled őket, ha belép, kilép, átmegy egy másik csoportba, nem kell vadászni az egész erdőben, hogy hol bújhatott még meg.

Jogot meg csak DL csoportnak adsz. Őket bepakolod egy „Resource” OU-ba és az egész jogosultsági rendszeredet egyszerű skripttel kilistázod 1 perc alatt. Szintén csak lokális adatokra támaszkodva. Gyakorlati tapasztalat, hogy mindezt az ACL-ből horror kiszedni egymásba ágyazott, több tartományba szétszórt csoportok esetén. Egy VBS-WMI szkriptem még megvan valahol hozzá, de napokig szüttyög pár száz gigányi file rendszeren. (Persze biztos azt is meg tudná valaki írni jobban.)

Azzal, hogy a Universal csoportokat kihagyod a játékból, nagyon sok fejfájást megspórolsz magadnak:
- Hol legyenek a Global Cataloge szerverek?
- Hány kell belőlük telephelyenként?
- Mekkora replikációs forgalmat generálnak?
- Mikor replikálódnak már végre le az új tagok?
- Universal Group Cache Mode beállítgatása?
- Lassú bejelentkezés távoli, nem működő bejelentkezés elérhetetlen GC esetén?
- A Univerzál group adminisztrációját ki csinálja? Kinek adjunk rá jogot? Ismét UG-knak? Na és azokra??? 

Természetesen egy ilyen rendszernek van egy komoly hátránya is. Kő keményen meg kell tervezni, s sok meló megcsinálni. De ezt csak egyszer kell. S a napi meló utána sokkal könnyebb.

Természetesen nem hiszem, hogy csak ez az egyetlen jó megoldás. Vagy, hogy ennek nincsenek hibái. Pont azért kezdtem ezt a topikot, hogy hozzuk össze ki hogy oldotta meg a saját rendszerében, s miért jobb az mint a többi. Sokat tanulhatunk belőle. A mellékelt kép alapján akár el is indulhatna az eszmecsere. Miért csinálnátok máshogyan?

Üdvözlettel: Venicz László


AGDLP.pdf

Re: Csoport Stratégiák Barcsi Tamás - NetAcademia (2009. 11. 27. 07:04) Barcsi Tamás - NetAcademia
  Tanulságos, megfontolandó, és jó, amit írtál. :) Ha nem véded le szerzői joggal, akkor majd beleszövöm tanfolyamon a mondandómba, mint élő példa... :)
 
Re: Csoport Stratégiák Venicz László (2009. 11. 27. 08:15)
  Majd megállapodunk a licencdíjról. :-)
 
Re: Csoport Stratégiák Győri György (2009. 11. 28. 09:12) Győri György
  Csatlakoznék a Tamáshoz. Nagyon jó! :)
 

Bejelentkezve hozzá is szólhat

Cím: 1077 Budapest, Kéthly Anna tér 1.
Telefon: (06 1) 472-1214
Fax: (06 1) 472-1215
Nyitvatartás, ügyfélszolgálat: 830-1630
Regisztrációs szám: 01-0707-04
Fat akkreditációs lajstromszám: AL-1680
Írjon nekünk!
Tudástár PPT-k Dokumentumok Blog Próbatesztek