Megosztás a következőn keresztül:


Windows-hitelesítési hibák hibakeresése

Ha a Windows-hitelesítést biztonsági mechanizmusként használja, a Biztonsági támogatási szolgáltató felülete (SSPI) kezeli a biztonsági folyamatokat. Ha biztonsági hibák lépnek fel az SSPI-rétegben, azokat a Windows Communication Foundation (WCF) felszínre helyezi. Ez a témakör keretrendszert és kérdéseket tartalmaz a hibák diagnosztizálásához.

A Kerberos protokoll áttekintését lásd: Kerberos Explained; az SSPI áttekintéséhez lásd az SSPI-t.

Windows-hitelesítés esetén a WCF általában az Egyeztetés biztonsági támogatási szolgáltatót (SSP) használja, amely Kerberos kölcsönös hitelesítést végez az ügyfél és a szolgáltatás között. Ha a Kerberos-protokoll nem érhető el, a WCF alapértelmezés szerint visszaesik az NT LAN Manager (NTLM) szolgáltatásba. Konfigurálhatja azonban a WCF-et úgy, hogy csak a Kerberos protokollt használja (és kivételt állít be, ha a Kerberos nem érhető el). Konfigurálhatja a WCF-et a Kerberos protokoll korlátozott formáinak használatára is.

Hibakeresési módszertan

Az alapszintű módszer a következő:

  1. Határozza meg, hogy Windows-hitelesítést használ-e. Ha bármilyen más sémát használ, ez a témakör nem érvényes.

  2. Ha biztos abban, hogy Windows-hitelesítést használ, állapítsa meg, hogy a WCF-konfiguráció a Kerberos direct vagy a Negotiate szolgáltatást használja-e.

  3. Miután megállapította, hogy a konfiguráció a Kerberos protokollt vagy az NTLM-et használja-e, a megfelelő környezetben értelmezheti a hibaüzeneteket.

A Kerberos Protocol és az NTLM rendelkezésre állása

A Kerberos SSP megköveteli, hogy egy tartományvezérlő Kerberos-kulcsterjesztési központként (KDC) működjön. A Kerberos protokoll csak akkor érhető el, ha az ügyfél és a szolgáltatás is tartományi identitásokat használ. Más fiókkombinációkban az NTLM-et használja a rendszer az alábbi táblázatban összefoglalt módon.

A táblafejlécek a kiszolgáló által használt lehetséges fióktípusokat jelenítik meg. A bal oldali oszlop az ügyfél által használt lehetséges fióktípusokat jeleníti meg.

Helyi felhasználó Helyi rendszer Tartományi felhasználó Tartományi gép
Helyi felhasználó NTLM NTLM NTLM NTLM
Helyi rendszer Névtelen NTLM Névtelen NTLM Névtelen NTLM Névtelen NTLM
Tartományi felhasználó NTLM NTLM Kerberos Kerberos
Domaingép NTLM NTLM Kerberos Kerberos

A négy fióktípus a következő:

  • Helyi felhasználó: Csak gépi felhasználói profil. Például: MachineName\Administrator vagy MachineName\ProfileName.

  • Helyi rendszer: A beépített fiókrendszer egy olyan gépen, amely nem csatlakozik tartományhoz.

  • Tartományi felhasználó: Windows-tartomány felhasználói fiókja. Például: DomainName\ProfileName.

  • Tartománygép: Windows-tartományhoz csatlakoztatott gépen futó gépi identitással rendelkező folyamat. Például: MachineName\Network Service.

Megjegyzés:

A szolgáltatás hitelesítő adatait az Open osztály metódusának meghívásakor rögzíti a ServiceHost rendszer. Az ügyfél hitelesítő adatai mindig beolvasva lesznek, amikor az ügyfél üzenetet küld.

Gyakori Windows-hitelesítési problémák

Ez a szakasz néhány gyakori Windows-hitelesítési problémát és lehetséges megoldást ismertet.

Kerberos Protocol

Kerberos-protokollal kapcsolatos SPN-/UPN-problémák

Ha Windows-hitelesítést használ, és a Kerberos protokollt az SSPI használja vagy egyezteti, akkor az ügyfélvégpont által használt URL-címnek tartalmaznia kell a szolgáltatás gazdagépének teljes tartománynevét a szolgáltatás URL-címében. Ez feltételezi, hogy a szolgáltatás futtatásához használt fiók hozzáféréssel rendelkezik a számítógép (alapértelmezett) egyszerű szolgáltatásnév (SPN) kulcsához, amely akkor jön létre, amikor a számítógép hozzá lesz adva az Active Directory-tartományhoz, amelyet leggyakrabban a szolgáltatás hálózati szolgáltatásfiók alatti futtatásával lehet elvégezni. Ha a szolgáltatás nem fér hozzá a számítógép SPN kulcsához, meg kell adnia annak a fióknak a megfelelő SPN-t vagy felhasználói főnevet (UPN), amely alatt a szolgáltatás az ügyfél végponti identitásában fut. A WCF spn és UPN használatával való működésével kapcsolatos további információkért lásd: Service Identity and Authentication.

Terheléselosztási forgatókönyvek, például webfarmok vagy webkertek esetében gyakori eljárás, hogy minden alkalmazáshoz egyedi fiókot határozunk meg, hozzárendelünk egy SPN-t az adott fiókhoz, és biztosítjuk, hogy az alkalmazás összes szolgáltatása ebben a fiókban fusson.

Az Ön szolgáltatásának fiókjához tartozó SPN (szolgáltatás-princípál név) beszerzéséhez Active Directory tartományi rendszergazdának kell lennie. További információ: Kerberos Technical Supplement for Windows.

A Kerberos Protocol Direct megköveteli, hogy a szolgáltatás tartománygép-fiók alatt fusson

Ez akkor fordul elő, ha a ClientCredentialType tulajdonság be van állítva Windows , és a NegotiateServiceCredential tulajdonság értéke falseaz alábbi kódban látható.

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

A probléma megoldásához futtassa a szolgáltatást egy Domain gépfiókkal rendelkező gépen, például a Network Service használatával, egy tartományhoz csatlakoztatott gépen.

A delegáláshoz hitelesítő adatok egyeztetése szükséges

Ha a Kerberos hitelesítési protokollt delegálással szeretné használni, a Kerberos protokollt hitelesítő adatok egyeztetésével kell implementálnia (más néven "több láb" vagy "többlépéses" Kerberos). Ha a Kerberos-hitelesítést a hitelesítő adatok egyeztetése nélkül valósítja meg (amit néha "egylövetű" vagy "egylábas" Kerberosnak is neveznek), akkor kivétel keletkezik.

A Kerberos hitelesítő adatok egyeztetésével történő implementálásához hajtsa végre a következő lépéseket:

  1. Delegálás megvalósítása úgy, hogy a AllowedImpersonationLevel elemet beállítja Delegation-re.

  2. SSPI-egyeztetés megkövetelése:

    1. Ha standard kötéseket használ, állítsa a NegotiateServiceCredential tulajdonságot true értékre.

    2. Ha egyéni összeköttetéseket használ, állítsa be az AuthenticationMode elem attribútumát a(z) Security elemben a SspiNegotiated értékre.

  3. Az SSPI-egyeztetés megkövetelése a Kerberos használatához az NTLM használatának letiltásával:

    1. Tegye ezt kódban a következő utasítással: ChannelFactory.Credentials.Windows.AllowNtlm = false

    2. Ezt a konfigurációs fájlban is megteheti az allowNtlm attribútum falsebeállításával. Ez az attribútum az <ablakokban> található.

NTLM-protokoll

Az SSP visszavált az NTLM-re, azonban az NTLM le van tiltva.

A AllowNtlm tulajdonság értéke false, amely arra készteti a Windows Communication Foundation (WCF)-et, hogy megkíséreljen kivételt dobni, ha az NTLM-t használják. Ha ezt a tulajdonságot úgy állítja be, hogy false nem akadályozza meg az NTLM hitelesítő adatainak átvitelét a vezetéken keresztül.

Az alábbiakban bemutatjuk, hogyan tilthatja le az NTLM-hez való visszalépést.

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

NTLM bejelentkezés sikertelen

Az ügyfél hitelesítő adatai érvénytelenek a szolgáltatásban. Ellenőrizze, hogy a felhasználónév és a jelszó helyesen van-e beállítva, és megfelel-e a szolgáltatást futtató számítógép által ismert fióknak. Az NTLM a megadott hitelesítő adatokkal jelentkezik be a szolgáltatás számítógépére. Bár a hitelesítő adatok érvényesek lehetnek azon a számítógépen, amelyen az ügyfél fut, ez a bejelentkezés sikertelen lesz, ha a hitelesítő adatok érvénytelenek a szolgáltatás számítógépén.

Névtelen NTLM-bejelentkezés történik, de a névtelen bejelentkezések alapértelmezés szerint le vannak tiltva

Ügyfél létrehozásakor a AllowedImpersonationLevel tulajdonság értéke Anonymousaz alábbi példában látható, de alapértelmezés szerint a kiszolgáló letiltja a névtelen bejelentkezéseket. Ez azért fordul elő, mert a(z) AllowAnonymousLogons osztály WindowsServiceCredential tulajdonságának alapértelmezett értéke false.

Az alábbi ügyfélkód megpróbálja engedélyezni a névtelen bejelentkezéseket (vegye figyelembe, hogy az alapértelmezett tulajdonság 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

Az alábbi szolgáltatáskód módosítja az alapértelmezett beállítást a névtelen bejelentkezések kiszolgáló általi engedélyezéséhez.

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

A megszemélyesítésről további információt a Delegálás és megszemélyesítés című témakörben talál.

Másik lehetőségként az ügyfél Windows-szolgáltatásként fut a beépített fiókrendszer használatával.

Egyéb problémák

Az ügyfél hitelesítő adatai nincsenek megfelelően beállítva

A Windows-hitelesítés a WindowsClientCredential osztály ClientCredentials tulajdonsága által visszaadott ClientBase<TChannel> példányt használja, nem a UserNamePasswordClientCredential. Az alábbiakban egy helytelen példát mutatunk be.

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!

Az alábbiakban a helyes példát mutatjuk be.

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()

Az SSPI nem érhető el

A következő operációs rendszerek nem támogatják a Windows-hitelesítést, ha kiszolgálóként használják: Windows XP Home Edition, Windows XP Media Center Edition és Windows Vista Home kiadások.

Fejlesztés és üzembe helyezés különböző identitásokkal

Ha az alkalmazást egy gépen fejleszti, és egy másik gépen helyezi üzembe, és különböző fióktípusokat használ a hitelesítéshez az egyes gépeken, eltérő viselkedést tapasztalhat. Tegyük fel például, hogy az alkalmazást egy Windows XP Pro rendszerű gépen fejleszti ki a SSPI Negotiated hitelesítési mód használatával. Ha helyi felhasználói fiókot használ a hitelesítéshez, akkor az NTLM protokollt fogja használni. Az alkalmazás fejlesztése után üzembe helyezi a szolgáltatást egy Windows Server 2003 rendszerű gépen, ahol tartományfiók alatt fut. Ezen a ponton az ügyfél nem fogja tudni hitelesíteni a szolgáltatást, mert Kerberost és tartományvezérlőt fog használni.

Lásd még