A bwin Európa egyik legnagyobb online fogadási oldalt üzemeltető cége. Napi 250.000 aktív felhasználót és 19 millió fogadást szolgálnak ki naponta, szóval kell a teljesítmény. A cikk bemutatja a kiszolgáló architektúrát, és azt, hogy utóbbi öt évben hogy sikerült másodpercenkét 12.000 tranzakció kiszolgálásától eljutni ennek a százszorosáig.

How bwin is using SQL Server 2016 In-Memory OLTP to achieve unprecedented performance and scale

A .NET Core programok adatbázis kapcsolódási lehetőségeinek a könyvtára ez a cikk. A következő technológiák kerülnek szóba, egész jó kis felsorolás:

EntityFramework Core (EF Core), Dapper, Microsoft SQL Server, SQLite, PostgreSQL, MySQL, Microsoft SQL Server Compact Edition, DB2, Oracle, Azure DocumentDB, MongoDB, RavenDB, Redis, Apache Cassandra, CouchBase, CouchDB, Neo4j, RethinkDB, Lucene.NET, OLE DB.

És a cikk: .NET Core Data Access

Az Azure Functions-ról korábban már volt szó. Ebből cikkből kiberül, hogy tudunk Azure Function-t github kódtárból telepíteni, és hogy tudunk ilyen a Slack-ből közvetlenül hívni.

Hey Slack, where’s my flight?

A Docker Swarm segítségével Docker kiszolgálókat lehet becsomagolni egy Docker kiszolgálóba.

Step by step: Scale ASP.NET Core with Docker Swarm

Az előfizetésünk egyszerű, mint a bot: 300.000 Ft-ért egy éven át az összes tanfolyamunkon résztvehet egy fő.

Hogyan lehetséges ez a gazdasági csoda?

Úgy, hogy a félmilliós tanfolyamokat a többszázezer forintos, hivatalos nemzetközi tankönyvcsomagok tették olyan drágává. Azok a tankönyvcsomagok, amelyeket sosem használtunk a tanfolyamokon. Akik jártak nálunk Ethical Hacking vagy fejlesztői vagy rendszergazdai tanfolyamon, tudják, hogy hogyan megy az oktatás: 1200 oldalas tankönyvek olvasgatására semennyi idő sincs. Petya, Tamás, Gábor még sosem nyúlt a tankönycsomaghoz oktatás közben, mert vagy együtt hekkelünk, vagy olvasgatunk. Vagy-vagy!

Na ezeket a többszázezer forintos tankönyveket dobtuk ki. Többé nem kell kisteherautóval jönni tanfolyamra, cserébe   megvalósíthatóvá vált az előfizetéses konstrukció: évente egyszer fizet, mindent vihet!

Szólj az informatikai vezetőnek, hogy tudjon róla: felvirradt a költséghatékony oktatás napja!

Az MS ingyenes, nyílt forráskódú, multiplatformos kódszerkesztője sokféle módon és sokfelé bővíthatő. Itt van néhány példa:

Build an Amazing HTML Editor Using Visual Studio Code

Build an Amazing Markdown Editor Using Visual Studio Code and Pandoc

Visual Studio Code Jumpstart for Node.js Developers

Using Visual Studio Code with a Raspberry Pi (Raspbian)

Nos, akinek rendelkezésre áll a Reflections és a dinamikus kódgenerálás, az bizony nagy eszközök birtokába kerül. És még mondja valaki, hogy a Reflections lassú :)

High performance field clobbering

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"

Rengeteg érdekes és erős érv van akörül, hogy ha Wep API-t fejlesztünk, a fejlődés egyes verzióit hogyan érdemes kezelni. Ha pedig előkerül a RESTful jelző, az egész még bonyolultabbá válik. Szokásosan remek cikk, jó linkekkel, és egy könyvtárral, aminek a segítségével kényelmes lehetőséget kapunk a kezünkbe.

ASP.NET Core RESTful Web API versioning made easy

Összefoglalás és linkgyűjtemény a JavaScript memóriakezeléséről, a szemétgyűjtő működéséről, és néhány tipikus hibáról.

Garbage Collection and Memory Management in JavaScript