PREMESSA
VMWare Server 2.0 è un prodotto estremamente utile, visto che fornisce gratuitamente la consolidata tecnologia di virtualizzazione di VMWare: personalmente utilizzo VMWare Server 2.0 nei miei ambienti di test e laboratorio, anche se qualche cliente ha deciso di usarlo per appoggarci sopra funzioni non critiche del proprio sistema  informativo.

Personalmente, ritengo che in questi casi il miglior sistema operativo Host è Linux: innanzitutto non si devono pagare le licenze per un S.O. il cui unico compito è far girare il software di virtualizzazione e, in secondo luogo, una buona installazione Linux (leggi, text only con il minimo dei servizi installati ed operativi) ha una occupazione di memoria decisamente inferiore a quella di una qualunque installazione di base di Windows.

VMWare si può installare su molte distribuzioni (ho personalmente provato Debian, Ubuntu e CentOS), ma la mia scelta cade quasi sempre sul "clone" di RedHat, ovvero CentOS, per il semplice motivo che VMWare stessa "certifica" il suo prodotto proprio per RedHat e che l'installazione su CentOS non richiede la ricompilazione dei moduli di VMWare.

CONFIGURAZIONE
Il primo passo per "far conoscere" gli utenti Windows alla macchina Linux è quello di joinare la macchina stessa adl dominio Active Directory (vedi questo articolo per ulteriori informazioni).
Una volta che il vostro serverino Linux è a tutti gli effetti una macchina del dominio AD, possiamo indagare un po' meglio su come VMWare autentica gli utenti: la risposta tutto sommato standard dato che VMWare utilizza PAM (acronimo di Pluggable Authentication Module) come meccanismo di autenticazione: brevemente, PAM è una "suite of shared libraries that enable the local system administrator to choose how applications authenticate users" (frase tratta dal manuale di PAM che rende molto bene l'idea!). La "versatilità" di PAM è legata in primis ai file di configurazione che consentono di specificare uno "schema" diverso per ogni applicazione ed al fatto che le "librerie" di autenticazione sono molte e variegate.

Vediamo allora com'è fatto il file di VMWare (chiamato vmware-authd) dentro la directory /etc/pam.d:

auth       required     pam_unix.so shadow nullok
account    required     pam_unix.so

Cerchiamo di spiegare quello che si trova nel file, senza entrare nel dettaglio del PAM.

Il valore prima colonna specifica il "management task" ovvero a cosa serve quella regola: le due opzioni indicate specificano rispettivamente in che modo autenticare (= verificare che lo username e la password siano valide) gli utenti (opzione auth) mentre la seconda (opzione account)svolge compiti generici legati all'autenticazione (es. verificare che l'utente si logghi solo da una postazione ben specifica e magari solo in certe ore del giorno).

Il valore della seconda colonna invece (in entrambi i casi required) serve per specificare cosa succede se la regola fallisce e required specifica che il fallimento di questa regola causa il fallimento dell'autenticazione e dell'accounting.

Il valore successivo (pam_unix.so) è la vera e propria libreria che svolge le operazioni di autenticazione ed i valori che seguono sono tipici per ogni libreria: pam_unix è la "classica" autenticazione basata sul classico file passwd/shadow ed i parametri indicati specificano rispettivamente l'utilizzo delle "shadow password" e mentre nullok consente di loggarsi anche con password vuote (brrrrrrrrrr!).
Nel caso della riga account il pam_unix.so controlla alcune opzioni specifiche del modulo shadow (senza entrare nel dettaglio) e se non vengono trovati la libreria ritorna OK.

Allora, vediamo cosa dobbiamo aggiungere per far funzionare l'autenticazione con Winbind, il modulo Linux che si interfaccia con AD:

auth       sufficient   /path_to_library/pam_winbind.so krb5_auth
auth       required     pam_unix.so shadow nullok
account    required     pam_unix.so

Come si può vedere è stata aggiunta una riga dove si invoca la libreria PAM di winbind (pam_winbind.so) specificando che la libreria deve usare il kerberos (parametro krb5_auth). Guardando con attenzione si nota però che il winbind è sufficient acontrario del pam_unix.so che è required: l'opzione sufficient  fa si che, in caso di fallimento della regola, PAM continui l'elaborazione con le regole successive.

In pratica, in questa configurazione, VMWare prova prima ad autenticare l'utente in AD e poi, se non funziona, passa al file passwd/shadow locale della macchina linux. Se le due regole fossero state messe al contrario (ovvero prima required pam_unix e poi sufficient pam_winbind.so), l'utente AD non sarebbe mai riuscito ad entrare visto che PAM non avrebbe trovato l'utente dentro il passwd/shadow locale ed, essendo la regola di tipo required non avrebbe proseguito nella valutazione delle regole.

Con questa banale configurazione, il vostro serverino linux + VMWare 2.0 assomiglierà parecchio al fratello maggiore ESX! Non solo: i permessi di accesso a VMWare Server potranno essere dati ai gruppi di Active Directory
 

vmware2 ad


NOTA: se aggiornate VMWare (rilascio di una nuova build) è praticamente certo che il file /etc/pam.d/vmware-authd verrà sovrascritto con quello predefinito e dovrete quindi rimodificarlo da zero!

ATTENZIONE! Quando VMWare parte (e anche periodicamente) prova a verificare se i gruppi usati nelle autorizzazioni esistono. Se all'avvio macchina VMWare parte PRIMA Winbind c'è il rischio che non riesca a trovare i gruppi: il risultato è che i gruppi "mancanti" vengono rimossi dalla configurazione!
La soluzione (almeno per ora) consiste nel mettere WINBIND in avvio PRIMA di VMWare (di solito parte al runlevel 3 almeno con ordine intorno al 20 - basta portarlo verso il 90 e accertarsi che WINBIND usi il 20)