La sécurité sous le capot

Dans l’esprit de Microsoft, ces comptes sont destinés à  limiter l’utilisation du compte système local. Comme le mot de passe de ce compte change automatiquement et à  intervalles réguliers, les administrateurs utilisent souvent ce compte comme l’identité de sécurité pour les applications et les services. Toutefois, le fait que le compte système local possède de nombreux privilèges système locaux rend cette pratique dangereuse : si un intrus parvient à  accéder à  l’application ou au service, tout le système est en péril. Pour réduire cette vulnérabilité, les deux nouveaux comptes de XP Pro et de .NET Server ont des privilèges utilisateur réguliers. Pour accéder aux ressources non locales, le compte Local Service utilise un contexte de sécurité anonyme, tandis que le compte Network Service utilise le compte machine local.

  XP Pro et .NET Server présentent également plusieurs modifications cryptographiques importantes. Tout d’abord, Microsoft affirme que XP Pro et .NET Server améliorent nettement la performance SSL (Secure Sockets Layer) de Windows (bien que pour l’instant on n’en ait que très peu de preuves). Deuxièmement, les implémentations EFS de XP Pro et .NET Server supportent 3DES (Triple DES). Troisièmement, XP Pro et .NET Server utilisent un nouveau protocole d’authentification appelé authentification Digest. Il s’agit d’un protocole d’authentification fondé sur un principe challenge-réponse défini dans le cadre de la spécification HTTP 1.1. Bien que l’authentification Digest ait été disponible comme un fournisseur d’authentification pour Microsoft IIS (Internet Information Services) 5.0, le protocole n’était pas intégré dans la SSPI (Security Support Provider Interface) de l’OS comme un vrai SSP (Security Support Provider). Pour plus d’informations sur l’authentification Digest, voir la RFC (Request for Comments) 2617 de l’IETF (Internet Engineering Task Force), « HTTP Authentication : Basic and Digest Access Authentication », à  l’adresse http://www.ietf.org/rfc/rfc2617.txt.

  Enfin, Microsoft envisage d’inclure quelques importantes améliorations de l’authentification de confiance et interforêt dans .NET Server. En raison des contraintes de conception de l’AD (Active Directory), Win2K n’utilise Kerberos que dans des scénarios d’authentification interforêt spécifiques. Dans Win2K, un logon interactif de type Kerberos entre deux forêts n’est possible que quand il existe une relation de confiance directe entre les deux domaines, et les relations de confiance en mode forêt croisée transitive (transitive cross-forest) ne fonctionneront pas. .NET Server prend en charge la vraie authentification interforêt de type Kerberos et les relations de confiance transitives. Pour définir des relations de confiance, .NET Server offre un nouveau Trust Wizard. .NET Server supporte également la qualification de confiance pour permettre de définir des contraintes de validité SID pour certaines relations de confiance.