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.

Exchange Online Protection – a Safe Listek veszélyei

Sok szervezetnél van rá igény, hogy külső partnerektől mindenképpen megkapják az emaileket. Az Exchange Online erre négyféle megoldást is biztosít:

  • Mail flow rules (transport rules)
  • Outlook Safe Sender beállítás
  • IP allow list (connection filter)
  • Allowed sender/domain list (anti-spam policynél)

Most az utolsót nézzük meg, az allowed sender/domain listákat. Ahogy említettem, vannak olyan küldők, ahonnan mindenképp meg kéne kapjuk a maileket. Gyakorlati példa lehet a szamlakozpont.hu vagy gov.hu

Ilyenkor az üzemeltetők ezeket a domainek felveszik az Allowed Domain listre, hogy biztos beérkezzenek a levelek.

Mi lehet evvel a gond?

Sajnos az, hogy az ilyen feladóval érkező mailek mentesülnek az alábbi szűrések alól:

  • Spam
  • Spoof (levélhamisítás)
  • Phishing (adathalászat)

Valamint az összes küldő hitelesítés ellenőrzés alól: SPM, DKIM, DMARC

Egyedül a malware és high-confidence phishing szűrés valósul meg.

Ahogy látjuk, ez a fajta engedélyező lista komoly veszélyeket hordozhat ; bár biztosak lehetünk felőle hogy a kívánt feladótól érkező levelek nem akadnak fenn a szűrőnkön, de sajnos utat nyihat a támadóknak is.

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.

OneDrive- hozzáférés megtagadva

Egy gyors esetleírás.

Környzetet: a felhasználók használják az OneDrive-ot, és a Desktop/Documents/Pictures mappa is oda van irányítva (lásd cikk: OneDrive mint felhasználói backup | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com)

A gépek Microsoft Endpoint Management-tel (Intune) menedzseltek, Windows Information Protection policy beállítva.

Hibajelenség: nem lehet új file-t létrehozni az OneDrive folderekben, hozzáférés megtagadva hibaüzenettel.

Megoldás:

A WIP-policyben meghatározott Data Recover Agent tanúsítványa lejárt.

Cseréljük ki a DRA tanúsítványt, és újra működőképes lesz az OneDrive.

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.