Ladění chyb ověřování ve Windows

Při použití ověřování systému Windows jako mechanismu zabezpečení zpracovává rozhraní SSPI (Security Support Provider Interface) procesy zabezpečení. Pokud na vrstvě SSPI dojde k chybám zabezpečení, objeví se služba Windows Communication Foundation (WCF). Toto téma obsahuje architekturu a sadu otázek, které vám pomůžou s diagnostikou chyb.

Přehled protokolu Kerberos najdete v tématu Vysvětlení protokolu Kerberos; Přehled SSPI najdete v tématu SSPI.

Pro ověřování systému Windows WCF obvykle používá poskytovatele zabezpečení Security Support Provider (SSP) Negotiate, který provádí vzájemné ověřování Kerberos mezi klientem a službou. Pokud protokol Kerberos není k dispozici, wcf se ve výchozím nastavení vrátí do nt LAN Manageru (NTLM). Wcf však můžete nakonfigurovat tak, aby používal pouze protokol Kerberos (a pokud není k dispozici protokol Kerberos), můžete vyvolat výjimku. Wcf můžete také nakonfigurovat tak, aby používal omezené formuláře protokolu Kerberos.

Metodologie ladění

Základní metoda je následující:

Určete, jestli používáte ověřování systému Windows. Pokud používáte jiné schéma, toto téma se nevztahuje.
Pokud jste si jisti, že používáte ověřování systému Windows, určete, jestli vaše konfigurace WCF používá protokol Kerberos direct nebo Negotiate.
Jakmile zjistíte, jestli vaše konfigurace používá protokol Kerberos nebo NTLM, můžete porozumět chybovým zprávům ve správném kontextu.

Dostupnost protokolu Kerberos a NTLM

Zprostředkovatel sdílených služeb Kerberos vyžaduje, aby řadič domény fungoval jako distribuční centrum klíčů Kerberos (KDC). Protokol Kerberos je k dispozici pouze v případech, kdy klient i služba používají identity domény. V jiných kombinacích účtů se používá protokol NTLM, jak je shrnuto v následující tabulce.

Záhlaví tabulky zobrazují možné typy účtů používané serverem. V levém sloupci jsou uvedeny možné typy účtů používané klientem.

	Místní uživatel	Místní systém	Uživatel domény	Doménový počítač
Místní uživatel	NTLM	NTLM	NTLM	NTLM
Místní systém	Anonymní NTLM	Anonymní NTLM	Anonymní NTLM	Anonymní NTLM
Uživatel domény	NTLM	NTLM	Kerberos	Kerberos
Doménový počítač	NTLM	NTLM	Kerberos	Kerberos

Konkrétně tyto čtyři typy účtů zahrnují:

Místní uživatel: Profil uživatele pouze počítače. Například: MachineName\Administrator nebo MachineName\ProfileName.
Místní systém: Integrovaný účet SYSTEM na počítači, který není připojený k doméně.
Uživatel domény: Uživatelský účet v doméně Windows. Například: DomainName\ProfileName.
Doménový počítač: Proces s identitou počítače spuštěnou na počítači připojeném k doméně Windows. Například: MachineName\Network Service.

Poznámka:

Přihlašovací údaje služby se zaznamenávají, když je zavolána metoda Open třídy ServiceHost. Přihlašovací údaje klienta se čtou vždy, když klient odešle zprávu.

Běžné problémy s ověřováním systému Windows

Tato část popisuje některé běžné problémy s ověřováním Systému Windows a možné nápravy.

Protokol Kerberos

Problémy SPN/UPN s protokolem Kerberos

Při použití ověřování systému Windows, a pokud se protokol Kerberos používá nebo vyjednává pomocí SSPI, adresa URL, kterou klientský koncový bod používá, musí obsahovat plně kvalifikovaný název domény hostitele služby v adrese URL služby. Předpokládá se, že účet, pod kterým je služba spuštěná, má přístup k klíči hlavního názvu služby počítače (SPN), který se vytvoří při přidání počítače do domény služby Active Directory, což se nejčastěji provádí spuštěním služby v rámci účtu síťové služby. Pokud služba nemá přístup ke klíči hlavního názvu služby počítače (SPN), musíte zadat správný hlavní název služby nebo uživatelský hlavní název (UPN) účtu, pod kterým je služba spuštěná, v identitě koncového bodu klienta. Další informace o tom, jak WCF funguje se SPN a UPN, naleznete v tématu Identita služby a ověřování.

Ve scénářích vyrovnávání zatížení, jako jsou webové farmy nebo webové zahrady, je běžným postupem definovat jedinečný účet pro každou aplikaci, přiřadit k ho účtu hlavní název služby (SPN) a zajistit, aby se všechny služby aplikace spouštěly v tomto účtu.

Pokud chcete získat hlavní název služby (SPN) pro účet vaší služby, musíte být správcem domény služby Active Directory. Další informace naleznete v technickém dodatku Kerberos pro Windows.

Protokol Kerberos Direct vyžaduje, aby služba běžela pod účtem počítače domény.

K tomu dochází, když vlastnost ClientCredentialType je nastavena na Windows a vlastnost NegotiateServiceCredential je nastavena na false, jak je znázorněno v následujícím kódu.

WSHttpBinding b = new WSHttpBinding();
// By default, the WSHttpBinding uses Windows authentication
// and Message mode.
b.Security.Message.NegotiateServiceCredential = false;

Dim b As New WSHttpBinding()
' By default, the WSHttpBinding uses Windows authentication 
' and Message mode.
b.Security.Message.NegotiateServiceCredential = False

Aby byla služba opravena, spusťte ji pomocí účtu Network Service na počítači připojeném k doméně.

Delegování vyžaduje vyjednávání o přihlašovacích údajích.

Pokud chcete používat ověřovací protokol Kerberos s delegací, musíte implementovat protokol Kerberos s vyjednáváním autentizačních údajů (někdy označovaný jako "multi-leg" nebo "multi-step" Kerberos). Pokud implementujete ověřování protokolem Kerberos bez vyjednávání přihlašovacích údajů (někdy označované jako "jednorázové" nebo "single-leg" Kerberos), dojde k výjimce.

Pokud chcete implementovat Protokol Kerberos s vyjednáváním přihlašovacích údajů, proveďte následující kroky:

Implementovat delegování nastavením AllowedImpersonationLevel na Delegation.
Vyžadovat vyjednávání SSPI:
1. Pokud používáte standardní vazby, nastavte vlastnost NegotiateServiceCredential na hodnotu true.
2. Pokud používáte vlastní vazby, nastavte AuthenticationMode atribut elementu Security na SspiNegotiated.
Vyžadovat, aby vyjednávání SSPI používalo protokol Kerberos tím, že zakáže použití protokolu NTLM.
1. Udělejte to v kódu pomocí následujícího příkazu: ChannelFactory.Credentials.Windows.AllowNtlm = false
2. Nebo to můžete udělat v konfiguračním souboru nastavením atributu allowNtlm na false. Tento atribut je obsažen v oknech<>.

Protokol NTLM

Vyjednávání SSP přepne na NTLM, ale NTLM je zakázán

Vlastnost AllowNtlm je nastavena na false, což způsobí, že Windows Communication Foundation (WCF), pokouší se co nejlépe vyvolat výjimku, pokud je použita NTLM. Nastavením této vlastnosti na false nemusí zabránit odesílání přihlašovacích údajů NTLM po síti.

Následující příklad ukazuje, jak zakázat záložní použití protokolu NTLM.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.Windows.AllowNtlm = false;

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.Windows.AllowNtlm = False

Přihlášení NTLM se nezdařilo

Přihlašovací údaje klienta nejsou ve službě platné. Zkontrolujte, jestli jsou uživatelské jméno a heslo správně nastavené a odpovídají účtu známému počítači, na kterém je služba spuštěná. NTLM používá zadané přihlašovací údaje k přihlášení k počítači služby. I když přihlašovací údaje můžou být platné v počítači, na kterém je klient spuštěný, přihlášení selže, pokud přihlašovací údaje nejsou platné v počítači služby.

K anonymnímu přihlášení NTLM dochází, ale anonymní přihlášení jsou ve výchozím nastavení zakázaná.

Při vytváření klienta je AllowedImpersonationLevel vlastnost nastavena na Anonymous, jak je znázorněno v následujícím příkladu, ale ve výchozím nastavení server zakáže anonymní přihlášení. K tomu dochází, protože výchozí hodnota AllowAnonymousLogons vlastnosti WindowsServiceCredential třídy je false.

Následující kód klienta se pokusí povolit anonymní přihlášení (všimněte si, že výchozí vlastnost je Identification).

CalculatorClient cc =
    new CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.Windows.AllowedImpersonationLevel =
System.Security.Principal.TokenImpersonationLevel.Anonymous;

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.Windows.AllowedImpersonationLevel = _
System.Security.Principal.TokenImpersonationLevel.Anonymous

Následující kód služby změní výchozí nastavení pro povolení anonymních přihlášení serverem.

Uri httpUri = new Uri("http://localhost:8000/");
ServiceHost sh = new ServiceHost(typeof(Calculator), httpUri);
sh.Credentials.WindowsAuthentication.AllowAnonymousLogons = true;

Dim httpUri As New Uri("http://localhost:8000/")
Dim sh As New ServiceHost(GetType(Calculator), httpUri)
sh.Credentials.WindowsAuthentication.AllowAnonymousLogons = True

Další informace o zosobnění najdete v tématu Delegování a zosobnění.

Případně je klient spuštěný jako služba systému Windows pomocí integrovaného účtu SYSTEM.

Další problémy

Přihlašovací údaje klienta nejsou správně nastaveny.

Ověřování systému Windows používá WindowsClientCredential instanci vrácenou ClientCredentials vlastností ClientBase<TChannel> třídy, nikoli UserNamePasswordClientCredential. Následující text ukazuje nesprávný příklad.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.UserName.UserName = GetUserName(); // wrong!
cc.ClientCredentials.UserName.Password = GetPassword(); // wrong!

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.UserName.UserName = GetUserName() ' wrong!
cc.ClientCredentials.UserName.Password = GetPassword() ' wrong!

Následující ukazuje správný příklad.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
// This code returns the WindowsClientCredential type.
cc.ClientCredentials.Windows.ClientCredential.UserName = GetUserName();
cc.ClientCredentials.Windows.ClientCredential.Password = GetPassword();

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
' This code returns the WindowsClientCredential type.            
cc.ClientCredentials.Windows.ClientCredential.UserName = GetUserName()
cc.ClientCredentials.Windows.ClientCredential.Password = GetPassword()

SSPI není k dispozici.

Následující operační systémy nepodporují ověřování systému Windows při použití jako server: Windows XP Home Edition, Windows XP Media Center Edition a Windows Vista Home edition.

Vývoj a nasazení s různými identitami

Pokud vyvíjíte aplikaci na jednom počítači a nasazujete na jiný a používáte různé typy účtů k ověřování na každém počítači, můžete zaznamenat jiné chování. Předpokládejme například, že vyvíjíte aplikaci na počítači s Windows XP Pro pomocí SSPI Negotiated režimu ověřování. Pokud k ověření použijete místní uživatelský účet, použije se protokol NTLM. Po vytvoření aplikace nasadíte službu na počítač s Windows Serverem 2003, na kterém běží pod účtem domény. V tomto okamžiku klient nebude moct službu ověřit, protože bude používat Protokol Kerberos a řadič domény.

Viz také

Last updated on 2025-06-17

Sdílet prostřednictvím