OpenLDAP e Microsoft Active Directory

Da Security e-Book.

Spesso e' facile integrare le macchine unix modificando la struttura di Microsoft Active Directory usando SFU[1] o le relative estensioni che sono disponibili a partire da Windows 2003 R2 e successive. Nelle grosse realta' enterprises non sempre e' possibile questa integrazione, piu' per problemi organizzativi che tecnici, perche' le persone che si occupano dell'amministrazione di ambienti Windows non sono le stesse che gestiscono gli ambienti Unix/Linux. Inoltre spesso prodotti commerciali hanno bisogno di installare dei plugin per poter intercettare il cambio della password da parte di un utente, in quanto Active Directory usa un hash proprietario.

Come fare quindi per gestire in un unico punto le password anche per gli ambienti Unix/Linux? E' possibile, tramite un apposito disegno architetturale, fare in modo che un LDAP adatto ad ambienti open, quale ad esempio OpenLDAP[2], si integri con Active Directory per gestire la base utenti.

Indice

L'architettura

Sono stati provati numerosi prodotti, come ad esempio meta directory che fossero in grado di correlare in tempo reale informazioni da Active Directory e da altre fonti dati, quali ad esempio databases. Queste soluzioni si sono rivelate troppo pesanti e complesse per l'utilizzo normale o alcune volte troppo instabili.

La soluzione adottata e' stata quindi di usare un LDAP open source (OpenLDAP): che conterra' le informazioni aggiuntive degli utenti (es: UID, GID, ecc..) e che utilizzera' una chain authentication. OpenLDAP, infatti, permette di utilizzare per autenticare un utente il meccanismo della libreria SASL, quindi permettendo autenticazioni quale ad esempio PAM e GSSAPI. Sfruttando quindi le PAM, potremmo "agganciare" Active Directory e autenticare l'utente con la password di dominio. Anche se e' possibile collegarsi ad Active Directory utilizzando direttamente Kerberos tramite GSSAPI, si e' scelto di utilizzare le PAM per permettere un'autenticazione flessibile: usando le PAM potremmo sfruttare ulteriori meccanismi per autenticare l'utente come ad esempio un sistema di One Time Password (OTP).

Figura 1 - Architettura d'insieme

In Figura 1 e' rappresentata la visione di insieme dello schema architetturale utilizzato. Il server, che chiameremo Proxy LDAP, verra' interrogato da clients LDAP quali ad esempio workstation Unix e sistemi server Unix, in particolare la soluzione e' stata provata con Linux e Solaris. Il proxy server prendera' in carico la richiesta, interfacciandosi con i server di autenticazione ovvero i Domain Controllers di Windows e il radius server che gestisce i token OTP.

Figura 2 - Architettura di dettaglio

La Figura 2 va nel dettaglio del Proxy LDAP ed e' diviso in tre macro aree funzionali: il server LDAP, il provisioning e la sincronizzazione con Active Directory.

Il server LDAP e' la parte principale del sistema e provvede a gestire le queries LDAP provenienti dai client. Il sistema e' basato su OpenLDAP ed e' organizzato come un LDAP standard. OpenLDAP permette di agganciare un meccanismo di sicurezza esterno tramite l'utilizzo delle librerie SASL[3]. SASL permette di agganciare differenti schemi di autenticazione tramite il SASL Authentication server (saslauthd): sfruttando questa potenzialita', e' possibile utilizzare come meccanismo di autenticazione le librerie PAM[4]. In questo modo siamo liberi di scegliere il meccanismo di autenticazione del sistema operativo piu' opportuno: utilizzeremo quindi winbind per verificare l'autenticazione dell'utente con Active Directory ed eventualmente il modulo pam_radius per l'autenticazione con il server OTP.

La sincronizzazione con Active Directory avviene attraverso uno programma chiamato adimport. Questo programma prende informazioni dal Domain Controller relative all'utente, attraverso una interfaccia a riga di comando, e le inserisce nel server LDAP utilizzando un Directory Information Tree (DIT) standard.

Il provisioning e' l'ultimo componente del sistema Proxy LDAP e consiste in un'interfaccia web-based per la gestione delle utenze e dei gruppi LDAP. Il provisioning e' stato realizzanto a partire dal programma GOsa², opportunamente configurato in modo che solo le utenze e i gruppi unix possano essere modificati e che l'utente o l'amministratore non possa cambiare la password, in quanto la password e' effettivamente indicata in Active Directory.

[figure 1- LDAP chain] The OpenLDAP can use external authentication through the SASL authentication server (saslauthd). The authentication server supports different authentication mechanisms such as ldap, kerberos, shadown and PAM. The PAM libraries can be configured for authenticate to different systems, such as winbind, radius, ... Although Active Directory can be directly linked with SASL through Kerberos, I've decided to use the PAM mechanism, so that the end-user can be free to choose different schemas. In the customer case, it was implemented though winbind, leaving the choice open for integrating OTP tokens through PAM radius.

[figure 2 – authentication overview]

The result is a chain authentication: 1.The client ask the LDAP server 2.The user record in the LDAP has lookup information for SASL 3.SASL authentication server asks PAM libraries for authentication information 4.PAM invoke winbind server 5.The user is checked against Active Directory

Finding the User ID Sync/Import from Active Directory Web interface

Il server LDAP

Configurazione di Samba

Configurare il sistema per agganciare i Domain Controllers tramite Samba. E' importante sottolineare il tipo di idmap backend rid, che consente di generare gli UID/GID degli utenti a partire dal SID di Windows. Attraverso un algoritmo, due winbind indipendenti saranno capaci di generare lo stesso UID e GID. Questo ci servira' per la fasa di importazione.

[global]
   workgroup = AZIENDA
   realm = AZIENDA.LAN
   netbios name = PROXYLDAP
   server string = proxyldap
   security = ads
   password server = *
   domain master = No
   dns proxy = No
   template homedir = /tmp
   template shell = /bin/bash

   client schannel = Auto
   server schannel = Auto
   client signing = Auto
   server signing = Auto
   client use spnego = No

   socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

   use kerberos keytab = true

   winbind enum users = Yes
   winbind enum groups = Yes
   winbind use default domain = Yes
   winbind separator = /

   allow trusted domains = no
   idmap uid = 20000-100000
   idmap gid = 20000-100000
   idmap backend = rid

   local master = No

Faremo quindi la join al dominio con il seguente comando:

net ads join -U Administrator

SASL

Modifichiamo il file /etc/sysconfig/saslauthd, cambiando il parametro MECH come segue:

MECH=pam

In questo modo agganciamo le librerie PAM dal server saslauthd. Creiamo il file /usr/lib/sasl2/slapd.conf in modo tale che il server OpenLDAP usi come password check mechanism il server saslauthd. Il file deve contenere quanto segue:

pwcheck_method: saslauthd

PAM

Creiamo il file /etc/pam.d/ldap che verra' utilizzato dal daemon slapd di OpenLDAP per verificare la password degli utenti. Noterete il modulo winbind (pam_winbind.so) e il modulo RADIUS (pam_radius_auth.so)

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_winbind.so use_first_pass
auth        sufficient    pam_radius_auth.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_winbind.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_winbind.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

OpenLDAP

# comment
dn: dc=azienda,dc=lan
dc: azienda
description: Azienda Spa
objectClass: dcObject
objectClass: organization
o: namchi.com

dn: ou=users,dc=azienda,dc=lan
ou: users
objectClass: organizationalUnit

dn: ou=groups,dc=azienda,dc=lan
ou: groups
description: Group List
objectClass: top
objectClass: organizationalUnit

Importazione da Active Directory

Provisioning

Architettura di produzione

Figura 3 - Architettura di produzione

In produzione (Figura 3) si e' raddoppiato il sistema proxy, inserendo uno slave LDAP in un sito geograficamente differente. La replica ha solamente la funzionalita' di server LDAP, con un aggancio ad Active Directory e all'OTP server per l'autenticazione.

Note

  1. ↑ Windows Services for UNIX
  2. ↑ OpenLDAP e' un popolare LDAP server OpenSource
  3. ↑ SASL e' un acronimo di Simple Authentication and Security Layer
  4. ↑ PAM e' un acronimo per Pluggable Authentication Modules

Voci correlate

Estratto da "http://ebook.sikurezza.org/wiki/OpenLDAP_e_Microsoft_Active_Directory"
Strumenti personali
Pubblicità