Intégration Linux dans Active Directory

1. Intégration Linux dansActive Directory Pascal Sauliere Consultant Principal Sécurité Microsoft France

2. Avant de commencer… Cette session avec la démo disponible prochainement sur le site « interop » : http://www.microsoft.com/france/interop

3. Référence Windows Security and Directory Services for UNIX Guide • Download Center: http://go.microsoft.com/fwlink/?linkid=36975 • TechNet online: http://go.microsoft.com/fwlink/?linkid=68104

5. Objectif et vision • Objectif : intégrer Linux dans Active Directory • Identifier les différents moyens • Comment décider de la solution adaptée à l’environnement • Vision : • Chaque utilisateur a une et une seule identité et un mot de passe pour accéder à tous les services disponibles, une fois authentifié (SSO ?) • Toutes les informations d’un utilisateur relatives à la sécurité sont stockées dans un seul endroit

6. Définitions • Authentification : action de prouver qu’un Principal est vraiment l’entité qu’il prétend être • Principal : un participant dans une interaction, identifiable de manière unique – utilisateur, hôte, service • Autorisation : action de déterminer quelles actions un Principal peut effectuer dans un contexte donné • AuthZ Store : Stockage des données sur les Principaux nécessaires pour effectuer les autorisations

7. Approches • Converger vers un annuaire unique • Une identité, un mot de passe, en un seul endroit • Nécessite des standards de l’industrie • Windows nécessite Active Directory • Conserver l’infrastructure existante • Seul Kerberos v5 supporté • Ce n’est pas « en un seul endroit, » mais presque • Synchroniser, interopérer • « Un mot de passe, » mais pas « une identité » • Plus complexe

8. Cinq solutions valides • AD/Kerberos pour authentification uniquement • AD/Kerberos pour authentification et AD/LDAP pour autorisations • AD/LDAP pour authentification uniquement • AD/LDAP pour authentification et autorisations • Relation d’approbation entre AD/Kerberos et Kerberos UNIX pour authentification uniquement • L’approche recommandée est la solution 2

9. Utilisation de l’existant • Solution 5 • Prérequis : Kerberos V5 en place • En général un seul royaume (realm) • Architecture de domaine pas trop complexe • Kerberos V5 sous UNIX supporte une hiérarchie de confiance dans une forêt (avec quelques efforts) • Relations d’approbation inter-forêts délicates • Nécessite AD/AM pour les informations d’autorisation Windows pour les utilisateurs UNIX

10. Pourquoi n’intégrer que l’authentification ? • Solutions 1 (Kerberos) et 3 (LDAP) • Solution existante pour les autorisations • Demi-solution : • Réduit le nombre d’identités • Conserve les autorisations existantes • Solution acceptable pour le « deprovisioning »

11. Authentification LDAP ? • Certaines plateformes ne supportentpas Kerberos • Applications (composants web) • Ne pas confondre avec solutions de fédération • Il s’agit d’un scénario interne • LDAP n’a pas été conçu comme un protocole d’authentification • Nécessite des précautions pour éviter les mots de passe en clair (SSL/TLS) • Limitations en performance et évolutivité • « L’authentification » LDAP est un bind LDAP • La seule preuve de l’identité est une connexion LDAP établie • Pas de transitivité de l’identité

12. Solution recommandée • Solution 2 • Authentification Kerberos • LDAP pour les autorisations • Consolidation de l’annuaire, création/suppression ((de)provisioning) simplifiées, mot de passe unique, stratégie commune… • Utilise les protocoles et services tels qu’ils ont été conçus • Des produits commerciaux existent : • Quest (VintelaAuthentication Service) • Centrify (DirectControl)

13. Ouverture de session UNIX • login récupère username, password • login appelle PAM pour authentifier l’utilisateur • PAM utilise plusieurs modules pour tenter l’authentification • login appelle getpwnam() pour obtenir les données d’autorisation de l’utilisateur • getpwnam() appelle NSS • NSS utilise plusieurs modules pour tenter d’obtenir les données demandées • login utilise les données d’autorisation pour créer le processus initial (shell)

14. Autorisations intégrées • Schéma RFC 2307 ou SFU 3.0 pour les données d’autorisation spécifiques à UNIX • SFU 3.0 est aujourd’hui dépassé • Windows Server 2003 R2 (Identity Management for UNIX) inclut le schéma RFC 2307 • Différences très mineures avec la RFC ; La documentation contient les détails dans la section Migrating standard and nonstandardmaps • Certaines stratégies de groupe s’appliquent automatiquement

15. Préparation du test Pour la démo : • Windows Server 2003 R2, Active Directory, DNS, Certificate Service • RedHat 9 installé en mode « Workstation »

16. Composants utilisés sur RedHat 9 Kerberos • krb5-devel-1.2.7-10 (installé par défaut) • krb5-libs-1.2.7-10 (installé par défaut) • krb5-workstation-1.2.7-10 • css_adkadmin-2.2_linux (http://www.css-security.com/) • pam_krb5-1.60.1-css1_linux (http://www.css-security.com/) LDAP • openldap-2.2.17 • nss_ldap-220 • krb5-1.3.5 • cyrus-sasl-2.1.19

17. Démarche de test • Créer les OU, utilisateurs et groupes de test dans AD • Configuration et test de Kerberos pour l’authentification • Configuration et test de LDAP pour les autorisations • Configuration et test de l’authentification Kerberos (SASL) pour LDAP

18. RedHat 9 dans AD 2003 R2 Démo

19. Référence Windows Security and Directory Services for UNIX Guide • Download Center: http://go.microsoft.com/fwlink/?linkid=36975 • TechNet online: http://go.microsoft.com/fwlink/?linkid=68104 Site interopérabilité Microsoft France • http://www.microsoft.com/france/interop