Felsöka Windows-autentiseringsfel

Artikel
03/05/2024

När du använder Windows-autentisering som en säkerhetsmekanism hanterar SSPI (Security Support Provider Interface) säkerhetsprocesser. När säkerhetsfel uppstår på SSPI-lagret visas de av Windows Communication Foundation (WCF). Det här avsnittet innehåller ett ramverk och en uppsättning frågor som hjälper dig att diagnostisera felen.

En översikt över Kerberos-protokollet finns i Kerberos Explained. En översikt över SSPI finns i SSPI.

För Windows-autentisering använder WCF vanligtvis SSP (Negotiate Security Support Provider), som utför Ömsesidig Kerberos-autentisering mellan klienten och tjänsten. Om Kerberos-protokollet inte är tillgängligt återgår WCF som standard till NT LAN Manager (NTLM). Du kan dock konfigurera WCF att endast använda Kerberos-protokollet (och att utlösa ett undantag om Kerberos inte är tillgängligt). Du kan också konfigurera WCF att använda begränsade former av Kerberos-protokollet.

Felsökningsmetodik

Den grundläggande metoden är följande:

Ta reda på om du använder Windows-autentisering. Om du använder något annat schema gäller inte det här avsnittet.
Om du är säker på att du använder Windows-autentisering ska du avgöra om WCF-konfigurationen använder Kerberos direct eller Negotiate.
När du har fastställt om konfigurationen använder Kerberos-protokollet eller NTLM kan du förstå felmeddelanden i rätt kontext.

Tillgänglighet för Kerberos-protokollet och NTLM

Kerberos SSP kräver att en domänkontrollant fungerar som Kerberos Key Distribution Center (KDC). Kerberos-protokollet är endast tillgängligt när både klienten och tjänsten använder domänidentiteter. I andra kontokombinationer används NTLM, som sammanfattas i följande tabell.

Tabellrubrikerna visar möjliga kontotyper som används av servern. Den vänstra kolumnen visar möjliga kontotyper som används av klienten.

	Lokal användare	Lokalt system	Domänanvändare	Domändator
Lokal användare	NTLM	NTLM	NTLM	NTLM
Lokalt system	Anonym NTLM	Anonym NTLM	Anonym NTLM	Anonym NTLM
Domänanvändare	NTLM	NTLM	Kerberos	Kerberos
Domändator	NTLM	NTLM	Kerberos	Kerberos

Mer specifikt omfattar de fyra kontotyperna:

Lokal användare: Användarprofil endast för datorer. Till exempel: MachineName\Administrator eller MachineName\ProfileName.
Lokalt system: Det inbyggda kontosystemet på en dator som inte är ansluten till en domän.
Domänanvändare: Ett användarkonto på en Windows-domän. Exempel: DomainName\ProfileName.
Domändator: En process med datoridentitet som körs på en dator som är ansluten till en Windows-domän. Exempel: MachineName\Network Service.

Kommentar

Tjänstens autentiseringsuppgifter registreras när Open -metoden för ServiceHost klassen anropas. Klientens autentiseringsuppgifter läse när klienten skickar ett meddelande.

Vanliga problem med Windows-autentisering

I det här avsnittet beskrivs några vanliga problem med Windows-autentisering och möjliga lösningar.

Kerberos-protokoll

SPN/UPN-problem med Kerberos-protokollet

När du använder Windows-autentisering och Kerberos-protokollet används eller förhandlas fram av SSPI måste url:en som klientslutpunkten använder innehålla det fullständigt kvalificerade domännamnet för tjänstens värd i tjänst-URL:en. Detta förutsätter att kontot som tjänsten körs under har åtkomst till datorns (standard) SPN-nyckel (Service Principal Name) som skapas när datorn läggs till i Active Directory-domänen, vilket oftast görs genom att köra tjänsten under nätverkstjänstkontot. Om tjänsten inte har åtkomst till datorns SPN-nyckel måste du ange rätt SPN- eller användarhuvudnamn (UPN) för det konto under vilket tjänsten körs i klientens slutpunktsidentitet. Mer information om hur WCF fungerar med SPN och UPN finns i Tjänstidentitet och autentisering.

I belastningsutjämningsscenarier, till exempel webbgrupper eller webbträdgårdar, är det vanligt att definiera ett unikt konto för varje program, tilldela ett SPN till kontot och se till att alla programtjänster körs i det kontot.

För att få ett SPN för tjänstens konto måste du vara Active Directory-domänadministratör. Mer information finns i Kerberos Tekniska tillägg för Windows.

Kerberos Protocol Direct kräver att tjänsten körs under ett domändatorkonto

Detta inträffar när egenskapen ClientCredentialType är inställd på Windows och NegotiateServiceCredential egenskapen är inställd på false, enligt följande kod.

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

Du kan åtgärda problemet genom att köra tjänsten med ett domändatorkonto, till exempel Nätverkstjänst, på en domänansluten dator.

Delegering kräver förhandling med autentiseringsuppgifter

Om du vill använda Kerberos-autentiseringsprotokollet med delegering måste du implementera Kerberos-protokollet med förhandling om autentiseringsuppgifter (kallas ibland "multi-leg" eller "multi-step" Kerberos). Om du implementerar Kerberos-autentisering utan förhandling med autentiseringsuppgifter (kallas ibland "one-shot" eller "single-leg" Kerberos) genereras ett undantag.

Utför följande steg för att implementera Kerberos med förhandling om autentiseringsuppgifter:

Implementera delegering genom att ange AllowedImpersonationLevel till Delegation.
Kräv SSPI-förhandling:
1. Om du använder standardbindningar anger du NegotiateServiceCredential egenskapen till true.
2. Om du använder anpassade bindningar anger du AuthenticationMode -attributet för elementet Security till SspiNegotiated.
Kräv att SSPI-förhandlingen använder Kerberos genom att inte tillåta användning av NTLM:
1. Gör detta i kod med följande instruktion: ChannelFactory.Credentials.Windows.AllowNtlm = false
2. Du kan också göra detta i konfigurationsfilen genom att ange allowNtlm attributet till false. Det här attributet finns i <fönstren>.

NTLM-protokoll

Negotiate SSP återgår till NTLM, men NTLM är inaktiverat

Egenskapen AllowNtlm är inställd på false, vilket gör att Windows Communication Foundation (WCF) gör det bästa för att utlösa ett undantag om NTLM används. Om du anger den här egenskapen till false kanske inte NTLM-autentiseringsuppgifter skickas via kabeln.

Följande visar hur du inaktiverar återställning till NTLM.

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

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

NTLM-inloggningen misslyckas

Klientautentiseringsuppgifterna är inte giltiga för tjänsten. Kontrollera att användarnamnet och lösenordet är korrekt inställda och motsvarar ett konto som är känt för den dator där tjänsten körs. NTLM använder de angivna autentiseringsuppgifterna för att logga in på tjänstens dator. Även om autentiseringsuppgifterna kan vara giltiga på den dator där klienten körs misslyckas inloggningen om autentiseringsuppgifterna inte är giltiga på tjänstens dator.

Anonym NTLM-inloggning sker, men anonyma inloggningar är inaktiverade som standard

När du skapar en klient AllowedImpersonationLevel är egenskapen inställd på Anonymous, som du ser i följande exempel, men som standard tillåter servern inte anonyma inloggningar. Detta beror på att standardvärdet för AllowAnonymousLogons egenskapen WindowsServiceCredential för klassen är false.

Följande klientkod försöker aktivera anonyma inloggningar (observera att standardegenskapen är 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

Följande tjänstkod ändrar standardinställningen för att aktivera anonym inloggning av servern.

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

Mer information om personifiering finns i Delegering och personifiering.

Alternativt körs klienten som en Windows-tjänst med hjälp av det inbyggda kontot SYSTEM.

Andra problem

Klientautentiseringsuppgifterna är inte korrekt inställda

Windows-autentisering använder instansen WindowsClientCredential ClientCredentials som returneras av -egenskapen för ClientBase<TChannel> klassen, inte UserNamePasswordClientCredential. Följande visar ett felaktigt exempel.

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!

Följande visar rätt exempel.

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 är inte tillgängligt

Följande operativsystem stöder inte Windows-autentisering när de används som en server: Windows XP Home Edition, Windows XP Media Center Edition och Windows Vista Home-utgåvor.

Utveckla och distribuera med olika identiteter

Om du utvecklar ditt program på en dator och distribuerar på en annan och använder olika kontotyper för att autentisera på varje dator kan det uppstå olika beteenden. Anta till exempel att du utvecklar ditt program på en Windows XP Pro-dator med hjälp av autentiseringsläget SSPI Negotiated . Om du använder ett lokalt användarkonto att autentisera med används NTLM-protokollet. När programmet har utvecklats distribuerar du tjänsten till en Windows Server 2003-dator där den körs under ett domänkonto. I det här läget kommer klienten inte att kunna autentisera tjänsten eftersom den använder Kerberos och en domänkontrollant.

Dela via