Vezetés-technikai gondolat

Nemrég szabadságon voltam (ezért tudtam végre hosszú idő után ismét írni), s bár nem volt teljes “rádiócsend” (kollégám szavaival élve), azt is igyekeztem egyirányúvá alakítani: igyekeztem kívülről szemlélni a csapatom működését. Ennek eredményeképp, amikor a szokásos “Na, milyen volt a szabi?” kérdések fogadtak, azt tudtam válaszolni, hogy “Tanulságos” 😀

Tanárként is rengeteg olyan dolgot tanultam, ami nem a szakmára, hanem az emberek kezelésére vonatkozik. Ezt anno az MCT (tréneri) képzéssel tovább erősítettem – viszont természetesen nem mindent lehet könyvekből, szimulációs gyakorlatokból megtanulni.

Az egyik érdekes dolog, amit eddig nem használtam ki, az a kívülről történő megfigyelés. Mint vezető (s nem, mint főnök), nap mint nap együtt dolgozunk a srácokkal, tényleg együtt húzzuk a szekeret. Pont ezért, nem mindig látjuk távolról a képet. Sőt, továbbmegyek, néha a főnök (aki a szekéren ül) jobban érzékeli, hogy mikor (s jó esetben talán azt is, hogy miért) döccen egyet, hol kellene megolajozni. Számomra a szabi időszaka adott arra alkalmat, hogy ezt kívülállóként megfigyeljem, hogy a kijelölt helyettes(ek) mennyire értek meg a feladatra, miként tudják hatékonyan tovább vinni a lendületet – illetve egy visszajelzés részemre is, hogy hol lehetne még javítani. Ha belátjuk, hogy néha – akár részlegesen is – szükséges egy “újratervezés”, elismerjük, hogy nem vagyunk tökéletesek – még 🙂

SMTP on Windows Server 2022

Végre ismét tudok szakítani időt az írásra… Kezdetnek egy rövid téma, a Windows Server 2022-n található SMTP szolgáltatás.

Főleg amiatt, hogy O365-ben szigorítottak az email-küldési szabályokon (már nem lehet egyszerű SMTP-hitelesítést használni, helyette OAuth2 hitelesítést kell használni), helyenként még szükséges egy helyi STMP-relay használata. Igen ám, de mi van, ha a korral haladva Windows 2022 van a hálózatban? Nos, akkor viszont fel kell készülni egy “apró” problémára: a jobb klikk, tulajdonság után egy hibaüzenetet kapunk:

A neten rákeresve, természetesen találunk mindenféle próbálkozást az életre lehelésre, de a kiinduló az, hogy (bár sokan nem tudják), elvileg már 2015-ben “Deprecated” állapotba került az SMTP, a Windows 2003 EOL-jával:

“The IIS SMTP Virtual Server Component that is mentioned in this article is part of IIS 6.0, the support for which has ended with the support of Windows Server 2003. To relay emails to Office 365, use one of the supported versions of Exchange Server.” (cikk)

A gyakorlatban még be tudjuk izzítani, a MetaBase.xml állomány javításával (akár kétféle módon is, az alábbi leírásban a 4. pontnál van az “elágazás”):

1. Leállítjuk az Simple Mail Transfer Protocol (SMTP) szolgáltatást
   
2. Leállítjuk az IIS Admin Service szolgáltatást
   
3. Módosítjuk az C:\Windows\System32\inetsrv\MetaBase.xml állományt:
   
4. a. Keressük meg az “<IIsSmtpServer Location =”/LM/SmtpSvc” bekezdést, ürítsük a RelayIpList értékét (legyen RelayIpList=””) sort, majd mentsük
   

   b. Keressük meg az “<IIsSmtpServer Location =”/LM/SmtpSvc/1″ bekezdést, s (abc-sorrendben vannak a beállítások) szúrjuk be a RelayIpList=”” sort, majd mentsük
   

5. Indítsuk el az IIS Admin Service szolgáltatást
   
6. Indítsuk el az Simple Mail Transfer Protocol (SMTP) szolgáltatást, s tegyük át automatikusan indulóra
   

Ezek után már “szokásos” módon tudjuk használni az SMTP-szolgáltatást, de ne feledjük, hogy ez csak kerülő-megoldás, törekedjünk arra, hogy a régi eszközöket/programokat, amelyek miatt ezt bevezettük, mielőbb kivezessük a hálózatunkból.

Core server, FiberChannel és MPIO

Adott helyen abban kérték a segítségem, hogy egy három tagból álló Hyper-V fürt egyik kiszolgálóján valami nem kerek. A jelenség szerint a ClusterStorage-ba felcsatolt köteten belül nem látszanak a mappák, de ha adott VM-et oda akarunk mozgatni, akkor megjelenik a könyvtár, látszólag némi adattal, de a LiveMigration hibát dob.

A nyomozás során jó pár nehezítés jött szembe, hiszen a vason egy ingyenes (Core) Hyper-V futott, tehát a grafikus eszközöket (lokálisan) nem tudtam használni. Szerencsére annyi előnyöm volt, hogy tartományba léptetett gépről lévén szó, távolról a Server Manager segítségével pár dolgot grafikusan is meg tudtam mutatni a kollégáknak.

Azt elég hamar meg tudtuk nézni, hogy optikán (Fibre Channel) van összekötve a tárolóval, de a kiosztott LUN-ok többszörösen jelentek meg a lemezek között. Ilyenkor természetesen az MPIO a következő lépés, nos, azt is meg tudtuk nézni távolról, hogy telepítve van (de természetesen itt is lehetett volna a Powershell). A következő kérdés viszont az MPIO beállítása volt, ami már egy érdekesebb történet, hiszen grafikus felületen pár klikk, ebben az esetben viszont vagy a Powershell megfelelő utasításai, vagy egy “régi”, parancs-sori eszköz segíthet: mpclaim. Ennek is rengeteg kapcsolója van; amivel érdemes kezdeni (s esetünkben ez már segített is), az

mpclaim -r -i -a “”

Ezek után már szépen látszottak a lemezek, sőt, a fürtben is teljes tagú szereplőként tudott részt venni.

Power plan on server

Most egy banális, de annál nagyobb súlyú tervezési hiba miatt lett a piros gomb megnyomva.

Adva van egy cég, a szokásos két tartományvezérlővel, viszont észlelték, hogy időnként a két DC nem elérhető, leállított státuszban van. Ilyenkor mindig elindították, de egy ideig nem keresték a hiba okát (a miértet nem firtattam…). Amikor végül megelégelték, s segítséget kértek, kiderült a turpiság.

Első körben nézzük az eseménynaplót:

Kikerekedett a szemem. Nocsak. Egy kiszolgáló, ráadásul DC, elmegy aludni – ki engedte meg neki? Feltételezzük első körben, hogy nem egy spéci driver küldte aludni, hanem maga a rendszer, nézzük a “Power options” beállításokat. “High performance” opció volt kiválasztva, viszont egy érdekes sorral. Egy hagyományos, normális kiszolgálón ez így néz ki:

Az adott kiszolgálón viszont így:

Ezzel két probléma is van:

1. szerveren alapból nem elérhető

2. hiába módosítottam kézzel Never-re, egy idő után visszaállt 1h-ra – tehát itt valószínűleg GPO-ból van szabályozva.

Nézzük akkor a GPO-kat, mi vonatkozik a DC-kre. Sajnos kiderült, hogy a legrosszabb verzió, a Default Domain Policy lett piszkálva:

Ezzel szintén két probléma van:

1. MS-ajánlás, hogy nem szoktuk módosítani a Default policy-ket: volt már olyan segítségkérésem, hogy eltűntek/megsérültek az alap-GPO-k, s vissza kellett állítani őket nulláról, ilyenkor természetesen a változtatások elvesznek (jellemzően nincs dokumentálva, hogy milyen módosítások kerültek még bele).

2. ha már módosítjuk, akkor gondoljuk végig és teszteljük. Ha tényleg kell a teljes tartományra, attól még meg lehet úgy oldani (WMI; GPO-filtering – akár csoporttagság, akár Deny apply; GPO-linkelés csak adott OU-khoz, s még lehetne sorolni az opciókat), hogy kiszolgálókra (s főleg DC-kre!) ne legyen érvényes…

Intermediate CA fontossága

Adott cégnél felmerült az a probléma, hogy a levelező-kliens egy tanúsítvánnyal aláírt levél esetén panaszkodott az aláírásra (mindamellett, hogy a láncolat fő-tanúsítványa érvényes is volt és telepítve is!)

   

A sárga háromszög az alábbi hibaüzenetet rejtette, itt a “Részletek” a fontos:

Ha megnyitottuk, akkor ez a hibaüzenet fogadta a felhasználót:

Hiba:

A rendszer nem tudja érvényesíteni az aláírás létrehozásához használt tanúsítványt, mert a tanúsítvány kibocsátójának hitelességi tanúsítványa nem érhető el vagy érvénytelen.

A rendszer nem tudja meghatározni, hogy az aláírás létrehozásához használt hitelességi tanúsítvány megbízható-e vagy sem.

Aláírta: xx@domain.com, módszer: RSA/SHA256 idő: .

Szokás szerint a Részletek segítenek, akkor az aláírásnál ez a hibaüzenet fogad:

Hiba: Problémák léptek fel az aláírás létrehozásához használt hitelességi tanúsítvány érvényesítésekor.

Ezek után jön a valódi megoldás: ha rámegyünk a “Tanúsítvány megtekintése” gombra, akkor a köztes CA (mivel megbízható Root CA-tól lett kiállítva) automatikusan bekerül a felhasználó-szintű köztes tanúsítvány-kiállító-tárolóba. Ha ilyenkor megnézzük a “Certificate path“-t, akkor azt tapasztaljuk, hogy minden csupa pipa – sőt, ha bezárjuk sorra az ablakokat, amiken keresztül idáig jutottunk, mindegyiknél megjelenik a pipa.

S hogy miként lehet ezt a sok-sok ablakot elkerülni? Például, ha a láncolat összes elemét előre felvesszük a tanúsítványtárba (ez ugye mehetne akár gép-szinten), hiszen így tudja ellenőrizni a hitelességet – ehhez pedig fel tudjuk használni az előző lépések során látott/kapott tanúsítványok exportjait 🙂

TLS 1.0 és 1.1

Mint azt régebben már tudtuk, a nemrég megjelent Edge/Chrome 98-as verziójával kezdve megszűnik a TLS 1.0 és 1.1 támogatása. Ezt azok fogják leginkább észrevenni, akik régebbi rendszereken “ragadtak” ilyen/olyan okból kifolyólag, s a protokollt sem frissítették.

Ilyen esetben az alábbi üzenet jelenik meg:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Megoldás az természetesen kiszolgáló-függő, ha be lehet kapcsolni a TLS 1.2-t, akkor egy ideig meg lehet úszni a cseréjét, de ez mindenképp egy figyelmeztetés kell legyen az üzemeltetőnek. Sajnos elég sokan most kaptak észhez, s nyomják a piros gombot, amikor rájönnek, hogy most már telefonról/böngészőből nem használható az oldaluk/levelezésük…

Anélkül, hogy túlzottan belemennénk a részletekbe, a blogon már többször említett openssl-el ugyanakkor tudjuk tesztelni, hogy milyen titkosítási protokoll van támogatva:

openssl s_client -connect kiszolgalo.hu:443 -tls1

openssl s_client -connect kiszolgalo.hu:443 -tls1_1

openssl s_client -connect kiszolgalo.hu:443 -tls1_2

Amennyiben visszakapjuk a publikus tanúsítványt (meg a többi lekérdezett érték is jó), akkor a kiszolgáló támogatja a jelzett protokollt, ellenkező esetben vagy még “reszelnünk” kell rajta, vagy (ha annyira elavult) lecserélni egy korszerűbb változatra.

2022 januári frissítések

Nem szoktam minden apróságról írogatni (ezért most ennek kapcsán sem mennék bele technikai részletekbe), viszont úgy tűnik, még nem mindenkihez jutott el a információ, hogy a januári frissítés-csomag gondot okozhat az L2TP/IPSEC VPN felépítésében. Tudom, hogy rengeteg más hiba is javításra került benne, de attól még nem győzzük hangsúlyozni a tesztelés fontosságát. Az érintett foltok KB5009543 (Win10) és KB5009566 (Win11) eltávolítása segíthet.

@Soder, igen, tudom, még mindig szívás 😀

Exchange Y2K22 hiba

A Microsoft (s elsősorban az Exchange 2016/2019) fejlesztői sokat fognak mostanában csuklani, mivel a világon nagyon sok rendszergazda miattuk fogja az új évet hibakereséssel kezdeni.

A gond ott van, hogy a levelek beragadnak a kimenő sorba, „Message deferred by categorizer agent” hibaüzenettel. Az ok az, hogy az „MS Filtering Engine Update” megkapta a legújabb, “220101001” verziószámú (később a 02 végű) frissítését – viszont a verziószám tárolására használt változóban a „22” kezdetű érték már nem fér el (a pontos technikai részletek – signed long/unsigned long – már nem a cikk témája).

A megoldás aránylag egyszerű: kikapcsolni (Disable-AntiMalwareScanning.ps1) vagy átlépni a malware-szűrőt:

Set-MalwareFilteringServer -BypassFiltering $True -identity <Kiszolgálónév>

A Microsoft Exchange Transport újraindítása után szépen elindulnak a levelek 😊

Update: Javítás itt: https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447

Exchange vs AD-séma

Nemrég egyik olvasóm megkeresett, hogy segítsek neki, mert a séma-verziókról szóló cikkem segített neki, de az ott található linkek elavultak/érvénytelenek, a verziószámokról nem is beszélve.

Azóta valóban sok víz lefolyt a Dunán 🙂 Az AD-sémák felsorolásától most eltekintenék, a kolléga inkább Exchange-oldalról közelítette meg a témát. Nos, annak lekérdezését is frissítsük akkor, hiszen PS-ből csodálatosan lekérdezhető:

Import-Module ActiveDirectory

# Exchange Schema Version (forest)

$sc = (Get-ADRootDSE).SchemaNamingContext

$ob = “CN=ms-Exch-Schema-Version-Pt,” + $sc

Write-Output “(Forest Exch schema) RangeUpper: $((Get-ADObject $ob -pr rangeUpper).rangeUpper)”

# Exchange Object Version (forest)

$cc = (Get-ADRootDSE).ConfigurationNamingContext

$fl = “(objectClass=msExchOrganizationContainer)”

Write-Output “(Forest Exch object) ObjectVersion (Configuration): $((Get-ADObject -LDAPFilter $fl -SearchBase $cc – pr objectVersion).objectVersion)”

# Exchange Object Version (domain)

$dc = (Get-ADRootDSE).DefaultNamingContext

$ob = “CN=Microsoft Exchange System Objects,” + $dc

Write-Output “(Domain Exch object) ObjectVersion (Default): $((Get-ADObject $ob -pr objectVersion).objectVersion)”

Ha viszont csak a pőre számok érdekelnek bennünket, itt található egy aktuális lista (mondjuk más sorrendben, mint a fenti lekérdezés, de a kiíratásnál betettem az itt használt megnevezést is).

Ha pedig arra vagyunk kíváncsiak, hogy melyik Exchange CU esetén változik a séma, itt (2016 esetén itt) kapunk rá választ.

RDP tanúsítvány saját CA-val

Régebben, amikor sárga ablakokról beszéltünk, nem ejtettünk szót egy másik megoldásról. Jellemzően, mi van, ha van belső CA-nk: lehet-e használni az általa kiállított tanúsítványokat az RDP-kapcsolatokhoz? Nos, igen, bár kell hozzá pár dolog (hacsak nem akarjuk kézzel, egyesével ujjlenyomat alapján hozzárendelni).

Egyrészt a tanúsítvány kell tartalmazza vagy a “Server Authentication” vagy a “Remote Desktop Authentication” EKU-t. Az első, egyértelmű – de a második nincs a listában. Ilyenkor megtehetjük az, hogy felvesszük “custom” meghatározásként, 1.3.6.1.4.1.311.54.1.2 értékkel.

(Ha véletlenül elgépeltük, vagy mondjuk át akarjuk nevezni, akkor ADSIEdit a barátunk, a konfigurációs konténer:

CN=OID,CN=Public Key Services,CN=Services,CN=Configuration )

Tapasztalatom alapján javasolt, hogy ne csak CN-ben, hanem SAN-ban is legyen benne a gép “igazi” FQDN-je (ha más névvel akarunk rá hivatkozni, természetesen az is benne lehet a SAN-ban). A tanúsítvány helyét ne bántsuk, maradjon a “Personal” tárolóban (ugye az alap önaláírt máshol van).

Ez még nem elég, még “élesítenünk” is kell.

Ehhez Computer Configuration> Policies >Administrative Templates > Windows Components > Remote Desktop Services >Remote Desktop Session Host > Security (régebbi rendszerek esetén “Remote Desktop Session Host” helyett csak “Session Host“) útvonalon a “Server Authentication certificate template” értékét kell kitölteni, a sablon nevével (tudjuk, ez a szóköz nélküli verzió 🙂 ) – extrémebbek a sablon OID-ját is használhatják 🙂 .