1. Visión general de seguridad de GBDS 4

GBDS tiene un módulo de seguridad que utiliza tokens JWT para hacer cumplir la autenticación y autorización de usuarios. GBDS se puede integrar con cualquier almacenamiento de usuarios compatible con LDAP para la autenticación, y con Ranger para proporcionar autorización y auditoría de acceso.

1.1. Componentes

Hay cuatro componentes principales que trabajan juntos para proporcionar seguridad para la operación de GBDS: Módulo de seguridad de API, Almacenamiento de credenciales LDAP, Ranger y Solr.

Módulo de seguridad de API

Todas las solicitudes de API pasan primero por el módulo de seguridad, que hace cumplir la autenticación y autorización para los recursos protegidos.

Almacenamiento de credenciales LDAP

Una instancia de LDAP (por ejemplo, Active Directory, OpenLDAP) mantiene información sobre usuarios y grupos de usuarios, y proporciona autenticación para acceder a la API de GBDS y autorizar solicitudes de API.

Ranger

Apache Ranger es un marco de seguridad que proporciona control de acceso detallado a la API de GBDS. Se pueden crear políticas de seguridad para denegar o permitir el acceso a los puntos finales de la API según criterios como el nombre de usuario, los grupos de usuarios, el recurso solicitado, el método HTTP utilizado y la dirección IP.

Solr

GBDS utiliza Solr para almacenar registros de acceso para cada solicitud de API, lo que permite la auditoría. A través del panel de control de Ranger, estos registros se pueden ver, buscar y exportar.

1.2. Flujos de trabajo habilitados para la seguridad

1.2.1. Autenticación

Hay dos métodos para autenticarse con la API. Cuando el cliente no tiene un token válido, debe usar la autenticación por credenciales. En este caso, el cliente hace una solicitud al punto final de creación de token, pasando una carga útil JSON con credenciales válidas para un usuario en el almacenamiento de credenciales LDAP. Luego, el módulo de seguridad se vincula al almacenamiento de credenciales LDAP, utilizando las credenciales del usuario de enlace (ver más abajo), y realiza la autenticación. Luego, crea un sujeto autenticado: un usuario asociado con todos los grupos a los que pertenece. Finalmente, el módulo de seguridad construye un token JWT, lo firma digitalmente y lo envía de vuelta al cliente. Este token se puede utilizar para realizar solicitudes a la API de GBDS.

Flujo de autenticación

Cuando el cliente ya tiene un token válido pero está cerca de expirar, puede usar ese token para crear uno nuevo con un tiempo de expiración posterior. Primero, el cliente hace una solicitud al punto final de creación de token con el token válido. Luego, el módulo de seguridad validará el token y creará uno nuevo, utilizando el mismo sujeto autenticado, pero con un nuevo tiempo de expiración. A continuación, se enviará el nuevo token al usuario. Dado que este flujo de trabajo no requiere consultar el almacenamiento de credenciales LDAP, es mucho más rápido. Las aplicaciones cliente deben diseñarse para utilizar la renovación de tokens siempre que sea posible.

Flujo de autenticación

1.2.2. Realización de una solicitud de API

Una vez adquirido un token JWT válido, se enviará a la API de GBDS con cada solicitud, siguiendo el estándar JWT. Las solicitudes tendrán una cabecera de autorización con el esquema Bearer, es decir, Authorization: Bearer <token>. Para los recursos protegidos, el módulo de seguridad extraerá el token de la cabecera y validará su firma utilizando la Clave de firma original. Si el token es válido, la solicitud está autenticada. A continuación, el módulo de seguridad construirá un Contexto de autorización con el nombre del sujeto, los grupos del sujeto, el recurso solicitado, la dirección IP y el método HTTP. Este Contexto de autorización se enviará a Ranger para autorizar o denegar la solicitud y también se registrará en Solr, junto con su resultado: Permitido o Denegado. Finalmente, si la solicitud fue autorizada, se enviará a la API de GBDS para su procesamiento.

Realización de una solicitud de API

1.3. Configuración

1.3.1. Archivos

El módulo de seguridad utiliza cuatro archivos de configuración diferentes:

  • /etc/griaule/conf/gbscluster.properties: Archivo de configuración principal de GBDS. Cuando se habilita la seguridad, las opciones de seguridad se configuran a través de este archivo.
  • /etc/griaule/conf/gbsapi/keystore.jks: Almacén de claves protegido por contraseña que contiene la Contraseña del usuario de enlace de LDAP y la Clave de firma JWT. Solo accesible por el usuario griaule.
  • /etc/griaule/conf/gbsapi/truststore: Almacén de confianza protegido por contraseña que contiene el Certificado del servidor LDAP para permitir conexiones ldaps. Solo accesible por el usuario griaule.
  • /etc/griaule/conf/gbsapi/.password: Archivo de contraseña que contiene las contraseñas tanto del almacén de claves como del almacén de confianza. Las contraseñas se almacenan en texto claro, por lo que este archivo solo debe ser accesible por el usuario griaule.

1.3.2. Opciones de seguridad

GBDS puede ejecutarse con o sin seguridad habilitada y esto se controla mediante la clave de configuración booleana: gbscluster.api.security.enabled. Cuando esta clave se establece en falso, se deshabilita toda la seguridad y se ignoran todas las demás claves de seguridad. Si se establece en verdadero, las siguientes claves de configuración DEBEN configurarse también:

General

  • gbscluster.api.security.keystore: ruta al almacén de claves generado por el script de generación de almacenes de claves.
  • gbscluster.api.security.truststore: ruta al almacén de confianza que contiene el certificado del servidor LDAP. Requerido cuando se utiliza ldaps.
  • gbscluster.api.security.passwords: ruta al archivo que contiene las contraseñas del almacén de claves y del almacén de confianza. Este archivo debe tener acceso restringido al usuario griaule.

Autenticación

  • gbscluster.api.security.ldap.url: URL de conexión al servidor de almacenamiento de usuarios LDAP.
  • gbscluster.api.security.ldap.userSearchBase: Nombre distinguido (DN) del repositorio de usuarios en el servidor LDAP. Ejemplo: ou=Usuarios,dc=pd,dc=griaule
  • gbscluster.api.security.ldap.userSearchAttribute: Atributo de usuario que se utilizará como nombre de usuario durante la autenticación. Ejemplo: sAMAccountName, uid
  • gbscluster.api.security.ldap.userGroupMembershipAttribute: Atributo de usuario que contiene información de pertenencia a grupos. Ejemplo: memberOf
  • gbscluster.api.security.ldap.bindUserDN: Nombre distinguido del usuario de enlace. El usuario de enlace es una cuenta de usuario utilizada por GBDS para enlazar con el servidor LDAP, autenticar usuarios y obtener sus grupos.

Token

  • gbscluster.api.security.token.ttlInMilliseconds: Tiempo de vida, en milisegundos, del token jwt. Valores válidos: entre 30 minutos y 3 horas.

Autorización

  • gbscluster.api.security.authorization.ranger.configurationDirectory: Directorio con la configuración específica de ranger para GBDS.

2. Integración con Active Directory

2.1. Verificar la resolución DNS

Antes de comenzar, asegúrese de que la resolución de nombres para el dominio al que se integrarán las máquinas del clúster esté funcionando correctamente. Para un dominio llamado pd.griaule, use el siguiente comando:

dig -t SRV _ldap._tcp.pd.griaule

Note

Asegúrese de que la sección ANSWER esté presente y que contenga el nombre de host y la dirección IP del controlador de dominio.

Warning

Corrija cualquier problema de resolución DNS antes de continuar.

2.2. Instalar paquetes requeridos

sudo yum install realmd sssd oddjob oddjob-mkhomedir adcli sssd-ad sssd-tools

2.3. Integrarse con AD

Usando la utilidad realm, es la forma más conveniente de integrar SSSD con AD. Ejecute el siguiente comando para mostrar información básica sobre el dominio:

realm discover <nombre_de_dominio>

2.3.1. Unirse al dominio

Para unirse, necesitará una cuenta que pertenezca al grupo de administradores de dominio:

sudo realm join -U <nombre_de_usuario> <nombre_de_dominio>

A continuación, habilite NSS y PAM con:

authconfig --enablesssd --update

Y finalmente, verifique si la máquina se unió al dominio correctamente consultando un usuario en el dominio:

id <nombre_de_usuario>@<nombre_de_dominio>

2.3.2. Solución de problemas

Si surgen problemas, utilice los siguientes consejos:

  • Verifique dos veces la resolución del nombre DNS. Esta es la causa de la mayoría de los problemas.
  • Asegúrese de que el directorio “/etc/sssd/” y “/etc/sssd/conf.d” existan y ambos tengan permiso 0600.
  • Aumente el nivel de depuración en “/etc/sssd/sssd.conf” en todas las secciones, es decir, “[sssd]”, “[nss]”, “[pam]”, “[domain]”. Luego, reinicie el servicio sssd: “sudo service sssd restart”. Los registros estarán en la carpeta “/var/log/sssd/”
  • En caso de error “Permiso insuficiente para unirse al dominio …”: el usuario utilizado para unirse al dominio no tiene permiso. Verifique si pertenece al grupo “Administradores de dominio”.

3. Integración con OpenLdap

Esta guía explica cómo realizar una instalación mínima de OpenLdap que será compatible con GBDS tanto para la autenticación como para la autorización.

3.1. Instalar OpenLdap

3.1.1. Dependencias

Conéctese al host ldap e instale los paquetes necesarios:

sudo yum -y install openldap compat-openldap openldap-clients openldap-servers openldap-servers-sql openldap-devel

3.1.2. Iniciar el demonio Ldap

A continuación, inicie el demonio ldap y configúrelo para que se inicie automáticamente en el arranque del sistema

systemctl start slapd.service

systemctl enable slapd.service

systemctl status slapd.service

3.1.3. Generar contraseña de root

Ejecute el comando “ldappasswd” para crear una contraseña de root de Ldap. Anote tanto la contraseña como la versión hash, devuelta por “ldappasswd”.

sudo slappasswd

3.1.4. Crear base de datos hdb

hdb es una variante jerárquica de la base de datos bdb. En la plantilla de configuración a continuación, establezca las siguientes variables según su caso de uso:

  • olcSuffix: representa el nombre de dominio para el cual Ldap servirá información de cuenta. Además, este nombre distinguido se agregará a las consultas que se envían al backend
  • olcRootDN: es el nombre distinguido del usuario que tendrá acceso administrativo al servidor Ldap
  • olcRootPW: establezca la contraseña para el usuario administrador. Esta contraseña será la salida hash del comando “slappasswd”, que se ejecutó anteriormente

Coloque la siguiente configuración dentro de un archivo llamado “db.ldif”.

Warning

ASEGÚRESE DE REEMPLAZAR olcRootPW, olcRootDN y olcSuffix.

dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=oldap,dc=pd,dc=griaule

dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=ldapadm,dc=oldap,dc=pd,dc=griaule

dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}theHashedPasswordValueFromSlapPasswd

Warning

Asegúrese de que no haya espacios al final de las líneas vacías, de lo contrario causará problemas. Ver: https://serverfault.com/questions/578710/wrong-attributetype-when-using-ldapadd

3.1.4.1. Empuje los cambios al servidor

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f db.ldif

Warning

Si no usa sudo, tendrá problemas de permisos: “ldap_modify: acceso insuficiente (50)”

3.1.5. Restringir el acceso de monitor al ldapadm

Coloque la siguiente configuración en un archivo llamado “monitor.ldif” y actualice “dn.base”, que dice ACTUALIZARME, con el DN del valor establecido en “oclRootDN” anteriormente.

dn: olcDatabase={1}monitor,cn=config changetype: modificar reemplazar: olcAccess olcAccess: {0}to * por dn.base=”gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth” leer por dn.base=”ACTUALIZARME” leer por * ninguno

3.1.5.1. Aplicar los cambios en el servidor

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f monitor.ldif

Warning

Si no utiliza sudo, se encontrará con problemas de permisos: ldap_modify: acceso insuficiente (50)

3.1.6. Agregar archivo de configuración de hdb-backend

Este archivo establecerá opciones de configuración básicas para el backend hdb.

sudo cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG sudo chown ldap:ldap /var/lib/ldap/DB_CONFIG

3.1.7. Agregar esquemas esenciales de LDAP

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif

3.1.8. Habilitar el módulo memberOf

Warning

ESTO DEBE HACERSE ANTES DE CREAR CUALQUIER GRUPO. EL ATRIBUTO MEMBEROF ES UN ATRIBUTO OPERACIONAL Y NO SE CREA RETROACTIVAMENTE

Este módulo es necesario para consultar los grupos de un usuario. Coloque la siguiente configuración en un archivo llamado memberof_config.ldif

dn: cn=module,cn=config cn: module objectclass: olcModuleList objectclass: top olcmoduleload: memberof.la olcmodulepath: /usr/lib64/openldap

dn: olcOverlay={0}memberof,olcDatabase={2}hdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf

Para aplicar los cambios en el servidor, ejecute el comando:

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_config.ldif

3.1.9. Generar la base de datos para su dominio

Finalmente, especificamos una base de datos, que utiliza la configuración creada previamente, para atender todas las solicitudes a nuestro dominio (valor de olcSuffix). Actualice el DN para Usuarios y Grupos para que coincida con su dominio configurado. Coloque la configuración en db_structure.ldif

# Crear entrada para el dominio dn: dc=oldap,dc=pd,dc=griaule objectClass: domain objectClass: top dc: oldap

# Crear una OU para Usuarios dn: ou=Users,dc=oldap,dc=pd,dc=griaule objectClass: organizationalUnit ou: Users

# Crear una OU para Grupos dn: ou=Groups,dc=oldap,dc=pd,dc=griaule objectClass: organizationalUnit ou: Groups

Para aplicar los cambios en el servidor, use la cuenta de administrador configurada (olcRootDN) después del parámetro -D. La utilidad ldapadd le pedirá la contraseña de la cuenta de administrador establecida anteriormente.

sudo ldapadd -x -D 'cn=ldapadm,dc=oldap,dc=pd,dc=griaule' -W -H ldapi:/// -f db_structure.ldif

3.2. Solución de problemas

Tenga en cuenta que los mensajes de error devueltos por OpenLdap pueden ser bastante confusos. Entonces, si tiene algún problema para hacer que la instalación funcione, es una buena idea habilitar el modo de depuración. Detenga el servicio slapd y luego reinicie el proceso directamente, con la bandera de depuración -d -1:

slapd -d -1 -u ldap -h "ldap:/// ldapi:///"

Si TLS está habilitado, también incluya la cadena para el punto final ldaps:

slapd -d -1 -u ldap -h "ldap:/// ldapi:/// ldaps:///"

3.3. Cifrar contraseñas OpenLdap

De forma predeterminada, OpenLdap almacena contraseñas en texto claro. Para cambiar este comportamiento, necesitamos: (i) establecer un algoritmo global de hash de contraseñas y (ii) habilitar la política de contraseñas para cifrar automáticamente cualquier contraseña de texto claro entrante.

3.3.1. Configurar el algoritmo de hash

Utilizaremos el algoritmo SHA-512 con 50k rondas y 16 bytes de sal. Cree un archivo llamado hash_algorithm.ldif

dn: cn=config replace: olcPasswordHash olcPasswordHash: {CRYPT}

dn: cn=config replace: olcPasswordCryptSaltFormat olcPasswordCryptSaltFormat: $6$rounds=50000$%.16s

Para enviar los cambios al servidor:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f hash_algorithm.ldif

3.3.2. Importar el esquema de política de contraseñas

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif

3.3.3. Cargar el módulo de política de contraseñas

Cree un archivo llamado password_policy_config.ldif con el siguiente contenido:

# cargar el módulo de política de contraseñas dn: cn=module,cn=config cn: module objectClass: top objectClass: olcModuleList olcModuleLoad: ppolicy.la olcModulePath: /usr/lib64/openldap

# aplicar la superposición de política de contraseñas a nuestra base de datos dn: olcOverlay={1}ppolicy,olcDatabase={2}hdb,cn=config objectClass: olcPPolicyConfig objectClass: olcOverlayConfig olcOverlay: ppolicy olcPPolicyDefault: cn=Password Policy,ou=Policies,dc=oldap,dc=pd,dc=griaule olcPPolicyForwardUpdates: FALSE olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: FALSE

Luego, envíe estos cambios con:

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f password_policy_config.ldif

Si encuentra un error que se queja de que pwdAttribute no existe, significa que el esquema de política de contraseñas no se importó.

3.3.4. Crear política de contraseñas predeterminada

Cree un archivo llamado password_policy.ldif

# crear política de contraseñas predeterminada dn: cn=Password Policy,ou=Policies,dc=oldap,dc=pd,dc=griaule objectClass: top objectClass: device objectClass: pwdPolicy cn: Password Policy pwdAttribute: userPassword

Luego, envíe los cambios con el siguiente comando:

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f password_policy_config.ldif

3.4. Mejorar la seguridad

3.4.1. Desactivar la vinculación anónima

Cree un archivo con el nombre disable_anon_binding.ldif:

dn: olcDatabase={-1}frontend,cn=config add: olcRequires olcRequires: authc

dn: olcDatabase={2}hdb,cn=config add: olcRequires olcRequires: authc

Luego, envíe los cambios:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f disable_anon_binding.ldif

Para probar si los cambios funcionaron, ejecute la siguiente búsqueda anónima:

# sin TLS ldapsearch -x -LLL -H ldapi:/// "(cn=*)"

3.4.2. Desactivar el acceso de lectura a las contraseñas de usuario

Finalmente, cualquier usuario puede recuperar la contraseña de otro usuario. Aunque las contraseñas están cifradas, esto debe evitarse. Aún más si decidió almacenar las contraseñas en texto plano. Entonces, cree un archivo llamado disabled_password_read.ldif.

Warning

ASEGÚRESE DE QUE NO HAYA SALTO DE LÍNEA PARA olcAccess

dn: olcDatabase={2}hdb,cn=config add: olcAccess olcAccess: to attrs=userPassword by dn="<olcRootDN>" write by self write by * auth
-
add: olcAccess olcAccess: to * by dn="<olcRootDN>" write by users read by self write by * auth

Realice los cambios

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f disabled_password_read.ldif

Si ejecuta una búsqueda vinculada con cualquier usuario que no sea olcRootDN, la única contraseña que se devolverá es la del propio usuario.

ldapsearch -x -D '<non_root>' -LLL -H ldapi:/// "(cn=*)"

3.5. Habilitar LDAPS

Antes de continuar, asegúrese de que su instancia de OpenLdap esté funcionando y que tenga dos unidades organizativas: una para usuarios y otra para grupos. Puede hacer esto usando Apache Directory Studio para conectarse a su servidor usando su URL de conexión ldap, por ejemplo, ldap://192.168.0.100:389, y con su cuenta de administrador configurada (olcRootDN).

Para habilitar LDAPS, necesitará un certificado válido firmado por una autoridad de confianza. Alternativamente, proporcionamos una guía sobre cómo configurar su propia autoridad de certificación y cómo usarla para firmar certificados para su servidor.

3.5.1. Cree sus propios certificados

3.5.1.1. Cree su CA

Si ya tiene un certificado válido, puede omitir este paso.

En CentOS, encontrará el archivo openssl.cnf, que contiene la configuración principal para nuestra CA, en el directorio /etc/pki/tls. Sin embargo, nuestra CA vivirá bajo /etc/pki/CA.

Primero, cree los archivos index.txt y serial, que almacenarán información sobre los certificados firmados y el número de serie del certificado que se utilizará, respectivamente.

touch /etc/pki/CA/index.txt echo '01' > /etc/pki/CA/serial

A continuación, agregue las siguientes políticas a /etc/pki/tls/openssl.cnf:

# Para la política de CA
[ policy_match ]
countryName             = match stateOrProvinceName     = match organizationName        = match organizationalUnitName  = optional commonName              = supplied emailAddress            = optional

[ signing_policy ]
countryName             = match stateOrProvinceName     = match organizationName        = match organizationalUnitName  = optional commonName              = supplied emailAddress            = optional

[ signing_req ]
subjectKeyIdentifier    = hash authorityKeyIdentifier  = keyid,issuer

Ahora, cambie al directorio de CA

cd /etc/pki/CA

Generaremos el certificado de CA, válido por 10 años, con el siguiente comando. Se le pedirá la contraseña de la clave privada y la información sobre el sujeto del certificado (la CA en este caso). Tome nota de su contraseña, ya que la necesitará para firmar certificados.

openssl req -config /etc/pki/tls/openssl.cnf -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 3650

Luego, limite los derechos de acceso de la clave privada de la CA

chmod 0400 private/cakey.pem

3.5.1.2. Crear el certificado del servidor Ldap

Primero, creamos una solicitud de firma de certificado para el servidor Ldap

openssl req -config /etc/pki/tls/openssl.cnf -newkey rsa:2048 -nodes -sha256 -out ldap_cert.csr -outform PEM -keyout ldap_key.pem

A continuación, firmamos el server.csr utilizando la clave privada de la CA

openssl ca -config /etc/pki/tls/openssl.cnf -policy signing_policy -extensions signing_req -out ldap_cert.pem -infiles ldap_cert.csr

Eso es todo, ahora ldap_cert.pem es el certificado para su servidor y su clave privada está en el archivo ldap_key.pem.

Note

la clave privada del servidor no está cifrada (parámetro -nodes). Esto es menos seguro, pero OpenLdap NO admite claves cifradas. Por lo tanto, es fundamental restringir todo el acceso a este archivo, como haremos en los siguientes pasos.

3.5.2. Configurar OpenLdap para usar certificado y clave

Primero, copie el certificado de la CA en /etc/openldap/cacerts. Esto hará que OpenLdap confíe en los certificados firmados por su CA.

mkdir /etc/openldap/cacerts cp /etc/pki/CA/cacert.pem  /etc/openldap/cacerts chown -R ldap:ldap /etc/openldap/cacerts/

Luego, instale el certificado del servidor Ldap en /etc/openldap/certs

mv /etc/pki/CA/ldap_cert.pem /etc/openldap/certs chown ldap:ldap /etc/openldap/certs/ldap_cert.pem

mv /etc/pki/CA/ldap_key.pem /etc/openldap/certs chown ldap:ldap /etc/openldap/certs/ldap_key.pem chmod 400 /etc/openldap/certs/ldap_key.pem

Establecer el permiso 400 para la clave privada del servidor ES FUNDAMENTAL.

Cree un archivo llamado enable_ldaps.ldif con las siguientes configuraciones

dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/openldap/cacerts/cacert.pem
-
replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/ldap_cert.pem
-
replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/ldap_key.pem

Luego, aplique los cambios al servidor y pruebe los archivos de configuración

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f enable_ldaps.ldif

3.5.3. Habilitar el punto final TLS

En el archivo /etc/sysconfig/slapd, agregue ldaps:/// a la línea que comienza con SLAPD_URLS=. Después de eso, la línea debería verse así:

SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"

3.5.4. Forzar TLS

Cree un archivo force_tls.ldif con el siguiente contenido:

dn: olcDatabase={2}hdb,cn=config changetype:  modify add: olcSecurity olcSecurity: tls=1

Y luego aplique los cambios al servidor

sudo ldapmodify -v -Y EXTERNAL -H ldapi:/// -f force_tls.ldif

Ahora pruebe el requisito de TLS ejecutando la siguiente búsqueda. Debería ser denegada debido al requisito de TLS

ldapsearch -H ldap://<host> -D "cn=ldapadm,dc=oldap,dc=pd,dc=griaule" -W '(uid=ldapadm)'

Warning

A PARTIR DE AHORA, CUALQUIER LLAMADA A ldapi:/// QUE REQUIERA EL olcRootDN (es decir, aquellas que crean entidades en el árbol de directorios) DEBE SER REALIZADA EN ldaps:/// EN SU LUGAR. LAS LLAMADAS QUE PUEDEN USAR -Y EXTERNAL (es decir, las que modifican cn=config) TODAVÍA PUEDEN USAR ldapi:///.

3.5.5. Configuración de TLS del lado del cliente

Para permitir que utilidades como ldapsearch se conecten a través de TLS, agregue TLS_REQCERT allow a /etc/openldap/ldap.conf

echo "TLS_REQCERT allow" >> /etc/openldap/ldap.conf

3.6. Crear usuario de enlace para Ranger y GBDS

Tanto GBDS como Ranger requerirán un usuario para enlazar con el servidor LDAP y realizar consultas y autenticación. El único privilegio que necesita este usuario es leer el árbol de directorios.

Warning

No use olcRootDN como usuario de enlace.

Cree un archivo bind_user.ldif con el siguiente contenido. Reemplace el dn: por uno que coincida con su instalación. Además, establezca la contraseña del usuario de enlace. Si habilitó la encriptación de contraseñas, escriba la contraseña en texto plano. De lo contrario, use slappasswd para producir un hash de la contraseña y escriba el hash en el archivo .ldif (similar a cómo creamos la contraseña para olcRootDN)

dn: cn=gbds_bind,ou=Users,dc=oldap,dc=pd,dc=griaule objectClass: top objectClass: person objectClass: inetOrgPerson cn: gbds_bind uid: gbds.bind sn: Bind User userPassword: <password>

Aplique los cambios con:

# para ldapadd con tls habilitado -D "<olcRootDN>" -W -H ldaps:/// -f bind_user.ldif
# sin tls ldapadd -D "<olcRootDN>" -W -H ldapi:/// -f bind_user.ldif

Para probar si el usuario se creó correctamente, ejecute la siguiente búsqueda autenticándose con las credenciales del usuario de enlace credentials:his

ldapsearch -D "<bind_user_dn>" -W -H ldaps:/// "(cn=gbds_bind)"

3.7. API de LDAP

La API de LDAP es una API proporcionada por Griaule para ayudar en la gestión de usuarios y grupos. Puede autenticar, crear, eliminar o modificar datos de usuario y listar datos de usuario y datos de grupo a través de la API.

Note

Si los archivos de API no fueron proporcionados, comuníquese con el equipo de soporte de Griaule.

La API completa se puede acceder en API de LDAP.

Caution

La API funciona con seguridad SSL y se requiere un truststore y un keystore. Para obtener más información sobre cómo crearlos, consulte la sección Configuración de seguridad de GBDS.

3.7.1. Configurando la API

Para instalar y configurar correctamente la API, siga los siguientes pasos:

  1. Extraiga el paquete descargado.
  2. En /etc/griaule cree el directorio ldap.
  3. Mueva el directorio conf del paquete extraído al directorio /etc/griaule/ldap.
  4. Mueva el archivo config.properties al directorio /etc/griaule/ldap.
  5. Abra el archivo config.properties y ajuste los parámetros de configuración según su entorno.
  6. En /var/lib/griaule crear el directorio ldap.
  7. Mover el archivo bs-ldap-api.jar y los scripts kill-api.sh y start-api.sh al nuevo directorio.
  8. Ejecutar el script de inicio.

3.7.2. Creación de nuevos usuarios y grupos

Para crear un nuevo usuario, llame a Crear usuario. Esto creará el usuario, la contraseña y los grupos a los que pertenece.

Si se necesitan modificaciones en un usuario existente, llame a Modificar datos de usuario.

Para recuperar los datos del usuario, llame a Obtener datos del usuario.

Para agregar, modificar o eliminar grupos, acceda a /etc/griaule/ldap/conf/group-list.json y modifique el archivo en consecuencia. También puede ver todos los grupos llamando a Listar grupos.

4. Instalación de Ranger

Una vez que se haya configurado OpenLdap o Active Directory, puede proceder a instalar Ranger.

4.1. Prerrequisitos

4.1.1. Instalar ambari-infra

Vaya a Ambari e instale el servicio Ambari-infra. Esto proporcionará una instancia de Solr para almacenar datos de auditoría para Ranger.

4.1.2. Instalar y configurar una instancia de MySQL

  1. Instale una instancia de MySQL.

  2. Cree el usuario rangerdba y otórguele los privilegios necesarios.

    CREATE USER 'rangerdba'@'localhost' IDENTIFIED BY 'Rangerdba$1';

GRANT ALL PRIVILEGES ON *.* TO 'rangerdba'@'localhost' IDENTIFIED BY 'Rangerdba$1' WITH GRANT OPTION;

CREATE USER 'rangerdba'@'%' IDENTIFIED BY 'Rangerdba$1';

GRANT ALL PRIVILEGES ON *.* TO 'rangerdba'@'%';

GRANT ALL PRIVILEGES ON *.* TO 'rangerdba'@'%' IDENTIFIED BY 'Rangerdba$1' WITH GRANT OPTION;

FLUSH PRIVILEGES;

    Note

    Tenga en cuenta que Rangerdba$1 es la contraseña del usuario rangerdba. Reemplácela con la contraseña deseada.

  3. Pruebe si el usuario rangerdba se creó correctamente: mysql -u rangerdba -p.

  4. Instale el conector MySQL: yum install mysql-connector-java*.

  5. Registre el conector con Ambari, ejecutando el siguiente comando en el host con ambari-server instalado: ambari-server setup --jdbc-db=mysql --jdbc-driver=/usr/share/java/mysql-connector-java.jar.

4.2. Instalación del servicio Ranger

Vaya a Ambari y agregue el servicio Ranger. Pase por cada una de las siguientes pestañas de configuración antes de finalizar la instalación.

Ranger Admin++++++++++++

  1. Deje el nombre de usuario de Ranger DB como “rangeradmin”. Ponga cualquier contraseña que desee, pero anótela para más tarde.
  2. Asegúrese de que la opción “Configurar base de datos” y “Usuario de base de datos” estén configuradas en “Sí”.
  3. Para el nombre de usuario de DBA, use la cuenta de usuario creada en el paso anterior.

4.2.1. Información del usuario de Ranger

Este servicio importará tanto usuarios como grupos en la base de datos de Ranger.

Note

A continuación, damos SUGERENCIAS para los valores en varias opciones de configuración requeridas. Asegúrese de que coincidan con su implementación de Ldap.

  1. Cambie Fuente de sincronización a “Ldap/AD”.
  2. En la pestaña Configuración común:
    1. URL de LDAP/AD: Si la URL configurada aquí es para LDAPS, el certificado LDAPS deberá importarse en el almacén de confianza de usersync, tal como se describe en la sección Importación del certificado LDAPS para usersync.
    2. Usuario de enlace: Rellene el DN y la contraseña del usuario de enlace. Este usuario solo necesita privilegios de lectura en el repositorio de usuarios y grupos.
  3. En la pestaña Configuraciones de usuario:
    1. Atributo de nombre de usuario: atributo que almacena el nombre de usuario para iniciar sesión. Para AD, generalmente es “sAMAccountName” y para OpenLdap, “uid”.
    2. Base de búsqueda de usuario: Nombre distinguido para el nodo que contiene los usuarios que deben sincronizarse (Usuarios de AD).
  4. En la pestaña Configuraciones de grupo:
    1. Atributo de miembro del grupo: Atributo de la entidad Grupo que almacena qué usuarios pertenecen al grupo. Información sobre la membresía de usuario-grupo. Es generalmente “miembro”.
    2. Atributo de nombre de grupo: Atributo de grupo que contiene el nombre del grupo. Generalmente es “cn”.
    3. Clase de objeto de grupo: Clase de la entidad de grupo. Para AD, es generalmente “grupo”, para OpenLdap es generalmente “groupOfNames”.
    4. Base de búsqueda de grupo: con el nodo que contiene los grupos que deben sincronizarse.

4.2.2. Auditoría de Ranger

  1. Marque la opción “Auditoría a Solr”.
  2. Marque la opción “Solr Cloud”.

4.3. Verificación de la instalación

4.3.1. Sincronización de usuario

Vaya al sitio web de Ranger en http://<host>:6080, inicie sesión y vaya a Configuración, luego a Usuarios/Grupos. Todos los usuarios y grupos de la base de búsqueda de usuario/grupo deberían estar allí. Si ese no es el caso, se ha producido un problema con la sincronización de usuarios. Verifique el registro /var/log/ranger/usersync/usersync.log en busca de errores.

4.3.2. Auditoría de Solr

Vaya a la interfaz de usuario de ambari-infra y verifique la existencia de la colección “ranger_audits”.

4.4. Habilitación de la integración de Ldap con TLS

Para habilitar que Ranger use LDAPS en lugar de LDAP, se deben realizar dos cambios. Primero, debemos actualizar la URL de conexión de ldap a la protegida por TLS. En segundo lugar, debemos importar el certificado LDAPS.

4.4.1. Cambiar la URL de conexión de Ldap

Vaya a Ambari, Ranger, Configuraciones, Información del usuario de Ranger, Configuraciones comunes. Cambie la URL de LDAP/AD a “ldaps://<hostname>:636”.

4.4.2. Importar el certificado Ldaps

Si su repositorio Ldap está utilizando TLS, debe importar su certificado en el almacén de confianza de UserSync de Ranger.

Para obtener la ubicación del almacén de confianza, vaya a Ambari, Ranger, Configuraciones, Avanzado, Advanced ranger-ugsync-site, ranger.usersync.truststore.file. Luego, use la herramienta keytool de Java para importar el certificado Ldaps en el almacén de confianza. Si el almacén de confianza ya existe, necesitará su contraseña. Si no lo hace, tome nota de la contraseña utilizada. La necesitará más tarde.

sudo keytool -import -trustcacerts -alias $ALIAS -file $PATH_TO_YOUR_LDAPS_CERT -keystore /usr/hdp/current/ranger-usersync/conf/mytruststore.jks

A continuación, corrija los permisos y la propiedad del almacén de confianza:

Ejecutar los siguientes comandos para cambiar los permisos del archivo:

sudo chmod 640 /usr/hdp/current/ranger-usersync/conf/mytruststore.jks
sudo chown ranger:ranger /usr/hdp/current/ranger-usersync/conf/mytruststore.jks

Si el truststore es nuevo, ir a Ambari, Ranger, Configs, Advanced, Advanced ranger-ugsync-site y configurar las propiedades:

  1. ranger.usersync.truststore.file: con la ruta absoluta al truststore
  2. ranger.usersync.truststore.password: contraseña del truststore

4.4.3. Solución de problemas

4.4.3.1. No se puede crear SSLContext para la comunicación con el administrador de políticas

Hay un problema con las credenciales y claves de usersync. La única forma en que pude resolver este problema fue eliminando el truststore /usr/hdp/current/ranger-usersync/conf/mytrustore.jks, creándolo de nuevo con el certificado Ldaps y actualizando su configuración de contraseña en Ambari, Ranger, Configs, Advanced ranger-usersync-site

5. Configuración de seguridad de GBDS

Una vez instalados y configurados Ranger, Solr y el servidor Ldap, podemos proceder a configurar GBDS.

5.1. Crear keystore de GBDS

El keystore se utilizará para guardar la contraseña del usuario de enlace y la clave de firma para los tokens JWT generados por la API.

Ejecutar el script /var/lib/griaule/gbsapi/scripts/create_keystore.py pasando la ruta al nuevo keystore y la ruta para crear el archivo de contraseña. El script le pedirá la contraseña del usuario de enlace para guardarla. A continuación, el script creará un keystore con la contraseña del usuario de enlace y una clave de firma aleatoria. El keystore estará protegido por una contraseña generada aleatoriamente, que se guardará en el archivo de contraseña especificado. Por último, tanto el keystore como los archivos de contraseña se establecerán con permisos de solo lectura.

python /var/lib/griaule/gbsapi/scripts/create_keystore.py --store_path /etc/griaule/conf/gbsapi/keystore.jks --password_file /etc/griaule/conf/gbsapi/.passwords

Note

El archivo de contraseña contendrá contraseñas en texto claro. Por lo tanto, es fundamental que se mantenga en un lugar seguro con acceso solo para el usuario griaule.

5.2. Crear trustore para LDAPS

Si desea conectarse a su servidor Ldap utilizando SSL, debe importar el certificado del servidor en un truststore y configurar GBDS para que lo use.

Suponiendo que el certificado del servidor se llama server_cert.pem, ejecute el siguiente comando y use una contraseña fuerte para el truststore.

sudo keytool -import -trustcacerts -alias ldap_server -file <certificate_file> -keystore /etc/griaule/conf/gbsapi/truststore chown griaule:griaule /etc/griaule/conf/gbsapi/truststore chmod 400 /etc/griaule/conf/gbsapi/truststore

Además de crear el truststore, estos comandos también restringirán el acceso solo al usuario griaule. A continuación, guarde la contraseña del truststore en el archivo de contraseñas.

sudo -u griaule chmod u+w /etc/griaule/conf/gbsapi/.passwords && sudo -u griaule echo "truststore=<YOUR_PASSWORD>" >> /etc/griaule/conf/gbsapi/.passwords && sudo -u griaule chmod 400 /etc/griaule/conf/gbsapi/.passwords

5.3. Actualizar archivo de configuración

Editar el archivo /etc/griaule/conf/gbscluster.properties y modificar las siguientes propiedades:

  1. gbscluster.api.security.enabled: establecer en true para habilitar la seguridad

  2. gbscluster.api.security.keystore: ruta al keystore que acaba de crear (/etc/griaule/conf/gbsapi/keystore.jks)

  3. gbscluster.api.security.truststore: ruta al almacén de confianza que acaba de crear (/etc/griaule/conf/gbsapi/truststore).

  4. gbscluster.api.security.passwords: ruta al archivo de contraseñas (etc/griaule/conf/gbsapi/.passwords).

  5. gbscluster.api.security.ldap.url: Establezca la URL del servidor Ldap. Ejemplo: ldap://<host>:389. Si ha habilitado Ldaps, debería ser ldaps://<host>:636.

  6. gbscluster.api.security.ldap.userSearchBase: El DN del nodo del árbol que contiene los usuarios que podrán autenticarse contra GBDS. En nuestra guía de instalación de OpenLdap, este DN sería: ou=Users,dc=oldap,dc=pd,dc=griaule.

    Warning

    ESTO DEBE SER EL MISMO DN CONFIGURADO EN RANGER

  7. gbscluster.api.security.ldap.userSearchAttribute: Atributo de la entidad Usuario que contiene el nombre de usuario, que se utilizará durante la autenticación.

    Warning

    ESTO DEBE SER EL MISMO CONFIGURADO EN RANGER

  8. gbscluster.api.security.ldap.userGroupMembershipAttribute: Atributo de la entidad Usuario que contiene el DN de los grupos a los que pertenece. Por lo general, memberOf.

    Warning

    ESTO DEBE SER EL MISMO CONFIGURADO EN RANGER

  9. gbscluster.api.security.ldap.bindUserDN: DN del usuario de enlace. Utilice el mismo que se configuró para Ranger.

  10. gbscluster.api.security.token.ttlInMilliseconds: Tiempo de vida, en milisegundos, de los tokens JWT generados por la API. Los valores válidos están entre 30 minutos y 3 horas. Recomendamos 1 hora.

6. Instalación del Servicio de Autorización de Ranger

Para instalar y ejecutar el servicio de autorización de Ranger, es necesario crear usuarios GBDS y ADMIN.

Para crear el usuario administrador, abra el archivo administrator_group.ldif en la carpeta /etc/openldap y agregue lo siguiente al archivo:

dn: cn=administrator,ou=Groups,dc=oldap,dc=pd,dc=griaule objectclass: groupofnames cn: administrator description: IT Security Group
# Agregue los miembros del grupo, todos los cuales se supone que existen bajo people member: cn=gbds_bind,ou=Users,dc=oldap,dc=pd,dc=griaule

Luego, en el archivo gbds_user.ldif, cree el usuario GBDS.

dn: cn=gbds_user,ou=Groups,dc=oldap,dc=pd,dc=griaule objectclass: groupofnames cn: gbds_user description: IT Security Group
# Agregue los miembros del grupo, todos los cuales se supone que existen bajo people member: cn=gbds_bind,ou=Users,dc=oldap,dc=pd,dc=griaule

Aplique los cambios reiniciando el servicio de Ranger a través de la interfaz gráfica de Ambar.

sudo ldapadd -D "cn=ldapadm,dc=oldap,dc=pd,dc=griaule" -W -H ldapi:/// -f /etc/openldap/administrator_group.ldif sudo ldapadd -D "cn=ldapadm,dc=oldap,dc=pd,dc=griaule" -W -H ldapi:/// -f /etc/openldap/gbds_user.ldif

Note

Si TLS está activo, recuerde cambiar ldapi:/// a ldaps:///.

Cuando se apliquen los cambios, ejecute la Política de Autorización de Ranger.

java -jar /root/ranger-authorization-service-installer-1.0-SNAPSHOT-jar-with-dependencies.jar -admin_password 'Griaule.123' -admin_username admin -ranger_url \http://127.0.0.1:6080

Para finalizar el proceso, actualice los archivos XML de Ranger. Vaya a /etc/griaule/conf/gbsapi/ y en el archivo ranger-gbds-audit.xml, modifíquelo de la siguiente manera:

<name>xasecure.audit.jpa.javax.persistence.jdbc.url</name>
<value>jdbc:mysql://127.0.0.1:3306/ranger_audit</value>

<name>xasecure.audit.kafka.broker_list</name>
<value>localhost:9092</value>

<name>xasecure.audit.solr.solr_url</name>
<value>http://localhost:6083/solr/ranger_audits</value>

<name>xasecure.audit.destination.solr.urls</name>
<value>http://localhost:8886/solr/ranger_audits</value>

Haga lo mismo para el archivo ranger-gbds-security.xml

<name>ranger.plugin.gbds.policy.rest.url</name>
<value>http://localhost:6080</value>

7. Configurando PHP LDAP Admin

PHP LDAP Admin es una herramienta para administrar OPENLDAP a través de una interfaz gráfica de usuario, es una alternativa al uso de la CLI. El usuario puede agregar/modificar/eliminar usuarios, grupos, roles, etc. a través de la GUI. Tenga en cuenta que esto no es necesario para que LDAP funcione.

Primero, instale las dependencias de PHPLDAPAdmin.

En /etc/httpd/conf.d, actualice el archivo phpldapadmin.conf con lo siguiente:

# Require local Require all granted

Y también actualice el archivo config.php en la carpeta /etc/phpldapadmin con lo siguiente:

servers->setValue('server','name','Local LDAP Server');
servers->setValue('server','host','127.0.0.1');
servers->setValue('server','port',389);
servers->setValue('server','base',array('dc=oldap,dc=pd,dc=griaule'));
servers->setValue('login','attr','dn');

Ejecute el siguiente comando para iniciar y habilitar los servicios HTTPD:

$ systemctl enable httpd.service && systemctl start httpd.service && systemctl status httpd.service

Después de habilitar HTTPD, es necesario especificar posibles actualizaciones. Si el firewall está habilitado, ejecute:

firewall-cmd --permanent --zone=public --add-service=http firewall-cmd --reload

Y si SELinux está habilitado, ejecute:

setsebool -P httpd_can_connect_ldap on

Valide la apertura de la GUI de PHP LDAP Admin abriendo la GUI en http://localhost/ldapadmin con el usuario (DN, por ejemplo, cn=ldapadm,dc=oldap,dc=pd,dc=griaule) y la contraseña. Posteriormente, haga clic en los botones desplegables y confirme que todos los usuarios y grupos están disponibles.