Úvod Azure AD Connect

V interní síti potřebujeme server, kde nainstalujeme Azure AD Connect a zde bude probíhat synchronizace údajů. Ten má přístup k citlivým údajům lokálně i v cloudu, takže jej musíme dobře zabezpečit. Pokud potřebujeme vyšší dostupnost, tak můžeme instalovat i další server, který je ovšem pasivní (Staging mode) Provide High Availability for Azure AD Connect

Komunikace se inicializuje ze serveru s AAD Connect, takže není potřeba otevírat žádné porty dovnitř sítě. Dříve bylo možno vytvořit Site to Site VPN a skrze ni provozovat synchronizaci, to nyní Microsoft nepodporuje.

Na internetu je mnoho návodů na instalaci. Například videa Setup On Premise Active Directory Sync to Office 365, Azure AD - #2 - AzureAD Connect. Detailní obrázky How to Install and Configure Azure AD Connect. Návody v češtině Synchronizace AD do Azure Active Directory: přehled možností. A mnoho oficiální dokumentace Azure AD Connect sync: Understand and customize synchronization.

Na začátku je potřeba rozhodnout a připravit několik důležitých věcí. Na některé se podíváme dále. Základní příprava je Prerequisites for Azure AD Connect, Hybrid Identity Required Ports and Protocols.

Autentizace uživatelů

Důležité rozhodnutí je, jak se budou uživatelé ověřovat (přihlašovat). Azure AD Connect user sign-in options

Možnosti autentizace (metody přihlášení uživatele) jsou

• Password hash synchronization (PHS) - s účty se do cloudu synchronizuje i hash hesla, ověření tedy probíhá v cloudu, po změně hesla musí dojít k synchronizaci, může se i synchronizovat zpět do AD DS
• Pass-through authentication (PTA) - v lokální síti běží agenti, kteří provádí ověření uživatelů proti on-premises AD DS, musí tedy stále fungovat komunikace (je vyvolávána z interní sítě do online prostředí)
• Federated authentication - musíme mít zprovozněn federační systém, primárně Active Directory Federation Services

První dvě možnosti PHS a PTA označuje Microsoft jako Cloud Authentication. Azure AD zpracovává ověřovací proces.

Seamless Single Sign-On

Pro PHS a PTA můžeme povolit Single Sign-On. Azure Active Directory Seamless Single Sign-On: Quickstart. Při přístupu ke cloudovým aplikacím z počítačů v doméně, není potřeba zadávat heslo (zadává se uživatelské jméno), dojde ke Kerberos SSO. V prohlížečích se přidává adresa https://autologon.microsoftazuread-sso.com jako povolená pro Kerberos. V lokální doméně se vytvoří počítačový účet AZUREADSSOACC.

Pass-through authentication (PTA)

Pro PTA se instaluje AzureAD Authentication Agent (Pass-through Authentication Agent - PTA). Jedna instance se nainstaluje spolu s Azure AD Connect. Je doporučeno mít 3 instance (stažení je také z Azure AD Admin Center). Lidé se často ptají, jestli je možno instalovat agenta na doménový řadič. Microsoft to nikde oficiálně neuvádí, ale řada lidí to tak používá.

Microsoft návody

• Tutorial: Integrate a single AD forest using pass-through authentication (PTA)
• Microsoft 365 integration with on-premises environments
• Azure Active Directory Pass-through Authentication: Quickstart

Password Hash Synchronization (PHS)

Microsoft tuto metodu doporučuje a uvádí, že je bezpečná. Do Azure AD se nedostanou hesla, ale pouze speciálně vytvořený hash (bezpečnější než ten, který je v On-Premises AD DS). Synchronizace hashů hesla neprobíhá spolu se synchronizací adresáře, ale samostatně každé 2 minuty. Synchronizace přepíše existující hesla v cloudu.

Pokud dojde ke změně hesla v On-Premises, tak by se mělo velmi rychle projevit i v cloudu. Můžeme také povolit Password Write-Back, který zajistí synchronizaci při změně v cloudu. Pak můžeme využít například samoobslužné resetování hesla v Azure AD (self-service password reset).

Zapnutí PHS neovlivní aktuální session (aktuálně přihlášené uživatele), projeví se až při dalším požadavku na ověření. Zvážit musíme politiky hesel (Password complexity policy, Password expiration policy). Do Azure AD se synchronizují (a fungují) i hesla, která nesplňují podmínky na složitost v Azure AD. Uživatelé, kteří mají synchronizovaný hash hesla, jsou standardně bez vypršení (Never Expire). Defaultně také není funkční Force Password Change on Next Logon.

Více informací Implement password hash synchronization with Azure AD Connect sync

Změna metody přihlášení uživatele

Metody můžeme v průběhu jednoduše měnit. Spustíme Azure AD Connect a využijeme úkol Change user sign-in. Mělo by být bezproblémové, možná je složitější při změně s AD FS. Některá dokumentace obsahuje info, že dochází ke konverzi uživatelů. Novější uvádí, že toto se již neděje.

Dokumentace Changing the user sign-in method, Migrate from federation to password hash synchronization for Azure Active Directory

On-premises AD DS s neveřejnou (neroutovatelnou) doménou

Dříve se doporučovalo, aby se pro Active Direcotry doménu použil neveřejný název, například firma.local. Oproti doméně využívané v internetu, například firma.cz. Již před nějakou dobou se názor změnil, a hlavně kvůli používání cloudových služeb, se obecně doporučuje využít shodný název pro interní AD doménu i veřejnou doménu firmy, například firma.cz. Každá varianta má své výhody i nevýhody. Stejná doména je jednodušší pro uživatele, často pak mají stejné uživatelské jméno jako emailovou adresu. Ale je také jednodušší pro útočníky. V obou případech musíme určitým způsobem řešit DNS záznamy pro interní servery vs. veřejně dostupné.

V Azure AD nastavujeme ověřenou doménu (asi nechceme využívat počáteční defaultní firma.onmicrosoft.com), což musí být veřejná doména v naší správě. Ta se pak používá v přihlašovacím jméně uživatelů, v emailových adresách apod. Pokud chceme, aby měli uživatelé stejné přihlašovací údaje online v Azure, jako v on-premises adresáři, tak musí Azure AD doména odpovídat internímu UPN suffixu. Microsoft vše popisuje v Prepare a non-routable domain for directory synchronization, Azure AD UserPrincipalName population.

Je zde uvedeno, že se synchronizují pouze účty s User Principal Names (UPN) obsahující ověřenou doménu. Ale pokud UPN obsahuje neroutovatelnou (neveřejnou) doménu, tak se zamění za počáteční (defaultní doménu). Tedy z bouska@firma.local se stane bouska@firma.onmicrosoft.com.

Abychom pro přihlášení nemuseli využívat počáteční doménu, tak máme několik možností. Možná by stačilo použít alternativní login ID, tedy jako Azure AD uživatelské jméno (User Principal Names) zvolit on-premises atribut mail. To jsem netestoval. Další možnost je přejmenovat lokální doménu, což je pracné a má mnoho dopadů.

Nový UPN Suffix

Existuje relativně jednoduché řešení, které by nemělo nic podstatného ovlivnit. Jde o přidání Alternative UPN Suffix s veřejnou doménou. Ten jednoduše přidáme pomocí Active Directory Domains and Trusts kliknutím na Properties. Pak jej musíme přiřadit uživatelským účtům.

Každý účet může mít pouze jedno UPN, takže by vznikla obava, že se již nepůjde přihlašovat původním tvarem bouska@firma.local, když nastavíme bouska@firma.cz. Před lety jsem dělal testy s uživatelskými účty a vše popsal v Kerberos část 2 - AD uživatelské účty a Service Principal Name.

Z toho plynou následující možnosti přihlašování:

• pouze uživatelské jméno, pokud se automaticky doplňuje doména - bouska
• sAMAccountName (NetBIOS logon name) - firma\bouska
• uživatelské jméno s doménou (Implicit UPN) - bouska@firma.local
• User Principal Names (UPN) - bouska@firma.cz

Změnit UPN můžeme skupině uživatelů v jednom kontejneru jednoduše pomocí PowerShellu.

$LocalUsers = Get-ADUser -SearchBase "OU=Administrativa,DC=firma,DC=local" -Filter "UserPrincipalName -like '*firma.local'" -Properties userPrincipalName -ResultSetSize $null
$LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("@firma.local","@firma.cz"); $_ | Set-ADUser -UserPrincipalName $newUpn}

Microsoft Azure Active Directory Connect

Nainstalujeme AzureADConnect.msi (defaultně se instaluje s MS SQL Express) a projdeme průvodce. Poslední verzi můžeme stáhnout Azure AD connect. Můžeme zvolit Express instalaci nebo více nastavení pomocí Customize. V průběhu se přihlásíme účtem Global Admin Azure AD. Připojíme se k AD Forest a přihlásíme jako Enterprise Admin. Standardně necháme vytvořit lokální účet, pod kterým bude probíhat synchronizace.

Upgrade Azure AD Connect

Microsoft striktně doporučuje udržovat Azure AD Connect na posledních verzích. Dokument Azure AD Connect: Upgrade from a previous version to the latest popisuje různé metody, jak provádět upgrade. Standardně by měl fungovat automatický upgrade Automatic upgrade. Pomocí PowerShellu můžeme zjistit, zda jej máme povolený. Přesto mi ani na testu ani v provozu neprobíhal. Dokumentace uvádí, že můžeme zkontrolovat určité události v aplikačním logu, ale zdroj událostí Azure AD Connect Upgrade se mi vůbec nenabízí. Také jsou zde důvody, kdy není automatický upgrade podporovaný. Například, když používáme vlastní synchronizační pravidla.

Další možnost je In-place upgrade, popis je v Microsoft dokumentaci. Průběh je takový, že stáhneme novou verzi AzureADConnect.msi a spustíme. Proběhne určitá instalace a spustí se průvodce upgradem. Ten aktualizuje engine, nakonfiguruje a aktualizuje komponenty, pravidla a služby. Po skončení se spustí synchronizace (v určitých případech úplná).

Filtrování objektů pro synchronizaci

Důležitá volba je filtrování účtů uživatelů a zařízení, která se mají synchronizovat do Azure AD. Můžeme vybrat domény a organizační jednotky (OU) pro synchronizaci. Také můžeme nastavit, že se synchronizují pouze účty, které jsou zařazeny do definované skupiny. To mi přijde fajn, na začátku chceme určitě otestovat na vybraných účtech, hodit se to může i v budoucnu (záleží, jak vhodně máme organizované OU). Nevýhoda je, že nejsou podporovány vnořené skupiny (účty musí být přímo v této skupině). Také, že je skupina zadána pomocí Distinguished Name (DN), pokud ji tedy přesuneme do jiné OU, tak přestane synchronizace fungovat.

Optional features

Mezi Optional features se nachází řada položek, které záleží na našich požadavcích. Důležité je například Exchange hybrid deployment, pokud budeme v budoucnu chtít řešit hybridní Exchange. Všechna nastavení můžeme měnit dodatečně, když spustíme nainstalovanou aplikaci Azure AD Connect.

Změna nastavení

Nastavení, které jsme provedli při instalaci, můžeme kdykoliv upravit spuštěním nainstalované aplikace Azure AD Connect. Většinu voleb měníme pomocí Customize synchronization options nebo Change user sign-in. Pomocí View or export current configuration si můžeme zobrazit základní informace. Například jaká doména se synchronizuje, jaký účet se používá, jaký atribut se používá jako UPN a Sourche Anchor, apod. Pokud dojde ke změně schématu on-premises adresáře (třeba se aktualizuje Exchange, který mění schéma), tak se hodí volba Refresh directory schema.

Provoz Azure AD Connect

Po nainstalování Azure AD Connect získáme několik aplikací

• Azure AD Connect
• Synchronization Service
• Synchronization Service WebService Connector Config
• Synchronization Rules Editor

Kontrola synchronizace

Pomocí grafického nástroje Synchronization Service můžeme kontrolovat průběh synchronizace (případně ji i vyvolat). Na záložce Connectors jsou vidět (standardně) dva konektory, jeden do on-premises AD DS a druhý do Azure AD. Můžeme si prohlédnout základní parametry nebo vyvolat jednotlivé operace.

Na záložce Operations vidíme historii synchronizace. Běžně se na počátku provede Initial Synchronization a následně po 30 minutách (můžeme změnit) probíhá Delta Synchronization. Synchronizace se skládá z několika operací nad oběma konektory. Můžeme se doklikat až na jednotlivé objekty a jejich detaily.

Vyvolání synchronizace

Nejjednodušší je použít PowerShell. Poprvé musíme importovat modul

Import-Module -Name "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync" -Verbose

Poté můžeme jednoduše vyvolat rozdílovou synchronizaci (a v GUI sledovat průběh).

PS C:\> Start-ADSyncSyncCycle -PolicyType Delta
 Result
------
Success

Můžeme si i zobrazit (a měnit) nastavení plánovače. Azure AD Connect sync: Scheduler

PS C:\> Get-ADSyncScheduler
AllowedSyncCycleInterval            : 00:30:00
CurrentlyEffectiveSyncCycleInterval : 00:30:00
CustomizedSyncCycleInterval         : 
NextSyncCyclePolicyType             : Delta
NextSyncCycleStartTimeInUTC         : 12.08.2020 10:38:59
PurgeRunHistoryInterval             : 7.00:00:00
SyncCycleEnabled                    : True
MaintenanceEnabled                  : True
StagingModeEnabled                  : False
SchedulerSuspended                  : False
SyncCycleInProgress                 : True

Kontrola stavu v Azure AD

V Azure Active Directory Admin Center se nachází Azure AD Connect. Zde vidíme hlavní údaje o stavu synchronizace a přihlašování uživatelů. Je zde odkaz Azure AD Connect Health, kde můžeme nalézt chyby synchronizace.

Zamykání účtů Smart Lockout

V Azure AD můžeme konfigurovat zamykání účtu (defaultně je zapnuté) Protect user accounts from attacks with Azure Active Directory smart lockout.

Vystavení nových Kerberos klíčů pro Seamless single sign-on

Pokud používáme SSO pro Azure AD, tak Microsoft doporučuje každých 30 dní vystavit nové klíče pro počítačový účet AZUREADSSOACC v On-Premises AD lese. V Azure Active Direcotry admin center zobrazuje varování, pokud jsou klíče starší. Postup se nachází v Azure Active Directory Seamless Single Sign-On: Frequently asked questions kapitola How can I roll over the Kerberos decryption key of the AZUREADSSO computer account?.

Zjednodušený postup, jak provést v PowerShellu:

cd 'C:\Program Files\Microsoft Azure Active Directory Connect'
Import-Module .\AzureADSSO.psd1
New-AzureADSSOAuthenticationContext
Update-AzureADSSOForest

Zobrazí se dialog nejprve na přihlášení do Azure AD. Při aktualizaci na přihlášení do lokální AD, kde je potřeba zadat uživatelské jméno ve tvaru domena\uzivatel.

Princip synchronizace uživatelských účtů

V Azure AD / Microsoft 365 můžeme kombinovat cloudové účty a synchronizované z on-premises. V seznamu uživatelů je sloupec Sync status / Directory synced. To určuje, kde je účet primárně spravován (a kde je možno editovat vybrané atributy).

Source Anchor Attribute

Po první synchronizaci se účty on-premises AD a Azure AD spojí pomocí ID. Azure zapisuje hodnotu Source Anchor zpět do on-premises adresáře. Defaultně se používá atribut ms-DS-ConsistencyGuid (pokud není využit, při první instalaci Azure AD Connect je možno zvolit jiný atribut). V Azure AD je tato hodnota uložena v atributu ImmutableId. Hodnota se vytváří z atributu ObjectGUID pomocí operace ToBase64String($user.ObjectGUID.tobytearray()).

Azure AD Connect: objectGUID vs. mS-DS-ConsistencyGuid, Part 1

Synchronizace účtů

Při synchronizaci Azure AD Connect načítá všechny účty a pak používá zadané filtry. Pokud máme nastaveno, že se synchronizují pouze členové určité skupiny, tak musíme účet zařadit do skupiny. Pokud později účet ze skupiny odstraníme, tak při další synchronizaci dojde k jeho smazání v Azure AD a přemístí se mezi Deleted users. Při vrácení do skupiny se opět obnoví.

Pomocí PowerShellu můžeme zařadit do skupiny třeba všechny účty v určitém kontejneru.

$LocalUsers = Get-ADUser -SearchBase "OU=Administrativa,DC=firma,DC=local" -Filter *
$LocalUsers | ForEach-Object {Add-ADGroupMember -Identity "G AzureAD Users" -Members $_}

Při synchronizaci se rozhoduje, zda jde o nový účet nebo již spárovaný pomocí Source Anchor, pak se synchronizují případné změny. Pro nový účet se hledá, zda neexistuje odpovídající účet v Azure AD. Pokud ne, tak se vytvoří nový účet. Většina hodnot se přenáší pouze z lokálního AD do Azure AD (opačně pouze vybrané atributy, třeba pro Hybrid Exchange).

Spojení existujících uživatelů

Microsoft přímo uvádí, že se běžně předpokládá, že začínáme s novým (prázdným) Azure AD Tenant. V praxi může být situace, že provozujeme Azure AD, kde jsme vytvořili řadu uživatelů. Ti jsou zařazení do skupin, mají přiřazené licence, napsali různé příspěvky na Sharepoint a Teams apod. Ty samé uživatele máme také v lokálním AD. Později se rozhodneme, že chceme využít Connect a účty sjednotit.

Microsoft má nyní stručný a přehledný článek Azure AD Connect: When you have an existing tenant (před pár měsíci byl jeho obsah jiný).

Při synchronizaci se pro každý nový objekt on-premises AD pokouší najít odpovídající existující objekt Azure AD. Odpovídající objekt se hledá metodou:

• Hard Match - porovnává se Source Anchor (atribut immutableID), vyhodnocuje Connect i Azure AD
• Soft Match - porovnává se atribut userPrincipalName a proxyAddresses (primární emailová adresa, která má SMTP velkými písmeny), vyhodnocuje pouze Azure AD

Pokud se nalezne existující objekt v Azure AD, tak se změní z cloud-managed na on-premises managed. Všechny atributy objektu, které mají hodnotu v on-premises AD a jsou synchronizovány, se přepíší v Azure AD on-premises hodnotou. Ale vlastní účet, a jeho vazby, zůstává. Může se také změnit heslo (buď se přepíše nebo se začne provádět autentizace jinde), kterým se k účtu uživatel ověřuje.

Pokud se nalezne účet pomocí Soft Match, tak se přidá Source Anchor atribut do Azure AD a ten se synchronizuje zpět do on-premises AD. Stejně jako při vytvoření nového účtu.

Azure AD admin role

Pokud má existující cloud účet v Azure AD přiřazenu nějakou admin roli, tak nedojde k jeho spárování s odpovídajícím on-premises uživatelem. Je to ochrana, aby omylem nezískal administrátorská oprávnění neoprávněný uživatel. Pokud synchronizace proběhne, a takové účty existují, tak skončí ne moc jasnou chybou AttributeValueMustBeUnique. Řešení je cloud uživateli odebrat admin role, provést synchronizaci a role opět vrátit.

Soft Match pomocí userPrincipalName

Pokud máme existující uživatele v Azure AD a chceme je spojit s on-premises AD uživateli, tak většinou chceme, aby měli stejné přihlašovací jméno. Tudíž máme odpovídající userPrincipalName na obou stranách. Pak proběhne napoprvé Soft Match úplně automaticky a bez problémů. Já jsem při začátku hledání hlavně narážel na články zmiňující SMTP matching, jako How to use SMTP matching to match on-premises user accounts to Office 365 user accounts for directory synchronization. A zcela zbytečně dělal pokusy s nastavováním emailových adres.

Problémy a manuální nastavení Source Anchor

Pokud máme v on-premises AD neveřejnou doménu a vytvářeli jsme alternativní UPN sufix s veřejnou doménou, tak nesmíme zapomenout změnit UPN uživatelům, které budeme synchronizovat. Pokud to neuděláme, tak se pravděpodobně nespáruje účet s existujícím účtem v cloudu, ale vytvoří se nový s UPN jmeno@firma.onmicrosoft.com. Zároveň se přiřadí Source Anchor cloud uživateli a přenese zpět on-premises uživateli. Takže když následně opravíme UPN a cloud uživatele smažeme, tak synchronizace neprovede očekávané spárování, ale dojde k chybě.

Řešení této, a dalších problematických situací, je ruční nastavení atributu Source Anchor v Azure AD. Popis je v článku Merge on-premise with existing Azure AD user. V Azure AD smažeme nově vytvořený účet a hodnotu ID lokálního uživatele nastavíme na správný účet v Azure AD.

PowerShell pro Source Anchor

Níže jsou PowerShell příkazy pro zjištění informací a nastavení lokálně i v Azure AD.

Připojení do Azure AD

Install-Module -Name AzureAD
Connect-AzureAD

Zobrazení informací o účtu z Azure AD

Get-AzureADUser -ObjectId bouska@firma.cz | FT DisplayName, UserPrincipalName, Mail, UserType, DirSyncEnabled, ObjectId, ImmutableId

Zobrazení (porovnání) ID uživatele v on-premises AD, který byl synchronizován do Azure AD

$user = Get-ADUser bouska -Properties *
[System.Convert]::ToBase64String($user.'mS-DS-ConsistencyGuid')
sArNGJz9FE1233TVtxmP9w==
[System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())
sArNGJz9FE1233TVtxmP9w==

Nalezení Azure AD účtu podle ImmutableId

Get-AzureADUser -Filter "ImmutableId eq 'sArNGJz9FE1233TVtxmP9w=='"

Nastavení ImmutableId na účet v Azure AD

Set-AzureADUser -ObjectId bouska@firma.cz -ImmutableId 'sArNGJz9FE1233TVtxmP9w=='

Kontrola synchronizovaných atributů

Pomocí nástroje Synchronization Service můžeme také vyhledat objekty a podívat se na synchronizované atributy a pravidla. Na záložce Metaverse Search vybereme typ objektu a zadáme filtrovací parametry. Tlačítko Search zobrazí odpovídající objekty. Ty můžeme rozklinout a zobrazit vlastnosti.

Ve vlastnostech se můžeme přepnout na Connectors, kde můžeme otevřít objekt pro daný konektor. Zde je i tlačítko Preview, které zobrazí, jak by proběhla synchronizace (volíme Full nebo Delta) pro daný objekt. Změny můžeme následně uplatnit. Vidíme zde velmi detailně atributy, pravidla, co a jak se mění.

Změna mapování atributů

Po instalaci Azure AD Connect se nastaví defaultní synchronizační pravidla (Synchronization Rules), která definují, jaké objekty a atributy se jakým způsobem synchronizují. Prohlížet, vytvářet nová či editovat pravidla můžeme pomocí nástroje Synchronization Rules Editor. Pokud potřebujeme například nastavit, aby se nějaký atribut z on-premises AD přenášel do jiného atributu v Azure AD. Tak to relativně jednoduše můžeme. Podrobný popis je v článku Azure AD Connect sync: Make a change to the default configuration (další zajímavá informace How to Extract Azure AD Connect Attribute Mapping).

Neměli bychom upravovat existující pravidla, ale pro změnu chování vytvoříme nové pravidlo a nastavíme mu nižší prioritu (Precedence). V pravidle určujeme zdrojový systém, typ objektu, filtrování zdrojových objektů (třeba, aby přenášená hodnota nebyla prázdná) a vlastní transformaci. FlowType Direct pro přímý přenos hodnoty nebo Expression, pokud přidáváme nějakou funkci, cílový atribut, zdrojový atribut (nebo výraz/funkci) a typ spojení.

Problémy s přihlašováním uživatelů s Pass-through Authentication - Timeout

Najednou se začal objevovat problém, když se uživatel hlásil k nějaké Microsoft službě, kde zadával do formuláře uživatelské jméno a heslo, tak to velmi často neprošlo (přihlásil se třeba až na 4 pokus). Chyba či chování bylo různé. Služba na webu dokola zobrazovala přihlašovací dialog. Některé aplikace zobrazily chybu, že je špatné jméno, heslo nebo doména. Nejvíce informací se zobrazilo v PowerShellu, při přihlášení ke cloudovým službám.

New-CsOnlineSession : One or more errors occurred.: AADSTS80014: Validation request responded after maximum elapsed time exceeded.

Základní informace o řešení problém poskytuje článek Troubleshoot Azure Active Directory Pass-through Authentication.

Samozřejmost je zkontrolovat v Azure Active Direcotry admin center, že jsou agenti ve stavu Active. Docela dobré jsou logy v sekci Monitoring - Sign-ins, buď pro celé Azure AD nebo vybraného uživatele. Zde je hezky vidět průběh ověřování, včetně řady událostí stavu Failure. V detailech jsem nalezl podobné informace, jako zobrazil PowerShell.

Sign-in error code: 80014
Failure reason: Validation request responded after maximum elapsed time exceeded.

Podle článku se při této chybě má vytvořit Ticket na Support. Procházel jsem logy na jednotlivých AzureAD Authentication Agent, ale nic moc jsem nenalezl.

Nakonec jsem zkusil prostě restartovat službu Microsoft Azure AD Connect Authentication Agent na všech serverech, kde agent běží, a vypadá to, že se problém vyřešil. Prostě vypnout a zapnout by měl člověk zkoušet jako první.

Vzhled přihlašovací stránky

Zajímavá možnost je nastavit firemní grafiku (Company branding) pro přihlašovací stránku (a několik dalších míst). Nastavujeme obrázek na pozadí, logo, můžeme změnit některé texty. Když se uživatel přihlašuje k některé službě Microsoft 365 (pokud neproběhne SSO). Nejprve zadá přihlašovací jméno (emailovou adresu), čímž se identifikuje Tenant, následně obrazovka pro zadání hesla již má firemní grafiku. Případně se některé služby dají volat s určením Tenantu. Změní se také odhlašovací stránka a na řadě míst se zobrazuje nastavené firemní logo.

Můžeme zde také zablokovat volbu zůstat přihlášen (Keep me signed in), která využívá Cookie a obchází ověřování po dobu 180 dnů.

Více informací Add branding to your organization's Azure Active Directory sign-in page. Nastavení se provádí v Azure Active Directory Admin Center - Company branding.