Foro en Español

Reply
Highlighted
New Contributor

ClearPass y OpenLDAP - errores comunes.

ClearPass soporta autenticación 802.1x con PEAPv0/MsCHAPv2 usando como fuente de autenticación un servidor OpenLDAP. Aunque la integración entre ClearPass y OpenLDAP es sencilla, hay algunas causas comunes de error, a las que hay que prestar atención:

 

1.- Passwords de usuario en formato incorrecto

 

El password de usuario debe almacenarse en formato NT HASH (PlainText también está soportado, aunque no es recomendable). No se soporta SHA ni ningún otro método de Hash, para autenticación por MsCHAPv2.

 

Este pequeño script python calcula el hash NT de un password:

 

>>> from Crypto.Hash import MD4
>>> h = MD4.new()
>>> h.update("pon-aqui-tu-password".encode("utf-16le"))
>>> h.hexdigest().upper()

 

También se puede hacer online: https://www.browserling.com/tools/ntlm-hash

 

Si ya se está usando openLDAP para almacenar el password de los usuarios en otro formato (SHA, por ejemplo), lo recomendable es añadir un nuevo atributo al esquema, para almacenar el password en NTHASH. En ese caso, cuando el usuario cambie su password, deberán actualizarse los dos atributos.

 

2.- Permisos del usuario Bind DN

 

Al configurar la fuente de autenticación en ClearPass, se especifica un nombre de usuario y contraseña para hacer Bind al servidor OpenLDAP. Este usuario debe tener acceso de lectura a todas las cuentas de usuario, en particular al atributo donde se almacena el password de los usuarios en formato NTHash.

 

OpenLDAP utiliza ACLs para proteger el acceso a ciertos objetos o atributos. Es muy típico que el atributo userPassword o cualquier otro que contenga una contraseña, esté protegido por una ACL.

 

Las ACLs en vigor en un servidor OpenLDAP pueden consultarse ejecutando el comando:

 

# slapcat -b cn=config

 

Las ACLs se representan con el atributo olcAccess, por ejemplo:

 

dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=test,dc=tld
olcAccess: {0}toattrs=userPassword,shadowLastChange
 by self write
 by anonymous auth
 by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE

 

En este ejemplo, el atributo userPassword está protegido por una ACL que impide que ningún usuario pueda leer el userPassword de otro. Es imprescindible que añadamos una regla a esa ACL para permitir al usuario de ClearPass leer ese atributo.

 

Suponiendo que el Bind DN de ClearPass es "cn=clearpass,ou=system,dc=aruba,dc=local", la ACL correcta sería:

 

olcAccess: {0}to attrs=userPassword,shadowLastChange
 by self write
 by anonymous auth
 by dn="cn=clearpass,ou=system,dc=aruba,dc=local" read
 by * none

 

Reconfigurar incorrectamente el esquema de OpenLDAP implica riesgo de pérdida de datos, por lo que siempre deben hacerlo administradores experimentados. En este caso, la modificación de la ACL se haría en dos pasos:

 

  • Creando en el servidor openldap un fichero /tmp/acl.ldif con el siguiente contenido:
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=clearpass,dc=test,dc=tld" read by * none
  • Importando el cambio al esquema con el comando:
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/acl.ldif

 

De nuevo: Esto es solo un ejemplo. Reconfigurar incorrectamente el esquema de OpenLDAP implica riesgo de pérdida de datos, por lo que siempre deben hacerlo administradores experimentados, y siempre teniendo una copia de seguridad actualizada. Los cambios se realizan bajo la responsabilidad única del administrador del OpenLDAP. No soy responsable de ningún daño al sistema que pueda producirse por la aplicación de estos cambios.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: