Conceptos Básicos: Qué constituye una Identidad en la Nube

Qué constituye una Identidad en la Nube

¡¡Hola!! desde Panamá.  Estamos visitando esta meca centroamericana como participantes e la conferencia Latinoamericana ISACA CACS/ISRM 2014.
También tuvimos el privilegio de ser charlistas en la sesión de Identidad en la nube, la nueva seguridad.

Introducción

Esta nueva serie se enfoca en la Identidad como Servicio en la nube (IdaaS).  Como saben, Centrify tiene dos lineas de producto:  Server Suite y User Suite.  El primer tópico es entender la composición de la identidad en la nube.  A nivel básico, puede ser tan simple como un identificador y una contraseña, sin embargo en la práctica esto no se traduce en aplicaciones con mucho valor.

¿Cuál es el problema con identidades en la nube?

Las aplicaciones SaaS extienden las fronteras de IT de la empresa ya que estas ofrecen sus servicios fuera e la empresa transportadas vía el Internet.  Esto implica que el suministro (alta/baja) eficiente es imperativo.  Una vez un usuario sale de la empresa, si no hay un proceso rápido y consistente de baja del usuario se produce una exposición al riesgo de fuga de información.  Este es el problema más básico, sin embargo es solo parte de la historia.  Cualquier aplicación que ofrece valor agregado tendrá requerimientos más complejos que van más allá de la identidad y la Federación (SSO):

• Asignación de licencias:  este tópico afecta los costos de la aplicación.  La manera que su proceso se asegure que las licencias sean gestionadas y recicladas de manera adecuada puede impactar el costo de licenciamiento.

  

  En este ejemplo, pueden ver los costos de Google Apps.

• Gestión de Roles, Perfiles o Grupos:  Dependiendo de la aplicación, el rol o perfil define los parámetros o derechos dentro de la aplicación.  Este es el principio de una seguridad adecuada
   

  

  Salesforce usa los perfiles (profile) para los accesos basados en roles.

• Autenticación Multifactor (MFA) y verificación de dos pasos:  Estas capacidades son cada vez más necesarias, ayudan a complementar las directivas y políticas.  Los ataques recientes a sistemas de consumidor son ejemplos de esta necesidad.

  

  Múltiples factores de autenticación y verificación de dos pasos son imperantes

• Políticas:  Cada proveedor SaaS tiene diferentes contextos y maneras de lidiar con las directivas y políticas.  Sin embargo ¿no sería conveniente tener un marco de referencia o modelo consistente que funcione en todos los puntos finales (estaciones, móviles)?

  

  Los proveedores SaaS tienen diferentes modelos de directivas

• Apoyo a la Gestión de Móviles (MDM), Aplicaciones Móviles y SSO Móvil:  Esta capacidad se hace imprescindible a medida que los móviles son una parte más importante en el arsenal del trabajador de la información.

  

  MDM, MCM, y SSO Móvil son más prevalentes

¿Existe una solución consolidada amigable al Directorio Activo?

La pregunta final es la siguiente - ¿existe una solución que puede resolver esta problemática con infraestructura actual (AD) y sin la necesidad de sincronizar información privilegiada?   

¡Si!

De eso se trata Centrify User Suite.  En los siguientes artículos vamos a explorar ejemplos prácticos con Google Apps, Office 365 and Salesforce. El  primer artículo va a tratar sobre el concepto de Federación.

Laboratorio # 5: Creación y Configuración de la Zona HQ y Grupos de Sistemas

En este laboratorio

• Usaremos la consola Access Manager para crear la zona llamada HQ
• Se definirá la configuración de identidades UNIX por defecto para la zona
• Se crearán los Roles de Sistemas (Computer Roles) para los sistemas de bases de datos y servicios Web.
  
  
  Encienda el CC para ver la transcripción en Español.

Para crear la zona HQ

1. Ingrese al sistema CLIENT1 con Jessie (el administrador UNIX)
2. Abra la consola Centrify Access Manager (del escritorio)
3. En la ventana Connect to forest, seleccione OK
4. En la consola Access Manager, en el lado izquierdo, haga click derecho en Zones y seleccione Create New Zone.
5. En zone name, escriba HQ y presione el botón next.
6. En la página de compatibilidad (Agent Compatibility page) vamos a seleccionar Hierarchical Zone.
   En este blog no se contemplarán las zonas Clásicas.
7. En la ventana Management Model, seleccione Standard Zone, presione Next y luego Finish.

 Configure la configuración por defecto de las identidades UNIX de la zona

1. En el panel izquierdo, expanda Zones, y luego la zona HQ.
2. Haga click derecho a esta zona (HQ), seleccione properties y seleccione la pestaña de  User Defaults.
3. En el campo UID,  abra el menú desplegable y seleccione auto-private group.  Siga a la pestaña Group Defaults
4. En el campo GID, abra el menú desplegable y seleccione Generate GID from SID
5. Seleccione OK, esto cerrará las propiedades.

Nota:  Estos son los valores por defecto, las identidades se pueden modificar en cualquier momento.

Añada los Roles de Computadoras (Computer Roles) para los Servidores de Bases de Datos y Servidores Web

1. En el panel izquierdo, expanda Zones > HQ > Authorization
2. Haga click derecho en Computer Roles y seleccione "Create Computer Role" 
3. En el nombre (name), escriba Database Servers
4. En la opción de computers group, haga click en el menú desplegable y seleccione <...>
5. En la ventana de Find Objects, digite UNIX y presione el botón Find Now.
6. En los resultados, haga doble click al grupo UNIX Database Servers y seleccione OK
   Repita el mismo proceso para los servidores Web, con el nombre Web Servers con el grupo de AD UNIX Web Servers. 

Conceptos Básicos: Las Zonas de Centrify

¿Qué son las Zonas (Zones)?

• De acuerdo al diccionario de la Real Academia Española:
  f. "Extensión considerable de terreno cuyos límites están determinados por razones administrativas, políticas, etc"
• Un nombre de mercadeo de una tecnología (1, 2, etc.)
• Un mecanismo para establecer modelos de gobernación de seguridad (accesos y privilegios) para sistemas UNIX y Linux (también Windows!) con el Directorio Activo y las soluciones de Centrify.

La tercera opción es la mejor, pero la respuesta es un componente de las tres definiciones. En el contexto de la gestión de accesos y privilegios, las zonas de Centrify son como carpetas que almacenan información de identidad e información sobre los privilegios de los usuarios.  Las zonas combinan el uso de Directorio Activo, la especificación RFC 2307, técnicas propias de Centrify y la metodología de Windows Authorization Manager para permitir la implementación de estos principios:

1. El principio de mínimo acceso:  el usuario final solo debe poder acceder sistemas relacionados a sus funciones en la empresa.
2. El principio de mínimos privilegios:  el usuario final solo debe tener los privilegios necesarios para ejecutar sus funciones en la empresa.
3. El principio de separación de funciones:  controles que requieren que más de una pueda ejecutar ciertas funciones para prevenir error o fraude. 

Estos principios se pueden implementar usando el control de accesos basado en roles (Role Based Access Controls, RBAC en inglés).  Las zonas permiten la gestión de identidades en UNIX (login, UID, GID, Home, Shell, etc.) 

Reutilización de Procesos
Una capacidad no muy conocida de las Zonas es que permiten que las organizaciones reutilicen sus procesos existentes para la alta/baja y cambio de identidades UNIX, administración de accesos y gestión de privilegios.  El proceso es la práctica de agregar, remover o combinar las membresías en grupos de seguridad del Directorio Activo.  Por años este mismo proceso se ha utilizado para otorgar privilegios, proporcionar acceso a carpetas de red o impresoras de red, servicios de Exhange o Sitios de Sharepoint, entre otros.

¿Qué quiere decir esto? Simplicidad de la Integración
La integración entre Centrify y cualquier otra solución que proporcione servicios de gestión de identidades, aprovisionamiento y gestión de privilegios es bastante sencilla ya que no requiere agentes o conectores dedicados.  CUALQUIER solución de esta índole tiene la abilidad de integrarse al Directorio Activo y proporciona las funciones de alta y baja de usuarios a los grupos de seguridad del Directorio Activo (independientemente del producto o vendedor: Oracle, Courion, Microsoft FIM, Sailpoint, etc.) 

La Historia de las Zonas de Centrify
Las zonas eran de dos dimensiones (planas), a esto se le llama zonas clásicas (classic zones);  las limitaciones de las zonas planas es que su administración requería de mucho esfuerzo.  Esto cambió hace unos años con la introducción de zonas jerárquicas (hierarchical zones ó HZ).  El gran poder de las zonas se extendió al implementar la gestión de accesos y privilegios, y desde el año 2013 las zonas pueden establecer gobernación de acceso y privilegio tanto a sistemas UNIX como Windows!!!!  Esto tiene altas implicaciones para las empresas que desean incrementar su seguridad y hacerlo de manera fiduciaria.
Nota de Moderación:  El autor opina que las zonas clásicas deben ser expiradas del producto.  Este blog no poporciona soluciones con zonas clásicas.

¿Cuáles son las reglas de diseño para las Zonas de Centrify?

• Una sola zona combinada con roles de computador (Computer Roles) debe satisfacer la necesidad de la mayoría de las organizaciones.  Sin embargo, es posible que existan normativas, razones legales o administrativas que impliquen la creación de zonas paralelas o subzonas (por ejemplo: reglas de la unión Europea, Separación de funciones, la normativa de tarjetas de pago, etc.)
• Cada zona que se utilice para controlar acceso a los sistems UNIX debe tener definida sus reglas para el control de identidades UNIX (UID, GID, login, Shell, GECOS).  La consola Access Manager proporciona múltiples opciones, pero la más común es:
• El login es la cuenta de usuario del AD samAccountName  (username)
• UID/GID la mejor opción es generar un número único basado en el SID.  El SID es el SystemIdentifier en el AD.
• El campo GECOS usualmente es el Display Name del AD (Nombre + Apellido)
• Los campos Home y Shell usan variables para especificar lo que defina el sistema.  Esto puede ser bastante conveniente.
• Para cada zona dedicada para UNIX, los mecanismos de aprovisionamiento deben ser planeados (manual, automático, etc)
• Las identidades se otorgan al nivel de la zona.  Las desviaciones y cambios a nivel de la sub-zona y sistema se consideran excepciones al proceso.
• Los privilegios (RBAC) se otorgan al idealmente nivel del grupo de sistemas;  cualquier desviación es una excepción.

Como hemos definido en este blog, el diseño de una zona se debe acatar a la metodología de Planear-Ejecutar-Verificar y Ajustar

¿Qué es el modo AutoZone?

AutoZone (AZ) es un modo de operación del agente de Centrify que permite que los sistemas UNIX, Linus o Mac ingresen al dominio sin restricciones de acceso para cualquier usuario del dominio AD local (o dominios confiados); efectivamente el sistema actua como una estación de trabajo normal.
El modo AutoZone es el único modo de operación de Centrify Express para UNIX/Linux;  aunque este escenario es deseable en algunas instancias, no se alinea con el principio de minimo acceso, o sea que sistemas con información u operaciones sensitivas no deben ser implementados en este modo de operación.

Otras desventajas del modo AutoZone son: 

• Hay que ser cuidadoso con la planeación.  En dominios con decenas de miles de usuarios las operaciones de cacheo son intensivas al desempeño del sistema. La regla es que si hasy mas de 1500 usuarios en el dominio, hay que establecer filtros o moverse a modo de Zonas.
• El modo AutoZone (express) no permite la manipulación de datos de identidad (login, UID, GID, etc)
• AutoZone no proporciona la gestión basada en roles (RBAC).  No hay agrupación de sistemas, etc.\

Este modo de operación será contemplado de manera limitada en este blog.

Laboratorio # 4: Instalación Centrify Standard Edition

En este laboratorio:

• Se instalará la consola Centrify Access Manager
• Se configura la consola Access Manager y especificaremos la carpeta OU para Licencias y Zonas
• Se verificarán las extensiones del programa Active Directory Users and Computers (ADUC) en el sistema CLIENT1

   
(presione el botón CC para ver la traducción al español)

Install the Centrify Standard Suite Access Manager

1. Ingrese al sistema CLIENT1 con el usuario Bryant Wheeler (Administrador de Windows)
2. Lanze el Windows Explorer y a bra a la carpeta  \\APP1\Files.  Copie la carpeta con los fuentes de instalación de Centrify en el escritorio (para no instalar usando la red).
3. Abra la carpeta DirectManage64 (o 32) y lanze el programa Setup.
4. En la ventana Welcome, presione next, seleccione "Agree" en los términos de la licencia, presione next, ingrese el nombre de su compañía, presione next. 
5. En la página de componentes, de-seleccione "Direct Manage Access - Utilities" y presione next.
6. Presione Next en la ventana Destination folder
7. Presione next y haga un check en Disable Publisher verification page  (nuestro laboratorio no tiene acceso al internet)
8. Presione next en la página resumen (summary) y next para iniciar a instalación.  Presione Finish cuando esta termine.

Configuración Inicial de Access Manager

1. Abra el programa Centrify DirectManage Access Manager (Access Manager) del escritorio.
2. Presione OK en la ventana "Connect to forest".
3. Presione siguiente (Next) en las ventanas Welcome y User Credentials
4. En la página Specify Licenses containers, presione browse y especifique la carpeta OU  Licenses OU bajo la Carpeta OUUNIX y presione next.  Haga click a Yes en la ventana que aparece.  (Todos los usuarios tendrán acceso de lectura a esta carpeta OU)
5. En la ventana Install license keys, ingrese la llave proporcionada por Centrify o use la llave de 30 días y presione next.
6. En la ventana Default Zone containers, presione browse y selecione Zones (bajo UNIX), presione next.
7. Quite el check en la ventana Delegation (no es necesario ya que las computadoras van a otra carpeta), y presione next.
8. Presione siguiente en la ventana AD notification handler.
9. Seleccione el check en la ventana Activate Pages y presione next, presione next en la ventana Summary, y luego presione Finish.

Verificación de la Pestaña Centrify en ADUC

1. Abra Start > All Programs > Administrative Tools  y haga click en el programa Active Directory Users and Computers (ADUC)
2. Navegue a la OU llamada Staff OU y haga doble-click en la cuenta de Bryant.
3. Verifique que existe una pestaña llamada Centrify en las propiedades del usuario.

Laboratorio # 3 - Preparación del Directorio Activo

En este laboratorio

1. Vamos a crear una Carpeta Organizadora (OU) llamada UNIX para almacenar el resto de los objetos y vamos a delegar la administración al Administrador de Sistemas UNIX.
2. Vamos a crear las Sub-Carpetas: Licenses (para las licencias), Zones (para las zonas), Roles (para los grupos que almacenan los roles), UNIX Groups (para los grupos UNIX), Servers (para los objetos de sistemas) y Computer Groups (para los grupos de computadoras).
3. Vamos a crear los grupos de seguridad necesitados en el Directorio Activo para la asignación de roles y agrupación de computadoras.

Para crear la Carpeta Organizadora y Delegar los permisos

(presione el botón CC para ver la transcripción en español)

1. Ingrese al sistema CLIENT1 con el usuario Bryant Wheeler (Administrador de Windows)
2. Abra Start > All Programs > Administrative Tools  y haga click en el programa Active Directory Users and Computers (ADUC)
3. En el lado izquierdo, haga click derecho en el dominio corp.contoso.com  y seleccione New > Organizational Unit
4. Ingrese el nombre UNIX y presione OK
5. En el menú View, seleccione Advanced Features (esto habilitará la pestaña de seguridad)
6. Haga click derecho en la carpeta UNIX y seleccione Properties.   En la pestaña Security, presione el botón Advanced.
7. En la pestaña Permissions presione Add. En la caja Object name, ingrese el nombre Jessie.Matthews y presione el botón check names (esto resolverá el nombre) y presione OK.
8. En la ventana permission entry, haga un check bajo la opción Full Control en la columna Allow y presione OK tres veces.
9. Cierre el programa ADUC y la sesión del sistema CLIENT1.

Ahora, el usuario Jessie (Administrador de sistemas  UNIX) tiene acceso administrativo a los objetos bajo esta OU.  El tendrá la capacidad de crear objetos, integrar sistemas al dominio, manipular identidades UNIX, etc, siempre y cuando sea bajo esta OU.

Creación de las siguientes Carpetas OU
(Licences, Zones, Roles, Servers, UNIX Groups)

(presione el botón CC para ver la transcripción en español)

1. Ingrese al sistema CLIENT1 con el usuario Jessie Matthews  (Administrador UNIX)
2. Abra Start > All Programs > Administrative Tools  y haga click en el programa Active Directory Users and Computers (ADUC)
3. En el lado izquierdo, expanda el dominio corp.contoso.com y haga click derecho en la OU UNIX y seleccione  New > Organizational Unit
4. Ingrese el nombre Licenses y presione OK.  
5. Repita los pasos 3 y 4 para:

• Licenses: contenedor para almacenar la información de licencias de Centriy (ya creada)
• Zones: Para almacenar las zonas.  Las zonas son como folders que guardan sistemas, usuarios, grupos e información de autorización.
• Servers:  para almacenar los objetos de sistemas UNIX/Linux ingresados al dominio
• Roles:  para almacenar los grupos de seguridad que se usarán para almacenar roles
• UNIX groups:  para almacenar los grupos de seguridad asociados a grupos UNIX
• Computer Groups:  para almacenar los grupos de seguridad usados para agrupar sistemas.

Creación de los Grupos de Seguridad (Roles y Grupos de Computadoras)

1. Haga click derecho en la OU llamada Roles (bajo UNIX) y seleccione New > Group
2. Ingrese el nombre UNIX Super Users y presione OK.  (A este grupo pertenecerán los súper usuarios)
3. Haga click derecho en la OU llamada Roles (bajo UNIX) y seleccione New > Group
4. Ingrese el nombre UNIX Regular Users y presione OK. (A este grupo pertenecerán los usuarios normales)
5. Haga click derecho en la OU llamada Computer Groups (bajo UNIX) y seleccione New > Group
6. Ingrese el nombre UNIX Database Servers y presione OK. (A este grupo pertenecerán los sistemas bases de datos)
7. Haga click derecho en la OU llamada Computer Groups (bajo UNIX) y seleccione New > Group
8. Ingrese el nombre UNIX Web Servers y presione OK. (A este grupo pertenecerán los sistemas web)

Laboratorio # 2: Implementando los sistemas UNIX/Linux en el Laboratorio Base

En este laboratorio

1. Se instalarán los sistemas CentOS 6.5, SUSE 10 SP3 y Solaris 5.10
2. Se verificarán las configuraciones de red (TCP/IP) y del servicio SSH de los sistemas UNIX/Linux.
3. Se modificarán los sistemas para que no lanzen los ambientes gráficos
4. Se verificará que el servicio Name Server Cache Daemon (NSCD) funciona automáticamente.
5. Se crearán usuarios locales en los sistemas y se habilitará la facilidad sudo::
   Dos usuarios en cada sistema y Jessie Matthews (jmatthews):
   Dos usuarios en el sistema de base de datos (CEN1); Jeremy Silva (jsilva) & Ramon Jimenez (rjimenez)
   Dos usuarios en el sistema web  (SUSE1); Doyle Russell (drussell) & Matt Sims (msims)
   A los usuarios centrifying, jmatthews se asignarán al grupo wheel group para que puedan elevar privilegios con sudo.
6. Se comprobará la conectividad entre el sistema CLIENT1 y los sistemas usando el cliente SSH PuTTY 
7. Se copiarán los agentes de Centrify en la plataforma correspondiente

Requerimientos del laboratorio

• Los requerimientos de la configuración base de los laboratorios de pruebas (DC1, APP1 y CLIENT1)
• Una máquina virtual con Centos 6.5 VM llamada CEN1
  http://wiki.centos.org/Download 
  Es posible que tenga que descargar el paquete NCSD para CentOS.
• Una máquina virtual con Novell SUSE 10 VM llamada SUSE1
  https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=10&service_pack=sp3&architecture=x86_64&package_name=index_all
• Una máquina virtual con Solaris 5.10 VM llamada SOL1
  http://www.oracle.com/technetwork/server-storage/solaris10/downloads/index.html

Instalación de los sistemas UNIX/Linux

Los sistemas en esta guía:

• CentOS 6.5 (CEN1) con dirección IP 10.0.0.151
• Novell SUSE 10 (SUSE1) con dirección IP  10.0.0.152
• Solaris 5.10 x86 (SOL1) con dirección IP  10.0.0.153  

Para configurar los Sistemas UNIX/Linux
Siga las instrucciones para cada plataforma:

En el sistema CEN1

1. Ingrese al sistema con con una cuenta que pueda elevar con sudo o con  super usuario y abra una terminal.
2. Verifique si el sistema está corriendo el servicio NetworkManager (NM)
   service NetworkManager status
   NetworkManager (pid ####) is running
   Nota: Siga los pasos apropiados si no usa el NetworkManager
3. Edite el archivo /etc/sysconfig/network con:HOSTNAME=cen1.corp.contoso.com
4. Copie la dirección MAC del interfaz: (Ejemplo eth0 with the Mac address 00.0c.29.2b.b7.ca)
   ifconfig eth0 | grep HWaddr
   eth0   Link encap: Ethernet  HWaddr  00:0C:29:2B:B7:CA
5.  Edite (o cree) el archivo /etc/sysconfig/network-scripts/ifcfg-<interfaz> y ingrese (o edite) las siguientes lineas:  (con el ejemplo anterior)
   DEVICE=eth0
   NM_CONTROLLED=yes
   ONBOOT=yes
   HWADDR=00:0C:29:2B:B7:CA
   IPADDR=10.0.0.151
   NETMASK=255.255.255.0
   DNS1=10.0.0.1
6. Reinicie el servicio de la red:
   service network restart
7. Verifique la configuración (hostname, configuración DNS, prueba ping test a crl.corp.contoso.com)
   # hostname
   cen1.corp.contoso.com
   # cat /etc/resolv.conf    (busque las siguientes lineas)
   search corp.contoso.com
   nameserver 10.0.0.1
   # ping crl
   PING crl.corp.contoso.com (10.0.0.3) 56(84) bytes of data.
   64 bytes crl.corp.contoso.com (10.0.0.3): icmp_seq=1 ttl=128 time=17.2 ms
   Esto verifica que la configuración de la red está correcta y que el sistema tiene configurado a DC1 como su servidor DNS.
8. Cerciórese que el servidor SSH está corriendo:
   chkconfig | grep ssh
9. Si el servicio está apagado en los niveles de operación 3 y 5, habilite con este comando:
   chkconfig sshd on --level 35
10. Instale y habilite el servicio NCSD: 
    rpm -Uvh nscd-2.12-1.132.el6.x86_64.rpm
    chkconfig nscd on --level 35
    service nscd start
11. Asegúrese que el servidor SSH está configurado para la autenticación con el módulo PAM y que la opción de ChallengeResponse está habilitada.  En el archivo /etc/ssh/sshd_config edite las siguientes lineas:
    UsePAM  yes
    ChallengeResponseAuthentication yes
    
    Si hay lineas con los valores negativos, estas deben ser comentadas (con el signo de libra #) de lo contrario la última linea procesada será la configuración efectiva.
12. Hay que crear los usuarios administrativos y los DBAs:
    useradd -m -c "Centrifying User" centrifying
    useradd -m -c "Jeremy Silva" jsilva
    useradd -m -c "Ramon Jimenez" rjimenez
    useradd -m -c "Jesse Matthews" jmatthews (usuario administrativo)
13. Para otorgar privilegios administrativos a Jessie y Centrifying
    usermod -G wheel centrifying
    usermod -G wheel jmatthews
14. Configure Sudo en el sistema
    vi /etc/sudoers
    Solo hay que quitar el comentario a la linea del grupo wheel.
    %wheel ALL=(ALL)       ALL
    Grabe el archivo.

En el sistema SUSE1

1. Ingrese al sistema con con una cuenta que pueda elevar con sudo o con  super usuario y abra una terminal.
2. Edite el archivo /etc/hostname (o copie uno nuevo si no existe) con esta linea:
   suse1
3. Edite el archivo /etc/hosts.  Escriba el nombre del sistema en la linea correspondiente:
   127.0.0.1       localhost  suse1
4. Edite el archivo /etc/resolv.conf  y añada estas lineas:
   search corp.contoso.com
   nameserver 10.0.0.1
5.  Edite (o cree) el archivo /etc/sysconfig/network-scripts/ifcfg-<interfaz> y ingrese (o edite) las siguientes lineas:  (con el interfaz eth0)
   DEVICE=eth0
   ONBOOT=yes
   IPADDR=10.0.0.152
   NETMASK=255.255.255.0
6. Reinicie el servicio de red:
   service network restart
7. Verifique la configuración (hostname, configuración DNS, prueba ping test a crl.corp.contoso.com)
   # hostname
   suse1
   # cat /etc/resolv.conf    (busque las siguientes lineas)
   search corp.contoso.com
   nameserver 10.0.0.1
   # ping crl
   PING crl.corp.contoso.com (10.0.0.3) 56(84) bytes of data.
   64 bytes crl.corp.contoso.com (10.0.0.3): icmp_seq=1 ttl=128 time=17.2 ms
   
   Esto verifica que la configuración de la red está correcta y que el sistema tiene configurado a DC1 como su servidor DNS.


8. Cerciórese que el servidor SSH está corriendo:
   chkconfig | grep ssh
9. Si el servicio está apagado en los niveles de operación 3 y 5, habilite con este comando:
   chkconfig sshd on --level 35
10. Cerciórese que el servicio NCSD está corriendo
    
    chkconfig --list | grep nscdnscd      0:off  1:off  2:off  3:on   4:off  5:on   6:off
11. Si el servicio está apagado en los niveles de operación 3 y 5, habilite con este comando:
    chkconfig nscd on --level 35
12. Asegúrese que el servidor SSH está configurado para la autenticación con el módulo PAM y que la opción de ChallengeResponse está abilitada.  En el archivo /etc/ssh/sshd_config edite las siguientes lineas:
    UsePAM  yes
    ChallengeResponseAuthentication yes
    
    Si hay lineas con los valores negativos, estas deben ser comentadas (con el signo de libra #) de lo contrario la última linea procesada será la configuración efectiva.
13. Hay que crear los usuarios administrativos y los Usuarios Web:
    useradd -m -c "Centrifying User" centrifying
    useradd -m -c "Doyle Russell" drussell
    useradd -m -c "Matt Simms" msimms
    useradd -m -c "Jesse Matthews" jmatthews
    Nota:  el comando useradd está en /usr/sbin en caso que no esté en el path.
14. Para otorgar privilegios administrativos a Jessie y Centrifying
    usermod -G wheel centrifying
    usermod -G wheel jmatthews
15. Configure Sudo en el sistema
    vi /etc/sudoers
    Solo hay que quitar el comentario a la linea del grupo wheel.
    %wheel ALL=(ALL)       ALL
    Grabe el archivo.

En el Sistema SOL1

En un sistema Solaris,hay que cambiar estos archivos para cambiar la configuración de red:

/etc/nodename

/etc/hostname.interface

/etc/inet/hosts
/etc/inet/ipnodes

/etc/defaultdomain

/etc/netmasks

/etc/defaultrouter 

/etc/resolv.conf 

/etc/nsswitch.conf 

 No se configurará el default gateway (default router) por ahora

1. Ingrese al sistema con con una cuenta que pueda elevar con sudo o con  super usuario y abra una terminal.
2. Si el sistema está configurado para usar DHCP, borre el archivo /etc/dhcp.<interface> (por ejemplo: dhcp.e1000g0)
3. Edite el nombre del nodo en el archivo the /etc/nodename con esta linea
   sol1
4. Edite el nombre del sistema en el archivo /etc/hostname.<interface>  file (e.g e1000g0  /etc/hostname.e1000g0) con esta linea:
   sol1
5. Edite el archivo /etc/inet/ipnodes  y añada esta linea
   10.0.0.153    sol1
6. Edite el archivo  /etc/inet/hosts  y añada esta linea
   10.0.0.153    sol1
   también modifique esta linea
   127.0.0.1 localhost sol1
   Cerciórese que no hay "localhost.localdomain"
7. Edite el archivo /etc/defaultdomain file  (hay que crear el archivo si no existe), sólo escriba esta linea:
   corp.contoso.com
8. Edite el archivo /etc/netmasks y añada esta linea
   10.0.0.0    255.255.255.0
9. Edite el archivo/etc/resolv.conf file añada estas lineas:
   search corp.contoso.com
   nameserver 10.0.0.1
10. Verifique que el archivo /etc/nsswitch.conf está configurado para resolver nombres usando DNS.  Añada la entrada 'dns' si es necesario.  Puede verificar esto con el comando
    cat /etc/nsswitch.conf | grep dns  
    Los resultados deben ser asi (editelo si es necesario)
    hosts:    files dns
    ipnodes:  files dns
11. Probablemente tendrá que reiniciar el sistema (si cambió el archivo /etc/nsswitch.conf o reiniciar la red
    svcadm restart physical
12. Verifique la configuración (hostname, configuración DNS, prueba ping test a crl.corp.contoso.com)# hostnamesuse1
    # cat /etc/resolv.conf    (busque las siguientes lineas)
    search corp.contoso.comnameserver 10.0.0.1
    # ping crlcrl is alive
    
    Esto verifica que la configuración de la red está correcta y que el sistema tiene configurado a DC1 como su servidor DNS.
13. Verifique que el servicio NCSD está corriendo:
    $svcs \*name-service-cache\*STATE          STIME    FMRIonline         Dec_24   svc:/system/name-service-cache:default
14. Hay que crear los usuarios administrativos:
    useradd -m centrifying
    useradd -m -c "Jesse Matthews" jmatthews

Modifique los equipos para que inicien en modo de interfaz gráfico

No usaremos los ambientes gráficos (GUI) ya que estos se usarán con el propósito de servidores

En los sistemas CEN1 y SUSE1

1. Ingrese al sistema con con una cuenta que pueda elevar con sudo o con  súper-usuario y abra una terminal
2. Edite el archivo /etc/inittab
   id:3:initdefault:
3. Reinicie el equipo para que arranque en modo multi-usuario de servidor.

 En el sistema SOL1

1. Ingrese al sistema con con una cuenta que pueda elevar con sudo o con  súper-usuario y abra una terminal
2. Deshabilite el ambiente gráfico
   /usr/dt/bin/dtconfig -d
3.  El escritorio CDE o Java desktop ha sido deshabilitado, reinicie el equipo para que arranque en modo multi-usuario de servidor.

Pruebe la conectividad con el cliente PuTTY

1. Inicie en el equipo CLIENT1 con el usuario jessie.matthews.
2. Abra  el programa PuTTY y pruebe conexiones a todos los sistemas con su nombre (no con su dirección IP)
3. Opcional:  Grabe la sesión para cada equipo.

Nota:  No se recomienda que se permita el acceso de la cuenta de super usuario (root) con una terminal SSH.  Si prefiere hacer esto en su laboratorio (no es recomendado para que no se desarrollen malos habitos), hay que cerciorarse que el parámetro PermitRootLogin  está habilitado en el archivo de configuración del servidor SSH (/etc/ssh/sshd_config).

Copiado del agente de Centrify en los Sistemas

1. En el sistema CLIENT1, en el Explorador de Windows y abra la carpeta de red \\APP1\Files
2. Abra el programa WinSCP
3. Establezca una conexión a CEN1 con un usuario privilegiado.  Crear una nueva carpeta llamada Temp en el sistema de archivo raiz (/)
4. Abra /Temp
5. Tome el archivo centrify-suite-2013.3-rhel3-x86_64.tgz de la carpeta  \\APP1\Files y copiela la carpeta /temp en la ventana WinSCP, confirme la copia.
6. Repita el proceso en los sistemas siguientes:
   centrify-suite-2013.3-sol9-x86.tgz va en la carpeta /temp de SOL1
   centrify-suite-2013.3-suse9-x86_64.tgz va en la carpeta  /temp de SUSE1
7. Cierre la sesión en CLIENT1

Estado final del Laboratorio

Problemas del Negocio: # 1 La Administración y Autenticación de Usuarios en Sistemas UNIX y Linux

Información sobre nuestra empresa ficticia (Contoso):

• Sus competencias en el mercado no son en tecnología (a diferencia de Google o Apple que podrían desarrollar soluciones internas que se pueden mercadear o vender)
• Tienen un equipo de TI limitado y son conscientes de los costos.
• Valoran la eficiencia operativa.  
• Han acordado que hay que maximizar las inversiones en tecnologías como Directorio Activo en tanto a gente (preparación, experiencia), Procesos e Infraestructura.

Problema # 1:  La Administración  y Autenticación de Usuarios en Sistemas UNIX y Linux

Contoso está buscando empezar a procesar información de tarjetas de pago, y basándose en la normativa de protección de datos (Payment Card Industry o PCI en inglés) se embarcan en un proceso para implementar el reforzamiento de las siguientes reglas::

• Eliminar la práctica de compartir credenciales privilegiadas
• Establecer que todas las credenciales de usuarios en sistemas UNIX/Linux  estén únicamente identificadas (sección 8.1)
• Que los usuarios de sistemas UNIX puedan iniciar sesiones con sus credenciales del directorio activo
• Cerciorarse de que cuando las credenciales son habilitadas / deshabilitadas / limitadas en el servicio de directorio central, este efecto se propague a los sistemas UNIX y Linux
• Las políticas de contraseñas sean reforzadas uniformemente en todas las plataformas (Windows, UNIX, Linux, etc.)
• Preferiblemente las credenciales (incluyendo las contraseñas) sean implementadas de manera nativa, sin esquemas de sincronización.

Del punto de vista de cada grupo:

Administrador de Sistemas UNIX/Linux	- Con el tiempo se ha hecho muy difícil mantener las cuentas de usuario en cada servidor - Existen algunos mapeos NIS que deben ser descontinuados. - Cada vez que los auditores solicitan información, requiere un gran esfuerzo del equipo. - Las cuentas de súper usuario (root), Oracle, etc son compartidas y es difícil establecer la responsabilidad de ciertas acciones - Idealmente las cuentas de servicios del sistema deben ser mantenidas internamente en el sistema.
Analista de seguridad de la información	-         Como pronto vamos a empezar a procesar tarjetas de pago, es imperativo cerciorase que las cuentas privilegiadas no son compartidas entre varios individuos -          Todos los usuarios deben tener un identificador único, preferiblemente en el directorio central (AD). -          Hay que cerciorarse que la política de contraseñas (longitud, complejidad y expiración) ya existentes para clientes Windows, se pueden reforzar en sistemas UNIX/Linux
Gerente de Sistemas o Arquitecto	-          El flujo de trabajo para alta, baja y cambios de credenciales, al igual que de restauración de contraseñas es muy complicado.  Demasiado personal debe involucrarse y hay alto nivel de error -          Debemos estar listos para procesar información sobre tarjetas de pago -          Existe un sistema de Gestión de Identidades (Microsoft FIM) y nos encantaría usarlo para estandarizar los procesos.
Administrador de sistemas Windows (incluyendo el servicio de directorio activo)	-          Preferiblemente la solución implementada debe usar el directorio de manera nativa, sin extensiones propietarias al esquema de la base de datos y sin instalar programas en controladoras del dominio -          Debemos conservar el mismo modelo de almacenamiento y convenciones de nombres que existen en el directorio el día de hoy.

Actividades de Planificación (participantes)

Estas son las actividades de planificación con los respectivos participantes.  En proyectos de esta índole, no solo se debe adquirir o contratar el conocimiento cognitivo, sino que la coordinación y cooperación entre equipos e individuos también es un desafío.  Este tipo de soluciones desafían el modo de trabajo actual, y en organizaciones donde hay un alto nivel de fragmentación se presenta el síntoma de resistencia al cambio.  Se deben tomar decisiones, puntos medios deben ser encontrados, etc.  

Gobernación de Acceso  (entre todos)

Luego de conversar con el analista de seguridad, al evaluar el tipo de servidores existentes, y para promover la simplicidad, el administrador de UNIX decide que van a existir dos grupos de sistemas: 

• Servidores de Bases de Datos
• Servidores Web

Acceso y Gestión de Privilegios (entre todos)

Inicialmente dos roles:  Administradores de Sistemas y Usuarios Regulares

Los Administradores de Sistemas tendrán el derecho de ingresar a todos los sistemas y efectuar labores administrativas.

Los Administradores de Bases de Datos solo pueden iniciar sesiones en todos los servidores de bases de datos.

Los Administradores Web  solo pueden iniciar sesiones en todos los servidores web

Convenciones de Nombres y Almacenamiento de Objetos en el Directorio (entre los administradores de UNIX y del Directorio Activo)

Luego de investigar el producto, se propone la siguiente estructuras:

UNIX OU (padre)	para almacenar las carpetas subsiguientes
Servers OU	para almacenar los objetos de cuentas de computadoras
Computer Groups OU	para almacenar los grupos de AD que se usarán para los roles de computadora
Roles OU	para almacenar los grupos de AD que se usarán para los roles de los usuarios
UNIX Groups OU	para almacenar los grupos de AD que se corresponden a grupos en UNIX
Licenses OU	para almacenar la información sobre licencias
Zones OU	para almacenar la información pertinente a como el producto organiza los sistemas.

Gestión de Identidades (Administradores UNIX/Windows y el analista de seguridad)

Usuarios:  El proceso será manual hasta que se integre a la solución de gestión de identidades.  El administrador de sistemas UNIX trabajará para hacer la migración de usuarios existentes.  A partir de ese punto, cada usuario deberá tener una identidad única; los roles del usuario se proporcionarán luego de que la identidad es implementada.

Sistemas:

• Los administradores UNIX coordinarán con el grupo responsable por DNS para proporcionar la información IP.
• Una vez el sistema está en el directorio, el agente de Centrify automáticamente manejará el reloj y el ambiente Kerberos del sistema.

Delegación de Administración (Administradores UNIX/Windows y el analista de seguridad)

• El administrador del directorio activo va a delegar la administración de la carpeta OU para los objetos UNIX/Linux a los administradores UNIX.  Esto les permitirá manipular identidades, integrar sistemas, etc.
• Si se requiere un objeto de directiva de grupo (GPO) este debe ser creado por el administrador de Windows y delegado al Administrador UNIX

Servicios de Infraestructura (Administradores UNIX/Windows y el analista de seguridad)

• Hoy el servicio DNS y los servicios de sincronización de tiempo (NTP) están duplicados para cada infraestructura.  Se ha acordado usar los servicios proporcionados por el servicio de directorio activo en UNIX.

Servicios de Monitoreo (Administradores UNIX/Windows y el analista de seguridad)

• Los intentos de acceso fallidos deben ser registrados
• El uso de privilegios debe ser registrado

Herramientas Requeridas

• Los Administradores UNIX requieren de la herramienta  Active Directory Users and Computers.
• Las consolas de Centrify se instalarán en la computadora cliente.  

Laboratorios: Metodología de los Laboratorios

Una de las metas de este blog es proporcionar ejemplos prácticos que se pueden implementar en un entorno de producción o de pruebas para resolver los desafíos de la gestión de accesos e identidades en las plataformas UNIX y Linux.  Para aprovechar el tiempo y tener una configuración estándar, la metodología utilizarán  herramientas disponibles en el Internet.

La problemática del negocio gobernarán los laboratorios
Las laboratorios están diseñados para resolver los problemas empresariales de infraestructura y gestión de TI.  Se desarrollará una progresión de problemas y módulos dependientes;  esto ayudará a la audiencia a tener modelos de referencia que se pueden llevar a ambientes de producción.  Cada problemática será presentada en la perspectiva de los administradores UNIX, analista de seguridad de la información y gerente de TI;  si hay algunos detalles que se deben enfocar del punto de vista del administrador de Windows, estos serán presentados en la respectiva fase (Planificación-Ejecución-Verificación-Ajustes).

La infraestructura de Windows y Directorio Activo
Microsoft Technet tiene un excelente recurso en su serie de laboratorios de pruebas Test Lab Guides.  Este contenido está en Inglés, sin embargo, proporciona un modelo estándar de configuración que se puede aprovechar para establecer un modelo de referencia.  Los ejemplos presentados en el blog serán basados en la e configuración base para Windows Server 2008 R2.  Aquí está el diagrama:

La configuración base proporciona:
- Un bosque de Directorio Activo funcional (corp.contoso.com)
- Una red interna (corpnet) 10.0.0.0/24
- Servicios de resolución de nombre (DNS)
- Sitios web y carpetas compartidas
- Una unidad certificadora con sus listas de revocación de certificados

DC1 es la controladora de dominio y unidad certificadora
APP1 es el servidor de aplicaciones
CLIENT1 es el cliente, la mayoría de la administración se hará desde esta computadora
Las consolas de Centrify serán instaladas en este computador.
Los sistemas EDGE and INET1 no son usados hasta mucho más tarde, o sea que con los tres básicos se puede iniciar.

Infraestructura UNIX/Linux

A pesar de que la infraestructura cambiará con el caso de uso, la estructura básica contiene 3 másquinas:
- CEN1, un sistema CentOS 64 bit con la versión personal de  IBM DB2 (Express) y el servidor web Apache
- SUSE1 un sistema SUSE 10 SP3 con la versión personal de Oracle
- SOL1 un sistema  Solaris 10.

Notas sobre la configuración base:

• En la página 14, la guía recomienda que se configure la directiva de grupo "Domain member: Maximum machine account password age" al vaor de 999.  Esto quiere decir que la contraseña de la cuenta de la computadora en el AD cambiará cada 3 años.  En un modelo de producción, por defecto ese valor es de 30 días.  Este tema tiene implicaciones en la autenticación mutual del sistema.
• Recomiendo cambiar el objeto de directiva de grupo "Interactive Logon: Prompt user to change password before expiration" a 30 días.  Esto cambiará el aviso a 30 días antes de su expiración.
• Configure un  aviso corporativo cambiando el GPO "Interactive logon:  Message text for users attempting to log on" 

Nuestro laboratorio final se verá así:

Solo hay subscribirse a la sección de laboratorios para ser notificado.