Résultat final

le SID de l’utilisateur et les
SID de tous les groupes locaux et de
domaines auxquels l’utilisateur appartient.
Ensuite, SQL Server examine la
liste des SID pour voir si l’un d’eux correspond
à  une entrée dans la table
sysxlogins de la base de données maîtresse.
S’il existe une correspondance,
SQL Server donne accès à  ses bases de
données.

Les permissions dans les bases de
données fonctionnent aussi indépendamment
du protocole d’authentification
que le client utilise pour se
connecter. Pour les comptes domaine
Win2K, vous attribuez encore les permissions
et les membres de rôles
d’après le SID du compte ; donc, une
fois qu’un utilisateur est connecté, rien
ne change dans la structure d’autorisation
interne de SQL Server 2000.

Le seul changement par rapport à 
SQL Server 7.0 est que, dans tous les
cas, un client XP/Win2K se connectant
à  un serveur XP/Win2K tente de s’authentifier
en utilisant Kerberos. Si cette
authentification échoue, XP/Win2K revient
au protocole NTLM que NT et
Windows Me/9x utilisent. Comme SQL
Server 2000, 7.0 et 6.5 confient tous
l’authentification des comptes domaine à  l’OS, vous pouvez profiter
de Kerberos simplement en exécutant
SQL Server sur Win2K. Rappelons que,
par défaut, toutes les connexions de
confiance s’authentifieront auprès de
l’OS avant que SQL Server ne voie la
demande de connexion. Bien que les
utilisateurs de SQL Server 7.0 et 6.5 ne
puissent pas utiliser un SPN pour authentifier
leurs identités ou utiliser la
délégation pour se connecter à  des serveurs
à  distance, ils peuvent bénéficier
de la sécurité accrue du protocole
Kerberos sur NTLM et des meilleurs
outils d’administration qu’offre Win2K.
IPSec est également plus facile à  configurer
avec Win2K qu’avec NT, donc,
même si vous ne passez à  SQL Server
2000, songez à  passer de NT à  Win2K.

L’utilisation de SQL Server 2000 sur
Win2K offre une grande souplesse
dans le mode de gestion des logins, la
façon de sécuriser le processus d’authentification,
et le canal entre le client
et le serveur, et la manière dont vous limitez
l’accès aux services de toute l’entreprise.
Une grande partie de ce que
j’ai expliqué dans cet article survient
automatiquement quand vous avez un
domaine AD et Win2K sur le client et
les serveurs, donc les DBA (database
administrators) SQL Server n’auront
aucun mal à  utiliser Kerberos. Et vous
serez plus serein en sachant que
Kerberos garde les portes conduisant à 
vos données.