Self-Service Password Reset (SSPR) v Microsoft Entra ID: Průvodce nasazením pro snížení helpdesk ticketů (2026)

Aktualizováno: 17. srpna 2026

Self-Service Password Reset (SSPR) v Microsoft Entra ID je funkce, která umožňuje uživatelům resetovat vlastní heslo bez volání na helpdesk – u organizací s dobře nastaveným rolloutem snižuje objem ticketů na reset hesla o 60–80 % a průměrné MTTR z desítek minut na méně než dvě. V tomto průvodci pro rok 2026 najdete kompletní plán nasazení: pilotní skupinu, Password Writeback pro hybridní AD, migraci na Authentication Methods Policy, přípravu na povinnou registraci ověřovacích metod od září 2026 a metriky, které budete sledovat, abyste rollout obhájili u vedení.

• SSPR v Entra ID typicky snižuje objem ticketů na reset hesla o 60–80 % a šetří přibližně 70 USD za jeden reset, pokud rollout doprovodí kombinovaná registrace a komunikace.
• V hybridním prostředí musíte zapnout Password Writeback přes Entra Connect Sync nebo lehčí Cloud Sync agent verze 1.1.977.0+, jinak se změna hesla nedostane do on-premises AD DS.
• Legacy MFA a SSPR politiky byly Microsoftem deprecated k 30. září 2025 a veškeré ověřovací metody se dnes spravují pouze v Authentication Methods Policy.
• Od září 2026 bude Entra ID pro SSPR vyžadovat, aby měl uživatel explicitně zaregistrované ověřovací metody – neregistrovaní uživatelé budou při resetu odmítnuti.
• K nasazení potřebujete minimálně licenci Microsoft Entra ID P1 pro cloudové účty a Entra ID P1 pro on-premises writeback; Entra ID Free umožňuje pouze self-service change, ne reset zapomenutého hesla.
• Dlouhodobý cíl helpdesku by neměl být „rychlejší resety“, ale passkey/FIDO2 deployment, kde objem resetů asymptoticky klesá k nule.

Co je SSPR a proč šetří rozpočet helpdesku

Microsoft Entra Self-Service Password Reset (SSPR) je cloudová služba, která uživateli umožní resetovat nebo odemknout vlastní účet, pokud si zapomene heslo nebo se dostane do lockoutu. Uživatel prokáže identitu jednou nebo dvěma z předem registrovaných metod (Microsoft Authenticator, telefonní číslo, alternativní e-mail, FIDO2 klíč, případně bezpečnostní otázky) a nastaví si nové heslo. V hybridním scénáři je nové heslo v reálném čase zapsáno zpět do on-premises Active Directory přes Password Writeback.

Z pohledu IT operations to znamená konec nejnudnějšího ticketu ve frontě. V mém posledním deploymentu tvořily resety hesel 34 % objemu tier-1 ticketů – a přitom měly nejvyšší first-contact resolution rate ze všech kategorií, protože technik jen kliknul na „Reset password“ v AD Users and Computers. To je definice práce, která by nikdy neměla přijít k člověku. SSPR je řešení, které tuto práci přesune na uživatele bez toho, aby se snížila bezpečnost – naopak, správně nakonfigurované SSPR s MFA je bezpečnější než helpdesk technik, který přes telefon ověřuje volajícího podle jména a data narození.

Klíčové je ale slovo správně. Špatně nasazené SSPR – například bez pilotu, bez registrační kampaně nebo s příliš přísnými politikami – zvýší objem ticketů, protože si uživatelé začnou stěžovat, že jim něco nefunguje. Zbytek tohoto průvodce je o tom, jak se této pasti vyhnout.

Ekonomika ticketů: kolik reset hesla skutečně stojí

Buďme upřímní: bez čísel je jakákoli diskuse o SSPR jen názor. Průmyslové benchmarky pro rok 2026 (Gartner, HDI, Forrester) se shodují na následujících hodnotách, které používám při obhajobě rolloutu u CFO:

• Přímý náklad na jeden reset ticket: 60–75 USD (medián ~70 USD). Zahrnuje čas technika, ztrátu produktivity a náklady na ticketing platformu.
• Ztráta produktivity uživatele: 15–30 minut na incident (čekání ve frontě + přihlašování po resetu).
• Objem ticketů v typické enterprise organizaci: 20–50 resetů na 1 000 uživatelů měsíčně, s peaky v pondělí ráno a po dovolených.
• MTTR bez SSPR: 20–90 minut podle SLA a doby dne.
• MTTR se správně nasazeným SSPR: pod 2 minuty (uživatel si resetuje heslo sám).

Jednoduchá kalkulace: organizace s 5 000 uživateli a průměrem 30 resetů na 1 000 uživatelů měsíčně řeší 150 ticketů měsíčně × 70 USD = 10 500 USD měsíčně. Při realistickém 70% snížení po zavedení SSPR to je 7 350 USD úspor měsíčně, tedy zhruba 88 000 USD ročně jen na přímých nákladech, bez započtení produktivity a bez započtení psychologického efektu (technici tier-1 mají volnou kapacitu na řešení skutečně zajímavých incidentů, což snižuje fluktuaci).

Doporučuji tyto metriky zachytit před rolloutem jako baseline – jinak nemáte s čím po rolloutu srovnávat. Konkrétně: měsíční počet ticketů kategorie „Password Reset“, medián MTTR, First Contact Resolution (FCR) a poměr resetů ve špičce (pondělí 8–10) vůči zbytku týdne. Tato baseline vám za tři měsíce ospravedlní licenční upgrade P1 u finančního oddělení.

Předpoklady, licence a plán nasazení

SSPR má tři licenční úrovně, které se často zaměňují:

Licence	Self-service password change	Reset zapomenutého hesla (cloud)	Password Writeback (hybrid)
Entra ID Free	Ano	Ne	Ne
Microsoft 365 Apps / Business Basic	Ano	Ano	Ne
Entra ID P1 nebo P2	Ano	Ano	Ano

Pro drtivou většinu firem se smíšeným prostředím (Entra ID + on-premises AD DS) to znamená Entra ID P1 jako minimum. P1 licence je součástí Microsoft 365 E3/A3/Business Premium, takže mnoho organizací ji už má a jen ji nezapíná.

Před zahájením rolloutu si zkontrolujte tento checklist:

1. Entra ID P1 licence přiřazená všem cílovým uživatelům (SSPR neběží na uživatelích bez licence, i když je v pilotní skupině).
2. Aktuální verze Entra Connect Sync (2.4+) nebo Cloud Sync agenta (1.1.977.0 nebo vyšší) pro Password Writeback.
3. Otevřený outbound HTTPS provoz na port 443 z Entra Connect serveru na Azure Service Bus (např. ssprdedicatedsbprodfra-1.servicebus.windows.net).
4. Povolený TLS 1.2 na Entra Connect serveru a .NET Framework 4.8+.
5. Hybrid Identity Administrator role pro admin, který bude konfigurovat writeback.
6. Definovaný pilot: 30–50 IT-friendly uživatelů, ideálně z různých oddělení.

Krok za krokem: SSPR pro pilotní skupinu

Toto je nejrychlejší cesta z nulového deploymentu do funkčního pilotu:

1. Vytvořte v Entra ID skupinu SSPR-Pilot-Users (bezpečnostní, statická). Naplňte ji 30–50 uživateli.
2. V Entra Admin Center jděte na Protection → Password reset → Properties.
3. Nastavte Self service password reset enabled na hodnotu Selected a vyberte skupinu SSPR-Pilot-Users.
4. V sekci Authentication methods zvolte minimálně 2 metody a povolte alespoň Microsoft Authenticator (push notification) a telefon (SMS/hovor). Bezpečnostní otázky nechte vypnuté – v roce 2026 je považujeme za slabou metodu a Microsoft je ani neumí spravovat v nové Authentication Methods Policy.
5. V Registration nastavte Require users to register when signing in na Yes a Number of days before users are asked to re-confirm na 180.
6. V Notifications zapněte Notify users on password resets a Notify all admins when other admins reset their password – oba jsou zdarma a citelně zlepší auditovatelnost.
7. Nechte pilot běžet minimálně 2 týdny. Sledujte Sign-in logs, Audit logs a helpdesk kategorii „SSPR issue“.

Uživatel v pilotu se při dalším přihlášení uvidí kombinovanou registrační stránku aka.ms/setupsecurityinfo. Pokud už dříve zaregistroval MFA, jsou metody přenesené – nemusí registrovat dvakrát. Reset hesla probíhá na aka.ms/sspr a průchod trvá 30–90 sekund.

Kombinovaná registrace MFA a SSPR

Historicky Entra ID rozlišovalo dvě samostatné registrace – jednu pro MFA a druhou pro SSPR. Uživatelé tak byli nuceni registrovat metody dvakrát, což bylo zdrojem velké části původních ticketů („Nemůžu se dostat k resetu, i když MFA funguje“). Kombinovaná registrace (Combined Security Information Registration) tento problém řeší tím, že obě funkce sdílejí jednu sadu registrovaných metod.

Od dubna 2023 je kombinovaná registrace zapnutá by default pro všechny nové tenanty. Pokud spravujete starší tenant, ověřte to na Entra Admin Center → Protection → Authentication methods → Settings → Users can use the combined security information registration experience. Musí být Enabled.

Praktické důsledky pro rollout:

• Pokud jste už dříve zaváděli MFA, drtivá většina uživatelů má metody registrované a SSPR pro ně bude fungovat okamžitě. Toto je nejrychlejší způsob, jak dostat SSPR do produkce bez rozsáhlé komunikační kampaně.
• Uživatelé bez MFA (typicky service účty, které SSPR stejně nechcete povolit) je potřeba explicitně vyloučit ze skupiny SSPR.
• Kombinovaná registrace respektuje Authentication Methods Policy – pokud v ní zakážete SMS, uživatelé si SMS nemohou registrovat ani pro SSPR ani pro MFA.

Pokud spravujete i on-premises účty a lockouty, doporučuji si zároveň projít náš postup pro nalezení příčiny zamykání účtů v Active Directory. Značná část lockoutů má technický původ (uložené staré heslo v mapované síťové jednotce, mobilní Exchange klient), který ani SSPR nevyřeší, dokud zdroj neodstraníte.

Password Writeback: Connect Sync vs. Cloud Sync

V hybridním prostředí je Password Writeback funkce, která propíše heslo změněné v cloudu zpět do on-premises AD DS v reálném čase. Bez ní by měl uživatel po SSPR resetu funkční cloud heslo, ale doménové přihlášení do notebooku by nefungovalo – což je scénář, který okamžitě ticketuje. Writeback můžete implementovat dvěma způsoby, které se liší nároky na infrastrukturu a rozsahem podpory:

Vlastnost	Entra Connect Sync	Entra Cloud Sync
Instalace	Plný server (Windows Server, SQL LocalDB)	Lehký agent na doménovém serveru
Minimální verze	2.4+	1.1.977.0+ agenta
Podpora více domén	Jedna Entra Connect instance na tenant	Více disconnected domén (M&A scénáře)
Filtrování atributů	Plné (miiskmu.exe)	Základní, přes Entra portál
Password Writeback	Ano	Ano (od 1.1.977.0)
Podpora Azure operated by 21Vianet	Ano	Ne
Doporučení pro nové deploymenty	Legacy tenants, komplexní filtry	Preferováno pro nové rollouty

Zapnutí writebacku pro Connect Sync: v Entra Admin Center jděte na Protection → Password reset → On-premises integration a zaškrtněte Write back passwords to your on-premises directory. Pokud jsou detekovány Cloud Sync agenti, můžete dodatečně zaškrtnout Write back passwords with Microsoft Entra Connect Cloud Sync.

Detailní postup a přesná nastavení najdete v oficiální dokumentaci na Microsoft Learn: Enable Cloud Sync SSPR writeback. Ta obsahuje i PowerShell skript pro reset oprávnění na servisním účtu, který doporučuji spustit vždy před go-live – prostor pro chyby v Kerberos-based delegaci je zde velký.

Ze zkušenosti: pro nové deploymenty v roce 2026 jednoznačně preferuji Cloud Sync. Agent má menší memory footprint, updatuje se automaticky přes Microsoft Update, nemá závislost na SQL a přežije reboot doménového řadiče lépe než plný Entra Connect. Jediné důvody pro plný Entra Connect jsou komplexní atributové mapování, staré scénáře jako Exchange Hybrid s writeback do Exchange atributů, nebo nasazení v Azure operated by 21Vianet.

Migrace na Authentication Methods Policy

Do roku 2025 měli administrátoři tři místa, kde se dala povolit ověřovací metoda: legacy MFA policy, legacy SSPR policy a novější Authentication Methods Policy. Entra při registraci šel řetězcem – nejdřív nová policy, pak legacy MFA, nakonec legacy SSPR. Výsledkem bylo, že tři administrátoři mohli nastavit tři různé věci a nikdo přesně nevěděl, co je aktuálně platné.

Microsoft to zjednodušil: 30. září 2025 byly legacy MFA i SSPR policy oficiálně deprecated. Od tohoto data spravujete všechny metody na jednom místě: Entra Admin Center → Protection → Authentication methods → Policies. Pokud jste migraci nedokončili, dostali jste jednu ze dvou nepříjemností: buď se legacy nastavení ignorují (uživatelé mohou skončit bez povolené metody a nemohou se přihlásit), nebo se disabled (nemůžete metody spravovat starým způsobem, ale novým ještě nejsou nakonfigurované).

Pokud jste ještě nezmigrovali (v roce 2026 už to je vzácné, ale stává se to u opuštěných tenantů), postup je:

1. Otevřete Authentication methods policy a klikněte na Manage migration.
2. Stav Pre-migration ponechte, dokud v nové policy nezapnete všechny metody, které používali vaši uživatelé.
3. Přepněte na Migration in Progress – v tomto stavu se čte nová policy, ale legacy nastavení jsou fallback (bezpečná varianta).
4. Otestujte pilotem 1–2 týdny.
5. Přepněte na Migration Complete. Legacy policy jsou od této chvíle ignorovány.

Změna září 2026: povinná registrace ověřovacích metod

Do září 2026 Microsoft ohlásil další zpřísnění: SSPR bude vyžadovat, aby měl uživatel explicitně zaregistrované ověřovací metody, které vyhovují Authentication Methods Policy. Dnes existují edge case scénáře, kdy Entra při resetu akceptovala i metody „zděděné“ z předchozí legacy konfigurace. Po září 2026 tento fallback zmizí a uživatelé bez registrovaných metod uvidí při pokusu o SSPR chybovou stránku.

Praktické důsledky:

• Spusťte v příštích 4 týdnech audit registrací – kolik uživatelů má registrovanou nejméně jednu metodu vyhovující vaší politice.
• Uživatele bez registrace zařaďte do Registration Campaign, která je při přihlášení donutí přidat Microsoft Authenticator.
• Zvažte povinnou registraci alespoň dvou metod – jedna zařízení (telefon) může být ztraceno, druhá (alternate email nebo FIDO2 klíč) je záchranný pás.
• Připravte helpdesk skript pro uživatele, kteří po 7. září 2026 uvidí novou chybu SSPR – většina bude potřebovat asistovanou registraci, ne reset.

Podrobný časový plán a přesné podmínky Microsoft publikuje v Microsoft Learn: Manage authentication methods migration. Sledujte i Message Center v Microsoft 365 Admin Center pod ID MC-změn na klíčové slovo „SSPR“.

Řešení nejčastějších chyb SSPR

A teď to důležité: tři chyby, se kterými se v roce 2026 setkávám nejčastěji, a jak je řešit (pořadí je podle četnosti v mém trackeru za poslední rok):

SSPR_0009: „Password reset hasn't been enabled by your administrator“

Uživatel není členem skupiny povolené pro SSPR, nebo administrátor omylem přepnul politiku zpět na None. Ověřte na Password reset → Properties, že uživatel je v cílové skupině. Pokud používáte dynamickou skupinu, ověřte i její pravidlo – běžný footgun je pravidlo user.accountEnabled -eq true, které vyloučí čerstvě obnovené účty.

SSPR_0029: „On-premises configuration error“

Password Writeback selhal. Postup:

# Na Entra Connect serveru zkontrolujte poslední chybu
Get-WinEvent -LogName Application -MaxEvents 50 |
    Where-Object { $_.ProviderName -like '*PasswordReset*' -or $_.Message -like '*writeback*' } |
    Format-Table TimeCreated, Id, LevelDisplayName, Message -AutoSize

# Ověření TLS 1.2 (běžte jako admin)
$tls = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name SchUseStrongCrypto -ErrorAction SilentlyContinue
if ($tls.SchUseStrongCrypto -ne 1) {
    Write-Warning 'TLS 1.2 není vynucen. Nastavte SchUseStrongCrypto=1 a restartujte server.'
}

# Test dostupnosti Azure Service Bus
Test-NetConnection -ComputerName 'ssprdedicatedsbprodfra-1.servicebus.windows.net' -Port 443

Nejčastější příčiny SSPR_0029 v mém trackeru: (1) firewall neopený na 443/HTTPS pro Service Bus, (2) blokovaný TLS 1.2 kvůli starému Windows Serveru 2012 R2, (3) heslo servisního účtu (MSOL_...) resetované administrátorem bez následného re-runu Entra Connect wizarda.

„The password change failed to write back“ v Audit Logu

Tato chyba znamená, že Entra dostal cloud reset, ale AD DS ho odmítl. Nejčastěji kvůli Password Policy on-premises – uživatel nastavil heslo, které vyhovuje Entra ID Password Protection, ale ne on-premises Fine-Grained Password Policy (FGPP). Sjednoťte politiky. Také zkontrolujte, že MSOL_ účet má na uživatelské OU delegována práva „Reset password“, „Change password“, „Read lockoutTime“ a „Write lockoutTime“.

Kompletní katalog chybových kódů najdete v Microsoft Learn: Troubleshoot self-service password reset.

PowerShell reporting a Registration Campaigns

Pro reporting registrace SSPR používám Microsoft Graph PowerShell SDK – Azure AD PowerShell modul je od března 2024 deprecated a v roce 2026 už jen omezeně funkční.

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All','User.Read.All','Reports.Read.All'

# Report všech uživatelů a jejich zaregistrovaných metod
$users = Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,AccountEnabled |
    Where-Object AccountEnabled

$report = foreach ($u in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $u.Id
    [pscustomobject]@{
        UPN                = $u.UserPrincipalName
        DisplayName        = $u.DisplayName
        MethodCount        = $methods.Count
        HasAuthenticator   = [bool]($methods | Where-Object { $_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.microsoftAuthenticatorAuthenticationMethod' })
        HasPhone           = [bool]($methods | Where-Object { $_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.phoneAuthenticationMethod' })
        HasFido2           = [bool]($methods | Where-Object { $_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.fido2AuthenticationMethod' })
        SsprReady          = $methods.Count -ge 2
    }
}

$report | Export-Csv .\sspr-readiness.csv -NoTypeInformation -Encoding UTF8
$report | Where-Object { -not $_.SsprReady } | Measure-Object | Select-Object -ExpandProperty Count

Výstupem je CSV a číslo uživatelů, kteří nejsou ready. Ten spouštím jako scheduled task každé pondělí ráno a poslední řádek ukládám do Log Analytics workspace, kde si tvořím trendový graf. Přidávám k němu i sloupec „Adopted SSPR reset in last 30 days“ (data z Audit Logu, aktivita Reset password (self-service)) – to je moje severní hvězda.

Pro dotažení neregistrovaných uživatelů použijte Registration Campaign: Entra Admin Center → Protection → Authentication methods → Registration campaign. Nastavte Nudge users to set up Microsoft Authenticator na Enabled a zvolte, kolikrát po sobě může uživatel prompt odložit (doporučuji 3, pak vynutit). Kampaň běží mezi standardními přihlášeními, takže není potřeba žádná komunikace ze strany IT.

Cesta k passwordless

SSPR je taktické vítězství, ale strategicky je to pořád jen efektivnější způsob práce s heslem. Skutečný cíl v roce 2026 je passwordless – nasazení passkeys (FIDO2), Windows Hello for Business a certifikátové autentizace na spravovaných zařízeních. Data z tenantů, které jsem migroval, ukazují jasný pattern:

• Rok 1: SSPR nasazeno → počet resetů klesá o 60–80 %.
• Rok 2: passkey rollout pro spravovaná zařízení → počet resetů dál klesá o dalších 70–90 %.
• Rok 3: passkeys povinné pro nové účty, hesla ponechávána jen jako emergency fallback → počet resetů se blíží nule, měřitelný v jednotkách měsíčně na tisíce uživatelů.

Zajímavá souvislost: organizace, které nasadily Windows LAPS pro rotaci lokálních administrátorských hesel a BitLocker recovery key v Entra ID, mají typicky i vyzrálejší identity plane a passwordless migrace je pro ně mnohem jednodušší. Passkey je z pohledu helpdesku „přenosné zařízení, které nikdy nezapomenete“ – pokud ho uživatel ztratí, přejde na nové zařízení stejným procesem jako po ztrátě telefonu, což je věc, na kterou už dnes existuje standardní playbook.

Nevidím žádný dobrý argument, proč v roce 2026 začínat s hesly. Passwordless-first je nová default pozice; SSPR je jen most tam, kde ještě hesla máte.

Co změřit příští měsíc

Popravdě, rollout, který neměříte, se nikdy neobhájí u vedení. Toto jsou čtyři metriky, které si nastavuji na dashboard hned první den po pilotu (a byly by první, co bych si nastavil, kdybych zítra restartoval kariéru u nového klienta):

1. SSPR Registration Rate: procento aktivních uživatelů, kteří mají zaregistrované alespoň dvě metody. Cíl: 95 %+ do 90 dnů od zahájení Registration Campaign.
2. SSPR Usage Rate: počet úspěšných self-service resetů za měsíc / celkový počet resetů (self-service + helpdesk). Cíl: 70 %+ do konce prvního čtvrtletí.
3. MTTR pro Password Reset kategorii: medián času od otevření ticketu do vyřešení. Cíl: pod 5 minut (protože zbývající tickety jsou hlavně asistované registrace, ne skutečné resety).
4. Deflection Ratio: procentuální pokles počtu reset ticketů oproti baseline. Cíl: −60 % za tři měsíce, −80 % za šest.

Reportujte je měsíčně stakeholderům a vždy je párujte s dolarovou hodnotou (počet ušetřených ticketů × 70 USD). To je jazyk, kterému rozumí finanční ředitel, a to je člověk, který schvaluje váš další automatizační projekt.

Často kladené otázky

Jaký je rozdíl mezi self-service password change a self-service password reset?

Password change je situace, kdy uživatel zná staré heslo a chce ho změnit; funguje i s Entra ID Free licencí. Password reset je situace, kdy uživatel heslo zapomněl a musí prokázat identitu jinou metodou; vyžaduje Entra ID P1 nebo vyšší, nebo Microsoft 365 licenci s cloudovým SSPR.

Můžu SSPR povolit jen pro některé uživatele?

Ano. V Entra Admin Center → Password reset → Properties zvolte Selected a vyberte jednu bezpečnostní skupinu (statickou nebo dynamickou). Nested groups jsou podporovány, ale v Admin Center můžete současně vybrat pouze jednu top-level skupinu; pro víc scope skupin použijte nested membership nebo Microsoft Graph API.

Fungují bezpečnostní otázky i po přechodu na Authentication Methods Policy?

Ano, ale spravují se stále v legacy SSPR policy – Microsoft je zatím nemigroval do nové Authentication Methods Policy. Doporučuji je vypnout a nahradit silnějšími metodami (Microsoft Authenticator, FIDO2), protože jsou zdaleka nejzranitelnější vůči sociálnímu inženýrství.

Co se stane, když neprovedu migraci na Authentication Methods Policy?

Legacy MFA i SSPR policy byly deprecated k 30. září 2025. Po tomto datu se legacy nastavení buď ignorují (uživatelé mohou skončit bez povolené metody), nebo je nelze editovat starým způsobem. Riskujete výpadek přihlašování včetně Global Adminů, což může vést k tenant-wide lockoutu.

Kolik ticketů typicky ušetří SSPR v prvním roce?

Průmyslový benchmark je 60–80% snížení objemu password-related ticketů při správně provedeném rolloutu s kombinovanou registrací a Registration Campaign. Při průměrné ceně 70 USD za ticket to je pro organizaci s 5 000 uživateli řádově 80 000–100 000 USD ročně na přímých nákladech.

Musím zapnout Password Writeback, pokud jsme čistě cloudová organizace?

Ne. Writeback je potřeba jen v hybridním scénáři, kde synchronizujete uživatele z on-premises Active Directory přes Entra Connect Sync nebo Cloud Sync. Cloud-only tenant má reset kompletně v Entra ID a žádnou další konfiguraci nepotřebuje.