Windows 2000, comme son prédécesseur
d'ailleurs, prend en charge une panoplie
de protocoles d'authentification
pour valider l'identité des utilisateurs qui
s'y connectent, quelque soit le type de
connexion (locale ou distante).
Le choix de Microsoft d'intégrer
nativement le protocole Kerberos v5.0
dans Windows 2000 a relégué au second
plan le
protocole Windows NT
LAN Manager (NTLM) qui était jusque là utilisé comme protocole par défaut
dans Windows NT. Il doit son maintient
pour des raisons de compatibilité avec
les versions précédentes de Windows
et dans les cas où Kerberos ne peut
être exploité.
Cependant, seuls les postes clients
Windows 2000 ou XP pourront tirer
profit de Kerberos, Windows 9x, Me et
NT continueront à utiliser le protocole
NTLM.
L’intégration de Kerberos dans
Windows 2000 apporte plus de flexibilité
et d’efficacité dans le processus
d’authentification.
Mécanisme d’authentification
Kerberos
Prenons le cas d’un utilisateur qui désire
accéder à un serveur Exchange
2000 pour consulter ses messages.
Au moment de l’ouverture de session,
le poste client Windows 2000 envoie
une requête au serveur DNS
( Domain Name Server) à la recherche
d’un enregistrement SRV pour le KDC
(Key Distribution Center), présent par
défaut sur chaque contrôleur de domaine.
Une fois localisé, la requête est
envoyée au KDC auprès duquel il obtiendra
un ticket d’octroi de ticket
(TGT ou Ticket Granting Ticket). Le
KDC rajoute au TGT des données d’autorisation
comprenant le SID de l’utilisateur
et ses groupes, issus du domaine
du compte. Le TGT est requis
pour l’obtention du ticket de session,
précieux sésame qui permettra l’accès
aux différents services du réseau, dont
Exchange 2000.
L’intérêt principal de ce ticket de
session est de réduire le nombre des
demandes d’authentification au
contrôleur de domaine et donc d’accélérer
les réponses du serveur Exchange
2000.
Un ticket de session pour l’accès au
serveur Exchange 2000 peut être réutilisé
pour de nouvelles connexions ultérieures
puisqu’il dispose d’une durée
de vie de dix heures par défaut,
paramétrable au niveau des politiques
de sécurité Kerberos du domaine. Le
ticket de session est automatiquement
détruit lorsque l’utilisateur se déconnecte
de sa session sur le domaine.
Kerberos offre encore plus de sécurité
pour l’authentification du
compte système Exchange 2000 auprès
du contrôleur de domaine.
Microsoft a abandonné l’utilisation
du compte de service cher à Exchange
5.5 au profit d’un compte système local
à la machine. Le compte Local System
reçoit les accréditations nécessaires
auprès du KDC pour accéder aux
services Exchange. Pour des raisons de
sécurité évidentes, le mot de passe du
compte Local System est réinitialisé
par le système tous les 7 jours.
Attention cependant à l’utilisation
de Kerberos (version 5 standard, définit
dans la RFC 1510) sur un réseau utilisant
la translation d’adresses (NAT ou
Network Address Translation). En effet,
l’authentification Kerberos est incompatible avec NAT car l’adresse IP translatée
de la machine qui émet le ticket
de session et l’adresse IP réel de cette
même machine contenu dans le ticket
de session ne coïncident plus.
La délégation d’authentification
Face à la complexité des architectures
multi-tiers, Kerberos apporte une solution
intéressante au niveau des authentifications
multiples : la délégation
d’authentification.
Prenons l’exemple d’un utilisateur
distant qui désire accéder à sa messagerie
via son browser. La seule information
dont il dispose pour cela est un
lien hypertexte vers un serveur Web
qui le redirige vers le serveur Exchange
2000 hébergeant sa boîte aux lettres.
Ce type d’architecture trois-tiers
impliquant des serveurs Exchange
2000 frontaux (front-end) et principaux
(back-end) nécessite plusieurs
authentifications successives et peut
devenir très vite pénible pour l’utilisateur.
L’utilisation de la délégation d’authentification
de Kerberos permet au
serveur frontal de s’authentifier auprès
du serveur principal qui héberge la
banque d’information en utilisant les
accréditations de l’utilisateur.
En effet, l’utilisateur qui veut accéder
à sa messagerie à travers un serveur
Exchange 2000 frontal Outlook
Web Access demande au KDC un ticket
transférable (forwardable ticket) qu’il
va transmettre au serveur frontal. Ce
dernier va effectuer une demande de
ticket de session Exchange 2000 à la
place du client et le transmettre par la
suite au serveur principal.
Téléchargez cette ressource
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.