Linux Windows: Prove di convivenza

Transcript

1 PierGiorgio Malusardi Microsoft Italia Linux Windows: Prove di convivenza [Type text]

2 Sommario Introduzione... 3 Cos è Active Directory... 3 Estensioni di Active Directory per UNIX/Linux... 4 Ambiente di test... 5 Installazione dei componenti aggiuntivi di Windows Server 203 R Configurazione di Active Directory e dei servizi di supporto... 7 Configurazione del Time Service in Windows... 7 Configurazione del Time Service in Linux... 8 Creazione degli utenti in Active Directory... 8 Creazione delle home directory sul server Windows Configurazione dei computer con Linux Join al dominio Active Directory del computer Linux Configurazione di Kerberos come servizio di autenticazione Configurazione di LDAP come servizio di autorizzazione e store delle informazioni utente Test della connettività verso il Domain Controller Active Directory come server LDAP Configurazione del mount delle home directory create sul Domain Controller Active Directory Riferimenti PierGiorgio Malusardi Linux Windows: prove di convivenza Microsoft

3 Introduzione Uno dei problemi che si è posto quasi subito nel mondo dell informatica distribuita è il mantenimento di un sistema di gestione centralizzata delle identità (ossia delle informazioni riguardanti gli utenti dei sistemi), in modo da consentire agli utenti di accedere alle risorse presenti in rete da un qualsiasi punto. Nel tempo, le risposte a questa sfida sono state diverse, basate su tecnologie e protocolli diversi, spesso non interoperabili. Focalizzandoci sui due mondi che ci interessano nell ambito di quest articolo (Windows e UNIX/Linux) le principali soluzioni al problema della centralizzazione della gestione delle identità sono (senza pretendere di essere esaustivo): UNIX/Linux YP NIS NIS+ LDAP Sviluppato da Sun Microsystems Il suo nome iniziale (YP Yellow Pages modificato perché marchio registrato in UK) spiega il prefisso di molti dei tool di gestione. È un sistema di gestione degli account che si sovrappone al tradizionale sistema UNIX basato sui file passwd group shadow. Sfrutta una serie di mappe per fornire ai client di rete diverse informazioni (nomi macchina, copie utenti-password,...). È un evoluzione del precedente. Il Lightweight Directory Access Protocol ora alla versione tre e definito dallo RFC 2251 definisce un protocollo di accesso ai servizi di directory. Questo protocollo è usato per accedere a database distribuiti e gerarchici che possono contenere informazioni qualsiasi. Nell ambito della gestione delle identità il database conterrà informazioni riguardanti gli utenti: nome utente, UID, GID, password, ecc... Su questo protocollo si basano diverse soluzioni di gestione delle identità, commerciali e open (Sun ONE Directory Server, OpenLDAP, Novell edirectory). Kerberos Inizialmente sviluppato al MIT (Massachusetts Institute of Technology) il protocollo di autenticazione Kerberos è ora uno standard IETF (RFC 1510). Windows Lan Manager NTLM Active Directory Tabella 1 Questo protocollo definisce un sistema di autenticazione delle identità per l accesso alle risorse in rete. Questo protocollo di autenticazione, inizialmente sviluppato in collaborazione con IBM, è presente sin dalle prime versioni di Windows ed è tuttora implementato per compatibilità all indietro. Ora alla versione due, è un evoluzione di LAN Manager ed è presente anche nelle ultime versione di Windows per compatibilità all indietro e per gestire situazioni in cui non è presente un server di autenticazione centralizzato. Introdotta con Windows 2000, Active Directory è una soluzione di gestione dell autenticazione delle identità e di autorizzazione degli accessi alle risorse, basata su diversi protocolli standard tra cui Kerberos e LDAP. Cos è Active Directory Come indicato in Tabella 1, con Windows 2000 è stata introdotta come strumento di gestione centralizzata delle identità Active Directory. Active Directory è fondamentalmente un servizio per la gestione delle identità (utenti, computer, servizi, ecc...) e delle autorizzazioni che si basa, per il suo funzionamento, su alcuni protocolli standard: Kerberos È il protocollo di autenticazione inventato al MIT (Massachusetts Institute of Technology), poi formalizzato con lo RFC Il protocollo prevede l esistenza di almeno un server di autenticazione (KDC Key Distribution Center) di cui tutte le entità di rete (utenti, servizi, computer) si fidano. Il KDC autentica l entità che chiede l accesso a una risorsa e rilascia un ticket per l accesso a questa. Il ticket è specifico per l accesso a una data risorsa e ha una durata limitata nel tempo. Le entità di rete possono essere organizzate in REALM (reami) che sono entità amministrative e confini di sicurezza. Microsoft Linux Windows: prove di convivenza PierGiorgio Malusardi 3

4 LDAP Tra diversi REALM è possibile creare delle relazioni di fiducia (trust) in modo da consentire a un entità (es. un utente) appartenente a un REALM l accesso a risorse (es. un file server) presente in un altro REALM. Nel mondo Windows il ruolo dei REALM è svolto dai Domini Active Directory e il ruolo dei server KDC è svolto dai Domain Controller (controllori di dominio). La versione di Kerberos usata da Windows è la 5. Questo protocollo è pensato per la gestione d informazioni contenute in database gerarchici e distribuiti. Il protocollo consente di gestire informazioni qualsiasi. La struttura del database e le informazioni in esso contenuto sono definite dalla Schema (elenco delle classi di oggetti e dei relativi attributi creabili nel database). Lo Schema di Active Directory è definito da Microsoft, ma è estensibile in modo che possa gestire nuovi attributi legati a classi già definite (per esempio l attributo Stipendio aggiunto alla classe User) o nuove classi (derivate da classi già esistenti o create ex-novo per esempio la classe AutoAziendale). Active Directory usa il protocollo LDAP v.3 per gestire le informazioni riguardanti le entità di rete (utenti, computer, servizi, ecc.). Il ruolo di LDAP server è svolto dai Domain Controller. LDIF standard SNTP (RFC 1769) è lo strumento utilizzato in una rete basata su Active Directory per mantenere allineati i tempi macchina entro una tolleranza di 5 minuti (valore di default modificabile). LDAP Data Interchange Format (RFC 2849) è utilizzato per apportare modifiche al database LDAP usato da Active Directory (inserzione/estrazione di dati, modifiche dello schema, ecc...). X.509 L infrastruttura X.509 (RFC 3280 e 2459) può essere usata con Active Directory per consentire l autenticazione su Kerberos usando certificati digitali e smartcart. Tabella 2 Active Directory oltre ad implementare i servizi di autenticazione e autorizzazione fornisce anche: un metodo di replica dei dati tra i diversi Domain Controller (replica per attributo e multimaster), un sistema per la gestione centralizzata delle configurazioni dei client e dei server (Group Policy), il supporto per sever di posta Exchange, la possibilità di mantenere nel suo database i dati dei DNS basati su Windows, e altri servizi ancora. In quest articolo vedremo come utilizzare i servizi nativi di Active Directory per gestire anche le identità degli utenti UNIX/Linux e la loro autenticazione in fase di logon a macchine UNIX/Linux. Estensioni di Active Directory per UNIX/Linux DNS Il servizio DNS è fondamentale per il funzionamento di Active Directory. Definisce lo spazio dei nomi dei domini Active Directory e costituisce lo strumento utilizzato dalle diverse entità per trovare i server che erogano i servizi di Active Directory (KDC server, LDAP Server,...). Non può esistere un Domino Active Directory senza il corrispettivo dominio DNS (mentre non è ovviamente vero il contrario). SNTP Il protocollo Kerberos prevede la sincronizzazione dei tempi macchina per il suo corretto funzionamento. Uno sfasamento dei tempi, oltre una certa tolleranza, tra i client, i server e il KDC può portare all impossibilità di accedere alle risorse di rete. Il protocollo Le cose interessanti, ai fini dell integrazione Windows UNIX/Linux, sono che un Dominio Active Directory è anche un REALM Kerberos e che un Domain Controller di Active Directory è anche un server KDC e un server LDAP standard. Kerberos e LDAP sono anche implementati e supportati in pressoché tutte le versioni di UNIX/Linux e quindi questi due protocolli saranno i pilastri su cui costruiremo la possibilità di utilizzare Active Directory come servizio di autenticazione anche per gli utenti UNIX/Linux. Il primo problema che si pone è che lo Schema standard di Active Directory non prevede nessun attributo per la gestione delle informazioni tipiche degli utenti Linux (es. UID, GID, shell di default, home directory, ecc...). È necessario quindi modificare lo schema in modo da associare alla classe User definita in Active Directory (e 4 PierGiorgio Malusardi Linux Windows: prove di convivenza Microsoft

5 ad altre classi) gli attributi necessari per gestire gli utenti del mondo UNIX/Linux. Ci sono due possibilità per fare questo: Installare su un Domain Controller i Service for UNIX 3.5. Questi sono liberamente scaricabili dal sito Microsoft, per tutti i possessori di una copia registrata di Windows 2000 Server o Windows Server 2003 (in una delle tante versioni). Installare i componenti aggiuntivi di Windows Server 2003 R2. Le due opzioni non sono identiche. L installazione dei Service for UNIX 3.5 introduce nello Schema di Active Directory circa trenta attributi per la gestione di utenti, computer, servizi, ecc... UNIX/Linux. Il nome di questi attributi inizia con mssfu30. Tra questi quelli di nostro interesse sono riportati in Tabella 3. mssfu30uidnumber mssfu30gidnumber mssfu30homedirectory mssfu30loginshell Tabella 3 Attributo della classe User per la gestione dello UID di utenti UNIX/Linux. Attributo della classe User per la gestione del GID di utenti UNIX/Linux Attributo della classe User per la gestione del percorso alla home directory. Attributo della classe User per la gestione del percorso alla shell di login di default dell utente. L installazione dei componenti aggiuntivi di Windows Server 2003 R2 introduce invece nello schema di Active Directory gli attributi definiti dallo RFC 2307 e rappresenta quindi una soluzione più aderente agli standard. Per questo motivo prenderemo in considerazione, in quest articolo, il caso di uso di Windows Server 2003 R2, indicando, dove è necessario, le differenze di configurazione che devono essere implementate da chi usa i Service for UNIX 3.5 (SFU3.5). Ambiente di test Per quest articolo userò un ambiente di test con un server Windows Server 2003 R2 (dc001.pgm.local), che fungerà da Domain Controller di un Dominio Active Directory di nome pgm.local, e un computer Linux (fc001.pgm.local) con installato Fedora Core 6. Chi voglia fare degli esperimenti può trovare una macchina virtuale con Windows Server 2003 R2 (da usare con Virtual Server 2005 R2 o con Virtual PC) a questo link: spx Installazione dei componenti aggiuntivi di Windows Server 203 R2 Per installare i componenti aggiuntivi di Windows Server 2003 R2 si deve inserire il secondo CD fornito e, alla comparsa del programma d installazione, selezionare l opzione che consente di portare a termine l installazione delle componenti aggiuntive (Figura 1). Figura 1 Terminato il processo d installazione, è possibile aggiungere alcuni componenti che ci saranno utili per integrare Windows e UNIX/Linux in un unico ambiente: si deve accedere a Control Panel Add/Remove Programs Add/Remove Windows Components e in questo selezionare Active Directory Services. Nella finestra di dialogo Active Directory Services selezionare Identity Management for UNIX, quindi OK (Figura 2). Nella finestra Windows Components, selezionare Other Network File and Print Services. Nella finestra di dialogo Other Network File and Print Services selezionare l opzione Microsoft Service for NFS e quindi OK (Figura 3). S installerà in questo modo sul server Windows il servizio NFS e il relativo client, rendendo più semplice lo scambio di file tra i due ambienti e rendendo possibile la creazione di un unico file system su cui appoggiare le home directory degli utenti sia per l ambiente UNIX/Linux che per l ambiente Microsoft. Rimanendo ancora nella finestra Windows Components, selezionare l ultimo componente: Subsystem for UNIX-based Application (Figura 4). Questo componente è un sottosistema che è eseguito sopra il kernel di Windows allo stesso livello del sottosistema Win32 e mette a disposizione un Microsoft Linux Windows: prove di convivenza PierGiorgio Malusardi 5

6 ambiente completo di esecuzione per applicazioni basate su UNIX. In particolare ci permetterà di eseguire delle shell UNIX (cshell e korn). Figura 2 Figura 4 È possibile scaricare e installare questi componenti in un qualsiasi momento successivo all installazione di SUA dal link: nixcomponents/webinstall.mspx Scaricati i componenti aggiuntivi, è possibile eseguirne l installazione lanciando il file eseguibile scaricato (Utilities and SDK for UNIX-Based Application_X86.exe) che si scompatterà nella directory scelta consentendo di lanciare il programma Setup.exe per l installazione vera e propria. Scegliendo l opzione Custom Installation, il programma d installazione consente di scegliere i componenti che si vogliono installare (Figura 5) Figura 3 Premere il bottone Next e attendere il completamento dell installazione dei componenti scelti. Durante l installazione del Subsystem for UNIX-based Application (SUA) una finestra di dialogo chiede se si vogliono scaricare da internet dei componenti aggiuntivi opzionali. Questi componenti opzionali comprendono oltre 300 utilità (GNU e basate su BSD, tra cui le shell) e le librerie e i tool di sviluppo (gcc, make,...) sia in versione 32 sia 64 bit. Figura 5 6 PierGiorgio Malusardi Linux Windows: prove di convivenza Microsoft Secondo il tipo di ambiente da integrare (UNIX e/o Linux) conviene aggiungere, alle scelte di default, anche le SRV-5 Utilities e/o le GNU Utilities. Se si vogliono ricompilare per SUA dei programmi UNIX/Linux si deve installare anche lo GNU SDK. Scegliendo di installare lo GNU SDK sarà richiesto di accettare la licenza LGPL sotto cui questo tool è distribuito (Figura 6). È possibile installare un tool per Visual Studio (opzione non visibile in Figura 5) per eseguire il debug di applicazioni UNIX/Linux per SUA.

7 componenti che useremo (ad esclusione delle shell bash), essendo parti integranti di Windows Server 2003 R2 sono supportati da Microsoft. Figura 6 È quindi chiesto (Figura 7) se abilitare, per le utilità installate, la possibilità di usare setuid e la gestione case sensitive dei nomi dei file (Windows normalmente conserva il case del nome dei file, ma è case insensitive : per Windows FILE.txt e file.txt sono lo stesso file). Figura 8 Figura 9 Figura 7 Al termine dell installazione dei componenti aggiuntivi di Windows Server 2003 R2 e dei componenti opzionali per SUA avremo a disposizione: Le classi e gli attributi Active Directory per gestire entità UNIX/Linux Un server e un client NFS (Figura 8) Tool e librerie di sviluppo per applicazioni UNIX/Linux in SUA e due shell UNIX (cshell e kshell Figura 8) Chi fosse interessato ad una shell bash per il sottosistema SUA può trovarne i sorgenti al link Procediamo ora all installazione dei Support tools inserendo il CD di installazione di Windows Server 2003 e lanciando suptools.msi dalla directory Support. Accettare tutte le impostazioni di default. Abbiamo ora a disposizione tutto quello che ci serve per integrare l autenticazione di utenti UNIX/Linux in Active Directory. È da sottolineare che tutti i Configurazione di Active Directory e dei servizi di supporto Siccome Kerberos richiede che la differenza di tempo macchina tra il KDC e gli altri computer del REALM non superi un valore prefissato, il primo passo sarà garantire la sincronizzazione dei tempi macchina. Supporremo che i nostri server abbiano accesso ad Internet e quindi useremo dei time server pubblici come sorgenti dei tempi. Configurazione del Time Service in Windows Il Time Service in Windows può essere configurato usando l utilità a linea di comando w32tm.exe. 1. Avviare l editor del Registry: in Start Run digitare regedit e cliccare OK 2. Trovare la voce: HKEY_LOCAL_MACHINE\System\CurrentControlSe t\services\w32time\timeproviders\ntpclient Microsoft Linux Windows: prove di convivenza PierGiorgio Malusardi 7

8 3. Nel pannello di destra fare clic con il tasto destro del mouse sulla voce Enabled e selezionare Modify dal menù contestuale 4. Nella finestra di dialogo Edit DWORD Value, inserire 0 nel campo Value data, cliccare OK e chiudere l editor del registry. 5. Aprire una shell. (Cliccare Start, cliccare Run, inserire cmd e cliccare OK). 6. Al prompt inserire: w32tm /config /update Questo commando rende effettive le modifiche apportate alla configurazione. 7. Al prompt dei comandi inserire il seguente comando: net stop w32time && net start w32time Questo commando riavvia il servizio con la nuova configurazione. Configurazione del Time Service in Linux In Linux il time service è fornito dal demone NTP (ntpd in Fedora Core 6) che costantemente aggiorna l orologio di sistema con il tempo fornito dal server NTP. Il file di configurazione per il demone NTP è ntp.conf (tipicamente in /etc in Fedora) che è letto all avvio del demone. Verificare che il servizio sia attivo eseguendo in una shell il comando # ps ef grep ntpd Se il servizio non è avviato si provveda ad avviarlo e a configurarlo per l avvio al boot del sistema. Modificare, con l editor preferito, il file /etc/ntp.conf perché contenga almeno le seguenti linee (indispensabili al corretto funzionamento del demone NTP nel nostro scenario): # ntp.conf ntpd configuration file server ntp1.ien.it server ntp2.ien.it server dc001.pgm.local #server windows driftfile /var/lib/ntp/ntp.drift service ntpd restart in alternativa /etc/init.d/ntpd restart. Creazione degli utenti in Active Directory Iniziamo adesso a creare in Active Directory gli utenti che dovranno fare logon su macchine Linux. Anche se non necessario, il mio consiglio, per chiarezza di configurazione, è di mantenere gli utente specifici del mondo Linux in una struttura separata in Active Directory. A questo scopo creiamo un apposita struttura di Organizational Unit (contenitori di oggetti): 1. Da Start Administrative tools avviare Active Directory Users and Computers 2. In Active Directory Users and Computers fare clic, con il tasto destro del mouse, sul dominio (nel mio caso pgm.local) e, dal menu contestuale, scegliere New Organizational Unit. 3. Nella finestra New Object Organizational Unit, inserire Linux-OU (o un altro nome di vostro piacimento) nel campo Name e cliccare OK. 4. Fare clic con il tasto destro del mouse sulla organizational unit Linux-OU e, dal menù contestuale, scegliere New Organizational Unit. 5. Nella finestra di dialogo New Object Organizational Unit, nel campo Name inserite UNIX-Users (o un altro nome di vostro piacimento) e cliccate OK. 6. Ripetere le operazioni 4 e 5 per creare le organizational unit UNIX-Groups e UNIX- Computers fino ad ottenere la struttura di Figura 10. Questo è un file di configurazione minimale. Le linee server indicano quali server NTP di livello superiore saranno interrogati per avere il tempo corretto. La linea driftfile consente al demone NTP di registrare, nel file indicato, informazioni relative all accuratezza dell orologio locale. In questo modo si riducono i problemi di mantenimento del tempo locale corretto in caso d irraggiungibilità dei server indicati: nel file è scritto il tasso di modifica del tempo locale rispetto a quello dei server dei tempi. Dopo la modifica del file di configurazione il demone deve essere riavviato con il comando: Figura 10 Dopo aver creato la struttura di OU, passiamo a creare gli utenti. 1. Da Active Directory Users and Computers fare clic con il tasto destro del mouse sulla OU UNIX-Users e dal menu contestuale scegliere New e User. 2. Nella finestra di dialogo New Object User, nel campo Full Name inserire il nome utente (nel mio caso lx001), nel campo User logon name inserire il nome utilizzato per il logon (lx001), e cliccare Next. 8 PierGiorgio Malusardi Linux Windows: prove di convivenza Microsoft

9 3. Nella finestra di dialogo New Object User inserire, e confermare, una password, deselezionare l opzione User must change password at next logon e cliccare Next e quindi Finish. Ripetere l operazione per creare tutti gli utenti desiderati (se gli utenti da inserire fossero molti, è possibile eseguire l import degli account Linux o usare degli script per la creazione bulk degli utenti). Creiamo ora i gruppi di sicurezza a cui gli utenti Linux apparterranno. Il concetto di gruppo di utenti in Windows è analogo a quello UNIX/Linux. 1. Sempre in Active Directory Users and Computers, cliccare con il tasto destro del mouse la OU UNIX- Groups, dal menù contestuale scegliere New e quindi Group. 2. Nella finestra di dialogo New Object Group, nel campo Group Name inserire il nome desiderato per il gruppo di utenti (nel mio caso lx-grp001) e cliccare OK. Ripetere l operazione fino a creare tutti i gruppi necessari. Per consentire la lettura dei dati in Active Directory agli utenti Linux è necessario configurare un utente di servizio che faccia da proxy. 1. Sempre in Active Directory Users and Computers fare clic con il tasto destro del mouse sul contenitore Users e scegliere dal menù contestuale New e User. 2. Nella finestra di dialogo New Object User, nel campo Full Name inserire padl, nel campo User logon name inserire ancora padl e cliccare Next. 3. Nella finestra di dialogo New Object User inserire e confermare una password (questa password sarà usata successivamente e quindi è necessario ricordarla), deselezionare l opzione User must change password at next logon, selezionare le opzioni User cannot change password e Password never expire, cliccare Next e quindi Finish. Impostiamo ora gli attributi relativi a UNIX/Linux dei gruppi e degli utenti appena creati in Active Directory. 1. Ancora in Active Directory Users and Computers espandere la organizational unit Linux-Groups e fare doppio clic su uno dei gruppi di utenti creati (nel mio caso lx-grp001). 2. Nella finestra <nome gruppo> Properties selezionare il tab UNIX Attribute e impostate i valori dei campi come segue (Figura 11) a. NIS domain: nome del dominio Active Directory b. GID: un valore di GID appropriato (nel mio caso 10001) c. Members: inserire gli utenti che appartengono a questo gruppo usando il bottone Add Figura Ripete l operazione per gli altri gruppi di sicurezza 4. In Active Directory Users and Computers espandere la organizational unit Linux-Users e fare doppio clic su uno degli utenti creati (nel mio caso lx001). 5. Nella finestra <nome utente> Properties selezionate il tab UNIX Attributes e riempite i campi come indicato sotto (Figura 12): a. NIS domain: nome del dominio Active Directory (nel mio caso pgm) b. UID: un valore appropriato di UID (nel mio caso 20001) c. Login shell: /bin/bash (o un altra shell di vostra scelta) d. Home directory: /winhome/<nome utente> (per me /winhome/lx001) e. Primary group name (GID): il nome o il GID del gruppo primario cui l utente appartiene (nel mio caso lx-grp001) 6. Ripetere l operazione per gli atri utenti Figura 12 Microsoft Linux Windows: prove di convivenza PierGiorgio Malusardi 9

10 L utente che funge da proxy per l accesso ad Active Directory dai computer Linux richiede una configurazione diversa dagli altri utenti Linux: NIS domain: nome del dominio Active Directory (nel mio caso pgm) UID: 499 (se non è già in uso) Login shell: /sbin/nologin Home directory: /dev/null Queste impostazioni impediscono l uso dell utente proxy (padl) per login locali sulle macchine Linux. Creazione delle home directory sul server Windows Nella configurazione degli attributi UNIX degli utenti Active Directory abbiamo indicato, come home directory, /winhome/<nome_utente> invece dell usuale /home/<nome_ utente>. Questa directory, di cui eseguiremo il mount all avvio sulle macchine Linux, risiede sul server Windows ed è esportata dal servizio NFS installato su questo. Sul server Windows selezionate una partizione con sufficiente spazio per contenere i dati utente e create una directory con il nome che preferite (nel mio caso e:\winhome). Sotto questa directory create le directory con i nomi degli utenti che faranno login da Linux. NFS Sharing e selezionare Share this folder con le seguenti opzioni (Figura 13): Sharename: winhome (o il nome che avete inserito negli attributi UNIX degli utenti) Encoding: ANSI Anonymous UID: (corrisponde a nfsnobody) Anonymous GID: (corrisponde a nfsnobody) Per l impostazione della sicurezza degli accessi premere il bottone Permissions (Figura 14). Tenete presente che le impostazioni dei diritti d accesso fatte a livello di NTFS sono per utente e più raffinate rispetto a quelle impostabili a livello di NFS. Figura 13 Impostare la sicurezza NTFS delle diverse home directory in modo che solo il proprietario abbia diritto di accesso in lettura e scrittura e cambiate l owner delle directory assegnandole ai corretti utenti. Per esportare con NFS la directory radice delle home directory, fare clic con il tasto destro sulla stessa e selezionare, dal menù contestuale, Properties. Nella finestra <nome_directory> Properties, scegliere il tab Figura 14 Resta a questo punto da configurare il servizio NFS in esecuzione su Windows Server 2003 R2 perché usi Active Directory come store delle informazioni utente: 1. Da Start Administrative tools lanciare la console di gestione Microsoft Service for NFS. 2. Nella finestra nfsmgmt - [Microsoft Service for NFS] fare clic con il tasto destro del mouse su Microsoft Service for NFS e scegliere Properties dal menù contestuale. 3. Nella finestra Microsoft Service for NFS Properties inserire localhost (se il server NFS coincide con il Domain Controller, come nel mio caso) nel campo User Name Mapping Server e il nome del dominio Active Directory (nel mio caso pgm.local) nel campo Active Directory Domain dopo aver selezionato la 10 PierGiorgio Malusardi Linux Windows: prove di convivenza Microsoft

11 Figura 15 check box Active Directory Lookup (Figura 15). 4. Premere OK. Configurazione dei computer con Linux Configuriamo ora Linux per usare Active Directory come servizio di autenticazione (via Kerberos) e di autorizzazione (via LDAP) per gli utenti Linux. Il primo passo da compiere è inserire i computer Linux nel REALM Kerberos che vogliamo usare per l autenticazione. Quest operazione è nota, nel mondo Microsoft, come join al dominio. a. Consideriamo come esempio il computer Linux con nome host fc001.pgm.local e l utente host_fc001 con password Passw0rd appartenente al realm kerberos PGM.LOCAL b. Il comando da inserire da linea di comando per ottenere key table e mappatura è il seguente (su un unica linea): ktpass out c:\temp\fc001.keytab pass Passw0rd princ host/fc001.pgm.local@pgm.local mapuser host_fc001 ptype KRB5_NT_SRV_HST Useremo il file fc001.keytab appena creato sulla macchina Linux per consentire il logon della stessa al realm Kerberos. 5. Trasferire il file <nome_host>.keytab (fc001.keytab) sul computer Linux. ATTENZIONE Questo file contiene la chiave privata del computer Linux e quindi deve essere trasferito su questo in modo da garantirne la sicurezza. I file contenenti le chiavi dei computer devono essere eliminati dopo l uso o conservati in luogo sicuro. Join al dominio Active Directory del computer Linux Quest operazione richiede l esecuzione di alcuni passaggi sul server Windows e alcune operazioni sul computer Linux. Sul controllore di dominio Windows: 1. In Active Directory Users and Computers, creare nella OU Linux-Computers (o nella OU dove preferite siano gestiti i computer Linux) un nuovo account utente (attenzione: usare un account utente e non un account computer) usando la procedura vista in precedenza. Nei campi Full name e User logon name inserite come nome utente un valore simile a host_<nome_breve_computer_linux> (nel mio caso host_fc001) e premete Next (Figura 16). 2. Inserire e confermare una password adeguata, selezionare l opzione Password never expires, cliccare Next e quindi Finish. 3. Verificate che il nome del computer Linux sia inserito nel DNS usato da Active Directory. 4. Lanciare una shell dei comandi e usare l utility ktpass (installata con i Support Tools) per creare un key table e una mappa tra il principal (utente in termini Kerberos) del computer Linux e l utente appena creato in Active Directory: Figura 16 Sul computer Linux: 1. Usare i seguenti comandi per verificare che siano installati i pacchetti necessari al funzionamento di Kerberos lato client: #rpm q krb5-workstation #rpm q krb5-libs Se i pacchetti non sono installati, si deve provvedere alla loro installazione dal CD/DVD della distribuzione usata o da Internet. In Fedora Core 6 sono presenti le versioni di entrambi i pacchetti. 2. Verificare che l ora sul client Linux e sul server Kerberos (il Domain Controller Windows Server 2003) siano sincronizzate. 3. Modificare il file /etc/krb5 come indicato di seguito (utilizzando il nome del dominio AD/realm Kerberos e i nomi dei server realmente usati): Microsoft Linux Windows: prove di convivenza PierGiorgio Malusardi 11

12 [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = PGM.LOCAL dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [realms] PGM.LOCAL = { kdc = dc001.pgm.local:88 default_domain = pgm.local } [domain_realm] [kdc] *.pgm.local = PGM.LOCAL.pgm.local = PGM.LOCAL profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { debug = false ticket_lifetime = renew_lifetime = forwardable = true krb4_convert = false } 4. Spostare il file <nome_host>.keytab (nel mio caso fc001.keytab) in /etc/krb5.keytab # mv fc001.keytab /etc/krb5.keytab 5. Modificare il proprietario del file <nome_host>.keytab (nel mio caso fc001.keytab): # chown root /etc/krb5.keytab 6. Modificare i permessi di accesso al file <nome_host>.keytab in modo che sia accessibile solo all utente root: # chmod 600 /etc/krb5.keytab 7. Usando uno degli account creati in Active Directory per il logon da computer Linux (nel mio caso l utente lx001), verificare la configurazione del client Kerberos con i seguenti comandi : # kinit lx001 Alla richiesta di password per l utente lx001@pgm.local inserire la password impostata. # klist Se tutto correttamente si ottiene un messaggio simile al seguente: Ticket cache: FILE:/tmp/krb5cc_0 Default principal: lx001@pgm.local Valid starting 01/09/07 16:45:20 Expires 01/10/07 02:45:23 Service principal krbtgt/pgm.local@pgm.local renew until 01/10/07 16:45:20 Verificare la correttezza dei dati contenuti nella key table con il comando # klist k Si dovrebbe ottenere come risposta un messaggio simile al seguente: Keytab name: FILE:/etc/krb5.keytab KVNO Principal host/fc001.pgm.local@pgm.local Quest operazione conclude l inserimento della macchina Linux nel dominio Acitve Directory. Ci restano ora da configurare i metodi di autenticazione e di autorizzazione sulla macchina Linux per gli utenti creati in Active Directory. Configurazione di Kerberos come servizio di autenticazione Il controllo dei metodi di autenticazione è fatto attraverso i pluggable authentication module (PAM). Su Fedora Core 6 i PAM si configurano attraverso file posti nella directory /etc/pam.d : esiste un file per ogni servizio e il nome file è identico al nome del servizio. I servizi che all avvio non trovano in /etc/pam.d un file con nome uguale a quello del servizio leggono il file system-auth (in realtà questo è un link a system-auth-ac). Molti dei file di configurazione PAM includono un riferimento a system-auth per ereditare le configurazioni contenute in questo. Le linee presenti in questi file definiscono un servizio (autenticazione, cambio password, autorizzazione, ) e il modulo che esegue il servizio stesso (es. pam_krb5 è il modulo che esegue l autenticazione su un server Kerberos). È possibile che lo stesso servizio sia svolto da più moduli (es. l autenticazione può essere svolta da pam_krb5 e da pam_unix). Per il nostro ambiente di test ci basterà configurare system-auth. Dato che non tutti gli utenti saranno presenti in Active Directory (per esempio l utente root è bene che non lo sia) dovremo inserire nel file di configurazione almeno due linee per il servizio di autenticazione: una per pam_krb5, impostato come sufficient, che precede quella per pam_unix. In questo modo è prima provata l autenticazione su Kerberos e se questa va a buon fine, non viene tentata l autenticazione locale. I passaggi per effettuare manualmente la configurazione dell autenticazione verso un server Kerberos sono i seguenti: 1. Fare un copia di salvataggio del file /etc/system-auth-ac # cd /etc/pam.d # cp system-auth-ac system-auth-ac.old 2. Modificare in modo che sia simile al seguente: 12 PierGiorgio Malusardi Linux Windows: prove di convivenza Microsoft

13 %PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time # authconfig is run. 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_krb5.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_krb5.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_krb5.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 session optional pam_krb5.so ATTENZIONE Il simbolo a fine linea indica che la linea successiva è la continuazione di quella corrente La configurazione del client LDAP è fatta modificando il file /etc/ldap.conf. Questo file contiene le impostazioni per diversi aspetti del funzionamento del client LDAP, ma solo alcune delle opzioni devono essere modificate nel nostro scenario. 2. Fare una copia di salvataggio del file ldap.conf #cp /etc/ldap.conf /etc/ldap.conf.old 3. Modificare il file in modo che sia simile al seguente: # /etc/ldap.conf # File di configurazione per la libreria LDAP # nameservice switch e per il modulo PAM LDAP # Pagine man: nss_ldap(5) e pam_ldap(5) # Server LDAP. Deve essere risolto senza # usare # LDAP. Possono essere indicate piu host, # separate da uno spazio host dc001.pgm.local # Il distinguished name da cui iniziare la # ricerca. base ou=linux-ou,dc=pgm,dc=local # Altro modo per specificare il server # LDAP uri ldap://dc001.pgm.local # Versione di LDAP da usare (default: 3) ldap_version 3 # Utente usato per la connessione al # server # Opzionale: il default è un bind anonimo binddn cn=padl,cn=users,dc=pgm,dc=local # La password dell utente usato per la # connessione al server bindpw Passw0rd Configurazione di LDAP come servizio di autorizzazione e store delle informazioni utente Il penultimo passaggio è configurare sulla macchina Linux il client LDAP in modo che usi il Domain Controller di Active Directory come server LDAP in cui trovare i dati utente e i dati di autorizzazione. I passaggi da eseguire sono i seguenti: 1. Verificare che il supporto a LDAP sia installato: #rpm q openldap-clients #openldap-clients Se openldap-clients non fosse installato, si deve provvedere alla sua installazione dal CD/DVD della distribuzione in uso o da internet. # La porta del servizio LDAP. # Opzionale: default è 389. port 389 # Range della ricerca. (Opzioni: sub, one, # base) scope sub # Limite di tempo per le ricerche timelimit 120 # Limite di tempo per bind e connect bind_timelimit 120 # Limite di Idle; il client chiude le # connessioni se il server non viene # contattato Microsoft Linux Windows: prove di convivenza PierGiorgio Malusardi 13

14 # entro il tempo indicato (solo nss_ldap) idle_timelimit 3600 # UID minimo e massimo consentiti come # utenti nel server LDAP pam_min_uid 500 # Aggiorna le password in Active Directory # creando una Unicode password e # modificando l attributo unicodepwd. pam_password ad # Mappe per RFC 2307 (AD) nss_map_objectclass posixaccount user nss_map_objectclass shadowaccount user nss_map_attribute uid samaccountname nss_map_attribute uidnumber uidnumber nss_map_attribute gidnumber gidnumber nss_map_attribute loginshell loginshell nss_map_attribute gecos name nss_map_attribute homedirectory unixhomedirectory nss_map_attribute shadowlastchange pwdlastset nss_map_objectclass posixgroup group nss_map_attribute uniquemember member nss_map_attribute cn samaccountname pam_login_attribute samaccountname pam_filter objectclass=user pam_password ad ATTENZIONE Il simbolo a fine linea indica che la linea successiva è la continuazione di quella corrente 4. Modificare il proprietario e diritti di accesso del file /etc/ldap.conf: # chown nscd /etc/ldap.conf # chmod 600 /etc/ldap.conf 5. Fare una copia di salvataggio del file /etc/nsswitch.conf #cp /etc/nsswitch.conf /etc/nsswitch.conf.old 6. Modificare il file /etc/nsswitch.conf in modo che sia simile al seguente: # /etc/nsswitch.conf # File di configurazione per # Name Service Switch passwd: shadow: group: hosts: files ldap [TRYAGAIN=continue] files ldap files ldap [TRYAGAIN=continue] files dns bootparams: nisplus [NOTFOUND=return] files ethers: netmasks: files files networks: files protocols: files ldap rpc: services: netgroup: files files ldap files ldap publickey: nisplus automount: files ldap aliases: files nisplus Questo file è usato per configurare il servizio NSS in modo che, analogamente ai moduli PAM, sia in grado di usare diverse sorgenti di dati per le diverse funzioni. 7. Riavviare il servizio Name Service Caching Daemon (nscd). Questo servizio mantiene in cache i dati recuperati da Active Directory (server LDAP) in modo da accelerare l accesso ai dati in caso di richieste duplicate. # /etc/rc.d/init.d/nscd restart oppure # service nscd restart Test della connettività verso il Domain Controller Active Directory come server LDAP Prima di effettuare l ultima configurazione sul computer Linux, la configurazione del mount delle home directory, eseguiamo un test della connettività ad Active Directory come server LDAP. 1. Da una shell eseguire il comando (su un unica riga): # ldapsearch x -h D cn=padl,cn=users,dc=pgm,dc=local -w Passw0rd b ou=linux-ou,dc=pgm,dc=local -s sub '(cn=lx003)' Sostituite nella linea di commando il distinguished name dell utente usato per la connessione ad Active Directory (parametro -D), la relativa password (parametro -w), il distinguished name del percorso da cui iniziare le ricerche (parametro -b) e l oggetto da ricercare (parametro -s) che nel mio caso è l utente lx003. Se la connessione al server LDAP funziona correttamente, si ottiene come risposta qualcosa di simile a quanto segue: # extended LDIF # # LDAPv3 # base <ou=linux-ou,dc=pgm,dc=local> with # scope subtree # filter: (cn=lx003) # requesting: ALL # # lx003, Linux-Users, Linux-OU, pgm.local dn: CN=lx003,OU=Linux-Users,OU=Linux- OU,DC=pgm,DC=local objectclass: top objectclass: person 14 PierGiorgio Malusardi Linux Windows: prove di convivenza Microsoft

15 objectclass: organizationalperson objectclass: user cn: lx003 givenname: lx003 distinguishedname: CN=lx003,OU=Linux- Users,OU=Linux-OU,DC=pgm,DC=local instancetype: 4 whencreated: Z whenchanged: Z displayname: lx003 usncreated: usnchanged: name: lx003 objectguid:: cvegvgzdwkwcefds5jg9sg== useraccountcontrol: badpwdcount: 0 codepage: 0 countrycode: 0 badpasswordtime: 0 lastlogoff: 0 lastlogon: 0 pwdlastset: primarygroupid: 513 objectsid:: AQUAAAAAAAUVAAAAfYUl6NCn553gm9nTXwQAAA== accountexpires: logoncount: 0 samaccountname: lx003 samaccounttype: userprincipalname: lx003@pgm.local objectcategory: CN=Person,CN=Schema,CN=Configuration,DC=pg m,dc=local uid: lx003 mssfu30name: lx003 mssfu30nisdomain: pgm mssfu30posixmemberof: CN=lx- grp001,ou=linux-groups,ou=linux- OU,DC=pgm,DC=local uidnumber: gidnumber: unixhomedirectory: /winhome/lx003 loginshell: /bin/bash # search result search: 2 result: 0 Success # numresponses: 2 # numentries: 1 In Fedora Core 6 è possibile utilizzare il tool systemconfig-authentication per abilitare e configurare l autenticazione verso un server Kerberos e l autorizzazione verso un server LDAP (nel nostro caso il controllore di dominio Windows Server 2003 R2) come indicato nelle figure 17 e 18. Il tool system-config-authentication si preoccupa di modificare i file /etc/nsswitch.conf, /etc/pam.d/system-auth-ac e parzialmente i file /etc/krb5.conf e /etc/pam.d. Figura 17 Figura 18 Configurazione del mount delle home directory create sul Domain Controller Active Directory Per eseguire il mount automatico dello share NFS sulla macchina Linux 1. modificare il file /etc/fstab inserendo una riga simile alla seguente: dc001.pgm.local:winhome /winhome nfs 2. creare una directory per il mount del file system nfs dedicato alle home directory degli utenti definite in Active Directory (nel mio caso la directory /winhome) A questo punto la configurazione del computer Linux è terminata ed è possibile fare logon da questa macchina con qualsiasi utente definito in Active Directory. PierGiorgio Malusardi Microsoft Linux Windows: prove di convivenza PierGiorgio Malusardi 15

16 Riferimenti Download dei Service for UNIX 3.5 Tool UNIX per Windows Windows Security and Directory Service for UNIX v w/00wsdsu.mspx 16 PierGiorgio Malusardi Linux Windows: prove di convivenza Microsoft