Configurazione di Windows con Kerberos e LDAP

Contrariamente a Linux, dove il modulo per Kerberos è da installare, su Windows 2000 e superiori invece è già parte del sistema operativo, in quanto è alla base dell’autenticazione Microsoft. Per fare il setup del Kerberos di Windows come workstation invece è necessario avere il Resource Kit, in quanto contiene delle utility a riga di comando che ci serviranno per il setup, in particolare i programmi ksetup.exe, klist.exe e opzionalmente ktpass.exe. Per quanto riguarda , abbiamo precedentemente accennato che Windows non è in grado di rivolgersi direttamente ad un LDAP server per scaricare il profilo utente, in quanto il servizio di autenticazione Microsoft, seppur usando un backend LDAP (Active Directory), viene effettuato attraverso NetBIOS over TCP/IP. Non potendo cercare le caratteristiche dell’utente su LDAP, Windows ne cerca le caratteristiche sul database utente locale, in quanto è necessario mappare in qualche modo il nome utente ad un determinato Security ID (detto SID); questa mappatura viene effettuata al setup dell’ambiente Kerberos. Esistono due diversi approcci: il primo è quello di mappare ad ogni utente kerberos un analogo utente locale; il secondo è quello di creare un utente “contenitore” e di associare tutti gli utenti kerberos ad un singolo account locale. Il primo approccio è utile soprattutto per le macchine personali, ad esempio un portatile o una scrivania su cui sicuramente siederà una determinata persona. Il secondo è più adatto per gli utenti roaming, ovvero per quelli che hanno le scrivanie o i computer in condivisione, ad esempio per le persone che non sono spesso in ufficio. L’approccio proposto sarà di sfruttare il primo scenario, ovvero di associare un utente Kerberos ad un utente locale, ad esempio il nostro Mario Rossi che usa principalmente la workstation windows (nel nostro laboratorio picard.azienda.it). A questo punto è necessario creare con Local Users and Groups gli utenti locali, nel nostro caso mrossi; si assume che si sappia creare gli utenti attraverso i tool di sistema. Prima di provare il logon, sul server zeus, creiamo il principal corrispondente alla workstation Windows:

# kadmin.local -q “addprinc -pw miapassword5 host/picard.azienda.it@AZIENDA.IT”

Attenzione

non bisogna riutilizzare un principal esistente, ad esempio uno già creato per ambiente Unix, ma è necessario crearne uno nuovo con un hostname differente. Vedremo in seguito nel paragrafo “Gestire il dual boot Linux/Windows” quale sia il problema e come risolverlo. Da riga di comando, e con i tool del Resource Kit nella directory corrente, procedere come segue:

C:\> net time /sntp:time.azienda.it
C:\> ksetup /SetDomain AZIENDA.IT
C:\> ksetup /SetMachPassword miapassword5
C:\> ksetup /AddKdc AZIENDA.IT kdc.azienda.it
C:\> ksetup /AddKpasswd AZIENDA.IT kdc.azienda.it
C:\> ksetup /mapuser * *

Significato Comandi

Vediamo adesso il significato dei comandi. Il primo comando permette di aggiungere un server NTP per la sincronizzazione dell’orologio di sistema, per evitare il fenomeno di disallineamento denominato clockskew (vedi Kerberos). Il secondo definisce il realm di default, mentre il terzo imposta la password della workstation Windows associata al principal creato in precedenza: si ricorda che il nome host del principal si ottiene mediante il nome NetBIOS della workstation aggiunto al dominio di default del realm specificato. Il quarto e il quinto comando definiscono esplicitamente il KDC e il server di riferimento per il cambio delle password relativo al realm AZIENDA.IT. Infine, il sesto si riferisce alla mappatura degli utenti come avevamo determinato precedentemente.

A questo punto è necessario un reboot per applicare le impostazioni del sistema Kerberos. Una volta riavviato, nella schermata di Log-On grafico (GINA), tramite la drop-down combo, sarà possibile scegliere AZIENDA.IT (Kerberos Realm) tra le opzioni ed immettere quindi la username e password Kerberos.

Già attraverso il logon abbiamo verificato lo scambio di informazioni tra la workstation Windows e il KDC. Come ulteriore prova, attraverso il tool klist.exe potremmo elencare i nostri ticket:

C:\>klist tickets

Cached Tickets: (2)

   Server: krbtgt/AZIENDA.IT@AZIENDA.IT
      KerbTicket Encryption Type: Kerberos DES-CBC-CRC
      End Time: 3/19/2004 5:30:57
      Renew Time: 3/25/2004 19:30:57


   Server: host/voyager.azienda.it@AZIENDA.IT
      KerbTicket Encryption Type: Kerberos DES-CBC-CRC
      End Time: 3/19/2004 5:30:57
      Renew Time: 3/25/2004 19:30:57

Oppure visualizzare il TGT rilasciato dal nostro KDC:

C:\>klist tgt

Cached TGT:

ServiceName: krbtgt
TargetName: krbtgt
FullServiceName: mrossi
DomainName: AZIENDA.IT
TargetDomainName: AZIENDA.IT
AltTargetDomainName: AZIENDA.IT
TicketFlags: 0x40e00000
KeyExpirationTime: 1/1/1601 1:00:00
StartTime: 3/18/2004 19:30:57
EndTime: 3/19/2004 5:30:57
RenewUntil: 3/25/2004 19:30:57
TimeSkew: 1/1/1601 1:00:00