Kerberos, ASP.Net et IIS_WPG

Quel est le lien entre Kerberos, ASP.Net et IIS_WPG?

Lorsqu’une application ASP.Net est configurée pour utiliser l’authentification Windows:

<authentication mode= »Windows » />

Et qu’on souhaite personifier l’utilisateur entrant:

<identity impersonate= »true » />

Pour accéder un serveur SQL distant:

<connectionStrings>
<add name= »<ConnectionName> » connectionString= »Data Source=<ServerName>;Initial Catalog=<DataBaseName>;Integrated Security=SSPI » providerName= »System.Data.SqlClient » />

Si vous vous demandez la différence entre Integrated Security=SSPI et Integrated Security=True, vous pouvez aller lire ceci.

En passant, vous ne pouvez pas spécifier un utilisateur de domaine dans la chaîne de connexion (via User Id et Password). C’est uniquement un utilisateur SQL Server qui peut être utilisé. Pour utiliser une identité de domaine, il faut plutôt impersonifier celui-ci:

<identity impersonate= »true » userName= »accountname » password= »password » />

Vous devrez configurer Kerberos pour que l’identité de la personne qui accède à l’application ASP.Net puisse être déléguée jusqu’au serveur SQL.

Idéalement il faut définir un utilisateur de domaine qui sera utilisé pour l’Application Pool de l’application. Il faut ajouter des SPNs (ex. HTTP/webserver.domaine.com) sur cet utilisateur et activer la “Constrained Delegation” vers SQL Server.

image

Malgré tout, il se peut que vous obteniez cette erreur à partir d’un poste client (double hop):

Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.

Et c’est là qu’entre en jeu le groupe local nommé IIS_WPG.

This step is done to allow the application pool identity the ability to impersonate the user on the web server. If you look at the computer’s user right assignments you will see Impersonate a client after authentication and the IIS_WPG group is added there by default.

Référence: Fun with the Kerberos Delegation Web Site (étape 7)

Bref, le compte que vous avez utilisé pour l’Application Pool de votre application ASP.Net doit être ajouté au groupe local IIS_WPG pour être en mesure d’impersonifier un autre utilisateur.

image

Lorsqu’il s’agit d’une application SharePoint, cette étape n’est pas nécessaire car SharePoint ajoute automatiquement l’utilisateur de son Application Pool à ce groupe.

Une alternative à cette solution est de configurer SQL Server pour accepter l’authentification mixe et mettre cette utilisateur directement dans la chaîne de connexion de SQL.

Mais chez Syntell nous préférons utiliser Kerberos et désactiver l’authentification mixe.

Si vous avez des questions sur nos produits et services, n’hésitez pas à nous contacter.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s