Azure, Microsoft 365, Office 365, Cloud

Tento článek obsahuje moje stručné poznámky k velmi rozsáhlé oblasti Azure AD pro služby Microsoft 365 / Office 365. Neměl jsem čas na detailnější studium, takže jsem se snažil co nejjednodušeji otestovat a zprovoznit potřebné. Tedy replikaci lokálních účtů do online prostředí. Navíc v situaci, kdy již v Azure AD existovaly ručně vytvořené účty (cloud), a ty bylo potřeba spárovat s lokálními účty (on-premises). Neručím za přesnost a již vůbec není článek komplexní.

Tento článek jsou pouze moje poznámky. Obsahuje stručné informace o použití PowerShellu pro získání informací o uživatelích v Azure AD a schránkách v Exchange Online (EXO). Dále se věnuje práci s licencemi a různým hromadným operacím. Popisuje možnost odebrání (zablokování) určité služby, jako je Exchange Online nebo Teams. Na závěr jsou tyto informace použity k vyřešení problému, kdy uživatel se schránkou v on-premises má druhou schránku v EXO.

Než se pustíme do konfigurace hybridního Exchange, kdy využíváme servery v naší společnosti (On-Premises) dohromady s cloudovými servery Exchange Online (EXO), tak je potřeba vědět, jak to ovlivní směrování (Transport Routing) a tok pošty (Mail Flow). Co případně musíme upravit, aby se neobjevil problém s doručováním zpráv. Protože vzniknou dvě Exchange organizace, které sdílí stejnou doménu, tak musíme určit kam přichází pošta z internetu a jak odchází. S tím úzce souvisí přijímací a odesílací konektory (Connectors) v obou prostředích. A konfigurace našich veřejných domén (Accepted Domains). Hodně se věnujeme speciální situaci, kterou Microsoft nepopisuje v dokumentaci. Pokud z interních serverů odesíláme zprávu jiné organizaci, která je hostovaná na stejných EXO serverech, tak zprávu zpracuje náš Tenant Exchange Online a přepošle.

Pokud provozujeme ve své síti Exchange Server a využíváme (nebo se chystáme) také Microsoft cloudové služby (Office 365), tak se patrně dostaneme k tomu, že potřebujeme zprovoznit Exchange Hybrid. Tehdy spolu komunikuje naše On-Premises Exchange organizace a Exchange Online. Můžeme přesunout některé/všechny schránky do cloudu nebo jen využít napojení MS Teams a dalších služeb na interní schránky. V testovacím prostředí jsem narazil na řadu problémů (v produkci to bylo lepší).

Článek popisuje některé důležité principy fungování hybridní konfigurace Exchange. Jaké atributy se musí synchronizovat do Azure AD pro korektní funkčnost. Jak se řeší schránky v On-Premises organizaci versus v Exchange Online a jak můžeme zjistit, kde má určitý uživatel schránku. Jak se správně schránka vytváří a přesouvá. Popisuje všechny situace, které mohou v praxi vzniknout, z pohledu umístění schránky pro jednoho uživatele. Věnuje se opravě nefunkčních variant. Nejvíce je rozebírána situace, kdy má jeden uživatel schránku na interním serveru a zároveň schránku v cloudu (jedna z nich je v podstatě nefunkční). Řada věcí se musí provádět pomocí PowerShellu.

Tento článek předchází sérii, která bude popisovat Skype for Business Hybrid. Popisuje problém, který nastává, pokud jsme neprovedli (a možná vůbec neuvažovali) hybridní konfiguraci Skype for Business. Provozujeme interní Skype for Business Server a korektně jsme synchronizovali uživatele do Azure AD. V Online prostředí někteří uživatelé využívají Teams, často dohromady s On-Premises Skype for Business (a považují to milně za dvě oddělené aplikace). Pak narazí na problém, že v Teams mohou kontaktovat pouze uživatele ze stejné organizace (Tenantu), nikoliv externí uživatele. To se netýká schůzek (Meetings) přes odkaz.

Pokud provozujeme On-Premises Skype for Business Server, a začneme využívat cloudové služby Microsoft 365 / Office 365 (přesněji aplikaci Teams), tak ve většině případů musíme řešit hybridní konfiguraci Skype for Business. Cílem je, aby mohli být někteří uživatelé na interním serveru a někteří v cloudu a fungovaly všechny komunikace. Situace je komplikovaná, protože v cloudu jde v současnosti o Skype for Business Online a zároveň Teams. Princip je trochu podobný jako Exchange Hybrid, kdy máme některé schránky interně a jiné v cloudu.

Microsoft Cloud obsahuje dva nástroje pro komunikaci a spolupráci, které se v hlavních oblastech překrývají, Skype for Business Online a Microsoft Teams. Obě platformy mohou existovat vedle sebe nezávisle, můžeme řízeně využívat určité vlastnosti z každé z nich nebo mohou určitým způsobem spolupracovat. Chování, a uživatelské použití, se řídí nastavením koexistence (Coexistence mode), které se také označuje jako upgrade do Teams (Teams Upgrade). Další komplikace přináší využití Skype for Business Hybrid. Pro uživatele je důležité, jak funguje interoperabilita mezi Teams a Skype for Business a jak je možné se připojovat na schůzky.

Když zprovozníme Skype for Business Hybrid, tak nám začne fungovat komunikace mezi našimi lokálními a cloudovými uživateli na sdílené SIP doméně. Uživatele můžeme přesouvat z On-Premises prostředí do Online a opačně. Přesun se vždy provádí z interního prostředí. Důležité je poznat, kde se který uživatel nachází. Hodit se také může informace, jaké atributy v Active Directory se využívají.

Vyjdeme ze situace, že máme nastavený Skype for Business Hybrid. Část našich uživatelů zůstala na interním Skype for Business Serveru. Část jsme přesunuli do cloudu do Teams only módu, takže pracují pouze v Teams. Prakticky se podíváme, jak mezi nimi funguje komunikace v různých klientech. V druhé části si popíšeme problematické chování, kdy je komunikace iniciována z Teams. Často to vypadá, že se Teams snaží doručit zprávu příjemci v Teams, kde ovšem nemá účet.

Microsoft Store for Business (MSfB) je cloudový nástroj (zdarma) pro distribuci (nikoliv instalaci) Windows 10 aplikací (produktů). Podmínkou je Azure AD Tenant a využívaní Azure AD účtů. Jedna z jeho vlastností je Private Store, kam můžeme umísťovat vybrané aplikace, které jsou dostupné uživatelům. Na Windows 10 Enterprise můžeme nastavit pomocí Group Policy, že Microsoft Store nabízí pouze aplikace z Private Store. MSfB má i řadu dalších vlastností.

V článku si popíšeme, jak vytvořit konektor z Configuration Manager do Azure služby Microsoft Store for Business. Dále nastavit synchronizaci aplikací z obchodu do SCCM, abychom s nimi mohli pracovat. Stručně zmíníme rozdíl v práci s Online a Offline aplikacemi. Na závěr bodově popíšeme, jak odinstalovat předinstalované Windows 10 In-Box Apps. Jedná se o aplikace z Microsoft Store, tedy (moderní) Universal Windows Apps.

Článek se věnuje využití Microsoft Store ve Windows 10 pro firemní účely, tedy s pomocí Microsoft Store for Business a Private Store. Popis je z pohledu uživatele. Jak může k aplikacím přistupovat přes web a z různých edicí Windows 10. A jak se Universal Windows Apps odinstalují.

V článku se podíváme na možnosti Azure AD pro samoobslužnou změnu či reset hesla nebo odemknutí účtu (SSPR). Zaměříme se na situaci, kdy máme On-Premises Active Directory Domain Services (AD DS) uživatele synchronizované do cloudového Azure AD. Ne tak důležité je, že se využívá Password hash synchronization (PHS). Na začátku budeme řešit zpětný zápis hesla (Password Writeback), aby se změny hesel v cloudu projevily i v On-Premises. Zmíníme pojem moderní autentizace, politiky hesel a důležité jsou ověřovací metody (Authentication methods).

Navážeme na minulý článek, který se věnoval samoobslužnému portálu na reset hesla nebo odemknutí účtu (SSPR). Podíváme se na to, co Microsoft označuje jako přihlašování bez hesla (Passwordless Sign-in). Zde za pomoci aplikace Microsoft Authenticator. Jako hlavní se budeme věnovat vícefaktorové autentizaci (Multi-Factor Authentication - MFA). Znovu si zmíníme ověřovací metody a podíváme se i na jejich správu v Azure AD / Entra ID.

Registrace počítačů a dalších zařízení (jako jsou mobilní telefony) do Azure AD nám může přinést různé výhody. Krátce zmíníme základní možnost Azure AD Device Registration. Dále se budeme věnovat Hybrid Azure AD Join. Kdy máme počítače připojené k On-Premises AD doméně, jejich účty synchronizujeme do Azure AD a počítače se zaregistrují do Azure AD. Mohou pak využívat výhody obou prostředí. V Azure AD funguje SSO a podmíněný přístup (Conditional Access).

FortiGate podporuje protokol SAML, který můžeme využít pro ověřování uživatelů. Jedno z míst, kde jej můžeme použít, je přihlašování administrátorů do webového rozhraní (GUI). A jeden ze zdrojů identity může být Microsoft Azure Active Directory (Azure AD). Ověřování vůči Azure AD nám dovoluje využít Conditional Access. Pomocí něj můžeme třeba nastavit vícefaktorové ověření (MFA). Nebo vyžadování spravovaného zařízení pro přístup.

FortiGate podporuje protokol SAML, který můžeme využít pro ověřování (autentizaci) uživatelů vůči vzdálenému serveru (podobně jako využíváme LDAP nebo RADIUS). Takto ověřené uživatele můžeme využít na různých místech. Zde se zaměříme na SSL VPN a jako Identity Provider (zdroj identity - externí ověřovací server) využijeme Microsoft Azure AD. Může jít o uživatele On-Premises AD DS domény, které synchronizujeme do Azure AD Tenantu (nebo čistě cloudové účty). Ověřování proti Azure AD nám dovoluje využít cloudovou bezpečnost. Například vícefaktorové ověření (Multi-Factor Authentication - MFA) a obecně Conditional Access.

V minulém článku jsme rozebírali možnost ověření uživatelů vůči Azure AD při přihlášení do SSL VPN. Využíval se protokol SAML a bylo možno požadovat vícefaktorové ověření (Multi-Factor Authentication - MFA). Nešlo ale zároveň použít ověření klientského certifikátu. Existuje další možnost, kdy se dá využít MFA v Azure AD, dokonce dohromady s certifikátem. Má ovšem řadu jiných omezení. Využívá se Microsoft Network Policy Server (NPS), protokol RADIUS a NPS rozšíření pro Azure MFA (NPS Extension for Azure MFA).

Článek se věnuje situaci, kdy máme Fortinet FortiGate a na něm využíváme SSL VPN. Připojování do VPN chceme více zabezpečit. Takže se rozhodneme vyžadovat vícefaktorovou autentizaci při přihlašování uživatelů. Také chceme povolit připojení do VPN pouze z firmou spravovaných zařízení. To jsou počítače zařazené do AD domény. Využíváme cloudové služby Microsoft 365, kam replikujeme účty. Jako řešení se tedy nabízí napojení FortiGate na Azure AD / Entra ID pomocí SAML 2.0. A využití Azure AD / Entra ID MFA spolu s Conditional Access Policy.

První článek o mém seznamování se s řešením Microsoft Intune pro správu firemních i soukromých zařízení s různým operačním systémem. Velmi stručně si popíšeme, co Intune je, jaké jsou licence a jak se provede úvodní nastavení. Pak se podíváme na možnosti, jak dostat zařízení s Windows 10 nebo 11 do Intune správy, tedy jak je registrovat (Enroll). Některé metody si popíšeme podrobněji. Hlavní důraz je na firemní zařízení v prostředí s využívaným Hybrid Azure AD Join.

Podíváme se na možné způsoby registrace zařízení do Azure AD / Entra ID. Zaměříme se na operační systémy macOS a Android (iOS by měl být podobný), ale popíšeme si také Windows. V druhé části rozebereme Device Authentication, tedy ověření zařízení při přihlašování do Azure AD, které můžeme využít pro identifikaci zařízení a řízení přístupu. Opět je zajímavější fungování na macOS a Android, které má určitá omezení, kdežto Windows funguje jednoduše automaticky.

Po lehkém úvodu do Intune a registraci Windows zařízení, se v druhé části podíváme, jak registrovat (Enroll) zařízení s operačním systémem macOS. Opět může jít o firemní i soukromá zařízení. Dostupných metod je v tomto případě méně. Prakticky si popíšeme ruční registraci pomocí Company Portal, i automatizovanou, kde se zapojuje Apple Business Manager.

Ve třetí části o Microsoft Intune se podíváme na konfiguraci vlastností a nastavení spravovaných zařízeních. Intune umožňuje konfigurovat ohromné množství nastavení (nejvíce pro Windows). Pro konfiguraci můžeme využít několik způsobů. Hlavní je rozmyslet, co chceme nastavit, pak již zvolíme vhodnou metodu (k detailům nám pomůže dokumentace). Druhá otázka je, zda budeme nastavení aplikovat (přiřazovat) zařízení nebo uživateli.

Ve čtvrté části o Microsoft Intune se podíváme na druhou základní funkcionalitu, což je správa aplikací. V tomto díle se zaměříme na instalaci aplikací. Na další oblasti, jako je konfigurace a zabezpečení aplikací, možná přijde řada příště. Instalace aplikací je velice široká oblast. Díky tomu, že máme širokou škálu platforem a typů aplikací (možností instalace) a také cílových zařízení. Zkusíme si popsat obecné věci. Dále se zaměříme (stále stručně) na systémy Windows a macOS. Nebudeme v tomto článku příliš řešit mobilní platformy Android a iOS, kde přibývá řada specifických oblastí (a také třeba BYOD).

Pomocí Intune můžeme řídit instalaci aktualizací na macOS zařízeních (ovšem o dost omezeněji než na Windows). Můžeme vytvářet profily pro aktualizační politiky, které nasazují aktualizace na zařízení, a/nebo konfigurovat nastavení aktualizací operačního systému. Může jít o majoritní a minoritní aktualizace operačního systému, aktualizace aplikací, konfiguračních souborů nebo firmwaru.

Intune nabízí několik možností, jak řídit instalaci aktualizací na Windows zařízeních. Využívá se služba Windows Update for Business. Pro konfiguraci v rámci Intune využijeme nejčastěji Update Rings, kde vytvoříme několik skupin a s postupným zpožděním instalujeme aktualizace. Pro aktualizace verze Windows můžeme využít novější Feature Updates Policy. Jsou i další možnost, jako je Windows Autopatch, kterým se zde skoro nevěnujeme.

Využití Multi-Factor Authentication (MFA) je dnes běžným standardem. Podíváme se na možnosti, které nabízí Microsoft pro firemní účty v Microsoft Entra ID. Toto ověřování můžeme využít v rámci Microsoft 365, ale také napojit aplikace třetích stran či naše interní aplikace. Uvedeme si, jaké ověřovací metody jsou k dispozici, a proč jsou některé více bezpečné než jiné. Popíšeme fungování různých kategorií MFA.

Po obecném popisu Microsoft Entra Multi-Factor Authentication (MFA) se podíváme více prakticky na registraci a správu ověřovacích metod. Zaměříme se na možnosti Microsoft Authenticator, v tomto případě je optimální Phone sign-in. Pak si ukážeme průběh přihlášení pomocí MFA a použití některých ověřovacích metod.

Máme situaci, kdy pro nějakou aplikaci, zde si ukážeme pro SSL VPN na Fortinet FortiGate, využíváme autentizaci uživatelů z Microsoft Entra ID pomocí SAML 2.0. Když jsme nastavovali SAML Single sign-on v rámci Enterprise Application, tak se vygeneroval self-signed certifikát s platností 3 roky. Ten se používá pro komunikaci mezi aplikací a Entra ID. Popíšeme si postup obnovy (výměny) certifikátu, když končí jeho platnost.