Pascal SauliereConsultant Principal SécuritéMicrosoft France

Intégration Linux dansActive Directory

Avant de commencer…

Cette session avec la démo disponible prochainement sur le site « interop » :

http://www.microsoft.com/france/interop

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

Objectif et vision

Objectif : intégrer Linux dans Active Directory

Identifier les différents moyensComment 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

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

Approches

Converger vers un annuaire uniqueUne identité, un mot de passe, en un seul endroitNécessite des standards de l’industrieWindows nécessite Active Directory

Conserver l’infrastructure existanteSeul 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

Cinq solutions valides

1. AD/Kerberos pour authentification uniquement2. AD/Kerberos pour authentification et AD/LDAP

pour autorisations3. AD/LDAP pour authentification uniquement4. AD/LDAP pour authentification et autorisations5. Relation d’approbation entre AD/Kerberos et

Kerberos UNIX pour authentification uniquement

L’approche recommandée est la solution 2

Utilisation de l’existant

Solution 5Pré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

Pourquoi n’intégrer que l’authentification ?

Solutions 1 (Kerberos) et 3 (LDAP)Solution existante pour les autorisationsDemi-solution :

Réduit le nombre d’identitésConserve les autorisations existantes

Solution acceptable pour le « deprovisioning »

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 interneLDAP 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 établiePas de transitivité de l’identité

Solution recommandée

Solution 2Authentification KerberosLDAP 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çusDes produits commerciaux existent :

Quest (Vintela Authentication Service)Centrify (DirectControl)

Ouverture de session UNIX

login récupère username, passwordlogin 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 NSSNSS 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)

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 2307Différences très mineures avec la RFC ; La documentation contient les détails dans la section Migrating standard and nonstandard maps

Certaines stratégies de groupe s’appliquent automatiquement

Préparation du test

Pour la démo :

Windows Server 2003 R2, Active Directory, DNS, Certificate Service

Red Hat 9 installé en mode « Workstation »

Composants utilisés sur Red Hat 9Kerberos

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-10css_adkadmin-2.2_linux (http://www.css-security.com/)pam_krb5-1.60.1-css1_linux (http://www.css-security.com/)

LDAPopenldap-2.2.17nss_ldap-220krb5-1.3.5cyrus-sasl-2.1.19

Démarche de test

1. Créer les OU, utilisateurs et groupes de test dans AD

2. Configuration et test de Kerberos pour l’authentification

3. Configuration et test de LDAP pour les autorisations

4. Configuration et test de l’authentification Kerberos (SASL) pour LDAP

Red Hat 9 dans AD 2003 R2Démo

Référence

Windows Security and Directory Services for UNIX Guide

Download Center: http://go.microsoft.com/fwlink/?linkid=36975TechNet online: http://go.microsoft.com/fwlink/?linkid=68104

Site interopérabilité Microsoft Francehttp://www.microsoft.com/france/interop