INFN wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== LDAP e Kerberos ======

===== Introduzione =====

Questa breve guida illustra i concetti ed i passaggi necessari per configurare OpenStack utilizzando LDAP per la gestione degli utenti e Kerberos per l'autenticazione.

Al fine di evitare il polluting della directory((Keystone tende ad utilizzare LDAP come se fosse un database relazionale)), si opterà per una directory LDAP separata da altre istanze.

In particolare, in Grizzly Keystone mantiene la struttura "non-standard" con i tenant trasformati in rami LDAP contenenti i ruoli come foglie ed i membri come attributi dei ruoli (si faccia riferimento alle [[https://agenda.infn.it/getFile.py/access?contribId=28&sessionId=2&resId=0&materialId=slides&confId=6179|slide]] della presentazione di Stefano Stalio presso il Workshop CCR 2013 per un'illustrazione dell'albero) e Quantum continua ad autenticarsi diverse volte al minuto contro Keystone, causando in questo modo un numero relativamente elevato di bind alla directory.

Per questi motivi, è consigliabile utilizzare una directory dedicata e quanto più "vicina" possibile a Keystone - possibilmente in esecuzione sulla stessa macchina.

===== Requisiti =====

La guida è stata sviluppata e testata nel seguente ambiente:

  * Ubuntu 12.04.2 (x86_64)
  * OpenStack Grizzly
  * Python 2.7
  * python-ldap
  * setup di OpenStack eseguito utilizzando come riferimento il manuale di OpenStack e la [[https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_MultiNode/OpenStack_Grizzly_Install_Guide.rst|guida d'installazione rapida]] presente su GitHub.

Non dovrebbe essere complesso adattarla ad ambienti RDO, ma **non** è stata testata con packstack.

===== Setup di OpenStack =====

Si faccia riferimento alla guida, arrestandosi alla configurazione di Keystone.

===== Setup di OpenLDAP =====

Come directory server si è scelto OpenLDAP, ma è ugualmente possibile utilizzare 389ds.

Negli esempi (LDIF e file di configurazione di Keystone) si utilizzeranno i seguenti valori:

^ Parametro ^ Valore                                   ^
| Dominio   | ostack.lngs.infn.it                      |
| Base DN   | dc=ostack,dc=lngs,dc=infn,dc=it          |
| Admin DN  | cn=admin,dc=ostack,dc=lngs,dc=infn,dc=it |
| Password  | admin_pass                               |

==== Preparazione della directory ====

Creare un file chiamato ''base.ldif'' col seguente contenuto:

<file>
# Users
dn: ou=Users,dc=ostack,dc=lngs,dc=infn,dc=it
objectClass: organizationalUnit
ou: Users

# Tenants
dn: ou=Groups,dc=ostack,dc=lngs,dc=infn,dc=it
objectClass: organizationalUnit
ou: Groups

# Roles
dn: ou=Roles,dc=ostack,dc=lngs,dc=infn,dc=it
objectClass: organizationalUnit
ou: Roles

# Hardcoded in OpenStack!!!!
dn: cn=9fe2ff9ee4384b1894a90878d3e92bab,ou=Roles,dc=ostack,dc=lngs,dc=infn,dc=it
objectClass: organizationalRole
ou: _member_
cn: 9fe2ff9ee4384b1894a90878d3e92bab

# Enabled bit emulation for users
dn: cn=enabled_users,dc=ostack,dc=lngs,dc=infn,dc=it
objectClass: groupOfNames
cn: enabled_users
member: cn=dumb,dc=ostack,dc=lngs,dc=infn,dc=it

# Enabled bit emulation for tenants
dn: cn=enabled_tenants,dc=ostack,dc=lngs,dc=infn,dc=it
objectClass: groupOfNames
cn: enabled_tenants
member: cn=dumb,dc=ostack,dc=lngs,dc=infn,dc=it
</file>

Il ruolo con id ''9fe2ff9ee4384b1894a90878d3e92bab'' è hardcoded in OpenStack ed utilizzato per identificare un membro di un determinato tenant nell'API Nova. Normalmente, questo ruolo viene creato da ''keystone-manage db_sync'' durante l'installazione di Keystone.

Il membro con DN ''cn=dumb,dc=ostack,dc=lngs,dc=infn,dc=it'' è un membro "dummy" necessario per rendere gli oggetti groupOfNames conformi allo schema. Keystone ignorerà questo membro.

Sempre facendo riferimento ad OpenLDAP, applicare le modifiche alla directory con:

  ldapmodify -W -D cn=admin,dc=ostack,dc=lngs,dc=infn,dc=it -f base.ldif

==== Creazione degli indici ====

(Questa sezione è specifica per OpenLDAP)

Al fine di rendere più efficiente l'accesso alla directory((e per evitare che slapd riempia i log di warning)), è necessario creare degli indici sugli attributi più utilizzati da Keystone per effettuare ricerche.

Creare un file chiamato ''indexes.ldif'' col seguente contenuto:

<file>
dn: olcDatabase={1}hdb, cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: cn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: ou pres,sub,eq
-
add: olcDbIndex
olcDbIndex: sn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: roleOccupant pres,eq
</file>

Ed applicare le modifiche eseguendo **come root**:

  ldapmodify -Y EXTERNAL -H ldapi:/// -f indexes.ldif

Il setup di OpenLDAP è ora completo e si può procedere con la configurazione di Keystone.

===== Configurazione di Keystone =====

Sfortunatamente, la documentazione di Keystone riguardo al supporto ad LDAP è carente o addirittura in aperta contraddizione col codice. Gran parte dei valori corretti sono stati determinati per errori successivi, analisi dei backtrace di Keystone ed in alcuni casi per analisi diretta dei sorgenti.

Prima di tutto, è necessario configurare il driver di identity management per utilizzare LDAP al posto di MySQL:

<file>
[identity]
driver = keystone.identity.backends.ldap.Identity
</file>

Dopodiché è necessario configurare come segue (sempre adattando al vostro ambiente) la sezione ldap di keystone.conf:

<file>
[ldap]
url = ldap://localhost
user = cn=admin,dc=ostack,dc=lngs,dc=infn,dc=it
password = ldap_pass
suffix = dc=ostack,dc=lngs,dc=infn,dc=it
use_dumb_member = True
allow_subtree_delete = False
dumb_member = cn=dumb,dc=ostack,dc=lngs,dc=infn,dc=it

user_tree_dn = ou=Users,dc=ostack,dc=lngs,dc=infn,dc=it
user_objectclass = inetOrgPerson
user_domain_id_attribute = None
user_id_attribute = cn
user_name_attribute = sn
user_mail_attribute = mail
user_pass_attribute = userPassword
user_enabled_default = True
user_attribute_ignore = tenant_id,tenantId,tenants
user_allow_create = True
user_allow_update = True
user_allow_delete = True
user_enabled_emulation = True
user_enabled_emulation_dn = cn=enabled_users,dc=ostack,dc=lngs,dc=infn,dc=it

tenant_tree_dn = ou=Groups,dc=ostack,dc=lngs,dc=infn,dc=it
tenant_objectclass = groupOfNames
tenant_domain_id_attribute = businessCategory
tenant_id_attribute = cn
tenant_member_attribute = member
tenant_name_attribute = ou
tenant_desc_attribute = description
tenant_attribute_ignore = tenantId
tenant_enabled_emulation = True
tenant_enabled_emulation_dn = cn=enabled_tenants,dc=ostack,dc=lngs,dc=infn,dc=it

role_tree_dn = ou=Roles,dc=ostack,dc=lngs,dc=infn,dc=it
role_objectclass = organizationalRole
role_id_attribute = cn
role_name_attribute = ou
role_member_attribute = roleOccupant
role_attribute_ignore =
</file>

Alcuni parametri meritano una spiegazione a sé:
  * ''use_dumb_member'' contrariamente a quanto riportato nella documentazione è richiesto per poter creare tenant conformi allo schema per oggetti groupOfNames
  * ''user_enabled_emulation'', ''user_enabled_emulation_dn'' e i rispettivi parametri per i tenant sono necessari per emulare la presenza di un campo ''enabled'', assente sia da inetOrgPerson che da groupOfNames; entrambe le DN devono puntare ad un oggetto di tipo groupOfNames definito in precedenza durante l'inizializzazione della directory
  * i parametri ''user_allow_create'' ed ''user_allow_update'' devono essere **temporaneamente** impostati a ''True'' per permettere al setup di Keystone di procedere con successo

===== Prosecuzione del setup di OpenStack =====

A questo punto, il setup di OpenStack può proseguire con la creazione di utenti e ruoli di base, service endpoint e l'installazione/configurazione degli altri servizi.

Una volta terminata, è caldamente consigliato impostare ''user_allow_create'' ed ''user_allow_update'' a ''False'' e riavviare Keystone.

===== Kerberos =====

L'integrazione con Kerberos avviene per mezzo di saslauthd e del meccanismo password ''{SASL}'' di OpenLDAP.

Prima di procedere, è necessario creare un principal ''host/FQDN'' per il controller node e trasferirlo in ''/etc/krb5.keytab'' sul controller node.

==== Installazione di saslauthd ====

Installare saslauthd ed il relativo plugin per GSSAPI. Su Ubuntu:

  apt-get -y install sasl2-bin libsasl2-modules-gssapi-mit

A questo punto, saslauthd deve essere configurato per utilizzare GSSAPI come backend di autenticazione. Su Ubuntu è sufficiente modificare ''/etc/default/saslauthd'' in modo da avere i seguenti valori:

<file>
START=yes
MECHANISM="kerberos5"
</file>

E successivamente avviarlo con

  service saslauthd start

A questo punto, è possibile testare il funzionamento con

  testsaslauthd -s slapd -u user@LNGS.INFN.IT -p 'password'
  
Se il vostro realm non prevede l'uso di AES, è **necessario** abilitare ''allow_weak_crypto'' in ''/etc/krb5.conf''.

==== Configurazione di OpenLDAP ====

È ora necessario definire il meccanismo di autenticazione SASL per slapd, creando ''/usr/lib/sasl2/slapd.conf'' col seguente contenuto:

<file>
mech_list: plain
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
</file>

Quindi aggiungere l'utente con cui è in esecuzione OpenLDAP al gruppo sasl:

  gpasswd -a openldap sasl

Ed infine riavviare slapd:

  service slapd restart

Da questo momento in poi, tutte le password con meccanismo ''{SASL}'' verranno verificate su Kerberos utilizzando saslauthd come proxy.

===== Gestione degli utenti =====

Per permettere l'autenticazione degli utenti su Kerberos è necessario che ogni utente abbia come attributo userPassword ''{SASL}principal@REALM''. Ciò, purtroppo, non è effettuabile tramite Horizon in quanto Keystone utilizza per default il metodo ''{SSHA}'' per salvare le password su LDAP.

Per aggiungere ed abilitare/disabilitare gli utenti, è possibile utilizzare un qualsiasi client LDAP in grado di creare oggetti inetOrgPerson. Presso i LNGS
sono in uso una serie di script denominati [[https://github.com/rfc1459/osgsa/|OSGSA]] che effettuano le operazioni di registrazione e abilitazione/disabilitazione degli utenti.

Gli script in questione possono essere utilizzati in ambienti OpenStack/LDAP creati secondo le indicazioni di questa guida. Idealmente, dovrebbero essere installati sul controller node e richiedono ''python-ldap'' e ''python-yaml''.