Archívum

Szerzői archívum

Out-of-office on Distribution Group

július 24, 2017 4 hozzászólás

Még régebben feltettek nekem egy kérdést, amit érdemesnek tartok egy eszmefuttatásra: miként lehet egy disztribúciós csoporton beállítani automatikus választ?

A kolléga eredeti ötlete az volt, hogy a levél-tippet használja fel (felhasználóknál a beállítás Fájl / Beállítások / Levelek / Email tippek szekció). Nos, az Outlook 2010-től használható email-tipp jellemzően* belső címzett esetén jelenik meg, s arra használható, hogy a feladó kiválasztása után, de még a levél elküldése előtt értesüljünk a címzett állapotáról. Pontosabban, ha az illetőnél be van kapcsolva a “Házon/magán kívül” állapot, akkor az ott megadott szöveg lesz látható még a levél elküldése előtt, illetve, ha tagja valamilyen csoportnak, akkor a csoporton beállított MailTip is látszik.

(* bizonyos, jól meghatározott esetekben külső címzett is, pl. érzékeny információ küldésekor).

Az eredeti kérdésre a választ több módon oldhatjuk meg, példaként 1-1 szerver-oldali, illetve fiók-szinten megvalósított ötletet írok, a teljesség/mélység igénye nélkül (no meg 3rd party megoldások kihagyásával).

A Transport Rule estén a szerveren hozunk létre egy szabályt, de annak formátuma (illetve az SMTP-kódja) nagyon hasonló a hibaüzenetekhez, még akkor is, ha saját hibaüzenetet teszünk be (most maradjunk az egyszerű rgazda szinten), ezért ezt – főleg kezdőknek – nem javaslom.

Fiók-oldalon sokkal elegánsabb megoldási lehetőségünk van, erre például egy dedikált fiókot hoznék létre – ő már tud OoO üzenettel válaszolni (ne feledjük, ez feladónként napi 1 üzenetet eredményez), az általa kapott leveleket pedig automatikusan továbbítani a csoportnak (akár úgy, hogy neki lokálisan is maradjon egy példány, naplózási céllal).

Sokan felkaphatják a fejüket, hogy de ők láttak az elosztási csoportokon olyan pipát, ami OoO-val kapcsolatos. Igen, a régebbi Exchange-ken az Advanced fülön grafikusan ki volt vezetve egy ilyen pipalehetőség („Send Out-of-office message to originator”), de ez csak arra való, hogy a tagok bármelyikén beállított OoO üzeneteket az eredeti feladónak küldje, ne a csoportnak szórja szét. Ha ez megfelelőnek tűnik az eredeti probléma megoldására, számítsunk rá, hogy nem biztos, hogy mindenki egységesen állítja be az ilyen üzeneteket, illetve, amennyiben a csoportból többen beállítottak maguknak saját OoO üzenetet, a feladó mindenkitől megkapja.

Az újabb Exchange-ken a grafikus kivezetés helyét a PS vette át:

Get-DistributionGroup * | Set-DistributionGroup -SendOofMessageToOriginatorEnabled:$true

Amennyiben még tovább bonyolítjuk a kérdést, s szeretnénk képet betenni: nos, ezt nem támogatja az OoO. Ha mégsem bírjuk ki, akkor Outlook segítségével létrehozunk egy szabályt, ami egy olyan sablonra mutat, amelyik megfelelően elő van készítve – de ez már tényleg túlmutat a cikk keretein 🙂

Kategóriák:Exchange Címke: ,

Windows 10 Fall Creators Update vs WannaCry & Petya

június 28, 2017 4 hozzászólás

Aki az IT világában él (sőt, akinek van számítógépe), biztosan tud a múlt havi WannaCry-járványról, ennek ráadásaként tegnap aktiválódott a Petya zsarolóvírus is. Mindkettő az SMB1 protokoll egyik hibáját használja ki, s ennek lassú kihalása okán kapták a már nem támogatott rendszerek is a javítófoltokat.

Ugyanakkor lassan, de biztosan elkezdtek csepegni infók a Win10 idei őszi frissítéséről. Az indító gondolathoz kapcsolódik az egyik friss és fontos információ is, aminek sokan nem fognak örülni: az említett frissítéstől kezdve megszűnik az SMB1, magyarul a Windows 2003 és régebbi rendszerekkel való kapcsolattartási lehetőség.

Tudom, sokan nem értik, hogy miért foglalkozom ilyen ősrégi rendszerekkel. Nos, egyszerűen azért, mert a magyar viszonyokat ismerve, nem egy cégnél található még ilyen oprendszer. Félig haladva a korral, vannak már Win10-es munkaállomások, de a szerver-csere még nem történt meg. Sőt, továbbmegyek, azok a régi nyomtatók/készülékek, melyek csak ezt a régi protokollt ismerik/használják, szintén ki fognak esni a játékból.

Természetesen kell haladni a korral. Hiszen mint említettem, a WannaCry/Petya is erre épül, ennek a sebezhetőségét használta ki. Általános (és kiterjesztett) támogatása is lejárt. Viszont hiába voltak a különböző fórumokon, médiákon elhangzott figyelmeztetések, áttérésre figyelmeztető oktató-videók, felhívások, sajnos továbbra is rengetegen vannak régi rendszerekkel – részben anyagi, részben más okok miatt. Érdemes az ottani rendszergazdáknak/informatikusoknak ismételten jelezni a vezetőség felé, hogy a kockázat folyamatosan nő…

ps. eredetileg egy hosszabb cikknek készült volna, de Petya áthúzta a tervem. Hogy mégse maradjon senki szakmai tartalom nélkül, egy elég jól összeállított MS-cikket linkelek be az SMB protokollokról.

Törölhetetlen OU

június 7, 2017 Hozzászólás

Adott helyen egy SBS2011-ről tértek át Windows Server 2012 R2 Foundation-re. A migrálás rendben lezajlott, viszont utána az AD-ban is rendet szerettek volna tenni, magyarul az SBS által létrehozott hierarchiát egyszerűsíteni.

Az útmutatást ekkor váltotta fel a gyakorlati segítségnyújtás: volt két szervezeti egység (OU), amit semmilyen módon nem tudtak törölni (a törlési opció nem is volt felajánlva a helyi menüben): az SBSComputers és SBSUsers. Ellenőrizték, hogy nincs betéve a „törlés-gátló” pipa, de a törlést továbbra sem tudták végrehajtani.

A megoldás megértéséhez kicsit vissza kell menjünk időben. A Windows 2003-ban (és 2003-as tartományi szinttől) jelent meg az a lehetőség, hogy a számítógép- és felhasználó-fiókok alapértelmezett helyét (Computers, illetve Users konténer) meg tudjuk változtatni (RedirCmp, RedirUsr). Az átirányítás során bekapcsolásra kerül a cél szervezeti egységeken az IsCriticalSystemObject attribútum is, ennek TRUE értéke okozza a törölhetetlenséget és az átnevezhetetlenséget. Az SBS ezt előszeretettel alkalmazza, az ominózus OU-kba irányítva a megfelelő fiókokat. (Csak egy apró megjegyzés, ha valaki nem SBS-en hajtja végre: a művelet végrehajtásához a PDC emulátor FSMO-szerepkörű géphez fog fordulni).

Igen ám, de miként tudjuk ellenőrizni, hogy hova is vannak irányítva? Nos, 2003-ban csak az ADSIEdit-el tudtuk megnézni, 2008-tól kezdve az „Advanced Features” bekapcsolásával az ADUC-ban is a tartomány tulajdonságainál, a WellKnownObjects attribútumban. Ez tartalmazza mindkét értéket (sőt, még mást is), számítógépek esetén a B:32:AA31 kezdetű, felhasználók esetén B:32:A9D1 kezdetű hexaérték után.

De már ez is a múlt. Windows Server 2008 R2 óta már Powershell segítségével is lekérdezhető:

Get-ADDomain | select ComputersContainer

Get-ADDomain | select UsersContainer

Amint megszüntettük a lokkolást (máshova irányítottuk), egyből megjelent a törlési lehetőség.

RDP tanúsítvány

május 24, 2017 Hozzászólás

Egy régi félkész cikket próbálok befejezni… A témát réges-rég is említettem, minimálisan, de azóta rengeteg víz lefolyt a Dunán 🙂

Nos, akkor kezdjük átismételni, mi történik, amikor RDP-vel csatlakozni próbálunk egy géphez (leírás, értékek). Első körben van egy biztonsági ellenőrzés, amelynek során a rendszer ellenőrzi a registry-ben, hogy van-e már mentett kapcsolatunk a távoli kiszolgálóhoz, s abban mit engedélyeztünk (HKCU\Software\Microsoft\Terminal Server Client\LocalDevices\<Név> – ha csak most engedélyezzük az elsőt, létrehozza a LocalDevices kulcsot is). Ennek fényében kapunk egy sárga, vagy, ha “online” csatlakozunk (nem RDP-állomány), akkor a változatosság kedvéért kék ablakot (hogy még bonyolultabb legyen, a kék ablak sem mindig pattan elénk, csak az 1, 2, 32 értékek hiányában):

 

A kék ablak (ha nem RDP-állományból, esetleg ha a LocalDevices értéke 12 (1100) – amennyiben betesszük a pipát, akkor az érték 77 (0100 1101) lesz):

Továbbjutva az első akadályon, máris egy másik registry-kulcs által szabályozott területre érünk. Ekkor a rendszer ellenőrzi a HKCU\Software\Microsoft\Terminal Server Client\Servers kulcs tartalmát, s amennyiben van, úgy alapértelmezés szerint felajánlja az itt található UsernameHint felhasználót s kéri a jelszavát. Amennyiben nincs, egy választó-ablakot dob fel, az aktuális felhasználónak kérve a jelszavát vagy lehetőséget adva másik felhasználónév/jelszó megadására. Ha van mentett jelszavunk, akkor természetesen kiolvastathatjuk a Hitelesítőadat-kezelőből is. Sikeres hitelesítés esetén megérkeztünk az aktuális témához, a második sárga ablakhoz:

Ennek megfejtése: szintén az előbb említett registry-kulcsban előfordulhat egy tanúsítvány-kivonat (hash) – ha ez érvényes, azaz megegyezik a gépen tárolt tanúsítvány lenyomatával, észrevétlenül csatlakozunk a kiszolgálóhoz – ellenkező esetben jön elő a jelzett, második sárga ablak. Ha utánajárunk az alapértelmezett, önaláírt tanúsítványnak, kiderül, hogy a számítógép tanúsítvány-tároló Remote Desktop mappájában található, így könnyen gondolhatnánk, hogy azt lecserélve hátradőlhetünk – de ez nem így van. Elkeseredésre azért nincs ok, mert azért a megoldás egyszerű: miután a “jó” tanúsítványt betesszük a számítógép tanúsítvány-tároló Personal mappájába , le kell cseréljük a WMI-ban tárolt tanúsítvány-kivonat értékét (szaknyelven a root\cimv2\TerminalServices névtér Win32_TSGeneralSetting osztály beállításaiban a SSLCertificateSHA1Hash értékét kell cserélni ).  Visszalépni nem lehet (de minek is kellene?).

Biztos, ami biztos, előbb lekérdezzük a jelenlegi értéket:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash

Ugyanezt az eredményt kell találjuk a grafikus felületen megnyitott tanúsítvány ujjlenyomat-értékében is (“Thumbprint”).

Szintén pl. a grafikus felület segítségével kiderítjük a számítógép “rendes” tanúsítványának lenyomatát, majd a cseréhez a következő utasítást kell végrehajtani:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=”THUMBPRINT”

Vagy aki inkább Powershell-t használna (Set-WmiInstance helyett lehetne swmi, hasonlóan a Get-WmiObject helyett gwmi):

# Lekérdezzük a jelenlegi lenyomatot

$TSGeneralSetting = Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

# A számítógép tanúsítvány-tárából kiválasztjuk az SSL-tanúsítvány lenyomatát (ha több tanúsítványunk van, akkor ellenőrizzük a kapott eredményt)

$thumb = (gci -path cert:/LocalMachine/My | select -first 1).Thumbprint

# Beállítjuk az új értéket Set-WmiInstance -Path $TSGeneralSetting.__path -argument @{SSLCertificateSHA1Hash=”$thumb”}

Ezt tovább tudjuk fokozni, hogyha más néven csatlakoztunk, további adatok lesznek a sárga ablakon:

 

Ha viszont egy olyan kiszolgálóra csatlakozunk, amelyik nem támogatja az NLA-t (például alábbi esetben Windows 2003), akkor az alábbi ablakok jönnek:

 

Huhh, elég volt a sárga ablakokból. Uff.

BitLocker kulcsok házirendben szabályozva

április 19, 2017 Hozzászólás

Adott helyen felmerült a házirendből szabályozott BitLocker – pontosabban a visszaállítási kulcsok mentésének módja. Magyarul, nem szeretnénk azt, hogy ha bekapcsolják a titkosítást, akkor USB-kulcsra, állományba vagy nyomtatásra kerüljön a visszaállító kulcs, hanem az AD-t használjuk erre a célra. Ha nem régi rendszerekről van szó, aránylag kevés beállítást kell végrehajtanunk, hogy sikeresek legyünk:

  1. Computer Configuration\Administrative Templates\System\Trusted Platform Module Services alatt engedélyezzük a Turn on TPM backup to Active Directory Domain Services opciót
  2. Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption alatt eldöntjük, hogy melyik ágon megyünk tovább: adatlemezre (beépített vagy eltávolítható) vagy rendszerlemezre szeretnénk alkalmazni a titkosítást. Döntés után a Choose how BitLocker-protected fixed drives can be recovered opcióba lépve, engedélyezve és a benne található lehetőségeket beállítva mondhatni készen is vagyunk.

(Aki Vista/2008 rendszereken szeretné, vagy bővebb információt olvasna, részletesebb leírás itt található).

Van viszont egy kapcsoló, amire szerintem nincs eléggé felhíva a figyelem, s kissé megkavarhatja az egyszerű rendszergazdát. Arról van szó, hogy ha nem pipáljuk be a „Omit recovery options from the BitLocker setup wizard” opciót, akkor a BitLocker bekapcsolásakor feldobja a hagyományos ablakot, hogy hova akarjuk menteni a visszaállító kulcsot – emiatt nem lehetünk biztosak benne, hogy a gép megkapta-e a házirendet (amiben beállítottuk, hogy AD-ba kerüljön). Ezt tehát mindenképp bepipálnám.

Ha kiadtuk a titkosítási parancsot, egy újraindítást fog kérni, majd utána a

manage-bde -status c:

parancs segítségével tudjuk lekérdezni a titkosítás állapotát.

Természetesen, utólag is van lehetőségünk a Control Panel/Bitlocker Drive Encryption menü segítségével a kulcs megszokott mentésére (USB-kulcs, állomány vagy nyomtatás). Amennyiben az AD-ból akarjuk mégis elővarázsolni, két lépést érdemes tennünk: feltelepítjük az RSAT-ból a „BitLocker Password Recovery Viewer”-t, majd a szükséges .dll állományt regisztráljuk:

regsvr32.exe BdeAducExt.dll

A fentiek hatására az ADUC-ban meg fog jelenni egy BitLocker Recovery fül, ami tartalmazni fogja a kívánt kulcsot.

u.i. Figyeljünk arra, hogy amennyiben úgy állítottuk be (ahogy a józan ész diktálja), hogy titkosítás előtt ellenőrizze az AD-kapcsolatot, úgy nem járható út, hogy napközben bekapcsoljuk a titkosítást, de nem indítjuk újra a gépet – ha ugyanis a kolléga leállítja, majd hazaviszi az eszközét, s otthon bekapcsolja, az AD-kapcsolat hiányában nem történik meg a várt művelet. Természetesen következő alkalommal (már AD-kapcsolattal) ismét lehet kérni a BitLocker bekapcsolását, ekkor az új kulcs is bekerül a másik mellé.

Házirendek csak hordozható gépekre

március 20, 2017 1 hozzászólás

Adott helyen felmerült a kérdés, hogy miként lehet úgy kiszórni egy házirendet, hogy csak a hordozható eszközökre legyen érvényes.

Egyrészt természetesen maradhat a jól bevált módszer, amely szerint AD-csoportot hozunk létre, s csak arra érvényesítjük a házirendet (vagy fordítva, abba tesszük azokat a gépeket, amelyekre nem kell érvényesüljön, s „Apply group policy – Deny” opciót választunk). Ugyanakkor létezik „elegánsabb” módszer is, WMI-szűrő segítségével.

Nem fogok felsorolni minden lehetséges szűrést, ami alapján kétfelé tudjuk választani a gépeink, néhány ötletet adok csak:

1. a memória fizikai mérete alapján: tudjuk, hogy a hordozható eszközökbe SODIMM memória kerül, asztali társaikba pedig „normál” méretű DIMM. Előbbinek FormFactor értéke 12, így a szűrönk így néz ki:

Select * from Win32_PhysicalMemory WHERE (FormFactor = 12)

2. az akkumulátor jelenléte alapján (ha nincs, akkor értéke 0; bár mivel van, aki akku nélkül használja, fenntartással kezelném):

Select * from Win32_Battery WHERE (BatteryStatus <> 0)

3. ha tudjuk, hogy minden DMI adat ki van töltve (személy szerint igyekszem erre mindig figyelni), akkor a ház típusa (burkolat) alapján is lehet szűrni, az általában használt értékek itt vannak felsorolva (ebben az esetben természetesen granulárisabban tudunk szűrni):

Select * From Win32_SystemEnclosure Where ChassisTypes = “9”

p.s. régi kapcsolatommal, Tamással [Aida64 vezető fejlesztője] történt egyeztetésem kapcsán felmerült, hogy most már sok alaplap – főleg a Mini-ITX és Mini-STX kialakításúak –, valamint sok mini-PC is SO-DIMM foglalatos, így az első nem biztos, hogy teljes értékű megoldás. Viszont akinek a hálózatában ilyenek vannak, használhatja a többi (akár általam le nem írt) módszert 🙂

Hibakód szöveges értelmezése egy Win2016 ütemezett feladat kapcsán

február 1, 2017 3 hozzászólás

Többször szokták tőlem kérdezni (tanfolyamokon is), hogy mi a legegyszerűbb módja egy hibakód „visszafejtésének”, azaz a hozzá tartozó szöveges hibaüzenet kiderítésének. S itt természetesen nem a „well-known” kódokról beszélek (pl. 0x80070005 Access denied) :).

Mivel kétféle módon jelenhetnek meg a hibakódok, kezdem a decimális formátummal (előtagja 0n) – ugyanis első lépésben úgyis hexává (előtagja 0x, a másik formátum) alakítjuk, s innentől már ugyanaz a menet. Tehát mit kell tudnunk, ha mondjuk egy 2147944189 számú hibaüzenetet meglátunk?

A megoldáshoz vegyünk elő egy számológépet, ami tudja a két számrendszert (Windows-on a számológépet pl. „Programozó” módba kell állítani). Kiválasztjuk a hibakód számrendszerét (decimális vagy hexadecimális), beírjuk az ismert értéket, majd megnézzük azt hexadecimális formában. Amennyiben az első négy karakter „8007”, akkor rendben vagyunk, ú.n. „Win32 Status Code” lesz a megfejtés, innentől csak a második négy karakter lesz érdekes.

Következő lépésként a második négy karaktert kell visszalakítsuk decimálissá. Ehhez a számológépbe beírjuk hexa formátumban, majd kiolvassuk decimálisban. Utolsó lépésként lefuttatjuk az alábbi parancsot, s meg is van a keresett szöveges hibaüzenet:

net helpmsg decimális_szám

Mivel az operációs rendszer nyelvén kapjuk vissza az üzenetet, a honosítások nem biztos, hogy visszaadják az eredeti értelmezést, így javaslatom szerint ezt mindenképp egy angol nyelvű gépen tegyük meg (utána könnyebb rákeresni is) – s reménykedünk benne, hogy nem visz tévútra.

S hogy miért pont ezt a konkrét hibakódot hoztam fel? Egy számomra eddig ismeretlen jelenség miatt: egy Windows 2016-on szerettem volna ütemezett feladatot beállítani, hogy egy technikai felhasználó nevében fusson – s ekkor örvendeztetett meg a rendszer a fenti kóddal. A felhasználónak volt elég joga, nem volt letiltva, nem volt zárolva – az egyedüli „hibája” az volt, hogy azon a gépen nem volt profilja (hiszen soha nem lépett be rajta). Az eddigi Windows-okon ez nem volt gond, legelső futtatásnál létrejött a profil – itt az idő szűkössége miatt leggyorsabb megoldás az volt, hogy bejelentkeztem a fiókkal, utána már csont nélkül elfogadta az ütemezett feladat hozzárendelését is.