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

Windows Security and Directory Services for UNIX Guide Download Center: TechNet online:

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

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

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

1.AD/Kerberos pour authentification uniquement 2.AD/Kerberos pour authentification et AD/LDAP pour autorisations 3.AD/LDAP pour authentification uniquement 4.AD/LDAP pour authentification et autorisations 5.Relation d’approbation entre AD/Kerberos et Kerberos UNIX pour authentification uniquement L’approche recommandée est la solution 2

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

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 »

Certaines plateformes ne supportent pas 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é

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 (Vintela Authentication Service) Centrify (DirectControl)

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)

LinuxWindows GINA (login) Kerberos (MIT de-facto) Credential (ticket) cache Default Credential (ticket) cache GSSAPI SSPI Application RFC 1510 – Kerberos V5 AS - Authentication Service TGS - Ticket Granting Service MIT de-facto CPW - Change password service Service principal key table Default Service principal key table LSA kinit klist kdestroy kpasswd (MIT de-facto) Login pam_krb5 KRB

Linux LDAP OpenLDAP... LDAP (V3) - RFC 2251 LDAP API - RFC 1831 LDAP search - RFC 2254 AD password change “protocol” login pam_ldap LDAP API Application Account Profile Password Clear or SSL protected

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 nonstandard maps Certaines stratégies de groupe s’appliquent automatiquement

Linux Windows ADSI Active Directory Services Interface LDAP LDAP API nscd cache daemon LDAP (V3) - RFC 2251 LDAP API - RFC 1831 LDAP search - RFC 2254 login getpwnam Application LDAP API Application Account Profile UID GID Home directory Groups … nss_ldap Account Profile Groups Tel # Office # … Cleartext, SSL, SASL

Kerberos MIT v1.3.7 ou plus Heimdal Spécifique au fournisseur (mais risques de problèmes) LDAP OpenLDAP 2.2 PADL nss_ldap

Pour la démo : Windows Server 2003 R2, Active Directory, DNS, Certificate Service Red Hat 9 installé en mode « Workstation »

Kerberos krb5-devel (installé par défaut) krb5-libs (installé par défaut) krb5-workstation css_adkadmin-2.2_linux ( ) pam_krb css1_linux ( security.com/ ) security.com/ security.com/LDAPopenldap nss_ldap-220krb cyrus-sasl

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

Windows Security and Directory Services for UNIX Guide Download Center: TechNet online: Site interopérabilité Microsoft France