Renforcement et sécurité des services Windows Vista/Longhorn

Renforcement et sécurité des services Windows Vista/Longhorn Jean-Yves Poublan Microsoft France

Renforcement des services – c'est quoi? • Isolation des services • Exécution en moindre privilège • SID de service • Restrictions des accès aux ressources • Restrictions des accès au réseau Objectif • Réduire la surface d'attaque • Protection du système • Protection des services

Sessions, Window Stations, Desktops Session 0 Session 1 Session n WinSta0 Screen-saver Winlogon Default

Session • Mécanisme permettant le support du multi-utilisateur avec interface locale (console physique) et déportée (Terminal Services), ou Fast User Switching • Ne pas confondre avec session de logon • Comprend processus, stations windows, sessions de logon • GetTokenInformation(TokenSessionId) • Process.GetCurrentProcess().SessionId • Instanciation d'espaces de nommage privés (session namespace) pour les objets kernel • events, semaphores, mutexes, etc… • Espace de nommage global accessible avec le préfixe "Global\" • Gestionnaire des sessions (Session Manager) – smss.exe • Responsable de la création des sessions • C’est le premier processus « créé » • Il prend ses paramètres de \HKEY_LOCAL_MACHINE\System\CurrentControlSet \Control\Session Manager • Il lance csrss.exe (sous système Windows) et winlogon.exe • Chaque session comporte son sous-système Windows et winlogon.exe

Window Station • Comprend presse-papier, Atom table, Desktops • Un processus est rattaché à une Window Station • GetProcessWindowStation • Périmètre de sécurisation du système de fenêtrage (sandbox) • Objet protégé par DACL • HWINSTA OpenWindowStation, SetProcessWindowStation • WinSta0: station Windows interactive • Clavier/souris, affichage • DACL accorde tous les droits à SYSTEM et logon SID • Autres stations Windows • Nommées d'après les session de logon - « Service-0xhigh-low$ • e.g. Service-0x0-3e5$ pour un service LOCAL SERVICE • DACL accorde les droits au principal • EnumWindowStations, CreateWindowStation • Remarques • Une session de logon se voit accorder des droits sur une Window Station par la DACL • Les services non interactifs ont leur Window Station créée spécifiquement • Les services interactifs doivent s'exécuter en tant que SYSTEM (de par la DACL restrictive sur WinSta0)

Desktop • Comprend Windows, Menus, Hooks • Un thread est rattaché à un Desktop • GetThreadDesktop • Périmètre de sécurisation du système de fenêtrage (sandbox) • Objet protégé par DACL • HDESK OpenDesktop, SetThreadDesktop • Messages Windows sont confinés au même Desktop • Pour WinSta0, trois desktops: • Default (Interactive) • Winlogon • Screen-saver • Active Desktop = Input Desktop = écran/clavier/souris • OpenInputDesktop • EnumDesktops, CreateDesktop, SwitchDesktop

Service Interactif • Les services interactifs utilisent WinSta0 • Flag SERVICE_INTERACTIVE_PROCESS de CreateService • ou "Allow Service to Interactwith Desktop" • Seuls les services s'exécutant en tant que SYSTEM peuvent être interactifs • De par la DACL positionnée sur WinSta0 • Droits pour SYSTEM et logon SID • Pourquoi les services interactifs sont à éviter? • Parce qu'ils partagent WinSta0 avec les applications utilisateur et qu'ils doivent s' exécuter en tant que LOCAL SYSTEM • Sujets aux attaques de type "shatter" • Chemin d'élévation de privilège via messages Windows • On peut configurer une machine pour interdire les services interactifs • NoInteractiveServices = 1 • HKLM\SYSTEM\CurrentControlSet\Control\Windows

Windows XP SP2 (1) Code managé: la runtime détecte la tentative d'affichage d'une boite de dialogue modale dans une station non interactive et lève l'exception InvalidOperationException

Windows Vista RTM Code managé: exception Meme si la MessageBox ne comporte pas ce bouton

MessageBox(MB_SERVICE_NOTIFICATION) • MB_SERVICE_NOTIFICATION • En principe, la boite de dialogue est redirigée vers WinSta0 de la même session TS (Session 0) • Si session interactive ouverte • WinSta0/default Desktop • Si pas de session interactive • WinSta0/Winlogon Desktop • CSRSS (WinSta0) gère son affichage • Si impersonation, la redirection se fait vers WinSta0 de la session TS du client • MB_DEFAULT_DESKTOP_ONLY • Default Desktop (de WinSta0) uniquement • Le desktop de la session interactive de l'utilisateur

Session 0Windows XP • Services et utilisateur de la console dans Session 0 • Windows Server 2003 • Session 0 = console • Sessions 1..n = sessions Terminal Services • Windows XP avec Fast User Switching • Session 0 = session du premier utilisateur • Sessions 1..n = utilisateurs suivants • Problèmes • Services interactifs (WinSta0) vulnérables aux attaques "shatter" • Collisions de noms objets kernel Session 0 Session 1 Application A Service A Application D Service B Application E Application B Service C Application F Application C

Windows XP Session 0 Session 1 (FUS) Session 0 Session 1 (FUS)

Session 0 Service A Service B Service C Isolation des services Session 0Windows Vista • Session 0 réservée pour les services Win32 exclusivement • Premier utilisateur console dans Session 1 • Gains • Isolation des services • Les services "interactifs" n'ont plus accès à la console • Protection contres attaques "shatter" provenant des applications utilisateur • Elimination des collisions de noms Session 1 Session 2 Application A Application D Application B Application E Application C Application F

Isolation des services Session 0Sont concernés… • Services interactifs • Drivers en mode utilisateur s'exécutant dans un service • Drivers User-Mode Driver Framework (UMDF) • Drivers d'imprimantes (service de spool) • "Printer Out of Paper" • Services qui interagissent avec des applications utilisateur via SendMessage ou PostMessage • Services qui se synchronisent avec des applications via des objets nommés • L'espace de nommage est instancié par session • Semaphores, mutexes, events… • Il faut utiliser le préfixe Global\

Isolation des services Session 0 • Les services ne devraient jamais ouvrir une fenêtre sur le desktop interactif • Pour une interaction ponctuelle • Utiliser WTSSendMessage • Pour une interaction plus poussée • Créer un processus dans la session cible avec CreateProcessAsUser • Utiliser un mécanisme d'IPC (sécurisé) pour communiquer avec des applications utilisateur • Référence • Impact of Session 0 Isolation on Services and Drivers in Windows Vistasur WHDC • http://www.microsoft.com/whdc/system/vista/ • Comment mettre en œuvre une IHM à partir d'un service – Keith Brown • http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToDisplayAUserInterfaceFromADaemon.html Note: si un service est conçu et se comporte correctement sous Windows XP avec Fast User Switching, ou Terminal Services, il y a de fortes chances qu'il continue à fonctionner correctement sous Windows Vista

CompatibilitéInteractive Services Detection service • Un service Windows Vista qui détecte les tentatives d'interaction IHM des services interactifs legacy • UI0Detect.exe • Start on demand • Une DLL de hook mise en œuvre par wininit.exe est utilisée pour démarrer le service lors de la création d'une fenêtre dans WinSta0 • S'exécute en tant LOCAL SYSTEM • Attire l'attention de l'utilisateur sur le fait qu'un service essaye d'interagir, et permet à l'utilisateur de basculer ponctuellement vers la session 0 • Mesure temporaire de compatibilité • L'objectif est plus d'attirer l'attention des fournisseurs de services sur la nécessité d'une mise à niveau

UI0Detect Démo

Restriction des services • Windows Vista et Longhorn Server disposent de mécanismes pour « durcir » et sécuriser les services Win32 • Privilèges moindres • SID de service • Jeton restreint en écriture (write-restrictedtoken) • Restrictions d’accès réseau • Ces mécanismes peuvent être mis en œuvre conjointement • Ces mécanismes facilitent l’utilisation des comptes builtinLocalServiceet NetworkService pour l’exécution des services • En permettant une granularité plus fine (service par service, ou pour une classe de service – les services retreints en écriture) des contrôles d’accès • En l’absence de ces mécanismes de contrôle, tous les services s’exécutant en tant que LocalService ou NetworkService (ou n’importe quelle identité) comporteraient les mêmes droits d’accès et privilèges

Restriction des services Clés de registre pour configuration du service • RequiredPrivileges (REG_MULTI_SZ) • Permet de spécifier les privilèges dont le service à besoin • Privilèges moindres • ServiceSidType (REG_DWORD) • SERVICE_SID_TYPE_NONE (0x0) • Pas de SID de service – Fonctionnement legacy • SERVICE_SID_TYPE_UNRESTRICTED (0x1) • SID de service – Jeton normal • SERVICE_SID_TYPE_RESTRICTED (0x3) • SID de service – Jeton restreint en écriture

Privilèges moindres • On spécifie les privilèges requis par le service au niveau de la configuration du service • ChangeServiceConfig2 (SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO) • SeBackupPrivilege\0SeRestorePrivilege\0\0 • sc.exe • sc <server>privs [service name] [Privileges] • sc <server> qprivs [service name] buffersize • Le SCM crée le processus hôte avec l’union des privilèges configurés pour les services hébergés • Cependant cet ensemble de privilèges ne peut excéder ceux du compte du service (E.g. NetworkService) • Si la configuration d'un service spécifie plus de privilèges que le compte du service, ces privilèges ne sont pas obtenus (ignorés)

SID de service • Un « per-service SID » peut être créé et associé à un service • S-1-5-80-{SHA-1 du nom du service} • Local à la machine • Pour ce faire, on configure le type de SID de service (ServiceSidType) à "Unrestricted" • ChangeServiceConfig2(SERVICE_CONFIG_SERVICE_SID_INFO) • SERVICE_SID_TYPE_UNRESTRICTED 0x00000001 • sc.exe • sc sidtype [service name] [type] • sc qsidtype [service name] • sc showsid [service name] • NAME: mysvc • SERVICE SID: S-1-5-80-1367702158-1701208665-2838300432-1083307162-2949717864 • Le SCM crée et rajoute le SID de service dans la liste des groupes du jeton du processus hôte (lors de l’instanciation de ce dernier) • Cependant le jeton reste un jeton "normal" (éventuellement avec des privilèges en moins) et le service peut accéder aux ressources du compte de service et de ses groupes. • On peut utiliser les SID de service dans les ACL pour contrôler l’accès aux ressources

Restriction des servicesJeton de sécurité User SID SE_GROUP_ENABLEDSE_GROUP_ENABLED_BY_DEFAULTSE_GROUP_MANDATORYSE_GROUP_OWNERSE_GROUP_LOGON_IDSE_GROUP_RESOURCESE_GROUP_USE_FOR_DENY_ONLYSE_GROUP_INTEGRITY_ENABLED Group SID Flags Group SID Flags Group SID Flags Restricting SID Restricting SID Restricting SID Privileges Flags: WRITE_RESTRICTED, … Flags: Defaults for new objects(Owner SID, Group SID, DACL)Logon session LUIDToken IDImpersonation levelSession ID, etc…

Jeton restreint en écriture • En plus du SID de service, on peut restreindre le service en écriture • Pour ce faire, on configure le type de SID de service (ServiceSidType) à "Restricted" • ChangeServiceConfig2(SERVICE_CONFIG_SERVICE_SID_INFO) • SERVICE_SID_TYPE_RESTRICTED 0x00000003 • Le SCM crée un jeton dit "restreint en écriture" (write-restrictedtoken) • Le jeton est marqué WRITE_RESTRICTED (flag) • Les SID de restriction sont • SID de service • SID write-restricted (S-1-5-33) • SID de logon • Everyone • Le SID de service et le SID write-restricted sont aussi rajoutés aux SID de groupes • L’accès en écriture aux ressources se fait par vertu des SID de restriction • Et non du compte de service utilisé et de ses groupes • Les accès en lecture ne sont pas affectés (correspond à "Unrestricted")

Restriction des servicesRemarques • Les restrictions s’appliquent au niveau du processus hôte • Regrouper dans un processus hôte les services ayant les mêmes types de restrictions • Union des privilèges • Pas de cohabitation des services unrestricted et restricted • Si on ne souhaite pas de SID de service • On peut configurer le service avec ServiceSidType à SERVICE_SID_TYPE_NONE • ChangeServiceConfig2(SERVICE_CONFIG_SERVICE_SID_INFO) • SERVICE_SID_TYPE_NONE 0x00000000 • Permet de forcer un fonctionnement à la 2000/XP dans le cas ou le système utiliserait unrestricted par défaut • LookupAccountSid/LookupAccountName

Privilèges sensibles • The following privileges are Elevation sensitive privileges - i.e. any service which has these privileges can take over the system. • SeTcbPrivilege - allows the holder to create logon sessions and inject arbitrary SIDs into the token • SeTakeOwnershipPrivilege - allows the holder to gain access to objects they are not granted access to by DACL • SeLoadDriverPrivilege - allows the holder to run arbitrary code in the kernel • SeBackupPrivilege - allows the holder to recover the SAM database and crack it offline • SeRestorePrivilege - allows the holder to change arbitrary files or ACLs on the filesystem • SeDebugPrivilege - allows the holder to run arbitrary code in the process of his choosing • SeImpersonatePrivilege - allows the holder to assume the identity of clients he lures to call him

Privilèges justifiant LOCAL SYSTEM • SeTcbPrivilege • SeCreateTokenPrivilege • SeTakeOwnershipPrivilege • SeDebugPrivilege • SeRestorePrivilege • SeLoadDriverPrivilege • SeCreatePermanentPrivilege • SeSystemEnvironmentPrivilege • SeManageVolumePrivilege

Restrictions réseau • Les règles Windows Service Hardening (WSH) permettent de restreindre l'accès réseau pour les services • Inbound et Outbound • Protocole/port/application/service/type de règle (allow/block) • Indépendantes des règles Windows Firewall Advanced Security du pare-feu intégré • Sont évaluées avant les règles WFAS du pare-feu • Cependant les règles du pare-feu s'appliquent • Ne permettent que de restreindre l'accès • En aucun cas de l'élargir • Sensées être configurées par l'installation du service • API INetFwServiceRestriction • Script VBS ou Powershell • Ne peuvent être configurées par les outils du pare-feu (mmc, netsh)

Restrictions réseau • Les règles Service Hardeningse trouvent dans • HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\Systems • Configurables via API/script seulement • Pour rappel, les règles du pare-feu intégré (WFAS) se trouvent dans • HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules • Administrables via mmc WFAS, netsh, group policy et API/script

Restrictions réseau • Script pour interdire tout accès réseau ' Create the FwPolicy2 object. Dim fwPolicy2 Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2") ' Get the Service Restriction object for the local firewall policy. DimServiceRestriction SetServiceRestriction = fwPolicy2.ServiceRestriction ' Restrict a service ServiceRestriction.RestrictServiceServiceName, ProgramName, TRUE, FALSE • Ce script crée deux règles SH v2.0|Action=Block|Active=TRUE|Dir=Out|App=c:\mysvc\mysvc.exe|Svc=mysvc|Name=Outbound service restriction rule for mysvc|Desc=Block all outbound traffic from service mysvc|Edge=FALSE| v2.0|Action=Block|Active=TRUE|Dir=In|App=c:\mysvc\mysvc.exe|Svc=mysvc|Name=Inbound service restriction rule for mysvc|Desc=Block all inbound traffic to service mysvc|Edge=FALSE|

Restrictions réseauMeilleure pratique pour les développeurs • Mettre en place les règles WSH (Service Hardening) lors de l'installation/configuration du service • Ces règles ont pour but de restreindre le service • Initiative du développeur • Documenter les protocoles/ports nécessaires au service pour l'administrateur ou exploitant • Le pare-feu (intégré, ou tierce-partie) doit être configuré indépendamment pour permettre au service de communiquer

Renforcement des servicesServices natifs Windows Vista • Plusieurs services précédemment SYSTEM maintenant s'exécutent en LOCAL SERVICE ou NETWORK SERVICE • Privilèges minimum spécifiés pour chaque service • Utilisation d'un SID de service • Les services de même profil (privilèges, type de SID, accès réseau, etc…) ont été regroupés • SVCHOST –k <service group>

Restriction des servicesServices natifs Windows Vista • Les services natifs de Windows Vista comportent leurs propres règles Service Hardening • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System • Elles ne sont pas configurables ni par API ni avec les outils du pare-feu • Exemple – pas d'accès réseau pour BFE • V2.0|Action=Block|Dir=in|App=%SystemRoot%\System32\svchost.exe|Svc=BFE|Name=Block inboundtraffic to BFE| • V2.0|Action=Block|Dir=out|App=%SystemRoot%\System32\svchost.exe|Svc=BFE|Name=Block outboundtrafficfrom BFE|

Restriction des servicesServices natifs Windows Vista • Exemple - Service Client DHCP

Restriction des servicesServices natifs Windows Vista • Profiles SVCHOST –k <servicegroup> • LocalService • Exécution avec LOCAL SERVICE, SID de service • EventSystem, LanmanWorkstation, SCardSvr, Win32Time… • LocalServiceNoNetwork • Exécution avec LOCAL SERVICE, SID de service, jeton restreint en écriture (write-restricted), pas d'accès réseau • BFE, Dps, MpsSvc • LocalServiceNetworkRestricted • Exécution avec LOCAL SERVICE, SID de service, restrictions réseau • AudioSrv, Eventlog, LmHost… • NetworkService • Exécution avec NETWORK SERVICE, SID de service • CryptSvc, DnsCache, NlsSvc, TermService… • NetworkServiceNetworkRestricted • Exécution avec NETWORK SERVICE, SID de service, restrictions réseau • PolicyAgent (ipsec) • LocalSystemNetworkRestricted • Exécution avec LOCAL SYSTEM, SID de service, restrictions réseau • AudioEndPointBuilder, Netman, WlanSvc, wudfsvs… • Dcomlaunch, rpcss, netsvcs, bthsvcs, regsvc, imgsvc, wersvc

Restriction des servicesSynthèse • Privilèges moindres • On accorde le minimum de privilèges nécessaires au fonctionnement du service • Sécurité minimum, faibles couts de mise en œuvre • Service “Unrestricted” avec SID de service • On peut contrôler l’accès aux ressources par le SID du service, mais le service accède à l'ensemble des ressources accessibles à son compte et à ses groupes. En ce sens le service n'est pas restreint. • Protection des ressources du service, couts de mise en œuvre modérés • Il faut configurer les ACL sur les ressources du service • Le type de SID "Unrestricted" permet de protéger les ressources du service • Service “Restricted” avec SID de service • Le contrôle d’accès en écriture aux ressources se fait sur la base du SID de service et/ou du SID write-restricted (classe des services restreints) • Niveau de sécurité le plus élevé, meilleure protection du système • Cependant les couts de mise en œuvre peuvent être élevés – nécessite une maitrise précise des ressources dont le service à besoin d'accéder en écriture • Le type de SID "Restricted" permet de protéger le système en cas de compromission du service • Restrictions réseau – règles SH • Inbound/Outbound, par service • Faibles couts de mise en œuvre Bien Mieux Très bien Dans tous les cas

Démarrage différé (Vista) • ChangeServiceConfig2 • SERVICE_CONFIG_DELAYED_AUTO_START_INFO • Clé de registre DelayedAutostart=1 • Option de configuration pour les services auto-start • Le SCM ne démarre ces services qu'en dernier • Le thread s'exécute initialement en priorité THREAD_PRIORITY_LOWEST et priorité I/O VeryLow • Une fois le service démarré, la priorité est augmentée à THREAD_PRIORITY_NORMAL • Améliore la rapidité de démarrage, telle que ressentie par l'utilisateur • Recommandé pour les services qui n'ont pas besoin d'être opérationnels immédiatement lors du démarrage • Attention aux dépendances • Autres services, clients, etc… • Pas de garantie sur le délai de démarrage • Services natifs ainsi configurés • BITS, Windows Update, etc…

Autres améliorations Vista • Notification de changement d'état • API NotifyServiceStatusChange • Permet à une application d'être notifiée des changements de l'état d'un service • Création, démarrage, arrêt, destruction, etc…

Autres améliorations Vista • Protocole de shutdown • Service peut demander une notification de pre-shutdown • SetServiceStatus SERVICE_ACCEPT_PRESHUTDOWN • SCM notifie le service avec SERVICE_CONTROL_PRESHUTDOWN • SCM attend que le service entre dans l'état SERVICE_STOPPED • Par défaut 3mn • Service peut demander un délai supplémentaire • SetServiceStatus SERVICE_STOP_PENDING • Après l'arrêt des services pre-shutdown le système continue avec l'arrêt des autres services comme sous Windows XP • Ordonnancement de l'arrêt des services • Ne concerne que les service pre-shutdown • HKLM\System\CurrentControlSet\Control\PreShutdownOrder • Exemple: Wuauserv (Windows Update Service) précède Gpsvc (Group Policy Client Service) • Sémantique: "Group policy s'applique après que Windows Update ait terminé"

Autres améliorations Vista • Reprise sur échec autre qu'un "crash" • A l'initiative du service • Configuration du service pour ce mode • ChangeServiceConfig2 • SERVICE_CONFIG_FAILURE_ACTIONS_FLAG • FailureActionsOnNonCrashFailures = true • sc • sc <server> failureflag [service name] [flag] • sc <server> -qfailureflag [service name] • Service signale un arrêt en échec au SCM • SetServiceExitCode

Choix d'un compte de service • Comptes builtin • Local Service – SID S-1-5-19 • 11 privilèges, dont SeImpersonatePrivilege • Pas de credentiels réseau (pas d'identité) • Network Service – SID S-1-5-20 • 10 privilèges, idem Local Service sauf SeSystemTimePrivilege • Credentiels réseau (compte machine du domaine) • System – SID S-1-5-18 • 26 privilèges, dont SeTcbPrivilege • Credentiels réseau (compte machine du domaine) • E.g. corpdom\contsta02 • A éviter - factorisation • Compte dédié du domaine • Credentiels réseau • Utile pour l'approche "trustedsubsystem" en tiers • Compte dédié local • Pas de credentiels réseau • Moins utile avec Vista de par le SID de service

Factorisation et restriction d'un service

Factorisation d'un service • Passerelle effectue une transition de protocole et impersonation • Problème: le service de la passerelle nécessite le privilège TCB et fait face au réseau • Solution retenue • Seul l'obtention d'une session de logon nécessite TCB • Factoriser cette fonction dans un composant COM+ hébergé dans un service séparé s'exécutant en TCB • Abaisser les privilèges du service de la passerelle • Network Service, SeImpersonatePrivilege

Transition de protocoleDomaine Windows 2003 • Les extensions S4U (Service For User) permettent la transition de protocole avec délégation contrainte (dans l'espace) • S4U2Self • Permet d'obtenir une session de logon et ticket Kerberos sans les credentiels du compte • LsaLogonUser(KERB_S4U_LOGON), WindowsIdentity(string userPrincipalName) • Nécessite TCB (SeTcbPrivilege) • S4U2Proxy • Utilisé pour obtenir un ticket de service suite à S4U2Self • Nécessite SeImpersonatePrivilege • Conditions • Le code du service s'exécute avec le privilège SeTcbPrivilege • Le compte de domaine du service est "trusted for delegation" • Le compte de l'utilisateur n'est pas "sensitive and cannotbedelegated" • Le service/ressource "backend" figure sur la liste des contraintes A2D2 ("allowed to delegate to") pour le compte de domaine du service • Si le compte du service n'est pas "trusted for delegation" • Accès aux ressources locales possible • Si appelant n'est pas TCB, jeton niveau Identity seulement • Permet de découvrir les groupes d'un utilisateurs • AccessCheck, CheckTokenMembership, Authz API

SPN • Un client Kerberos ne sait pas avec quel compte (identité) le service s'exécute • Pour obtenir un ticket de service, le client désigne le service par son SPN (Service Principal Name) • Service/Host • On mappe le SPN sur le compte du domaine utilisé par le service (dans Active Directory) • Compte de service dédié, ou compte machine (pour Local System ou Network System) • Setspn –A MySvc/consta02.corpdom.contoso.com CORPDOM\contsta02 • API DsWriteAccountSpn • Cet enregistrement doit se faire pour chaque instance du service dans le domaine • Lorsque le client demande un ticket de service en designant le SPN, ce ticket sera chiffré pour le compte du service (mot de passe du compte du service)

Délégation Kerberos • Domaine Windows 2000 • Non contrainte • Compte domaine du service "trusted for delegation" • Nécessite le TGT du client • Le client garde le contrôle • Peu utilisable de par l'absence de contrainte dans l'espace • Cependant contrainte dans le temps (durée du vie du ticket proxy)

Délégation Kerberos • Domaine Windows 2003 • S4U2Proxy (Service For User To Proxy) – Extension S4U (Service for User) • Contrainte dans l'espace • A2D2 – Allow To Delegate To (Attribut objet AD) • Liste des SPNs pour lesquels le service peut obtenir des tickets • Service n'utilise pas le TGT du client • Il utilise le ticket de service du client, ou le ticket obtenu par S4U2Self • Le client ne peut plus contrôler la délégation • MêmeallowedImpersonationLevel n'est qu'un "souhait"

Kerberos – Transition de protocole via S4U *En théorie seulement, l'accès distant serait possible de par l'existence du ticket Kerberosforwadable obtenu par S4U2Self (credentiels réseau)

Kerberos – Transition de protocole via S4US4U2Self, puis S4U2Proxy *Via S4U2Proxy – sujet aux contraintes A2D2 et le fait que le compte de l'utilisateur ne soit pas "sensitive and cannotbedelegated"

Renforcement et sécurité des services Windows Vista/Longhorn