Egy domaines környezetben levő kliens gépekhez tartozó lokális admin userek kezelése mindig fejfájást okoz. A beállítási lehetőségek nagyban függenek a cég policyjától.

• Van, aki alapból nem enged lokális usert létrehozni.
• Van, akinél lehet lokálisan felhasználó a gépeken, de az nem lehet az Administrators csoportban
• stb (ez a legegyszerűbb :) )

Korábbi Windows Server verzióknál létezett a Restricted Groups, amivel hellyel-közzel lehetett valamilyen szinten a csoporttagságokat menedzselni. Később (Windows 2008) felváltotta a Group Policy Preferences-nél megadható beállítás. 

Amikor itt létrehoztunk egy felhasználót - akit később ugyanezen a beállításon keresztül a lokális adminisztrátorok közé be is rakhattunk - és megadtuk a jelszavát is, a mentésnél figyelmeztetett minket a rendszer, hogy ez bizony a csoportházirendnél lesz elmentve, amit bárki egy tallózással megtalálhat, és ki is olvashatja az itt megadott jelszót.

Ez persze nem azt jelenti, hogy Plain Text lenne a mentett jelszó, azonban mindig van a cégnél ügyesebb júzer, aki képes megfejteni különböző, innen-onnan beszerezhető eszközök, netes leírások, videók segítségével ezeket a "titkos" bejegyzéseket. Valahogy így néz ki a létrejött állomány (ez persze függ a Preferences-ben megadott beállításoktól):

Ha szerettük és használtuk ezt a beállítást, akkor Windows Server 2016-ban igen meg fogunk lepődni, hiszen a felhasználó létrehozása, a csoporttagság, az update működik, viszont a jelszó mező "szürke", azaz itt már nem lehet megadni az értékét, így nem is lesz elmentve az előbb említett kiolvasható módon.

Nos, mi lesz így a megoldás? Lehetőleg úgy, hogy az eddigi bakikba se essünk bele, és nagyon szkriptelgetni se kelljen a cél érdekében.

A technológia nem új, gyakorlatilag egy 2015. júniusában publikált (de ugye eddig "sosem" kellett) lehetőségről lesz szó a továbbiakban. A megoldás a Microsoft LAPS, azaz a Local Administrator Password Management nevet kapta. Alapjában véve a built-in Administrator fiókra lett kitalálva, de valójában bármilyen (természetesen lokális) userre, így akár nem admin joggal rendelkezőkre is működőképes lehet.

Nézzünk meg néhány lépésen keresztül az implementálást és a használatot.

1. Töltsük le a Microsoft LAPS-ot

https://www.microsoft.com/en-us/download/details.aspx?id=46899

Találunk 32 és 64 bites verziókat is, van hozzá Guide is (ami itt-ott kicsit bután is fogalmaz), illetve megtalálható az oldalon a követelmény is. A cikk írásának pillanatában a támogatott OS résznél nem volt még ott a Windows 10 / Windows Server 2016 páros, pont ezért demóztam ezeken a verziókon, hogy lássuk: MŰKÖDIK! :) 

2. Telepítés

Az üzemeltetői tanfolyamomon (http://netacademia.hu/winserad) az első alapkövetelmény az szokott lenni, hogy mindent, amit csak lehet kliens oldalról oldjunk meg úgy, hogy egyszerű mezei gyenge júzerrel vagyunk bejelentkezve, amihez kell magasabb jogosultság, azt meg a megfelelő paraméterekkel indítjuk. Így én egy Windows 10-es (természetesen tartományba léptetett) klienssel demóztam.

Ha már lúd, legyen kövér, válasszuk a teljes telepítést.

Kapunk GPO Extension-t, amire egyébként is szükségünk lesz majd azoknál a gépeknél, amiket szeretnénk a LAPS segítségével menedzselni, egy grafikus felületet a jelszó kiolvasásához (Fat client UI), egy PowerShell modult, benne néhány commandlettel, illetve egy GPO Editor templétet, ez valójában az az ADMX fájl, ami majd szükséges lesz a számítógépekhez tartozó GPO-hoz.

3. Menedzselt kliensekre való telepítés

Bizony kénytelenek leszünk feltelepíteni azokra a kliensekre is a LAPS-ot, aminél a jelszavakat szeretnénk menedzselni. Két lehetőségünk is van erre:

• A letöltött MSI állományt telepítjük (SCCM, login script, GPO, kézi telepítés, stb)
• Egy gépre telepítjük a csomagot, és kimásoljuk a Program Files\AdmPwd\CSE könyvtárból az AdmPwd.dll állományt, amit az összes gépen a regsvr32.exe parancs segítségével be is regisztrálunk.

4. AD séma bővítése

Mivel új attribútumokat fogunk kezelni (ms-Mcs-AdmPwd, és ms-Mcs-AdmPwdExpirationTime), ezért kénytelenek leszünk az AD sémáját bővíteni. A szükséges attribútumok még a Windows Server 2016-ban sincsenek benne. Ettől nem kell megijednünk, a telepített LAPS mindent tartalmaz hozzá néhány PowerShell utasítás képében.

Lépések:

• Import-Module AdmPws.PS
  • Hogy elkerüljünk néhány kellemetlen órát kereséssel, hajtépéssel, hogy miért nem működik (saját tapasztalat), ez bizony Case Sensitive! :)
• Update-AdmPwdADSchema
  • Ha megvolt a megfelelő jogosultság, és sikerült lefuttatni, akkor valami hasonló üzenet fogad minket:

5. "Néhány" jogosultság beállítása

• Létrehozunk egy OU-t (az én példámban LAPS), amibe azokat a gépeket tesszük, amelyekre a LAPS-t szeretnénk alkalmazni. Valamint csinálunk egy Security Group-ot is hozzá (nálam ez a laps nevű csoport) Ebbe kerülnek majd azok a felhasználók (Desktop Adminok, Help Desk felhasználók, stb), akik majd az éppen aktuális jelszót kiolvashatják.
• Az OU Security beállításainál ennek a csoportnak adunk egy Allow engedélyt az All extended rights Permission-höz. Erre azért van szükség, hogy a csoport tagjai ki tudják majd olvasni a jelszó attribútum tartalmát.

• A beállítás helyességéről egyébként egy PWS utasítással meg is győződhetünk: Find-AdmPwdExtendedRights -Identity:LAPS | ft
  • Az -Identity paraméterben természetesen a saját létrehozott OU-nk nevét kell megadnunk.
  • Ha az ExtendedRightHolders oszlopban megjelenik a csoportunk (laps), akkor helyesen állítottuk be az előbb az engedélyeket.

• A gépeknek szükségük lesz majd arra a Permission-re, amivel a GPO-ban megadott lokális felhasználók jelszavait tudják saját maguk módosítani, így azt is meg kell adnunk erre az OU-ra: Set-AdmPwdComputerSelfPermission -OrgUnit LAPS

• Akár lehet is ellenőrizni grafikusan is, néhány Special Permission bejegyzés megjelent a SELF-hez az OU Security ACL-jében:

• És persze szükségünk lesz az imént létrehozott Security Group (laps) hozzáadásához is, hiszen nekik ki kéne olvasniuk a tárolt jelszót. Sőt, írási engedélyre is kell majd, így két utasítást kell futtatnunk. (Több csoport is megadható az AllowedPrincipals-nél, vesszővel elválasztva egymástól):
  • Set-AdmPwdReadPasswordPermission -OrgUnit LAPS -AllowedPrincipals btdomain\laps
  • Set-AdmPwdResetPasswordPermission -OrgUnit LAPS -AllowedPrincipals btdomain\laps

• Ennek az eredményét is le lehet ellenőrizni az OU Security ACL-eknél:

6. GPO készítése a menedzselt gépek számára

A LAPS telepítőjénél említettem, hogy kapunk egy ADMX állományt, amivel csoportházirendből megadhatók a szükséges beállítások. Hozzunk létre egy GPO-t, rendeljük a LAPS OU-hoz, majd nézzük meg ezeket az opciókat az Computer Configuration\Policies\Administrative Templates\LAPS résznél.

Az opciók, amiket kapunk a következők:

• Password Settings
  • Gyakorlatilag a felhasználó jelszava egy automatikusan generált érték lesz. A generálás szabályait lényegében itt adhatjuk meg. Komplexitás, jelszó hossza, maximális élettartam. 
  • A default értékek:
    • Nagybetű + kisbetű + szám + speciális karakter
    • 14 karakter hosszú jelszó
    • 30 naponta újragenerálva
• Name of administrator account to manage
  • Ha a beépített Administrator fiók jelszavát szeretnénk beállítani, akkor itt nem kell megadni semmit. 
  • Ha másik lokális user jelszavát szeretnénk módosítani (amit viszont létre kell hozni előbb, pl. a Preferences résznél levő Local users and Groups opcióval), akkor azt viszont itt megadhatjuk.

• Do not allow password expiration time longer than required by policy
  • Ha ezt engedélyezzük, akkor a Password Settings résznél megadott maximális élethossz lejárta esetén rögtön megváltozik a jelszó, nem tudjuk ezt meghosszabbítani.
• Enable local admin password management
  • Gyakorlatilag a legfontosabb beállítás, ez kell ahhoz, hogy az egész policy érvényre tudjon jutni.

7. Kliensek menedzselés

Gyakorlatilag már csak az maradt, hogy a GPO-ban megadott beállításokhoz mérten megadjuk azokat a számítógépeket, amelyekre az opciókat érvényesíteni kívánjuk. A létrehozott szervezeti egységbe mozgassuk bele ezeket a Computer objektumokat, és a csoportházirend frissítése / frissülése után máris kipróbálhatjuk a helyes működést.

Ellenőrizzük a generált jelszót! Ehhez nyissuk meg az adott Computer objektum tulajdonságait, és az Attribute Editor fülön görgessünk le a két új attribútumhoz:

• ms-Mcs-AdmPwd
  • Igen, ez lesz a jelszó, ezt kell majd használnunk.
  • Igen, ez plain text.
  • És igen, ezt csak akkor látjuk, ha tagjai vagyunk annak a csoportnak, akinek az 5. lépésnél megadtuj a jogosultságot.
• ms-Mcs-AdmPwdExpirationTime
  • Ez fogja megmutatni nekünk, hogy mikor jár lesz a jelszó. Gyakorlatilag 1601. január 1. 0 óra 0 perctől számol. Ha "emberibb" módon szeretnénk látni, akkor adjuk meg ezt az értéket a w32tm utasításnak: w32tm /ntte 131256693641732955
  • Az érték amúgy mindig GMT-ben lesz, ezt ne felejtsük el!

• Ha esetleg telepítettük a gépünkre a Fat client UI-t, akkor könyebb dolgunk van. A Start menüből LAPS UI néven el is érjük az alkalmazást, ahogy megadjuk (Browse sajnos nincs, így be kell gépelnünk) azt a gépnevet, amiből szeretnénk kiolvasni az aktuális értékeket (Jelszó, lejárat), illetve meg is adhatunk újabb lejárati időpontot (hacsak nem tiltottuk ezt le az előző GPO beállításnál). A Set gomb megnyomása egyébként automatikusan újragenerálja a jelszót is (ami majd a következő GPO frissítésnél el is jut a klienshez). A Password mező tartalmát természetesen itt is csak az olvashatja, aki tagja annak a bizonyos csoportnak, akinek megadtuk az olvasási jogosultságot.

• Ha inkább PowerShellt használnánk a lekérdezésre, arra is van lehetőség:
  • Get-AdmPwdPassword -Computername BTWIN10

• És természetesen a jelszó újragenerálására is van lehetőség PowerShellből:
  • Reset-AdmPwdPassword -ComputerName BTWIN10 -WhenEffective "08.11.2016 16:00"