Delen via


Fouten met Windows-verificatie opsporen

Bij het gebruik van Windows-verificatie als een beveiligingsmechanisme verwerkt de Security Support Provider Interface (SSPI) beveiligingsprocessen. Wanneer er beveiligingsfouten optreden op de SSPI-laag, worden deze weergegeven door Windows Communication Foundation (WCF). Dit onderwerp bevat een framework en een set vragen om de fouten te diagnosticeren.

Zie Kerberos Explained voor een overzicht van het Kerberos-protocol. Zie SSPI voor een overzicht van SSPI.

Voor Windows-verificatie gebruikt WCF doorgaans de Negotiate Security Support Provider (SSP), waarmee Kerberos wederzijdse verificatie tussen de client en service wordt uitgevoerd. Als het Kerberos-protocol niet beschikbaar is, valt WCF standaard terug op NT LAN Manager (NTLM). U kunt WCF echter configureren om alleen het Kerberos-protocol te gebruiken (en om een uitzondering te genereren als Kerberos niet beschikbaar is). U kunt WCF ook configureren voor het gebruik van beperkte formulieren van het Kerberos-protocol.

Methodologie voor foutopsporing

De basismethode is als volgt:

  1. Bepaal of u Windows-verificatie gebruikt. Als u een ander schema gebruikt, is dit onderwerp niet van toepassing.

  2. Als u zeker weet dat u Windows-verificatie gebruikt, moet u bepalen of uw WCF-configuratie gebruikmaakt van Kerberos direct of Negotiate.

  3. Zodra u hebt vastgesteld of uw configuratie gebruikmaakt van het Kerberos-protocol of NTLM, kunt u foutberichten in de juiste context begrijpen.

Beschikbaarheid van het Kerberos-protocol en NTLM

Voor de Kerberos-SSP moet een domeincontroller fungeren als het Kerberos Key Distribution Center (KDC). Het Kerberos-protocol is alleen beschikbaar wanneer zowel de client als de service domeinidentiteiten gebruikt. In andere accountcombinaties wordt NTLM gebruikt, zoals samengevat in de volgende tabel.

In de tabelkoppen worden mogelijke accounttypen weergegeven die door de server worden gebruikt. In de linkerkolom ziet u mogelijke accounttypen die door de client worden gebruikt.

Lokale gebruiker Lokaal systeem Domeingebruiker Domeincomputer
Lokale gebruiker NTLM NTLM NTLM NTLM
Lokaal systeem Anoniem NTLM Anoniem NTLM Anoniem NTLM Anoniem NTLM
Domeingebruiker NTLM NTLM Kerberos Kerberos
Domeincomputer NTLM NTLM Kerberos Kerberos

De vier accounttypen zijn met name:

  • Lokale gebruiker: gebruikersprofiel voor alleen machines. Bijvoorbeeld: MachineName\Administrator of MachineName\ProfileName.

  • Lokaal systeem: het ingebouwde accountSYSTEEM op een computer die niet is gekoppeld aan een domein.

  • Domeingebruiker: een gebruikersaccount in een Windows-domein. Voorbeeld: DomainName\ProfileName.

  • Domeinmachine: een proces met computeridentiteit die wordt uitgevoerd op een computer die is gekoppeld aan een Windows-domein. Voorbeeld: MachineName\Network Service.

Notitie

De servicereferenties worden vastgelegd wanneer de Open methode van de ServiceHost klasse wordt aangeroepen. De clientreferentie wordt gelezen wanneer de client een bericht verzendt.

Veelvoorkomende problemen met Windows-verificatie

In deze sectie worden enkele veelvoorkomende problemen met Windows-verificatie en mogelijke oplossingen besproken.

Kerberos-protocol

SPN/UPN-problemen met het Kerberos-protocol

Wanneer u Windows-verificatie gebruikt en het Kerberos-protocol wordt gebruikt of onderhandeld door SSPI, moet de URL die het clienteindpunt gebruikt, de volledig gekwalificeerde domeinnaam van de host van de service in de service-URL bevatten. Hierbij wordt ervan uitgegaan dat het account waaronder de service wordt uitgevoerd, toegang heeft tot de spn-sleutel (service-principalnaam) van de computer (standaard) die wordt gemaakt wanneer de computer wordt toegevoegd aan het Active Directory-domein. Dit wordt meestal gedaan door de service uit te voeren onder het netwerkserviceaccount. Als de service geen toegang heeft tot de SPN-sleutel van de computer, moet u de juiste SPN- of user principal name (UPN) opgeven van het account waaronder de service wordt uitgevoerd in de eindpuntidentiteit van de client. Zie Service-identiteit en -verificatie voor meer informatie over hoe WCF werkt met SPN en UPN.

In taakverdelingsscenario's, zoals webfarms of webtuinen, is het gebruikelijk om een uniek account voor elke toepassing te definiëren, een SPN toe te wijzen aan dat account en ervoor te zorgen dat alle services van de toepassing in dat account worden uitgevoerd.

Als u een SPN wilt verkrijgen voor het account van uw service, moet u een Active Directory-domeinbeheerder zijn. Zie Kerberos Technical Supplement voor Windows voor meer informatie.

Kerberos Protocol Direct vereist dat de service wordt uitgevoerd onder een domeincomputeraccount

Dit gebeurt wanneer de ClientCredentialType eigenschap is ingesteld Windows op en de NegotiateServiceCredential eigenschap is ingesteld op false, zoals wordt weergegeven in de volgende code.

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

Voer de service uit met behulp van een domeincomputeraccount, zoals Network Service, op een computer die lid is van een domein.

Delegering vereist referentie-onderhandeling

Als u het Kerberos-verificatieprotocol met delegatie wilt gebruiken, moet u het Kerberos-protocol implementeren met referentieonderhandeling (ook wel 'multi-leg' of 'multi-step' Kerberos genoemd). Als u Kerberos-verificatie implementeert zonder referentieonderhandeling (ook wel 'one-shot' of 'single-leg' Kerberos genoemd), wordt er een uitzondering gegenereerd.

Als u Kerberos wilt implementeren met referentieonderhandelingen, voert u de volgende stappen uit:

  1. Implementeer delegering door in te stellen AllowedImpersonationLevel op Delegation.

  2. SSPI-onderhandeling vereisen:

    1. Als u standaardbindingen gebruikt, stelt u de NegotiateServiceCredential eigenschap in op true.

    2. Als u aangepaste bindingen gebruikt, stelt u het AuthenticationMode kenmerk van het Security element in op SspiNegotiated.

  3. Vereisen dat de SSPI-onderhandeling Kerberos gebruikt door het gebruik van NTLM ongedaan te maken:

    1. Doe dit in code met de volgende instructie: ChannelFactory.Credentials.Windows.AllowNtlm = false

    2. U kunt dit ook doen in het configuratiebestand door het allowNtlm kenmerk in te stellen op false. Dit kenmerk bevindt zich in de vensters>.<

NTLM-protocol

Onderhandelen over SSP valt terug naar NTLM, maar NTLM is uitgeschakeld

De AllowNtlm eigenschap is ingesteld op false, waardoor Windows Communication Foundation (WCF) een best effort kan doen om een uitzondering te genereren als NTLM wordt gebruikt. Als u deze eigenschap instelt om false te voorkomen dat NTLM-referenties via de kabel worden verzonden.

Hieronder ziet u hoe u terugval naar NTLM kunt uitschakelen.

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

Aanmelden bij NTLM mislukt

De clientreferenties zijn niet geldig voor de service. Controleer of de gebruikersnaam en het wachtwoord juist zijn ingesteld en overeenkomen met een account dat bekend is bij de computer waarop de service wordt uitgevoerd. NTLM gebruikt de opgegeven referenties om u aan te melden bij de computer van de service. Hoewel de referenties mogelijk geldig zijn op de computer waarop de client wordt uitgevoerd, mislukt deze aanmelding als de referenties niet geldig zijn op de computer van de service.

Anonieme NTLM-aanmelding vindt plaats, maar anonieme aanmeldingen zijn standaard uitgeschakeld

Wanneer u een client maakt, wordt de AllowedImpersonationLevel eigenschap ingesteld op Anonymous, zoals wordt weergegeven in het volgende voorbeeld, maar de server staat standaard anonieme aanmeldingen toe. Dit gebeurt omdat de standaardwaarde van de AllowAnonymousLogons eigenschap van de WindowsServiceCredential klasse is false.

De volgende clientcode probeert anonieme aanmeldingen in te schakelen (houd er rekening mee dat de standaardeigenschap is 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

Met de volgende servicecode wordt de standaardinstelling gewijzigd om anonieme aanmeldingen door de server in te schakelen.

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

Zie Delegatie en imitatie voor meer informatie over imitatie.

De client wordt ook uitgevoerd als een Windows-service, met behulp van het ingebouwde accountSYSTEEM.

Andere problemen

Clientreferenties zijn niet juist ingesteld

Windows-verificatie maakt gebruik van het WindowsClientCredential exemplaar dat wordt geretourneerd door de ClientCredentials eigenschap van de ClientBase<TChannel> klasse, niet de UserNamePasswordClientCredential. Hieronder ziet u een onjuist voorbeeld.

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!

Hieronder ziet u het juiste voorbeeld.

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 is niet beschikbaar

De volgende besturingssystemen bieden geen ondersteuning voor Windows-verificatie bij gebruik als server: Windows XP Home Edition, Windows XP Media Center Edition en Windows Vista Home-edities.

Ontwikkelen en implementeren met verschillende identiteiten

Als u uw toepassing op één computer ontwikkelt en op een andere computer implementeert en verschillende accounttypen gebruikt om op elke computer te verifiëren, kan er een ander gedrag optreden. Stel dat u uw toepassing ontwikkelt op een Windows XP Pro-computer met behulp van de SSPI Negotiated verificatiemodus. Als u een lokaal gebruikersaccount gebruikt om bij te verifiëren, wordt het NTLM-protocol gebruikt. Zodra de toepassing is ontwikkeld, implementeert u de service op een Windows Server 2003-computer waarop deze wordt uitgevoerd onder een domeinaccount. Op dit moment kan de client de service niet verifiëren omdat deze Kerberos en een domeincontroller gebruikt.

Zie ook