Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Administration d'Oracle Solaris : services de sécurité Oracle Solaris 11 Information Library (Français) |
Partie I Présentation de la sécurité
1. Services de sécurité (présentation)
Partie II Sécurité du système, des fichiers et des périphériques
2. Gestion de la sécurité de la machine (présentation)
3. Contrôle de l'accès aux systèmes (tâches)
4. Service d'analyse antivirus (tâches)
5. Contrôle de l'accès aux périphériques (tâches)
6. Utilisation de l'outil de génération de rapports d'audit de base (tâches)
7. Contrôle de l'accès aux fichiers (tâches)
Partie III Rôles, profils de droits et privilèges
8. Utilisation des rôles et des privilèges (présentation)
9. Utilisation du contrôle d'accès basé sur les rôles (tâches)
10. Attributs de sécurité dans Oracle Solaris (référence)
Partie IV Services cryptographiques
11. Structure cryptographique (présentation)
12. Structure cryptographique (tâches)
13. Structure de gestion des clés
Partie V Services d'authentification et communication sécurisée
14. Authentification des services réseau (tâches)
17. Utilisation de Secure Shell (tâches)
19. Introduction au service Kerberos
20. Planification du service Kerberos
21. Configuration du service Kerberos (tâches)
22. Messages d'erreur et dépannage de Kerberos
23. Administration des principaux et des stratégies Kerberos (tâches)
24. Utilisation des applications Kerberos (tâches)
25. Service Kerberos (référence)
Terminologie spécifique à Kerberos
Terminologie spécifique à l'authentification
Fonctionnement du système d'authentification Kerberos
Interaction du service Kerberos avec le DNS et le service nsswitch.conf
Obtention de l'accès à un service à l'aide de Kerberos
Obtention d'informations d'identification pour le service d'octroi de tickets
Utilisation des types de chiffrement Kerberos
Utilisation de la table gsscred
Différences notables entre Oracle Solaris Kerberos et MIT Kerberos
Partie VII Audit dans Oracle Solaris
Pour accéder à un service spécifique sur un serveur spécifique, l'utilisateur doit obtenir deux types d'informations d'identification. Le premier est pour le ticket d'octroi de tickets (aussi appelé TGT). Une fois que le service d'octroi de ticket a déchiffré ces informations d'identification, le service crée d'autres informations d'identification pour le serveur auquel l'utilisateur demande l'accès. Ces informations d'identification peuvent ensuite être utilisées pour demander l'accès à ce service sur le serveur. Une fois que le serveur a déchiffré ces informations d'identification, l'utilisateur obtient l'accès. Les sections suivantes décrivent le processus de manière plus détaillée.
Pour démarrer le processus d'authentification, le client envoie une demande au serveur d'authentification pour un principal d'utilisateur spécifique. Cette demande est envoyée sans chiffrement. Aucune information sécurisée n'est incluse dans la demande, de sorte qu'il n'est pas nécessaire d'utiliser de chiffrement.
Lorsque la demande est reçue par le service d'authentification, le nom de principal de l'utilisateur est recherché dans la base de données KDC. Si un principal correspond à l'entrée dans la base de données, le service d'authentification obtient la clé privée pour ce principal. Le service d'authentification génère ensuite une clé de session utilisable par le client et le service d'octroi de tickets (appelez-la Session key 1) et un ticket pour le service d'octroi de tickets (Ticket 1). Ce ticket est également qualifié de ticket d'octroi de tickets (TGT). La clé de session et le ticket sont chiffrés à l'aide de la clé privée de l'utilisateur, et les informations sont renvoyées au client.
Le client utilise ces informations pour déchiffrer Session Key 1 et Ticket 1 à l'aide de la clé privée pour le principal de l'utilisateur. Comme la clé privée doit uniquement être connue de l'utilisateur et de la base de données KDC, les informations du paquet doivent être sécurisées. Le client stocke les informations dans le cache d'informations d'identification.
Au cours de ce processus, l'utilisateur est invité à saisir un mot de passe normalement. Si le mot de passe spécifié par l'utilisateur est le même que celui utilisé pour créer la clé privée stockée dans la base de données KDC, alors le client peut déchiffrer les informations envoyées par le service d'authentification. Maintenant, le client dispose d'informations d'identification à utiliser avec le service d'octroi de tickets. Le client est prêt à demander des informations d'identification pour un serveur.
Figure 25-2 Obtention d'informations d'identification pour le service d'octroi de tickets
Pour demander l'accès à un serveur spécifique, un client doit d'abord avoir obtenu des informations d'identification pour ce serveur à partir du service d'authentification. Reportez-vous à la section Obtention d'informations d'identification pour le service d'octroi de tickets. Le client envoie ensuite une demande au service d'octroi de ticket, qui inclut le nom du principal de service, Ticket 1, et un authentificateur chiffré avec Session Key 1. Ticket 1 a été initialement chiffré par le service d'authentification à l'aide de la clé du service d'octroi de tickets.
Comme la clé de service du service d'octroi de tickets est connue du service d'octroi de tickets, Ticket 1 peut être déchiffré. Les informations de Ticket 1 comprennent Session Key 1, de sorte que le service d'octroi de tickets peut déchiffrer l'authentificateur. A ce stade, le principal de l'utilisateur est authentifié avec le service d'octroi de tickets.
Une fois l'authentification réussie, le service d'octroi de tickets génère une clé de session pour le principal de l'utilisateur et le serveur (Session Key 2), et un ticket pour le serveur (Ticket 2). Session Key 2 et Ticket 2 sont ensuite chiffrés à l'aide de Session Key 1. Etant donné que Session Key 1 est uniquement connue du client et du service d'octroi de tickets, cette information est sécurisée et peut être envoyée sans problème sur le réseau.
Lorsque le client reçoit ce paquet d'informations, il déchiffre les informations en utilisant Session Key 1, qui était stockée dans le cache des informations d'identification. Le client dispose d'informations d'identification à utiliser avec le serveur. Maintenant, le client est prêt à demander l'accès à un service particulier sur ce serveur.
Figure 25-3 Obtention d'informations d'identification pour un serveur
Pour demander l'accès à un service spécifique, le client doit d'abord avoir obtenu des informations d'identification pour le service d'octroi de tickets à partir du serveur d'authentification, et des informations d'identification de serveur à partir du service d'octroi de tickets. Reportez-vous aux sections Obtention d'informations d'identification pour le service d'octroi de tickets et Obtention d'informations d'identification pour un serveur. Le client peut alors envoyer une demande au serveur en incluant Ticket 2 et un autre authentificateur. L'authentificateur est chiffré à l'aide de Session key 2.
Ticket 2 a été chiffré par le service d'octroi de tickets avec la clé de service pour le service. Etant donné que la clé de service est appelée par le principal de service, le service peut déchiffrer Ticket 2 et obtenir Session Key 2. Session Key 2 peut alors être utilisée pour déchiffrer l'authentificateur. Si l'authentificateur est correctement déchiffré, le client obtient l'accès au service.
Figure 25-4 Obtention de l'accès à un service donné