Scenari di Single Sign-On

monitorDopo aver dimostrato la fattibilità tecnica di un’architettura di Single Sign-On, è necessario calarla in una realtà aziendale ben definita, ovvero come faccio ad inserire una simile soluzione in azienda? Ho identificato tre diversi scenari:

  • Assenza di un dominio Windows 2000 con il server Kerberos installato su un sistema Unix.
  • Active Directory installato in azienda e uso del server Kerberos integrato in Windows 2000
  • Active Directory installato in azienda, uso di due server Kerberos (quello integrato in Windows 2000 e uno su Unix) e una relazione di fiducia (trust relationship) tra i due realm Kerberos.

Vediamo in dettaglio quali sono i vantaggi e gli svantaggi di ognuna di queste soluzioni.

Uso del KDC su sistemi Unix in assenza di Active Directory

In questo scenario, l’azienda non dispone di un server Windows 2000 (o superiori) oppure ha scelto di non adottare Microsoft Active Directory. Tipicamente è un ambiente con prevalenza di sistemi server Unix, dove ogni client è una workstation a sé stante. In particolare i client Windows 2000 non eseguono logon su nessun dominio. In questo caso sarebbe auspicabile installare il KDC e un LDAP server su un server Unix, creando in pratica quanto descritto in questo documento, facendo fare logon alle workstation Windows sul realm realizzato con il MIT Kerberos.

Uso del KDC integrato in Windows Active Directory

In questo ambiente l’azienda ha scelto di adottare Microsoft Active Directory, autenticando i client tramite questa metodologia. La prevalenza dei sistemi server si basa su Windows, con una bassa percentuale di sistemi Unix. In questo caso è possibile sfruttare il KDC integrato con Windows per “accogliere” i sistemi Unix in quanto AD, attraverso i tool forniti con il Resource Kit, è in grado di generare i Kerberos keytab file.

La prima cosa da fare è usare ktpass per generare l’account della macchina e creare il file /etc/krb5.keytab, ad esempio:

C:> Ktpass –princ host/hostname@NT-DNS-REALM-NAME –mapuser account -pass password –out UNIXmachine.keytab 
dove:
  • hostname è il nome del file DNS del server Unix
  • NT-DNS-REALM-NAME è il nome del realm (o del domino) di Active Directory
  • account è il nome utente di AD associato alla macchina
  • password è la password associata al sistema

Il file UNIXmachine.keytab contiene il keytab da inserire in /etc/krb5.keytab: si raccomanda di trasferirlo in una maniera sicura, ad esempio attraverso SSH. Editare quindi sul sistema Unix il file /etc/krb5.conf:

[libdefaults]
default_realm = AZIENDA.IT
default_tkt_enctypes = des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des-cbc-md5 des-cbc-crc

[realms]
AZIENDA.IT = {
	kdc = domaincontroller.azienda.it:88
}

Come si può notare, l’installazione è simile a quella del KDC in ambiente Unix, pertanto sulla workstation Unix si procederà con la normale personalizzazione dell’ambiente, ad esempio modificando il PAM oppure installando il modulo di autenticazione Web qualora si volessero erogare simili servizi.

Per completare l’installazione è necessario modificare Active Directory in modo tale da poter rispondere alle esigenze di LDAP, in particolare per gli attributi utente (home directory, uid/gid, ecc.), esattamente come nel nostro esempio si è usato OpenLDAP. Durante la sperimentazione ho avuto modo di provare l’ottimo plugin AD4UNIX di Maxim Batourine che permette di modificare le impostazioni Unix direttamente dalla console di Active Directory. Il file chiamato MKSADPlugins.msi può essere scaricato da http://www.padl.com/download/.

Si riporta a titolo di esempio un file ldap.conf che può essere usato in un ambiente Active Directory.

# @(#)$Id: ldap.conf,v 1.8 2002/02/26 08:50:37 root Exp $
base dc=azienda,dc=it
ldap_version 3
uri ldaps://dc.windows.azienda.it
binddn anonymous@azienda.it
timelimit 10
bind_timelimit 2

scope sub

pam_filter objectclass=user
pam_login_attribute sAMAccountName
pam_password ad

nss_base_passwd ou=users,dc=windows,dc=azienda,dc=it?one
nss_base_shadow ou=users,dc=windows,dc=azienda,dc=it?one
nss_base_group ou=group,dc=windows,dc=azienda,dc=it?one

nss_map_objectclass posixAccount User
nss_map_attribute uid sAMAccountName
nss_map_attribute uniqueMember Member
nss_map_attribute userPassword msSFUPassword
nss_map_attribute homeDirectory msSFUHomeDirectory
nss_map_objectclass posixGroup Group
nss_map_attribute cn sAMAccountName
Trust relationship tra un KDC Windows e uno Unix

Esiste un terzo scenario, in cui l’azienda ha deciso di adottare Microsoft Active Directory, ma ha una base significativa di server Unix installati. La gestione di un numero così significativo di macchine Unix potrebbe risultare difficile, soprattutto se il dipartimento IT che gestisce i sistemi Microsoft è differente dal dipartimento che segue i sistemi Unix. In questo caso è possibile effettuare una relazione di fiducia tra due realm di Kerberos, ovvero tra il mondo AD e quello Unix. Così facendo, i due mondi continueranno ad esistere in maniera indipendente, ma permetterà comunque gli amministratori Unix potranno sia accedere ai sistemi dalle workstation Windows, sia erogare servizi verso il mondo Microsoft.

Quanto descritto nei prossimi paragrafi vuole fornire un esempio dei comandi usati per effettuare il Trust Relationship tra AD e un KDC su Unix: per maggiori informazioni si faccia riferimento alla documentazione fornita da Microsoft e dal MIT Kerberos.

Setup del KDC di Windows Active Directory

Tutte le operazioni relative a Windows devono essere fatte su un Active Direcotry Server per il dominio. Di default la relazione di trust non è transitiva, cioè solo gli utenti direttamente provenienti dal dominio di fiducia si possono autenticare: sebbene in questo esempio non si voglia dimostrare un “trust chain” tra realm, si sappia che questo comportamento può essere modificato usando il tool netdom.exe.

Come analogamente fatto per il client, anche sul KDC Microsoft è necessario aggiungere il riferimento al KDC appartenente al realm Unix, ad esempio con:

C:> ksetup /addkdc UNIX.AZIENDA.IT kdc.unix.azienda.it

Questa operazione va effettuata anche su ogni workstation Windows che vuole accedere al dominio UNIX.AZIENDA.IT. Come accennato precedentemente con netdom.exe è possibile modificare il comportamento di default della “trust chain”, impostandolo a transitivo, ad esempio con:

c:\> netdom query /d:WINDOWS trust*
c:\> netdom query /d:WINDOWS UNIX.AZIENDA.IT /trans:yes*
c:\> netdom query /d:WINDOWS UNIX.AZIENDA.IT /trans*

Successivamente è necessario aggiungere le chiavi per l’autenticazione cross-realm sul KDC Windows. Avviare il Domain Tree Management (posizionato in Programs, Administrative Tools, Active Directory Domains and Trusts), con il tasto destro del mouse selezionare le Properties relative al proprio dominio e quindi la sezione Trust. Premere Add ed inserire il nome del dominio e la password; quando verrà notificato che non si tratta di un dominio Kerberos di Windows selezionare Ok.

Successivamente, è necessario legare un utente al realm remoto. Sempre da Domain Tree Management, selezionare Active Directory Users and Computers, poi View ed Advanced Features. Cliccare con il tasto destro sul nome utente, selezionare Name Mappings, il tab Kerberos Names e il pulsante Add. Aggiungere a questo punto il principal remoto, ad esempio utente@UNIX.AZIENDA.IT È necessario effettuare il reboot del KDC Microsoft per applicare le modifiche.

Setup del KDC di Unix

A questo punto è necessario creare le chiavi anche sul KDC presente sul server Unix. Bisogna sempre tenere presente che il sistema di crittografia Kerberos di Windows si basa su des-cbc-crc e non su des3-hmac-sha1 (il default del MIT). Una volta configurato correttamente il KDC, come già fatto durante la dimostrazione descritta in questo documento, per inserire le chiavi è sufficiente effettuare i seguenti comandi sul KDC attraverso il tool kadmin:

addprinc krbtgt/WINDOWS.AZIENDA.IT@UNIX.AZIENDA.IT
addprinc krbtgt/UNIX.AZIENDA.IT@WINDOWS.AZIENDA.IT

È necessario usare la stessa password per entrambe le chiavi. Oltre alla creazione dei principal, è necessario configurare ogni client per avere i puntatori al realm remoto. Come esempio vediamo un file krb5.conf, si noti in particolare la sezione capaths:

[libdefaults]
	default_realm = UNIX.AZIENDA.IT
	default_tkt_enctypes = des-cbc-md5
	default_tgs_enctypes = des-cbc-md5

[realms]
	WINDOWS.AZIENDA.IT = {
		kdc = kdc.windows.azienda.it:88
	}

	UNIX.AZIENDA.IT = {
		kdc = kdc.unix.azienda.it
		admin_server = kdc.unix.azienda.it
	}

[domain_realm]
	.unix.azienda.it = UNIX.AZIENDA.IT
	.windows.azienda.it = WINDOWS.AZIENDA.IT

[capaths]
	UNIX.AZIENDA.IT = {
		WINDOWS.AZIENDA.IT = .
	}
	WINDOWS.AZIENDA.IT = {
		UNIX.AZIENDA.IT = .
	}

Si noti nella sezione capath il punto dopo l’uguale. Per ogni utente Unix, creare un .k5login file nella home directory utente con gli altri principal che sono abilitati all’accesso, ad esempio:

# cat /home/utente/.k5login
utente@WINDOWS.AZIENDA.IT
utente@UNIX.AZIENDA.IT

Articoli Correlati:

  1. Scenario di Single-SingOn
  2. Unified User Management e Single Sign-On
  3. Configurazione di Windows con Kerberos e LDAP
taggato con , , , , , , , ,