Řešení potíží s konfiguracemi omezeného delegování kerberosu (KCD) pomocí proxy aplikace Microsoft Entra

Metody jednotného přihlašování se liší od jedné aplikace po jinou. Proxy aplikace Microsoft Entra ve výchozím nastavení poskytuje omezené delegování protokolu Kerberos (KCD). Uživatelé se ověřují v privátních aplikacích pomocí protokolu Kerberos.

Tento článek obsahuje jediný odkaz na řešení nejběžnějších problémů. Zahrnuje také diagnostiku složitějších problémů s implementací.

V tomto článku se předpokládá následující předpoklady.

• Nasazení proxy aplikací Microsoft Entra a obecný přístup k aplikacím, které nejsou KCD Další informace najdete v tématu Začínáme s proxy aplikací.
• Publikovaná aplikace je založená na Internetová informační služba (IIS) a implementaci protokolu Kerberos od Microsoftu.
• Hostitelé serveru a aplikací se nacházejí v jedné doméně Microsoft Entra. Další informace o scénářích napříč doménami a doménovými strukturami najdete v dokumentu white paper KCD.
• Aplikace se publikuje v tenantovi Microsoft Entra s povoleným předběžném ověřením. Očekává se, že se uživatelé budou ověřovat pomocí ověřování založeného na formulářích. Tento článek neobsahuje scénáře ověřování klientů s bohatým obsahem.

Požadavky

Většina problémů způsobuje jednoduchou chybnou konfiguraci nebo obecné chyby. Před řešením potíží zkontrolujte všechny požadavky v používání jednotného přihlašování KCD s proxy aplikací.

Hostitelé konektorů nejsou omezeni na komunikaci pouze s konkrétním řadičem domény místní lokality (DC). Zkontrolujte, jak se řadič domény používá, protože by se mohl změnit.

Scénáře napříč doménami se spoléhají na referenční seznamy, které nasměrují hostitele konektoru na řadiče domény, které můžou být mimo hraniční síť místní sítě. V těchto případech je stejně důležité posílat provoz dál do řadičů domény, které představují jiné příslušné domény. Pokud ne, delegování selže.

Vyhněte se aktivnímu systému ochrany před neoprávněným vniknutím (IPS) nebo zařízením IDS (Vniknutí) mezi hostiteli konektorů a řadiči domény. Tato zařízení jsou příliš rušivá a ruší základní provoz vzdáleného volání procedur (RPC).

Testování delegování v jednoduchých scénářích Čím více proměnných zavedete, tím více se možná budete muset potýkat. Pokud chcete ušetřit čas, omezte testování na jeden konektor. Po vyřešení problému přidejte další konektory.

Některé faktory životního prostředí můžou také přispět k problému. Abyste se těmto faktorům vyhnuli, minimalizujte architekturu co nejvíce během testování. Běžné jsou například chybně nakonfigurované interní seznamy řízení přístupu (ACL) brány firewall. Pokud je to možné, odešlete veškerý provoz z konektoru přímo do řadičů domény a back-endové aplikace.

Nejlepším místem pro umístění spojnic je co nejblíže jejich cílům. Brána firewall, která je vložená při testování, zvyšuje zbytečnou složitost a může prodlužovat šetření.

Co ukazuje problém s KCD? Existuje několik běžných informací, že jednotné přihlašování KCD selhává. První příznaky problému se zobrazí v prohlížeči.

Oba obrázky ukazují stejný příznak: selhání jednotného přihlašování. Přístup uživatele k aplikaci byl odepřen.

Řešení problému

Oddělte řešení potíží do tří fází.

Předběžné ověřování klienta

Externí uživatel, který se ověřuje přes prohlížeč. Možnost předběžného ověření pro Microsoft Entra ID je nezbytná pro fungování jednotného přihlašování (SSO) KCD. Otestujte a vyřešte tuto schopnost, pokud dojde k nějakým problémům. Fáze předběžného ověřování nesouvisí s KCD ani publikovanou aplikací. Všechny nesrovnalosti můžete snadno opravit tak, že zkontrolujete, že účet subjektu existuje v ID Microsoft Entra. Zkontrolujte, jestli aplikace není zakázaná nebo blokovaná. Odpověď na chybu v prohlížeči je dostatečně popisná, aby vysvětlila příčinu.

Služba delegování

Privátní síťový konektor, který získá lístek služby Kerberos pro uživatele z centra distribuce klíčů Kerberos (KCD).

Externí komunikace mezi klientem a front-endem Azure nemá žádný vliv na KCD. Tato komunikace se ujistěte, že funguje jen KCD. Služba proxy aplikací poskytuje platné ID uživatele, které slouží k získání lístku Kerberos. Bez tohoto ID není KCD možné a selže.

Chybové zprávy prohlížeče poskytují několik dobrých informací o tom, proč se něco nepovede. Zaznamenejte activity ID pole a timestamp pole v odpovědi. Informace pomáhají korelovat chování se skutečnými událostmi v protokolu událostí proxy aplikace.

Odpovídající položky v protokolu událostí se zobrazují jako události 13019 nebo 12027. Vyhledejte protokoly událostí konektoru v protokolech>aplikací a služeb microsoft Microsoft>Entra private network>Connector>Admin.

1. Pro adresu aplikace použijte záznam A v interním systému DNS (Domain Name System), nikoli CName.
2. Znovu se přesvědčte, že hostitel konektoru má právo delegovat na určený hlavní název služby (SPN) určeného cílového účtu. Znovu potvrzuje, že je vybrán libovolný ověřovací protokol . Další informace najdete v článku konfigurace jednotného přihlašování.
3. Ověřte, že existuje pouze jedna instance hlavního názvu služby (SPN) v Microsoft Entra ID. Problém setspn -x z příkazového řádku na libovolném hostiteli člena domény
4. Zkontrolujte, jestli se vynucuje zásada domény, která omezuje maximální velikost vydaných tokenů Kerberos. Zásady zastaví, aby konektor získal token, pokud je příliš velký.

Trasování sítě, které zachycuje výměny mezi hostitelem konektoru a omezeným delegováním protokolu Kerberos (KDC) domény, je dalším nejlepším krokem k získání podrobnějších informací o problémech na nízké úrovni. Další informace najdete v podrobném dokumentu Poradce při potížích.

Pokud lístky vypadají dobře, v protokolech se zobrazí událost oznamující, že ověřování selhalo, protože aplikace vrátila chybu 401. Tato událost označuje, že cílová aplikace odmítla váš lístek. Přejděte do další fáze.

Cílová aplikace

Příjemce lístku Kerberos poskytnutého konektoru. V této fázi očekáváte, že konektor odeslal lístek služby Kerberos do back-endu. Lístek je hlavička v první žádosti o aplikaci.

1. Pomocí interní adresy URL aplikace definované na portálu ověřte, že je aplikace přístupná přímo z prohlížeče na hostiteli konektoru. Pak se můžete úspěšně přihlásit. Podrobnosti najdete na stránce Řešení potíží s konektorem.

2. Ověřte, že ověřování mezi prohlížečem a aplikací používá Protokol Kerberos.

3. Spusťte DevTools (F12) v Internet Exploreru nebo použijte Fiddler z hostitele konektoru. Přejděte do aplikace pomocí interní adresy URL. Abyste měli jistotu, že je k dispozici vyjednání nebo Kerberos, zkontrolujte nabízené hlavičky webové autorizace vrácené v odpovědi z aplikace.

   • Další objekt blob Kerberos, který se vrátí v odpovědi z prohlížeče do aplikace, začíná YII. Tato písmena vám říkají, že je protokol Kerberos spuštěný. Microsoft NT LAN Manager (NTLM), na druhé straně, vždy začíná s TlRMTVNTUAAB, který čte NTLM Security Support Provider (NTLMSSP) při dekódování z Base64. Pokud se na začátku objektu blob zobrazí TlRMTVNTUAAB , protokol Kerberos není k dispozici. Pokud nevidíte TlRMTVNTUAAB, je pravděpodobně k dispozici kerberos.

     Poznámka:

     Pokud používáte Fiddler, tato metoda vyžaduje, abyste dočasně zakázali rozšířenou ochranu v konfiguraci aplikace ve službě IIS.

     

   • Objekt blob na tomto obrázku nezačíná s TIRMTVNTUAAB. V tomto příkladu je k dispozici Kerberos a objekt blob Kerberos nezačíná na YII.

4. Dočasně odeberte protokol NTLM ze seznamu zprostředkovatelů na webu služby IIS. Přejděte k aplikaci přímo z Internet Exploreru na hostiteli konektoru. Protokol NTLM již není v seznamu zprostředkovatelů. K aplikaci můžete přistupovat pouze pomocí protokolu Kerberos. Pokud přístup selže, může se jednat o problém s konfigurací aplikace. Ověřování protokolem Kerberos nefunguje.

   • Pokud protokol Kerberos není dostupný, zkontrolujte nastavení ověřování aplikace ve službě IIS. Ujistěte se, že je v horní části uvedena možnost Negotiate s protokolem NTLM přímo pod ním. Pokud se zobrazí možnost Nevyjednat, Kerberos nebo Negotiate nebo PKU2U, pokračujte pouze v případě, že je protokol Kerberos funkční.

     

   • Pokud je protokol Kerberos a NTLM zavedený, dočasně zakažte předběžné ověření pro aplikaci na portálu. Zkuste k němu přistupovat z internetu pomocí externí adresy URL. Zobrazí se výzva k ověření. Můžete to udělat se stejným účtem, který jste použili v předchozím kroku. Pokud ne, je problém s back-endovou aplikací, ne S KCD.

   • Opětovné povolení předběžného ověření na portálu Ověřte se prostřednictvím Azure tím, že se pokusíte připojit k aplikaci přes její externí adresu URL. Pokud jednotné přihlašování selže, v prohlížeči se v protokolu zobrazí chybová zpráva zakázáno a událost 13022:

     Privátní síťový konektor Microsoft Entra nemůže ověřit uživatele, protože back-endový server reaguje na pokusy o ověření protokolem Kerberos s chybou HTTP 401.

     

   • Zkontrolujte aplikaci IIS. Ujistěte se, že je nakonfigurovaný fond aplikací a hlavní název služby nakonfigurované tak, aby používaly stejný účet v Microsoft Entra ID. Přejděte ve službě IIS, jak je znázorněno na následujícím obrázku.

     

     Jakmile znáte identitu, ujistěte se, že je tento účet nakonfigurovaný s hlavním názvem služby (SPN). Příklad: setspn –q http/spn.wacketywack.com. Do příkazového řádku zadejte následující text.

     

   • Zkontrolujte hlavní název služby (SPN) definovaný proti nastavení aplikace na portálu. Ujistěte se, že fond aplikací aplikace používá stejný hlavní název služby nakonfigurovaný pro cílový účet Microsoft Entra.

   • Přejděte do služby IIS a vyberte možnost Editor konfigurace pro aplikaci. Přejděte na system.webServer/security/authentication/windowsAuthentication. Ujistěte se, že hodnota UseAppPoolCredentials je True.

     

     Změňte hodnotu na True. Spuštěním příkazu odeberte všechny lístky Kerberos uložené v mezipaměti z back-endového serveru.

     Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
     

Pokud necháte režim jádra povolený, zlepší se výkon operací protokolu Kerberos. Zároveň ale způsobí, že se lístek požadované služby dešifruje pomocí účtu počítače. Tento účet se také nazývá místní systém. Nastavte tuto hodnotu na Hodnotu True, aby se přerušila hodnota KCD, pokud je aplikace hostovaná na více než jednom serveru ve farmě.

• Jako další kontrolu zakažte rozšířenou ochranu. V některých scénářích se rozšířená ochrana přerušila, když byla povolená v konkrétních konfiguracích. V takových případech byla aplikace publikována jako podsložka výchozího webu. Tato aplikace je nakonfigurovaná pouze pro anonymní ověřování. Všechna dialogová okna jsou neaktivní, což naznačuje, že podřízené objekty nezdědí žádná aktivní nastavení. Doporučujeme testovat, ale nezapomeňte tuto hodnotu obnovit, pokud je to možné.

  Tato dodatečná kontrola vás sleduje, jak používat publikovanou aplikaci. Můžete aktivovat více konektorů, které jsou také nakonfigurované pro delegování. Další informace najdete v podrobnější technickém návodu k řešení potíží s proxy aplikací Microsoft Entra.

Pokud stále nemůžete pokračovat, může vám pomoct podpora Microsoftu. Vytvořte lístek podpory přímo na portálu.

Další scénáře

Proxy aplikace Microsoft Entra před odesláním žádosti do aplikace požádá o lístek Kerberos. Některé aplikace se této metodě ověřování nelíbí. Tyto aplikace očekávají, že budou probíhat konvenční jednání. První požadavek je anonymní, což aplikaci umožňuje reagovat na typy ověřování, které podporuje prostřednictvím 401. Tento typ vyjednávání protokolu Kerberos je možné povolit pomocí kroků uvedených v tomto dokumentu: Omezené delegování protokolu Kerberos pro jednotné přihlašování.

Vícesměrové ověřování se běžně používá ve scénářích, kdy se aplikace vrství. Mezi úrovně patří back-end a front-end. Obě úrovně vyžadují ověřování. Například SQL Server Reporting Services. Další informace naleznete v tématu Konfigurace omezeného delegování protokolu Kerberos pro proxy stránky webové registrace.

Další kroky

Nakonfigurujte KCD ve spravované doméně.