Openstuff Wiki : HowtoSambaAD

HomePage :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

Intégration d'un serveur LINUX dans un domaine Active Directory


Cet article explique comment intégrer un serveur Linux dans un domaine Active Directory. Nous verrons la configuration du client Kerberos ainsi que de Samba pour le dialogue avec le serveur AD. Puis nous terminerons avec l'authentification unifiées via l'utilisation de PAM.

1. Introduction Active Directory


Active Directory est au coeur des systèmes Microsoft Windows, c'est lui qui est en charge de la gestion des comptes utilisateurs, des authentifications, mais aussi d'un grand nombre d'informations sur les machines.

Active Directory repose sur différents protocoles réseaux :


2. Introduction à la gestion des utilisateurs UNIX


La gestion des comptes utilisateur LINUX est réalisée à l'aide de différents composants conformément à la philosophie UNIX (un programme fait une seule chose et la fait bien). Parmi ces différents acteurs, on trouve :

Les PAM (Pluggable Authentification Modules) permettent entre autres de sélectionner différentes procédures et sources d'authentification (ex: Authentification par cartes à puces, Bases de données, Annuaires...)

NSS (Name Services Switch) permet de fournir à Unix des services de correspondances entre noms, de toutes sortes (noms de machines et noms d'utilisateurs), et les identifiants de ces mêmes objets pour la machine (adresses IP et uid/gid) en utilisant diverses sources (Fichiers, Annuaires...).


3. Intégration d'un serveur Samba dans un domaine Active Directory


L'intégration d'un serveur Samba dans un domaine Active Directory nécessite la configuration d'un client Kerberos sur la machine Samba. Kerberos est un système d'authentification qui permet aux serveurs d'authentifier les utilisateurs et de communiquer en sécurité. Afin de réaliser l'intégration du serveur LINUX au domaine AD des composants additionnels sont requis.


3.1 Kerberos


Il est nécessaire de configurer un client Kerberos afin de valider l'identité du serveur LINUX dans le réseau Microsoft. Celui dialoguera avec le serveur AD pour effectuer des demandes de "tickets" au KDC qui seront utilisés pour assurer l'authenticité et la sécurité des communications.

Synchronisation du temps:

apt-get install ntpdate
ntpdate ntp.ciril.fr


Installation du client Kerberos:

apt-get install krb5-clients krb5-user


Configuration du client Kerberos (/etc/krb5.conf):

[libdefaults]
	    default_realm = EXAMPLE.COM

[realms]
EXAMPLE.COM = {
	    kdc = ad.example.com
	    admin_server = ad.example.com
}
[domain_realms]
	    .example.com = EXAMPLE.COM


Vérification de la connexion Kerberos:

kinit Administrateur@EXAMPLE.COM
klist
kdestroy


3.2 Samba


Pour accéder aux ressources partagées (SMB/CIFS) du domaine Windows, une installation de Samba est requise sur le serveur Linux qui jouera principalement le role de client SMB/CIFS.
Samba permettra également à l'aide de commandes MSRPC de dialoguer avec le serveur AD pour effectuer diverses opérations : ajout des informations sur le serveur LINUX dans l'annuaire, lister les comptes/groupes utilisateur, transmettre les demandes d'authentification...

Installation de Samba:

# apt-get install samba winbind


Configuration de Samba (/etc/samba/smb.conf):

# REALM Kerberos
realm = EXAMPLE.COM
# Domaine
workgroup = example0
# Active Directory Server gère la sécurité des ressources partagées
security = ADS
# Active Directory n'accepte pas les mots de passe en clair
encrypt passwords = yes


Création du compte machine pour le serveur Samba dans Active Directory:

net ads join -U Administrateur (pour quitter 'net ads leave')


Vérification d'accès via Kerberos aux ressources partagées du serveur "AD":

kinit Administrateur@EXAMPLE.COM
smbclient -L //AD -k
kdestroy


Vérification du "montage" d'une ressource partagée :

mount -t cifs -o username=Administrateur //ad/Public /mnt/test


=> voir également 'net ads info' et 'net ads status -U Administrateur'


4. Authentification unifiée UNIX / Windows


Le composant Winbind de Samba permet de résoudre les problèmes d'authentifications unifiées. Il permet principalement à l'aide de PAM (Pluggable Authentication Modules) et d'NSS (Name Service Switch) de faire apparaître des utilisateurs d'un domaine Windows comme des comptes UNIX.

Installation de Winbind:

apt-get install winbind


Configuration de Winbind (smb.conf):

# Correspondances des uids entre le serveur Linux et Active Directory
idmap uid = 10000-20000
# Correspondances des gids entre le serveur Linux et Active Directory
idmap gid = 10000-20000
# Lister les utilisateurs au démarrage de Winbind
winbind enum users = yes
# Lister les groupes au démarrage de Winbind
winbind enum groups = yes
# Caractère de séparation domaine/nom d'utilisateur (ex: DOMAINE+utilisateur)
winbind separator = +
# Si le domaine n'est pas spécifié on utilise celui par défaut
winbind use default domain = yes
# Shell par défaut
template shell = /bin/bash
# Répertoire home par défaut
template homedir = /home/win2k3/%D/%U


Vérification du fonctionnement de Winbind:

Redémarrage: /etc/init.d/winbind restart


Ajout du support Winbind à NSS (/etc/nsswitch.conf):

passwd: compat winbind
group:  compat winbind


Vérification du fonctionnement NSS+Winbind:

getent passwd
getent group


=> Doit renvoyer les comptes locaux POSIX et les comptes déclarés dans l'AD.


Ajout du support Winbind à PAM:

/etc/pam.d/common-auth:
auth    sufficient      pam_winbind.so
auth    required        pam_unix.so nullok_secure


/etc/pam.d/common-account:
account sufficient      pam_winbind.so
account required        pam_unix.so


/etc/pam.d/common-session:
session required        pam_unix.so
session required        pam_mkhomedir.so skel=/etc/skel/ umask=0077


(ou tout dans /etc/pam.d/system-auth)


Vérification de l'authentification PAM+Winbind:

mkdir -p /home/win2k3/EXAMPLE0


=> Il est possible de se logger sur une console avec un compte déclaré dans l'AD.
1ere fois essaye de s'authentifier sur l'AD. 2eme mot de passe pour le système local.

=> On peut également faire un ssh : (faire un restart du service /etc/init.d/ssh restart)

ssh Administrateur@localhost


=> plus besoin de créer de comptes POSIX ni Samba pour les partages: (idem /etc/init.d/samba restart)

smbclient -L localhost -U utilisateurAD

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki
Page was generated in 0.0693 seconds