HTML

A rendszergazda naplója

A rendszergazda naplója, hasznos megoldásokkal rendszergazda jelölteknek és felhasználóknak.

Friss topikok

Linkblog

2009.09.22. 19:22 Hegedűs_Gábor

Startup script Group Policy-ból, Login Script adminisztrátori jogokkal, korlátozott felhasználók esetében

Címkék: rendszergazdáknak startup script logon script login script startup szkript logon szkript login szkript

Megjegyzés: Javított verzió! Csak erős idegzetűeknek! :)

Rendszer: Szerver: Windows 2003 SP2, Angol. Kliensek: XP Professional SP3, Magyar

Probléma: Szerettem volna egy olyan login script-et írni, ami az összes problémámat megoldja, belenyúl a registry-be, fájlokat másol, ini fájlokat állít be. Kényelmes rendszergazdák, akik csak rendszergazdai jogosultsággal rendelkező felhasználókkal dolgoznak, rögtön rávágják, hogy szépen tegyek bele mindent a C:\windows\sysvol\domain\scripts\login.bat-ba és a domain felhasználó beállításainál rendeljem hozzá ezt a login szkriptet. Ez tökéletesen működik mindaddig, amíg nem korlátozott felhasználókról van szó.

Viszont korlátozott felhasználóknál rögtön gond van. Nem tudnak a registry-be írni, nem másolhatnak fájlokat bárhová, stb.

Egy kicsit körülnéztem a "piacon" és találtam egy-két bíztató kiinduló pontot. Az Group Policy-n keresztül elérhető, un. startup szkript ígéretesnek nézett ki, mivel local system jogosultságokkal fut. Aztán hamar rájöttem, hogy startup szkript csak számítógépekhez rendelhető, mivel még azelőtt lefut, mielőtt a felhasználó bejelentkezne. Így nem tudom az (leendő) aktuális felhasználó profilját elérni, a szkriptben a %userprofile% típusú változók értelmetlenné válnak.

Akkor viszont mit lehet tenni? A gépspecifikus feladatokat már kivettem, de még mindig több jogosultságra van szükségem, mint a bejelentkezett felhasználónak. Első gondolatom a "runas" volt. De hamar rájöttem, hogy biztonsági okokból, "by design" a runas jelszóval SEHOGY nem paraméterezhető. Van ugyan egy kis huncutság, kerülő megoldás, de nem túl szép. Helyette maradt a psexec, ami elsősorban távoli eljáráshívásra lett kitalálva, de gyönyörűen lehet lokálisan is használni és password-el is paraméterezhető.

Kérdés annyi maradt, hogy milyen felhasználói fiókot használjak a szkript futtatásához. Először a helyi számítógép rendszergazdai fiókjára gondoltam, de ez sajnos nem volt megfelelő, hiszen a hálózaton megosztott erőforrásokat, hálózati mappákat ezzel a fiókkal nem lehet elérni. A Domain rendszergazdai fiók szóba sem került, mert ugyan a felhasználók nem képzett hacker-ek, de azért paraméterként mégsem célszerű ezt a jelszót használni. Két megoldás merült fel: 1., mégis lokál rendszergazda és net use paranccsal elérni a hálózati meghajtót. 2., létrehozni egy új biztonsági csoportot, ami a megfelelő megosztásokat éri csak el és ezt a csoportot hozzáadni a klienseken a rendszergazdákhoz. A másodikat választottam, mivel így nem kellett változtatnom a már megírt szkriptjeim UNC útvonalain.

A megoldás már körvonalazódott. GPO-s startup script a registry változtatásokra, a felhasználóknak tiltott mappák elérésére. GPO-s logon script, rendszergazdai jogokkal, a korlátozott felhasználó által végre nem hajtható, fiókokhoz kötött műveletekre.   

Következzen hát részletesen is, mert elég sok buktatója van a dolognak.

1. Először létrehozunk egy biztonsági csoportot (pl. scriptgroup) és egy domain felhasználót (pl. script), aki ennek a csoportnak a tagja. Létrehozunk egy megosztott mappát, benne a logon szkripttel. A mappára olvasási jogot adunk a "scriptgroup" biztonsági csoportnak.

2. A felhasználót hozzáadjuk a kliensek "Rendszergazdák" csoportjához Group Policy segítségével. Itt nagyot bukhatunk, mert ha nem jól csináljuk, könnyen kitörölhetünk mindenkit a rendszergazdák közül, kivéve az előbb létrehozott biztonsági csoportot. Szóval, vegyünk egy megfelelő group policy-t, kisebb cégeknél akár a "Default Domain Policy"-t. Nyissuk ki a "Computer Configuration\Windows Settings\Security Settings" ágat és jobb egérrel kattintsunk a "Restricted Groups"-ra. Válasszuk az "Add group" menüpontot. Itt adjuk hozzá a "scriptgroup" biztonsági csoportunkat. Az utána megjelenő képernyőn a "This group is a member of:" melletti "Add" gombot használjuk.

 

 

 

 

 

Itt írjuk be azt, hogy "Rendszergazdák". Ugyanis ezzel a beállítással a kliensek lokális "Rendszergazdák" csoportjához hozzáadódik a mi "scriptgroup" csoportunk. A felső gomb használatával lecseréltük volna a "Rendszergazdák" csoport bejegyzéseit.

 

 


3.
A stratup script futattásához is létre kell hoznunk egy group policy bejegyzést. Ennek leírását itt találhatjuk. Egy kérdés merül csak fel, melyik GPO-t használjuk, mivel az AD-ban alapértlemezett "Computers" csoporthoz nem lehet ilyet hozzáadni. Itt eljárhatunk a hivatkozásban bemutatott, külön létrehozott OU segítségével, vagy akár létrehozhatunk a "Default Domain Policy" mellé egy teljes domain-re érvényes "Default Domain Computers Policy"-t is. Fontos, hogy figyeljünk arra, hogy a policy security beállításainál hozzáadjuk a "Domain Computers" csoportot, read és apply jogokkal.

Nagyon fontos, hogy a hivatkozásban is ismertetett módon elvegyük az "Authenticated Users" csoporttól a "Read" és az "Apply Group Policy" jogokat. Ez azért szükséges, hogy a felhasználók a munkaállomásokról ne tudják elolvasni a szkriptet és az átadott paramétereket se tudják kitallózni a \\szerver\sysVOL\domain\Policies\xxx\Machine\Scripts\scripts.ini helyről (thx to Blaise(R)).

Fontos az is, hogy a startup szkript alapértelmezetten felkínált helyén NE változtassunk, ne legyen pl. UNC útvonalon, mert így nekem sehogy sem akart működni.

Szóval nálam a startup szkript így néz ki:

A "jelszo" nálam paraméterként lett átadva, de ez lényegében mindegy. Szerepelhetett volna magában a szkriptben is. Ha jól beállítottuk a GPO jogosultságait, akkor a felhasználók nem fogják tudni elolvasni a jelszót. 

A szkript végén látható egy átirányítás, ami az amúgy láthatatlan kimenetet menti el mégis láthatóan egy "log.txt" nevű fájlba. A végén szereplő "2>&1" miatt a normál és a hiba kimenet is átirányítódik.

Maga a startup szkript tartalmaz a külső leírásban is szereplő "NET USER rendszergazda %1" parancsot is, ami a lokális rendszergazda jelszavát módosítja az átadott paraméter szerint. Persze az én startup szkriptem fő feladata nem ez volt, hanem pl. registry módosítások, de ezeket most nem részletezem.

Nagyon fontos feladat volt viszont, hogy  a később a logon szkript által használt psexec.exe fájlt a kliensekre másoljam, így a startup szkriptnek tartalmaznia kell a következőt: IF NOT EXIST %windir%\psexec.exe copy \\fs\script\pstools\psexec.exe %windir%

Másik fontos feladat, hogy a később lefutó logon szkript részére "lerakjuk" a jelszót egy biztonságos helyre. Hogy miért nem tudjuk itt is átadott paraméterként, vagy a szkriptben magában megadni a jelszót? Mert a logon szkript esetében nem tudjuk elvenni a felhasználóktól "Read" és az "Apply Group Policy" jogokat.
Tehát a startup(!) szkriptünknek kell egy ilyen sort is tartalmaznia: "echo jelszo >c:\dpsys\temp.tmp". Ez a "jelszo"-t beleírja a "c:\dpsys\temp.tmp" fájlba. A "dpsys" könyvtár jogosultságait módosítsuk úgy, hogy csak a "scriptgroup" felhasználói csoport tudja olvasni és írni, a hétköznapi felhasználóknak ne legyen semmilyen joga. (Ezt akár innen, a startup szkriptből is meg tudjuk tenni, de ezt most nem részletezem.)

4. Jöhet a logon szkript. Itt merül fel a kérdés, hogy miért a GPO-s logon szkript? Miért nem a "profile" login script? Azért, mert a GPO logon szkript kimenete nem látható.
Szóval a kiválasztott OU-n szerkesszük a GPO-t. Nyissuk ki a "User Configuration\Windows Settings\Scripts" ágat. Kattintsunk duplán a "Logon" feliratra.
A logon szkript nálam így néz ki:

Mint látható, a logon szkriptben már nyugodtan lehet UNC útvonalat használni.

A logon szkript feladata, hogy beolvassa a startup szkript által elhelyezett jelszót és ennek segítségével, "script" (rendszergazda) felhasználó jogosultságaival futtassa a tényleges logon szkript batch file-t.

Több módszer is létezik, amivel a "c:\dpsys\temp.tmp"-ből ki tudjuk olvasni a jelszót. Egyik módszer szerint, vázlatosan: 

  • "1.tmp" fájlban ez szerepel: "psexec.exe -u dp\script -p " (Itt vége a fájlnak, nincs Enter(!), viszont van egy szóköz a végén)
  • "2.tmp" fájlban: "-accepteula cmd.exe /c c:\dpsys\real_logon.bat %1 >>c:\dpsys\log.txt 2>&1"
  • "real_logon.bat" fájlban: A tényleges logon szkript parancsai.


A "logoncc.bat": 

rem A parancs kezdő részének átmeneti parancsfájlba másolása:
copy 1.tmp temp.bat
rem Jelszó hozzáfűzése:
type c:\dpsys\temp.tmp >>temp.bat
rem A parancs második részének hozzáfűzése:
type c:\dpsys\2.tmp >>temp.bat
rem A kész parancsfájl meghívása:
call temp.bat %1
rem A feleslegessé vált parancsfájl törlése:
del temp.bat

A psexec.exe segítségével érjük el, hogy a logon szkript (real_logon.bat) a "scriptgroup" csoport, "script" felhasználójával fusson le, akinek lokális rendszergazdai jogai vannak és eléri a szerveren lévő megosztást is. A "temp.bat" a végén ezt a parancsot futtatja:
psexec.exe -u dp\script -p jelszo -accepteula cmd.exe /c c:\dpsys\real_logon.bat %1 >>c:\dpsys\log.txt 2>&1
A "dp\script" a domain "script" nevű felhasználója. A "jelszo" itt a startup szkript által "lepakolt" jelszó. A végén a kimenet itt is átirányításra kerül.   
Itt viszont már elég sok a buktató. Az "-accepteula" kapcsoló nélkül nem fut a dolog, mert a psexec láthatatlan felugró ablakokat dobál, a licensz elfogadására. A "cmd.exe /c" nélkül nem mindig fut, ha pl. UNC útvonalat használunk a real_logon.bat-hoz. A "%userprofile%" pedig azért kerül paraméterként átadásra, mert ha más felhasználói fiók alatt futtatjuk a scriptet, akkor a szkripten belül használt %userprofile% változó nem az eredeti felhasználó fiókjára fog mutatni, hanem a "script" felhasználó fiókjára. Így viszont még elmenthetjük az "eredeti" profil útvonalát.
A %userprofile% nem véletlenül van zárójelek között, enélkül ugyanis nem 1 darab paraméterként mennének át a szóközt is tartalmazó útvonalak. Még egy buktató lehet a magában a .bat fájlban is. Ha az átadott paraméterre %1-el hivatkozunk, akkor az nyitó és záró zárójeleket is tartalmazni fog. Egy kis trükkel elhagyhatjuk ezeket a zárójeleket, mégpedig a %~1 hivatkozás használatával.

3 komment

A bejegyzés trackback címe:

https://rendszergazda-naploja.blog.hu/api/trackback/id/tr971400133

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Blaise(R) 2010.01.13. 16:56:07

Jó leírás, megtudtam pár hasznos dolgot belőle.
Viszont annyi szépséghibája van ennek a megoldásnak, hogy hiába adod át paraméterben a jelszót, így is könnyen megszerezhető. Majdnem ugyanolyan mintha magában a scriptben lenne.

Hegedűs_Gábor 2010.01.13. 17:00:48

Köszi. Arra gondoltál, hogy megnézi a Group Policy-ban? Vagy valami másra? Elfogadok tanácsot is. :)

Hegedűs_Gábor 2010.02.11. 19:18:20

Köszi. Javítottam a hibát.
süti beállítások módosítása