Levélküldés másodlagos emailcímről

Régóta fennálló probléma, hogy bár egy felhasználónak lehet több emailcíme is, küldeni csak az alapértelmezettről (primary smtp címről) tud.

Az Exchange Online-ban ez végre megoldódott, bármilyen smtp aliasról lehet már levelet küldeni (földi Exchange sajnos még vár erre a funkcióra). Ez azt jelenti hogy az adott cím kerül be a FROM és REPLY TO mezőbe.

Nézzünk egy gyakorlati példát:

Alex Wilbernek van egy másodlagos címe (sales@istvanffy.eu) és erről szeretne levelet küldeni.

Hogyan kapcsoljuk be?

A funkció bekapcsolásához futtassuk le a következő Exchange Online Powershell parancsot:

Set-OrganizationConfig -SendFromAliasEnabled $True

Az érvényrejutáshoz várni kell pár órát, mire minden tenant szerver átveszi a konfigurációt.

Hogyan küldjünk levelet másodlagos címmel?

Az Outlookban válasszuk ki a From mezőt, és írjuk be a másodlagos címet:

A fenti természetesen működik OWA esetén is.

A címzett pedig ezt látja:

Azaz a küldő neve mellett a másodlagos címe jelenik meg.

A Return-Path is megfelelő:

Ez a funkció hasznos lehet olyan esetekben is, mikor két cég összeolvad és a felhasználónak kell tudnia maileznie a régi és új emailcímmel.

Windowsupdate – automatic update és reboot opciók menedzselése

A Microsoft Endpoint Managerrel (régi nevén Intune) szabályozhatjuk a windows frissítések telepítését.

Az update és reboot mindig is küzdés volt a felhasználók és adminok között: “munka közben indult újra a gépem”, “frissítéskor csak teker és nem tudok dolgozni”, csak hogy pár panaszt említsünk. Sok esetben ezt a problémát a rosszul beállított update policy okozza.

Nézzük, hogy a MEM-ben milyen lehetőségeink vannak. A cikkben most csak az update telepítés és reboot részre térek ki, a többi opcióra nem.

Ha megnyitjuk a Windows 10 update ring-et, a következő beállításokat látjuk az User Experince Settings / Automatic update behavior résznél:

Az egyes beállítások részletezése:

  • Notify download: letöltés és telepítés előtt figyelmezteti a felhasználót, akinek kézzel kell elvégeznie a műveleteket.
  • Auto install at maintenance time: a maintenance időben letölti és telepíti a frissítéseket, kivéve ha a felhasználó használja a gépet, vagy pl. nincs töltőre dugva. A maintenance időt az Active hours beállítással adhatjuk meg (pl. 8-17 óra között nincs automatikus letötlés és telepítés-restart). Az újraindításhoz kéri a felhasználó engedélyét, ha ez nem történik meg 7 napig, utána magától újraindul.
  • Auto install and restart at maintenance time: hasonló az előző beállításhoz, csak itt a telepítés után automatikus restart következik (ha az eszköz nincsen használva). Az Active Hours megadásával a reboot itt is kontrollálható. A nem menedzselt eszközökhöz ez az alapbeállítás: telepítés után auto restart, ha nem hasznáják a gépet.
  • Auto install and restart at scheduled time: definiálhatjuk a telepítés napját-idejét. A telepítést követően elindul egy 15 perces visszaszámláló, amit a felhasználó elhalaszthat. Alapértelmezetten hajnali 3-kor telepít.
  • Auto install and reboot without end-user control: a frissítések letöltése és telepítése automatikusan megtörténik. Amikor az eszköz nincs használatban, a reboot is követi. Ennél az opciónál a felhasználónak csak read-only joga van a beállítási ablakon.
  • Reset to default: visszaállítja alaphelyzetre az auto update beállításokat

A fenti beállításokból kiválasztható a szervezet igényeinek megfelelő update mechanizmus.

A következőkben tekintsük át, hogy milyen figyelmeztetési lehetőségek vannak, a felhasználók felé.

Telepítés után, ha újraindításra van szükség, egy felbukkanó pop-uppal jelzi a rendszer. Ez a figyelmezetés 25 mp után eltűnik, és csak a kis ikon marad az óra mellett:

Amennyiben azt szeretnénk, hogy ez a figyelmeztetés megmaradjon és a felhasználónak kelljen nyugtáznia, kapcsoljuk be a Require user approval to dismiss restart notification részt a policyben:

Szintén egy hasznos funkció, ha a felhasználó figyelmét felhívjuk a közelgő kötelező újraindításra. Evvel lehetőséget adunk, hogy reboot előtt elmentse a megnyitott munkáit. A következő figyelmeztetéseket tudjuk megjeleníteni:

Azaz hogy az újraindulás előtt 4 órával fedobjon egy figyelmeztető üzenetet a felhasználónak, 30 perccel előtte pedig már egy elnyomhatatlan figyelmeztetés jelenik meg, visszaszámolással. Természetesen ezeket az értékeket állíthatjuk.

A frissítések telepítését és a gépek kötelező újraindítását kezelhetjük a Deadline beállításokkal is. Ennek lényege, hogy meghatározzuk, mikor kerüljenek fel az update-ek és mikor történjen az újraindítás.

A deadline a frissítés megjelenésétől számítja a megadott napokat. A fenti példa alapján, ha 10-én jön ki a frissítés a Microsoft Update-re, akkor legkésőbb 3 nap múlva automatikusan telepíti és megpróbálja az újraindítást is, ha az eszköz nincsen használatban. Ha definiáljunk Grace Period értéket, akkor annak értékével halasztja. Ez különösen hasznos, ha a felhasználó pl. szabadságról tér vissza, és így kap időt, hogy a telepítés-újraindítás kontrolláltan, pl. másnap történjen.

A deadline beállításokkal egy sokkal szorosabb frissítési ütemet tudunk kialakítani, mint az első részben taglalt beállításokkal. Amennyiben ezt a módszert választjuk, ne felejtsük el a Quality update deferral period (days) és Feature update deferral period (days) értékeket 0-ra tenni, különben policy conflict keletkezhet.

A deadline esetében max 30 napot határozhatunk meg.

Ajánlott konfiguráció: itt tennék egy szubjektív ajánlást, hogyan érdemes beállítani a teljes policyt:

  • Quality update deferral period (days): 7 nap. Így egy hétig nem ajánlja fel a frissítés telepítését, az IT addig tudja tesztelni a patch-et
  • Automatic update behavior: Auto install at maintenance time. A nem aktív időben a frissítések települnek és megjelennek a reboot kérő üzenetek, 7 napig. 7 nap után kötelező lesz a reboot, amiről figyelmeztetéseket jelenít meg.
  • Active hours start: 8 AM
  • Active hours end: 4 PM
  • Restart checks: Allow. Ha alacsony az akku töltöttsége, vagy presenting módban van a gép, akkor nem indul újra.
  • Require user approval to dismiss restart notification: Enabled. A felhasználónak kézzel kell leokéznia a pop-upot, evvel is tudatosítva benne, hogy a gépe újraindításra vár.
  • Remind prior to requried auto-restart with dismissible reminder: 8 óra
  • Remind prior to requried auto-restart with permament reminder: 1 óra
  • Change notification update level: Use the default Windows Update notifications

Összefoglalva: az update ring beállításkészlettel megtalálhatjuk a középutat a frissítések telepítése és felhasználói élmény negatív befolyásolása között.

M365 Enterprise és SMB csomagok összehasonlító táblázatok

Sokszor nemcsak az ügyfelek, de a tanácsadók is elveszettek lehetnek, hogy melyik M365 csomagban milyen szolgáltatás szerepel, milyen limitációkkal stb.

Az alábbi két táblázat hasznos lehet, hogy eligazodjuk a “rengetegben”

M365 Enterprise csomagok összehasonlító táblázat (PDF)

M365 SMB csomagok összehasonlító táblázat (PDF)

Minimal vs Full Hybrid – melyiket válasszam?

Ügyfelekkel beszélgetve tapasztalom, hogy sok a homály az Exchange Hybrid kialakításással kapcsolatban. A legtöbb elakadás ennél a képernyőnél történik:

Azaz jön a jogos kérdés, hogy a mi különbség a kettő között, és melyiket válassza az adott szervezet?

Minimal vs Full Hybrid

A Minimal Hybrid használata esetén az alább funkciók nem lesznek elérhetőek:

  • Cross-premises Free / Busy információk (naptármegosztás funkció a földi és felhős postafiókos felhasználóknál)
  • TLS – titkosított mail flow a földi Exchange és az Exchange Online között
  • Cross-premises eDiscovery funkciók
  • Automatikus OWA és ActiveSync átirányítás az EXO-ba migrált usereknél
  • Skype for Business vagy Teams integráció a földi postafiókok esetén

Természetesen megmaradak az alábbi lehetőségek:

Online mailbox migráció (a felhasználó a mozgatás alatt is tud dolgozni a levelezésében); nincs szükség az Outlook-profil újrakonfigurálására; nincs szükség külön név/jelszó használatára (a céges account adatok szinkronizálódnak)

Mely szervezeteknek ajánlható a Minimal Hybrid kialakítás?

  • Kis -és közepes méretű cégeknek, akik szeretnének gyorsan az Exchange Online-ba migrálni, de mégis szeretnének kontrollt (szemben pl. a cutover migrációval)
  • Amely szervezeteknek nincs szükségük a fenti teljes funkcionalitásra és nem terveznek hosszú távon hybrid fenntartást.
  • Felvásárlás vagy egyesülés esetén, ha az igény a mailboxok gyors migrációja

Mely szervezeteknek javasolt a Full Hybrid kialakítás?

  • Nagy létszámú szervezeteknek, ahol hosszú távon is terveznek a földi Exchange megtartásával
  • Ahol szükség van a maximális kontrollra a migrációkat tekintve, emiatt szükséges az együttélés (co-existence) biztosítása
  • Ahol szükséges a Free / Busy információk megléte és eDiscovery funkció

Fontos tudni, hogy ha már beállítottuk a Full Hybridet, akkor az O365 Hybrid Configuration Wizard futtatásakor már nem választhatjuk a Minimal Hybridet (a fenti screenshoton is inaktív a lehetőség). Viszont amennyiben Minimalt állítottunk be, bármikor válthatunk a Full Hybridre.

Az alábbi táblázatban összeállíottam pár szempontot a döntéshez:

IgényVálasztás
Mailboxok gyors migrációjaMinimal Hybrid
Office 365 mailboxok kezelése és földi AD szinkronizálásaMinimal Hybrid
Global Address List fenntartása a földi és and Office 365 közöttMinimal Hybrid
Organization configuration beállítások szinkronizálása, pl. ActiveSync policykMinimal Hybrid
A mailboxok migrációjának előkészítése (pre-sync) és migráció befejezése alkalmas időbenMinimal Hybrid
Bejövő és kimenő levelezés a földi Exchange-en keresztül kell történjenFull Hybrid
Földi Exchange és Exchange Online közötti levélforgalom TLS-sel legyen titkosítottFull Hybrid
Megtartani a mailek eredeti fejlécét , ami szükséges a  mailtippek és out of office válaszokhozFull Hybrid
Free / Busy funckió használata (naptármegosztás földi és felhős postafiókok között)Full Hybrid
Földi és felhős postafiókok közötti Full Access / Send as jogosultságok megtartásaFull Hybrid
Integráció  Skype for Business / Teams és  Exchange 2016 mailboxok között vagy cross-premises eDiscovery használataFull Hybrid
Kontrollált mailbox migrációFull Hybrid

Összefoglalva:

Ha a cél a lassabb, de teljesen kontrollált migráció és fontos a teljes együttműködés megtartása a földi és felhős postafiókkal rendelkező felhasználók között, válasszuk a Full Hybridet.

Ha a gyors migráció a prioritás, beáldozva néhány funkciót, akkor érdemesebb a Minimal Hybrid opciót választani.

Seamless SSO – cseréljük a Kerberos kulcsot

Az Azure portálon, az AD Connect résznél szemünkbe tűnhet egy sárga háromszöges figyelmeztetés:

Pánikra nincs ok, a napi működésre nincs kihatással 🙂

De mit jelent mindez?

Áttekintés

A Seamless SSO-t beállíthatjuk, ha password hash sync vagy pass-through authentikációt határoztunk meg (a két hitelesítési mód összehasonlítása: Password hash sync vagy pass-through authentication – összehasonlítás | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com) )

A Seamless SSO segíti a felhasználói élményt, hogy domain-joined gépeken automatikusan bejelentkeznek az Azure AD-ba.

Amikor az AD Connect segítségével konfiguráljuk az SSO-t, a földi domainben létrejön egy AZUREADSSOACC computer objektum. Ez felelős érte, hogy megvalósuljon az SSO az Azure AD-val. A működésének rövid leírása:

  1. Felhasználó be szeretne jelentkezni egy felhős web app-ba.
  2. Az App átírányítja az Azure AD-hoz.
  3. Az adott App nem továbbít semmilyen domain vagy tenant információt, ezért meg kell adni a felhasználónak a felhasználó nevét.
  4. A webbrowser 401-es hibát ad, mert nincs érvényes kerberos ticket.
  5. A felhasználó böngészője kerberos jegyet igényel a “AZUREADSSOACC” objektumhoz. Igen és itt nyer értelmet ez az objektum, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget és ez az objektum képviseli az Azure AD-t.
  6. Kapunk egy kerberos ticketet a “AZUREADSSOACC” objektumhoz, ami titkosítva lesz a “számítógép” kulcsával.
  7. A felhasználó böngészője elküldi a titkosított kerberos ticketet.
  8. Azure visszafejti a titkosított kerberos ticketet, azzal a kulcssal, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget.
  9. Amennyiben érvényes a jegy, akkor a böngésző visszakap egy tokent, amivel hozzáférhet az erőforráshoz.
  10. Ezáltal a felhasználó sikeresen bejelentkezett a wep app-ba, anélkül, hogy megadta volna a jelszavát.

(forrás: https://nlbit.blog/2020/08/07/seamless-sso-azureadssoacc/ )

Ez az objektumot érdemes egy külön OU-ba tenni és bekapcsolni rajta a “protect object from accidental deletion” opciót is.

A Kerberos-kulcs (decryption key) a lényeges, ezt érdemes legalább 30 napota cserélni. Ha nem tesszük, akkor kerül ki az Azure portálra a figyelmeztető ikon.

Hogyan cseréljük a Kerberos-kulcsot?

A művelethez szükségünk van Global Administrator és Domain Admin jogosultságra. Lépjünk be az AD Connect szerverre és admin powershellben navigáljunk el a “Microsoft Azure Active Directory Connect” mappába:

cd “C:\Program Files\Microsoft Azure Active Directory Connect\”

Importáljuk be az SSO modult:

Import-Module .\AzureADSSO.psd1

A következő paranccsal végrehajtjuk a hitelesítést az Azure AD felé:

New-AzureADSSOAuthenticationContext

Futtassuk le a kulcs-csere parancsot, és hitelesítsük magukat a földi AD felé:

Update-AzureADSSOForest

A hitelesítés után megtörténik a kulcs cseréje:

Rövid idő után frissül az Azure portálon is:

Összefoglalva: evvel az egyszerű művelettel érdemes legalább 30 naponta frissíteni a Kerberos-kulcsot. Az AZUREADSSOACC objektumra kevés figyelem jut, de érdemes jól “eltenni” egy külön OU-ba és bekapcsolni rajta a véletlen törlés elleni védelmet.

Folyamatos hozzáférés-ellenőrzés

Az Azure AD egyik, még Preview fázisban lévő megoldása, a Continous Access Evaluation jó eszköz lehet, hogy még robosztusabb legyen a hozzáférési szabályzatunk.

Amikor egy felhasználó bejelentkezik egy online szolgáltatásba (pl. Exchange Online), akkor az Azure AD egy hozzáférési tokent állít ki számára, egy óra érvényességgel. A token érvényésségének lejártáig él a hozzáférés.

(az időtartam egyébként szabályozható, pl. conditional access session control segtíségével)

Nézzünk egy alappéldát:

Mi történik, ha letiltunk egy felhasználót?

Sajnos, a token érvényessége ettől még megmarad és továbbra is eléri az online szolgáltatást. Ez sok szervezet számára elfogadhatatlan, és szükség van granulárisabb megoldásra.

Itt jön képbe a Conditional Access Evaluation (CAE). Ennek lényege, hogy bizonyos események hatására az addigi token érvényessége azonnal megszűnik és szükséges lesz egy újra-authentikáció végrehajtása.

Milyen eseményeknél történik meg?

  • A felhasználói fiókot letiltjuk/töröljük
  • Jelszóreset vagy jelszócserét követően
  • MFA engedélyezésekor a felhasználó számára
  • Az admin visszavonja a meglévő hozzáférési tokeneket
  • Azure AD Identity Protection magas kockázatot érzékel

Valamelyik esemény bekövetkeztekor gyakorlatilag egy percen belül megszűnik a hozzáférés a Sharepoint Online, Exchange Online és Teams szolgáltatásokhoz (jelen preview állapotban ezt a két szolgáltatást támogatja). Saját tesztelés alapján 20-30 mp elteltével jöttek az authentikációs popup-ok, laptopon-telefonon-tableten egyaránt.

Milyen alkalmazások támogatják a CAE-t?

Alapesetben a kliensek megpróbálják felhasználni a már meglévő tokent a hozzáféréshez. CAE-vel a kliens az ún. claim challenge segítségével tudja, hogy nem a tárolt tokent kell használnia, hanem újat kell kérnie az Azure AD-tól (authentikáció bekérése)

Az alábbi alkalmazások CAE-kompatibilisek:

  • Outlook Windows
  • Outlook iOS
  • Outlook Android
  • Outlook Mac
  • Outlook Web App
  • Teams for Windows (Only for Teams resource)
  • Teams iOS (Only for Teams resource)
  • Teams Android (Only for Teams resource)
  • Teams Mac (Only for Teams resource)
  • Word/Excel/PowerPoint for Windows
  • Word/Excel/PowerPoint for iOS
  • Word/Excel/PowerPoint for Android
  • Word/Excel/PowerPoint for Mac

Hogyan működik a gyakorlatban?

Az alábbi példában úgy állítottuk be a Conditional Access policyt, hogy az online szolgáltatást csak meghatározott IP-tartományokól elérhető (pl. irodai hálózat)

  1. A CAE-kompatibilis kliens megkéri a tokent az Azure AD-tól (vagy felhasználja a tárolt érvényes tokent)
  2. A Conditional Access Policy megvizsgálja a hozzáférési kérést és engedélyezi (mivel az irodai hálózatban van)
  3. A kliens megkapja a hozzáférési tokent
  4. A felhasználó elmegy az irodai hálózatból, átvált mobilnetre
  5. A kliens az engedélyezett IP-tartományon kívülről küldi a hozzáférési kérést
  6. Az Azure AD megvizsgálja a kérést
  7. Az Azure AD megtagadja a hozzáférést és 401+ claim challenge-et küld vissza a kliensnek
  8. A kliens értelmezi a 401+ claim challenge-t, és nem próbálja a tárolt tokent használni, hanem újat kér
  9. A Conditional Access megtagadja a hozzáférést, mert nem a policyben engedélyezett IP-tartományokból érkezett a kérés.

Hogyan engedélyezzük a CAE-t?

Navigáljunk a https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/ContinuousAccessEvaluation linkre és válasszuk az Enable preview funkciót

Kijelölhetünk csoportokat, tesztelési célből, vagy alkalmazhatjuk minden felhasználóra:

Limitációk az IP-tartományokkal kapcsolatban:

A CAE nem értelmezi az MFA Trusted IP vagy a country location beállításokat. Csak az Azure AD-ba felvitt Named Location IP-ket használja.

https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/NamedNetworks

Ide kell felvinni azokat az IPv4 és IPv6 tartományokat, amikre szeretnénk ebben az esetben a CAE-t hasznáni.

Összefoglaló:

A CAE egy nagyszerű irányba mutató fejlesztés, és bízhatunk benne, hogy a preview után még több funckióval bővül. Addig is, érdemes kipróbálni és használatba venni.

Password hash sync vagy pass-through authentication – összehasonlítás

Előző cikkemben (https://istvanffyzoltan.com/2020/12/15/office-365-federacio-megszuntetese/) bemutattam, hogyan lehet ADFS-ről átállni password hash sync authentikációra (PHS) az O365 esetén.

Szintén említettem értintőlegesen, hogy létezik a pass-through authentikációs megoldás is (PTA)

Felmerülhet a kérdés, hogy melyiket érdemes választani, mik az előnyeik és hátrányaik? Ezeket igyekeztem összeszedni a cikkben (feltételezve, hogy van földi környezet és az AD Connecten keresztül megtörtént a címtár szinkronizáció)

Password hash sync

A PHS esetén a földi AD-jelszavak módosított hash-jét szinkronizáljuk fel az Azure AD-ba, és a hitelesítés ott történik meg, a tárolt hash-ek alapján.

A folyamat az alábbi ábrán látható:

Hogyan jutnak fel a jelszó hash-ek az Azure AD-be?

  • Az Azure AD Connect kliens kétpercenként lekéri a domain controllerektől a jelszóhash-eket
  • A kliens a jelszóhash-t átalakítja egy 32 bájtos hexadecimális karakterré
  • utána egy binárissá alakítja UTF-16 kódolással
  • a kapott értéket megsózza (salt) további 10 bájttal
  • az így kapott eredményt pedig 1000 alkalommal újrahash-eli HMAC-SHA256 kódolással
  • a végeredményt pedig a tenanthoz dedikált Service Bus juttatja el az AzureAD-ba (TLS kapcsolaton keresztül)

Látható, hogy a folyamat egészen biztonságos. Az esetleges aggodalmak eloszlatása érdekében leszögezendő:

  • A PHS sosem synceli az aktuális jelszót.
  • A jelszó plain-text változata soha nem kerül ki a Microsofthoz.
  • Az eredeti MD4 jelszóhash soha nem szinkronizálódik közvetlenül; csak ennek a hashnek a fenti módon leírt, újrahash-elt változata kerül az Azure AD-ba.
  • Ha megszereznék az Azure AD-ban tárolt hash-t, azt nem lehet felhasználni a földi környezetben (pl. pass-the-hash támadással)

Milyen előnyei vannak a PHS-nek?

  • A felhős erőforrásokhoz való hitelesítés az Azure AD-ban történik.
  • Az AD Connect-en kívül nem igényel semmilyen földi komponenst.
  • A Microsoft biztosítja a DDOS és password spray támadások elleni védelmet.
  • Brute-force támadás elleni védelem: alapértelmezésben 10 hibás belépési kísérlet után 1 percre blokkol.
  • Password Protection: nem enged gyenge vagy tiltott jelszavakat beállítani jelszócsere esetén (pl. password123), evvel is védve az identitást. További infó: https://istvanffyzoltan.com/2020/02/01/azuread-password-protection/
  • IP-lockout: figyeli a belépésekhez használt IP-címeket, és ahonnan túl sok hibás kísérlet érkezik, azt ideiglenesen blokkolja, a valódi felhasználók a helyes jelszóval továbbra is hozzáférnek a szolgáltatásokhoz.
  • Leaked Credential Service: a Microsoft figyeli az ellopott felhasználónév/jelszó párosokat (darkweben) és figyelmeztet vagy tilt, ha a jelszó “közkézen” forog. Ez utóbbihoz szükséges az Azure AD P2 licensz.

Milyen hátrányai vannak a PHS-nek?

  • Az O365-ben a jelszólejáratot “never expire” állítja, azaz soha nem jár le. Ez sok szervezet szabályozása alapján nem megfelelő.
  • Ha a földi AD-ben lejár a jelszó, az O365-ben nem fog, tehát a felhasználó továbbra is be tud lépni.
  • A felhasználó letiltása / lockolása esetén a változás nem jut azonnal érvényre, csak a 30 percenkénti szinkronizálási ciklus után (azaz hiába disabled / locked az user account a földi környezetben, az O365-ba be tud lépni)

Pass-through authentication

PTA hitelesítés esetén a validálás a földi domain controllereken történik meg. Kis túlzással hívhatjuk lightweight-ADFS megoldásnak is.

A működése a következő:

  • Az user szeretne belépni az pl. Office portalra
  • Az Azure AD leküldi a kérést az on-prem környezetben futó PTA agenthez
  • A földi DC hitelesítése után az Azure AD visszakapja a hozzáférést és megtörténik a hitelesítés

PTA agentből bármennyit telepíthetünk a földi környezetünkbe, evvel is biztosítva a redundanciát. Az agent esetleges hibája esetén az authentikáció továbblép a következőre. A működéshez nem szükséges külső elérés (azaz tűzfalon portnyitás befelé, NAT, stb), az agent az outbound 443-as porton kommunikál az Azure AD-vel.

Az alábbi környezetben 7 PTA agent került telepítése, fizikai és virtuális szerverekre egyaránt, biztosítva a magas rendelkezésreállást.

Könnyen belátható, hogy ez jóval rugalmasabb a nagytestvér ADFS-nél.

Milyen előnyei vannak a PTA-nak?

  • Az authentikációt a “földön” tartjuk, azaz a domain controllereink végzik a hitelesítést
  • A jelszóhash-ek nem kerülnek az Azure AD-ba
  • A felhasználókon végzett műveletek (jelszólejárat, letiltás, lockolás) azonnal érvényre jutnak
  • A szervezetnek nagyobb a kontrollja a hitelesítés felett
  • Brute-force támadások elleni védelem, mint a PHS-nál
  • Támogatja az Azure AD Conditional Accesst, többfaktoros hitelesítést és legacy authentication szűrését
  • Könnyű high-availability kialakítás (több agent telepítésével)
  • Az agentek nem igényelnek karbantartást; automatikusan frissülnek

Milyen hátrányai vannak a PTA-nak?

  • Nem támogatja a Leaked Credentials szolgáltatást
  • Szükséges a földi környezetbe agentek telepítése
  • A földi AD elérhetetlensége esetén a felhős szolgáltatásokba történő hitelesítés meghiúsul
  • Régi kliensek (pl. Office 2010) nem biztos hogy jól működnek PTA-val

Lehet váltani a PTA és PHS között?

Igen! Az AD Connect kliensben bármikor megváltoztathatjuk, hogy PTA vagy PHS hitelesítést szeretnénk használni. Ez jól jöhet olyan katasztrófa esetén, ha pl. az összes PTA agentünk elérhetetlen: át tudunk váltani PHS hitelesítésre.

Az AD Connectben állítsuk át a kívánt hitelesítési módot:

Összefoglalás

Ahogy látjuk, mindkét megoldás vannak előnyei és hátrányai; szervezettől függ, hogy milyen szabályozás alapján választ. Ha cél a földi infrastruktúra és komplexitás csökkentése, válasszuk a PHS authentikációt. Ha szorosabb a szabályozás és több kontrollt szeretnénk, a PTA hitelesítés lehet a megfelelő. A kettő között váltás bármikor megejthető, így marad mozgástér a kísérletezéshez is.

Office 365 federáció megszüntetése

Ahol ADFS-t használnak az O365 federációra, ott érdemes elgondolkodni az alternatívákon,ugyanis az O365 felé történő authentikációs workloadot le tudjuk venni az ADFS farmunkról. Abban az esetben, ha csak emiatt tartottuk az ADFS-t, akkor le is lehet állítani, és spórolni a céges erőforrásokon (farm fenntartás, üzemeltetés, patchelés, rendelkezésre állás, hálózat, biztonsági megoldások stb. biztosítása).

A federáción kívül két lehetőségünk van az O365 felé történő hitelesítésre:

  • Password hash sync: ebben az esetben a földi AD-ben tárolt jelszóhash-ek szinkronizálódnak az AzureAD-be, és a hitelesítés ott is történik meg.
  • Pass-through authentication: a hitelesítés a földi AD-ben történik, telepített agentek segítségével.

A password hash sync esetén nincs szükségünk semmilyen földi infrastruktúrára, viszont a földi domainben beállított jelszópolicy/user lock/ user disabled események nem jutnak rögtön érvényre.

A pass-through authentikáció esetén az O365 portal kéri be a hitelesítő adatokat és validáltatja a földi környezetbe telepített PTA-agentek segítségével.

A mostani cikkben az egyszerűbb, password hash sync-re (továbiakkban PHS) való áttérést taglalom.

Magyarázat:

federated domain: ahol ADFS-t használunk a hitelesítésre

managed domain: ahol PHS vagy PTA segítségével authentikálunk.

A cél, hogy a federated domaint managed domainre kapcsoljuk.

Attől függően, hogy kezdetben hogy állítottuk be az ADFS-t, kétféle lehetőségünk van:

  • Azure AD Connect segítségével: ha a federációt az AD Connect segítségével állítottuk be, akkor a PHS-re áttérést kötelezően ott kell megtennünk. Ez a háttérben a Set-MsolDomainAuthentication paranccsal az összes federált domaint átállítja.
  • Azure AD Connect és Power Shell beállítással: csak akkor használjuk ezt az opciót, ha az ADFS-t nem az AD Connecten keresztül állítottuk be. A különbség annyi az előzőhöz képest, hogy nem futtatja automatikusan a Set-MsolDomainAuthentication parancsot, tehát később kézzel tudjuk megszabni, hogy melyik domaint konvertálnánk át.

Nézzük az első opciót, tehát ha az ADFS konfigurációt az AD Connectben tettük meg:

Első lépésként engedélyezzük az AD Connectben a password hash syncet. Ha lennének félelmeink a PHS-val kapcsolatban, itt egy részletes magyarázó cikk a működéséről: https://istvanffyzoltan.com/2020/07/12/miert-ne-feljunk-a-password-hash-szinkronizalastol/

TLDR: nem szinkronizálja a közvetlen jelszavunkat 🙂

Tehát, kapcsoljuk be a PHS syncet, ha még nem tettük volna meg:

Várjuk meg, amíg a sync végigmegy (30-60 percet)

Logokat lehet ellenőrizni:

  • Event Viewer and application logs
  • Azure AD Connect wizard troubleshooting task

Ahhoz hogy a domain-joined gépeken is menjen az SSO, a következő URL-eket adjuk hozzá az Intranet zónához GPO-val: (a GPO-ban az érték legyen 1)

Következő lépésben állítsuk be a PHS-t és engedélyezzük az SSO-t:

Az Azure portalon látni fogjuk, hogy eltűnt a Federation

Második opció, ha az ADFS-t nem az AD Connecten belül állítotuk be:

Itt is fontos, hogy előtte legyen beállítva a password hash sync, különben a federáció leváltásakor minden felhasználó különálló, új jelszót kap, ami komoly gondokat okozhat!

Ha működik a PHS, akkor lépjünk be az ADFS szerverünkre és futtassuk le az alábbi parancsokat admin powershellből:

install-module msonline

import-module msonline

connect-msolservice (adjuk meg a global admin account adatait)

végül kérdezzük le a federated / managed domainek listáját:

get-msoldomain

Futtasuk le a következő parancsot, megadva az ADFS szerverünk belső FQDN-jét:

Set-MsolADFSContext -Computer <ADFS FQDN>

Végül konvertáljuk át a federált domaineket managed-be:

Convert-MsolDomainToStandard -DomainName yourdomain.com -SkipUserConversion:$true -PasswordFile C:\userpasswords.txt

A SkipUserConversion értékre nagyon figyeljünk, feltétlenül legyen True az értéke, különben új jelszavakat generál az usereknek! A PasswordFile ettől függetlenül kötelező elem, adjunk meg egy érvényes útvonalat a txt filenak.

Egy újabb get-msoldomain paranccsal látjuk, hogy nincs federated domain immár:

Végül pedig állítsuk be a PHS-t:

Set-MsolDomainAuthentication -Authentication Managed -DomainName yourdomain.com

Ezt ellenőrizhetjük később az AD Connect felületén is. A teljes átváltáshoz várjunk 2-3 órát, addig előfordulhatnak login anomáliák, így ezt a műveletet érdemes munkaidőn kívül elvégezni.

Tesztelés:

Navigáljunk el a https://portal.office.com oldalra. A felhasználónév megadása után, a régi, federated scenárió esetén kaptunk egy redirectet az ADFS oldalra:

A federáció megszűntetése után viszont már az O365 portal kéri be a jelszavunkat:

Összefoglalás: ha csak az O365 miatt van ADFS szerverünk, akkor érdemes migrálni a PHS / PTA megoldások egyikére, jelentős erőforrásfogyasztás és hibalehetőséget tudunk elkerülni.

Háttérzajok elnyomása Teams meetingek során

A pandémia miatt nagyon sokan kényszerülnek otthonról dolgozni és meetingelni, ahol sokszor korántsem ideálisak a körülmények: pont akkor kezd el falat fúrni a szomszéd (ő is otthon van, ráér 🙂 ), a másik szobából áthallatszik a kisgyerekek zsinatolása, és még ezer háttérzaj lehet, ami zavarhatja a Teams-meetingeket.

Év végére megérkezett a frissítése a Teams szolgáltatásba, ami beépített zajszűrőt használ. A mesterséges intelligencia folyamatosan elemzi a hangokat és képes kiszűrni a nem beszédhez tartozó zajokat.

A Teams kliensben a Settings / Devices résznél találjuk a Noise Suppression beállításokat:

A következő opciók vannak:

  • Auto: a Teams figyeli a háttérzajokat és szükség esetén kiszűri őket, pl. kutyaugatás vagy papírzörgés
  • Low: a zajszűrés folyamatos, ideális ha pl. a háttérben zenét hallgatnak
  • High: minden zajt eltávolít, ami nem beszédhez köthető
  • Off: nincs zajszűrés

Az alapbeállítás az Auto, érdemes ezen maradni és hagyni, hogy a mesterséges intelligencia tegye a dolgát. A magasabb szintű szűrések (Low, High) viszont többletterhelés a gépnek, CPU szinten.

Amennyiben olyan “szerencsénk” van, hogy a szomszéd fúrni kezd, akkor a meeting idejére érdemes a High opciót választani.