Inicio > Tech - Security > Autenticación Oracle Enterprise Linux 6 con Active Directory

Autenticación Oracle Enterprise Linux 6 con Active Directory

Una de las principales necesidades crecientes de hoy en día es la seguridad en los sistemas y todo lo que ello conlleva, como la trazabilidad de los accesos a los sistemas, el envejecimiento de las contraseñas y la simplificación de la gestión de los usuarios.

Una de las formas de resolver estos objetivos, en nuestros sistemas unix, es la autenticación a través de entidades externas como LDAP o Active Directory (LDAP).

Para ejemplificarlo, presentamos un caso práctico de como autenticar Oracle Enterprise Linux 6 a través de Active Directory por medio de System Security Services Daemon (SSSD).

System Security Services Daemon (SSSD) es un servicio que pretende ofrecer una interfaz para NSS y PAM única, desde la que administrar el acceso remoto a directorios LDAP y a múltiples mecanismos de autenticación desde un único punto. Este servicio es un elemento fundamental en FreeIPA (el proyecto de identity-manager de RedHat, basado en su LDAP y no en OpenLDAP).

Se trata de disponer de un servicio independiente de nss que se encargue de las búsquedas en LDAP, Kerberos, etc. y que, además, si en algún momento se detuviera, el sistema no se ralentizaría.

Ventajas de SSSD

 

  • Greater extensibility
  • Multiple concurrently available identity stores
  • ID collision management features
  • SSL/TLS or SASL/GSSAPI is required
  • Single configuration file
  • Reduced server loads
  • Offline authentication

 

Proveedores SSSD

 

Local                      Accounts are kept in a local database

LDAP                      Relies on installed extensions of target directory

Kerberos                 Relies on installed extensions of target directory

AD                          Supports many native Active Directory® features

 

Arquitectura de una integración Active Directory con SSSD:

Integrating Red Hat Enterprise Linux 6 with Active Directory

En este post vamos a desarrollar un ejercicio práctico de este tipo de autenticación, para ello se han dispuesto los siguientes servidores virtuales:

2016-05-22 22_46_24-Libro1 - Excel

.

El primer paso en esta integración lo haremos en el DC (Domain Controller)

Como parte de la gestión de los permisos y los accesos vamos a proceder a crear dos grupos en AD:

    UNIXROOT

Los Usuarios miembros de este grupo podrán convertirse en root, en los sistemas unix, a través del comando “sudo su – “

    UNIXDBA

Los usuarios miembros de este grupo podrán convertirse en el usuario local oracle, de los sistemas unix, a través del comando “sudo su – oracle”

Creación del grupo:

Unixdba

Parámetros para unix:

unixdba2

Como se puede apreciar en la imagen, hemos optado por asignarle un GID. Este paso se repetirá por cada uno de los grupos que se vayan ha crear.

Creación de Usuario:

Para este laboratorio crearemos dos usuarios y cada uno pertenecerá a uno de los grupos definidos previamente:

user1

 

user2

Ahora aplicaremos unas configuracioness propias para los sistemas unix como son:

Home del usuario

Shell por defecto

UID

Grupo primario unix:

user3

Como siempre, esta tarea la realizaremos tantas veces sea necesaria.

Configuraciones en el Servidor OEL 6

Entendiendo que el servidor OEL está instalado, con una ip de la VLAN de DC y que el servidor DNS y NTP es el del Dominio, procederemos a instalar los siguientes paquetes desde el repositorio yum.

yum install sssd krb5­-workstation samba-­common authconfig

Ahora editaremos el fichero /etc/krb5.conf con la siguiente información:


[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = HERACLES.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
HERACLES.COM = {
kdc = SRVDC01.HERACLES.COM
admin_server = SRVDC01.HERACLES.COM
}
[domain_realm]
.heracles.com = HERACLES.COM
heracles.com = HERACLES.COM

El siguiente paso sera configurar samba en el fichero /etc/samba/smb.conf con la siguiente información:

[global]
workgroup = HERACLES
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = HERACLES.COM
security = ads
log file = /var/log/samba/log.%m
max log size = 50

Ahora vamos a obtener un “Kerberos ticket”

[root@srvoel02 ~]# kinit administrator
Password for administrator@HERACLES.COM:
[root@srvoel02 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@HERACLES.COM

Valid starting              Expiresp            Service principal
05/22/16 15:29:52           05/23/16 01:30:08   krbtgt/HERACLES.COM@HERACLES.COM
renew until 05/29/16 15:29:52
.

El siguiente paso sera unir este servidor al DC, para esto comprobaremos que este servidor no existe en el Dominio:

Server_domain

En nuestro caso no tenemos ningún servidor en el Dominio.

Para añadirlo ejecutamos la siguiente sentencia:

[root@srvoel02 ~]# net ads join -k ;
Using short domain name -- HERACLES
Joined 'SRVOEL02' to dns domain 'heracles.com'
-- Verify keytab
[root@srvoel02 ~]# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
 2 host/srvoel02.heracles.com@HERACLES.COM
 2 host/srvoel02.heracles.com@HERACLES.COM
 2 host/srvoel02.heracles.com@HERACLES.COM
 2 host/srvoel02.heracles.com@HERACLES.COM
 2 host/srvoel02.heracles.com@HERACLES.COM
 2 host/srvoel02@HERACLES.COM
 2 host/srvoel02@HERACLES.COM
 2 host/srvoel02@HERACLES.COM
 2 host/srvoel02@HERACLES.COM
 2 host/srvoel02@HERACLES.COM
 2 SRVOEL02$@HERACLES.COM
 2 SRVOEL02$@HERACLES.COM
 2 SRVOEL02$@HERACLES.COM
 2 SRVOEL02$@HERACLES.COM
 2 SRVOEL02$@HERACLES.COM
.

Ahora nuestro servidor unix ya debería formar parte del Dominio.

Server_domain_2

Configuramos SSSD authentication:

[root@srvoel02 ~]# authconfig --enablesssdauth --enablesssd --enablemkhomedir --update
Starting oddjobd:                                          [  OK  ]
.

Lo siguiente será modificar el fichero de configuración /etc/sssd/sssd.conf con la siguiente información:

[sssd]
config_file_version = 2
debug_level = 0
domains = heracles.com
services = nss, pam
# Uncomment/adjust as needed if IMU is not used:
#override_homedir = /home/%d/%u
#default_shell = /bin/bash
[domain/heracles.com]
id_provider = ad
access_provider = ad
# Permits offline logins:
# cache_credentials = true
# Use when service discovery not working:
# ad_server = srvdc01.heracles.com
# Enables use of POSIX UIDs and GIDs:
ldap_id_mapping = false

[root@srvoel02 ~]# service sssd start
Starting sssd:                                             [  OK  ]

[root@srvoel02 ~]# chkconfig sssd on
[root@srvoel02 ~]# chkconfig sssd –list
sssd               0:off    1:off    2:on    3:on    4:on    5:on    6:off

Llegados a este punto ya podemos entrar en nuestro OEL 6 con los usuarios de dominio generados previamente:

loggin1

Como se puede apreciar el acceso es efectivo pero, ¿podríamos hacer algo más?

sudo_su_1

No, aún no podríamos convertirnos en root. Para completar la configuración vamos a añadir a los dos grupos, creados previamente, al fichero /etc/sudoers de la siguiente manera:

%unixroot    ALL=(ALL)       NOPASSWD: ALL
%unixdba    ALL=NOPASSWD: /bin/su - oracle

Con la información añadida ya deberíamos ser capaces de cambiar al usuario root y oracle respectivamente.
Desde el usuario avt01:

[avt01@srvoel02 ~]$ id
uid=1345(avt01) gid=1345(unixroot) groups=1345(unixroot) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[avt01@srvoel02 ~]$ sudo su -
[root@srvoel02 ~]# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Desde el usuario avt02:

[avt02@srvoel02 ~]$ id
uid=1346(avt02) gid=1346(unixdba) groups=1346(unixdba) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[avt02@srvoel02 ~]$ sudo su -
[sudo] password for avt02:
Sorry, user avt02 is not allowed to execute '/bin/su -' as root on srvoel02.heracles.com.

Perfecto, este usuario no debería poder saltar a root.

[avt02@srvoel02 ~]$ sudo su - oracle
[oracle@srvoel02 ~]$ id
uid=500(oracle) gid=501(oinstall) groups=501(oinstall),502(dba) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[oracle@srvoel02 ~]$

Esto sí es lo que esperábamos.

Como resumen creo que SSSD simplifica tremendamente la autenticación, y sobre todo remarcar, que podremos seguir accediendo a los sistemas unix de forma offline; característica que me ha llamado la atención.

Aquí tenéis otro post que os puede resultar de interés:

  1. Aún no hay comentarios.
  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: