Je ne m’attendais pas à recevoir un tel retour par mail à ce sujet (si peu passionnant), et je ne parle pas que des sites de référencement. Cela me motiva donc à boucler la boucle en exécutant de nouveaux tests intensifs avec Windows 2008 (SP2) ainsi que Windows 2008 R2 afin de couvrir tous les cas de figure.
En résumé, quand la vérification de la signature PAC va-t ’elle se réaliser ?
Le tableau ci-dessous nous montre les différents scénarios possibles :
|
OS Serveur / Application ou Service Cible
|
2003 Serveur pre-SP2
|
2003 Serveur SP2 et supérieur, avec configuration additionnelle de la base de registre
|
2008 Serveur, 2008 Serveur R2
|
|
File & Print Sharing
|
PAS de Validation
|
PAS de Validation
|
PAS de Validation
|
|
Exchange Server
|
Validation
|
PAS de Validation
|
PAS de Validation
|
|
SQL Server
|
Validation
|
PAS de Validation
|
PAS de Validation
|
|
IIS dont le pool d’application tourne dans le contexte Local System ou Network Service
|
Validation
|
PAS de Validation
|
PAS de Validation
|
|
IIS dont le pool d’application tourne dans le contexte d’un utilisateur du domaine
|
Validation
|
Validation
|
Validation
|
En bref, la seule différence entre Windows Serveur 2003 et 2008/2008R2 est que la base de registre n’a plus à être modifiée puisque la valeur par défaut est inversée depuis 2008.
Une fois de plus, le point important ici est: si vous configurez Kerberos sur une ferme IIS (Sharepoint ou “simple” ASP.Net), la validation PAC sera TOUJOURS effectuée, quoique vous fassiez pour l’en empêcher A MOINS que l’application ne se voit accorder le droit « Autorisation d'agir dans le cadre du système d'exploitation », et en fasse usage.
Si l’application cible s’est vue accorder le privilège seTcb et en fait usage :
Accorder le privilège seTcb n’est pas suffisant parce qu’il sera désactivé par défaut jusqu’à ce que l’application le requière. Mais pourquoi en aurait-elle besoin ? Pour différentes raisons ce privilège peut être nécessaire par l’application du serveur. Deux usages courants sont expliqués dans les sections ci-dessous.
Transition de protocole
La transition de protocole est l’habilité pour une application serveur de déléguer les crédentiels d’un utilisateur vers un service back-end utilisant Kerberos, bien que non soumis de cette manière par le client.
En clair, cela signifie qu’un utilisateur peut être authentifié par un service utilisant des protocoles autres que Kerberos, tels que Basic, NTLM ou digest et que ce service, en utilisant cette particularité, transformera les crédentiels afin de les présenter à un autre serveur.
Exemple : un utilisateur qui s’authentifie à SharePoint en utilisant NTLM, désire utiliser le service de reporting qui tourne sur un second serveur. Le serveur SharePoint fera la transition nécessaire afin de transférer (appelé « déléguer ») les crédentiels de l’utilisateur au serveur SRS en utilisant Kerberos.
Ken Schaefer, MVP IIS, nous en donne un excellent aperçu sur son blog (en anglais) : IIS and Kerberos Part 5 - Protocol Transition, Constrained Delegation, S4U2S and S4U2P.
Services pour l’utilisateur (S4U – Services for user)
Les extensions S4U sont étroitement liées à la transition de protocole. Pour faire très court, elles permettent, sous certaines conditions, à une application d’effectuer un logon pour le compte de l’utilisateur sans connaître son mot de passe.
Cette caractéristique est, par exemple, utilisée dans le produits IAM (Identity Access Management) ou SSO (Single Sign-On) tels que IBM TAM/WebSEAL ou CA SiteMinder.
Pour chacune des technologies, puisque l’utilisateur ne s’authentifie pas à l’origine en utilisant Kerberos, il n’y a pas de PAC à valider.
OK. Mais finalement, pourquoi désactiver la validation PAC est si importante ?
En fait, je ne dirais pas que c’est « si important ». Cela peut permettre d’améliorer les performances sous certaines circonstances. Puisque, pour faire bref, le PAC est vérifié par l’application serveur avant d’accorder un Ticket-Granting-Service (TGS) au client, cela n’est pas effectué à chaque requête tant que le TGS reste valide (note : il existe certaines exceptions à cette règle). MAIS dans certains cas, la vérification initiale peut prendre un certain temps car 1) l’AD du client est distant (en termes de réseau, nombre de sauts, latence, bande passante, …) de l’AD du serveur ou 2) l’AS du client est trop chargé. Cela donne donc la fausse impression que l’authentification du client au serveur est ralentie alors qu’on s’attend à une nette amélioration en passant à Kerberos.
Ressources additionnelles (en anglais)
· MSDN Patterns & Practices - Protocol Transition with Constrained Delegation Technical Supplement
· MSDN Magazine April 2003 - Exploring S4U Kerberos Extensions in Windows Server 2003
· MSDN - [MS-APDS]: Authentication Protocol Domain Support Specification
Marc
(traduit de l’anglais par Anthony)