Sdílet prostřednictvím


Ř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ů. Řeší také diagnostiku složitějších problémů implementace.

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

  • Nasazení aplikačního proxy Microsoft Entra a obecné přístupy k aplikacím, které nepoužívají KCD. Další informace najdete v tématu Začínáme s proxy aplikací.
  • Publikovaná aplikace je založena na internetové informační službě (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 lesními strukturami najdete v bílé knize 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 nepokrývá scénáře ověřování pro bohaté klientské aplikace.

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žití 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 specifické lokální lokality (DC). Zkontrolujte řadič domény, který se používá, protože by se mohl změnit.

Scénáře napříč doménami se spoléhají na odkazy, které nasměrují hostitele konektoru na řadiče domény, které mohou být mimo místní síťový perimetr. V těchto případech je stejně důležité také směřovat provoz dál do řadičů domény zastupujících ostatní příslušné domény. Pokud ne, delegování selže.

Vyhněte se aktivovaným systémům prevence před průnikem (IPS) nebo systémům detekce průniku (IDS) mezi hostiteli konektorů a datacentry. 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 základní aplikace.

Nejlepším místem pro umístění spojnic je co nejblíže jejich cílům. Firewall, který je vestavěný při testování, zvyšuje zbytečnou složitost a může prodlužovat vyšetřování.

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

Snímek obrazovky, který ukazuje příklad chyby konfigurace K C D se zvýrazněnou chybou

Příklad : Autorizace selhala kvůli chybějícím oprávněním

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émů

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ává 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. Tyto komunikace pouze zajišťují, že KCD funguje. 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. V odpovědi zaznamenejte pole activity ID a timestamp. Informace pomáhají korelovat chování se skutečnými událostmi v protokolu událostí proxy aplikace.

Příklad : Nesprávná chyba konfigurace KCD

Odpovídající položky v protokolu událostí se zobrazují jako události 13019 nebo 12027. Protokoly událostí konektoru najdete 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 hlavní název služby (SPN) určeného cílového účtu. Ujistěte se, že je vybrán libovolný ověřovací protokol. Další informace najdete v článku o SSO konfiguraci .
  3. Ověřte, že ve službě Microsoft Entra ID existuje pouze jedna instance služebního hlavního názvu (SPN). Zadejte příkaz setspn -x z příkazového řádku na libovolném počítači, který je členem domény.
  4. Zkontrolujte, zda se vynucuje zásada domény, která omezuje velikost vydaných tokenů Kerberos na maximální . Zásady zabrání konektoru získat token, pokud by to bylo nadměrné.

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 naleznete v podrobném dokumentu o řešení potíží s.

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 Kerberos ticketu poskytnutého konektorem. V této fázi se očekává, že konektor odeslal lístek služby Kerberos do systému back-end. Vstupenka je záhlaví v první žádosti aplikace.

  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 konektoru řešení potíží.

  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 přítomno buď Negotiate, nebo Kerberos, zkontrolujte hlavičky webové autorizace vrácené v odpovědi z aplikace.

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

      okno kontroly sítě v prohlížeči

    • Objekt blob na tomto obrázku nezačíná kódem TIRMTVNTUAAB. V tomto příkladu je k dispozici Kerberos a Kerberosový blob nezačíná řetězcem 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 poskytovatelů. 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 Negotiate je uveden nahoře a NTLM je přímo pod ním. Pokud se zobrazí Not Negotiate, Kerberos nebo Negotiate, nebo PKU2U, pokračujte pouze v případě, že je protokol Kerberos funkční.

      zprostředkovatelé ověřování systému Windows

    • 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 backendovou 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, objeví se v prohlížeči chybové hlášení o zákazu a v protokolu se zobrazí 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.

      zobrazuje chybu HTTP 401 zakázaný přístup

    • Zkontrolujte aplikaci IIS. Ujistěte se, že nakonfigurovaný fond aplikací a SPN používají stejný účet v Microsoft Entra ID. Přejděte v IIS, jak je znázorněno na následujícím obrázku.

      okno konfigurace aplikace IIS

      Jakmile znáte identitu, ověřte, že je tento účet správně nastaven pomocí příslušného SPN. Příkladem je setspn –q http/spn.wacketywack.com. Do příkazového řádku zadejte následující text.

      zobrazuje okno příkazového okna SetSPN

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

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

      Možnost pověření pro fondy aplikací v konfiguraci IIS

      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, pokud chcete přerušit KCD, když je aplikace hostovaná na více než jednom serveru ve farmě.

  • Jako další kontrolu zakažte také rozšířenou ochranu . V některých scénářích rozšířená ochrana přerušila KCD, když byla povolena 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 zašedlá, což naznačuje, že podřízené objekty by nezdědily žádná aktivní nastavení. Doporučujeme testovat, ale nezapomeňte, pokud je to možné, tuto hodnotu obnovit na povoleno.

    Tato dodatečná kontrola vás nasměruje k použití vaší publikované aplikace. Můžete aktivovat více konektorů, které jsou také nakonfigurované pro delegování. Další informace najdete v podrobnější technickém návodu Řešení potíží s proxy aplikací Microsoft Entra.

Pokud stále nemůžete pokračovat, může vám pomoct podpora Microsoftu. Vytvořte podpůrný tiket přímo v rámci 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 lze povolit pomocí kroků uvedených v tomto dokumentu: omezené delegování protokolu Kerberos pro jednotné přihlašování.

Víceúrovňová autentizace se často používá ve scénářích, kdy je aplikace členěna do vrstev. Mezi úrovně patří zázemí (back-end) a uživatelské rozhraní (front-end). Obě úrovně vyžadují ověřování. Například SQL Server Reporting Services. Další informace najdete v tématu Konfigurace omezeného delegování protokolu Kerberos pro proxy stránky webové registrace.

Další kroky

Konfigurace KCD ve spravované doméně.