Microsoft Lync Server
Header

¿Porqué un usuario deshabilitado en el Directorio Activo puede iniciar sesión en Lync?

marzo 12th, 2015 | Posted by Santiago Buitrago in Directivas de Grupo | Lync Server - (0 Comments)

Es muy probable que cuando deshabilitéis un usuario en vuestro Directorio  Activo​ no lo hayáis hecho en Lync, puesto que son dos procesos diferentes (Deshabilitar un usuario en el Directorio Activo y en Lync). Esto puede suponer un problema de seguridad, porque es "posible" que el usuario pueda iniciar sesión en Lync y tener contacto con usuarios internos de forma legítima. Por lo que un usuario deshabilitado en Directorio Activo pero no en Lync podrá iniciar sesión en Lync durante cierto tiempo … (pulsar en la imagen para verla a tamaño real)

Usuario_Deshabilitado_Inicia_Sesión_En_Lync-5.png
Cuando digo cierto tiempo es porque como todos sabreis, cuando un usuario inicia sesión en Lync por primer vez en un equipo, el servidor de Lync emitará un certificado de usuario. Esto es así porque así el proceso de inicio de sesión es más rápido que utilizando las credenciales, y este certificado por defecto tiene una validez de 6 meses. Por lo que un usuario que ha iniciado sesión y el servidor le ha emitido su certificado, podrá iniciar sesión con este certificado durante seis meses (Lync Server: Modificar el tiempo de validez de un certificado de usuario) aunque su cuenta esté deshabilitada en el Directorio Activo.
 
Este comportamiento se puede modificar, pero no se recomienda, porque el utilizar el certificado para iniciar sesión en Lync acelerará el proceso. Aquí lo que debemos hacer es ser muy cuidadosos cuando damos de baja un usuario en nuestro Directorio Activo, y aquí os describo dos procesos en base a dos premisas:
  1. Usuario sin retorno a la empresa: usuario que deja de pertenecer a la empresa y que sabemos que no volverá a ella y se elminarán todos los datos de su perfil en Lync
    1. Quitar cuenta de Lync: Disable-CsUser -Identity <Nombre_Usuario>
    2. Deshabiltar su cuenta en el Directorio Activo
  2. Usuario con retorno a la empresa: usuario que deja de pertenecer a la empresa durante un tiempo, pero que durante el tiempo que esté fuera no queremos que se pueda conectar
    1. Revocar certificados de usuario en Lync Server: Revoke-CsClientCertificate -Identity <Nombre_Usuario>
    2. Deshabilitar su cuenta en el Directorio Activo 

Esto es a nivel de servidor, que es donde realizaremos los cambios, pero si queremos comprobar que esto es así podemos hacerlo de forma muy sencilla. Habilitamos un usuario en Lync e iniciamos sesión una primera vez, en  ese momento Lync emitirá un certificado que se instalará en el contenedor de certificados de usuario en el momento de iniciar sesión en Lync:

Usuario_Deshabilitado_Inicia_Sesión_En_Lync-6.png

Ahora deshabilitamos el usuario en el Directorio Activo si tener iniciado Lync, y una vez deshabilitado tratamos de iniciar sesión en Lync y sin problema:

Usuario_Deshabilitado_Inicia_Sesión_En_Lync-5.png

Por último ya con el usuario deshabilitado en Lync vamos a borrar el certificado que nos había emitido e instalado en el equipo en donde el usuario ha iniciado sesión. Esto podemos hacerlo de varias formas, eliminar directamente el certificado desde una consola MMC o cuando pulsando en Eliminar mi información de inicio de sesión desde el propio Lync:

 

Usuario_Deshabilitado_Inicia_Sesión_En_Lync-8.png
Usuario_Deshabilitado_Inicia_Sesión_En_Lync-7.png

 

Una vez hecho esto podemos observar que ya no tenemos el certificado de usuario en nuestro equipo:

 

Usuario_Deshabilitado_Inicia_Sesión_En_Lync-3.png
 
Si ahora tratamos de iniciar sesión, veremos que ya no podemos, puesto que en este caso lo primero que hará será tratar de validar nuestras credenciales en el Directorio Activo y ya teníamos la cuenta deshabilitada:

 

 

Usuario_Deshabilitado_Inicia_Sesión_En_Lync-4.png

 

Claramente si revocamos el certfiicado desde el servidor (que es lo suyo) de Lync (Revoke-CsClientCertificate -Identity <Nombre_Usuario>) ya no tenemos que hacer nada de esto, pero bueno, la idea era ver de forma clara cual es el comportamiento del cliente Lync antes esta situación. También comentaros que este artículo ya lo había publicado en su momento:  Deshabilitar un usuario en el Directorio Activo y en Lync pero he querido volver a recordarlo porque era un artículo bastante antiguo.
 

Espero que os sea de utilidad!!!

Como denegar el acceso a la red a equipos conectados vía DirectAccess

marzo 18th, 2014 | Posted by Santiago Buitrago in Directivas de Grupo - (0 Comments)

Una de las preguntas que los administradores se suelen hacer cuando ​implementan DirectAccess es como pueden evitar que se puedan conectar a la red, bien porque nos han robado la máquina o simplemente porque la hemos perido. Pues bien la respuesta es bien sencilla, tenemos varias formas de hacerlo:

  1. Deshabilitar la cuenta de equipo en el dominio: Efecto inmediato
  2. Elimina la cuenta de equipo: Efecto inmediato

Direct_Access_Deny_Red_11.png

3. Revocar el certificado de equipo: Tiempo de actualización de la CRL y distribución en los puntos de CRL

Este método es igual de efectivo, pero debemos tener en cuenta que en función del tamaño de nuestra organización podrá actuarlizarse la CRL en más o menos tiempo, lo cual permitirá a los equipos configurados con DirectAccess seguir conectándose mientras no se haya actualizado los puntos de distribución de la CRL. Teniendo en cuenta esto, vamos a ver cuales serían los pasos a seguir para revocar un certificado. Lo primero que debemos hacer es abrir la consola de administración de certificado, ir a la sección de Certificados Emitidos y en el listado de certificados buscar el que queremos revocar, pulsamos con el botón secundario del ratón encima de mismo y pulsamos en Todas las Tareas – Revocar certificado

Direct_Access_Deny_Red_3.png
Elegimos un Código de motivo por el cual queremos revocar el certificado (esto es a nivel informativo) y la fecha hora que se reovará (claramente lo haremos con fecha y hora del momento actual)

Direct_Access_Deny_Red_4.png

Ahora nos vamos a la opción de Certificados Revocados y verificamos que el certificado ha sido revocado
Direct_Access_Deny_Red_6.png
Y para acelerar el proceso de publicación de la CRL, sobre la opción de Certificados Revocados pulsamos con el botón secundario del ratón y pulsamos en Todas la tareas y Publicar, con esto forzaremos la actualización de la CRL

Direct_Access_Deny_Red_7.png
Ahora bien, si hemos configurado la distribución de la CRL en una ubicación diferente a la por defecto y como estamos utilizando una CA interna (en mi caso para los certificados del equipo del dominio uso una CA de Windows 2012) debemos copiar los ficheros actualizados de la CRL y copiarlos en la ubicación que corresponda. La idea es que el servidor pueda verificar la CRL antes de establecer el tunel IPSec con el cliente, de tal forma que si el certificado presentado por el cliente está presente en la CRL se denegará el acceso. Si bien es cierto, que para que esto funcione debemos tener configurado "Habilitar la comprobación fuerte de CRL para la autenticación de IPsec" (http://technet.microsoft.com/es-es/library/ee649260(v=ws.10).aspx). Por defecto se configura una comprobación débil, por lo que solo se deniegará el acceso si se comprueba que en la CRL aparece el certificado del equipo.

 

Por lo que hecho esto y actualizado los puntos de distribución de las CRL, el equipo seguirá conectado  pero en cuanto se intente volver a conectar ya no podrá hacerlo:

Direct_Access_Deny_Red_9.png

Si tenemos la posibilidad de acceder el equipo veremos que se quedará constantemente en "Conectando"

Direct_Access_Deny_Red_10.png

Desde luego la forma más rápida y efectiva está clara, borramos o desactivamos la máquina en el dominio. Pero también tenemos la posibilidad de revocar el certificado y que vía CRL se pueda verificar que el certificado se ha revocado y por lo tanto no es válido para tener acceso a la negociación vía IPSec de DirectAccess y no permitirá el acceso a al red.

Espero que os sea de utilidad!!!

Cómo unir un equipo a un dominio sin conexión y además configurarlo para DirectAccess

marzo 18th, 2014 | Posted by Santiago Buitrago in Directivas de Grupo - (0 Comments)

Cuando queremos desplegar DirectAccess (Windows Server 2012: DirectAccess (Actualizado 15-02-2013)) y tenemos usuarios itinerantes en nuestra organización, que no tienen contacto con el Directorio Activo durante meses nos encontramos con "pequeño problema" ….. pero con fácil solución:

  1. Configurar una VPN de Acceso Remoto
    1. Windows Server 2012, Configuración VPN con PPTP
    2. Windows Server 2012, Configuración VPN con SSTP
    3. Otras tecnologías: Cisco, SonicWall, 3Com, HP, Juniper, F5, etc…
  2. Unir los equipos al dominio con DJOIN

La primera opción requiere cierta configuración sencilla, pero si queremos hacerlo en tiempo record lo haremos con la opción de unir los equipos a un dominio si conexión. Además, nos permitirá que se le aplique de forma automatica la configuración de DirectAccess, por lo que acto seguido a unirse al dominio ya tendremos las máquinas preparadas para conectarse vía DirectAccess.

Como esquema rápido y pasos a seguir para la configuración, os dejo aquí esta imagen:

DirectAccess_Dominio_Offline.png
Voy a dividir la configuración en tres grandes pasos (por decir algo), pero que son muy fáciles. Lo primero que debemos hacer es provisionar los equipos que queremos añadir al dominio, para ello lo primero será crear las cuentas de equipo en nuestro dominio:

Desde la consola de Usuarios y Equipos de Active Directory, nos vamos a la OU en donde queremos crear las nuevas cuentas de equipos y pulsamos con el botón secundario del ratón y vamos a Nuevo – Equipo

DirectAccess_Dominio_Offline_13.png

Completamos los datos que nos solicita, básicamente el nombre del equipo

DirectAccess_Dominio_Offline_1.png

Si hemos configurado un grupo de seguridad para filtrar en DirectAcces a que equipos se les aplica la directiva de cliente, debemos modificar la membresía del equipo para que sea miembro del grupo al cual se le aplica la directiva de grupo

DirectAccess_Dominio_Offline_2.png

Esta es la GPO que se aplicará a los equipos que sean miembro del grupo ACL DA Equipos Remotos

DirectAccess_Dominio_Offline_4.png

En cuanto a la provisión del equipo ya estaría todo listo, ahora tendremos que hacer esto para todos los equipos que queramos añadir al dominio y aplicar la configuración de DirectAccess:

DirectAccess_Dominio_Offline_3.png

Ahora debemos ejecutar Djoin.exe en el controlador de dominio con derechos administrativos desde una línea de comandos, con esto crearemos un archivo .txt con los metadatos de la cuenta del equipo:

djoin /provision /domain <domain name> /machine <machine name of client> /policynames <Group Policy name for client settings> /rootcacerts /savefile <path for text file> /reuse

DirectAccess_Dominio_Offline_5.png

Con esto ya tenemos la mitad del proceso, ya tenemos nuestro fichero de texto con los metadatos necesarios para enviárselo a los usuarios itinerantes:

DirectAccess_Dominio_Offline_6.png

DirectAccess_Dominio_Offline_7.png

Ahora debemos enviar el fichero a los usuarios por algúna vía, pero busquemos algún método seguro para ello. Antes de que el usuario final pueda aplicar esta configuración, debe cumplir los siguientes requisitos:

  • El nombre del equipo se debe corresponder con el que hemos puesto en la provisión con Djoin.exe
  • Debe tener un usuario con derechos administrativos para poder aplicar la configuración con Djoin

Si vemos las opciones del Sistema, vemos que tenemos unido a ningún dominio pero el nombre del equipo ya establecido para ejecutar el Djoin.exe:

DirectAccess_Dominio_Offline_9.png

Y si vemos nuestra conexión de red, podemos obsevar que no tenemos conexión de DirectAccess (obvio)

DirectAccess_Dominio_Offline_8.png
Sí cumplimos con los requisitos, únicamente debemos ejecutar Djoin.exe desde una línea de comandos con privilegios:

djoin /requestodj /loadfile <path for text file> /windowspath c:\windows /localos

DirectAccess_Dominio_Offline_10.png

Una vez que hemos hecho esto, debemos reiniciar el equipo y ya tenemos nuestro equipo en el dominio y con la configuración de DirectAccess prepara para conectarse a la red de la empresa. Una vez que te se haya conectado mediante DirectAccess ya tenemos acceso a todos los servicios de la compañia. Si ahora volvemos a ver las opciones del Sistema podemos observar que ya estamos en el dominio:

DirectAccess_Dominio_Offline_12.png
Y que en nuestras conexiones de red ya vemos que tenemos DirectAccess y conectado!!!

DirectAccess_Dominio_Offline_11.png

De esta forma podemos unir al dominio todas las máquinas las cuales no tienen acceso al dominio de alguna forma (VPN, Red Local), un proceso sencillo y rápido.

Os dejo también otro enlace de como configurar DirectAccess en balanceo de carga con NLB:

Espero que os sea de utilidad!!!

GPO: Asignación de Sitios a Zonas en IE (20-01-2014)

enero 21st, 2014 | Posted by Santiago Buitrago in Directivas de Grupo - (0 Comments)

En la mayoría de las redes con tecnología Microsoft se suelen tener​ aplicaciones que utilizan Autenticación Intregrada, lo que permite que el usuario pueda autenticarse en ella de forma transparente. Por ejemplo, si tenemos una aplicación Web (SharePoint, CRM, OWA, etc..) con la autenticación integrada configurada, una vez hemos iniciado sesión en una máquina del dominio el usuario no tendrá que autenticarse de nuevo en la aplicación, puesto que enviará las credenciales con la que ha iniciado sesión. Para que el cliente pueda utilizar este tipo de autenticación y beneficiarse de ella, debemos configurar el Internet Explorer y añadir la URL en la zona de Intranet Local permitiendo así el inicio de sesión automático con el nombre de usuario y contraseña actuales (la sesión iniciada del usuario). La configuración por defecto de la Zona de Intranet Local es la siguiente en cuanto al Inicio de sesión

gpo_zona_Intranet_1.jpg
gpo_zona_Intranet_2.jpg

 
Esto es muy sencillo de configurar, creamos una GPO y editamos la siguiente opción: Configuración de usuario – Directivas – Plantillas Administrativas – Componentes de Windows – Internet Explorer – Lista de asignación de sitio a zona.
gpo_zona_Intranet_9.jpg
Solo tenemos que agregar a la izquierda la URL y a la derecha especificar la zona a la que corresponde (1 Zona de Intranet, 2 Sitios de Confianza, 3 Internet, 4 Sitios Restringidos)
 gpo_zona_Intranet_3.JPG
Ahora el usuario se conectaría a cualquier aplicación Web con autenticación integrada en el dominio asirlab.com  y no les solicitaría credenciales, accedería de forma transparente. Pero esta configuración tiene un problema, que el usuario NO podrá añadir más URL a ninguna de las zonas y esto no es muy operativo para nadie, ni para los usuarios ni para los administradores (depende cuales fuesen las necesidades claro está).  
gpo_zona_Intranet_4.jpg
 
Si queremos añadir distintas URL o Dominios a los sitios de Intranet (o cualquier otra zona) debemos crear las claves de registro "manualmente". Debemos añadir las URLs en la clave Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap, para ello creamos una GPO y vamos a Configuración de usuario – Preferencias – Configuración de Windows – Registro y ahí debemos crear la siguientes claves de registro para cada URL o Dominio:
 
El valor que establecemos identificará a cada una de las zonas (Internet, Intranet, Sitios de Confianza, Sitios Restringidos)
00000000 Equipo Local
gpo_zona_Intranet_18.jpg
00000001 Esta zona contiene todos los sitios web que se encuentran en la intranet de su organización (Intranet local)
gpo_zona_Intranet_14.jpg
00000002 Esta zona contiene sitios web que sabe no van a perjudicar el equipo o su información (Sitios de confianza)
gpo_zona_Intranet_15.jpg
00000003 Esta zona contiene todos los sitios web que no situó en otras zonas (Internet)
gpo_zona_Intranet_16.jpg
00000004 Esta zona contiene sitios web que potencialmente podrían perjudicar el equipo o su información (Sitios restringidos)
gpo_zona_Intranet_17.jpg
Por lo que si queremos añadir sitios de Intranet, debemos aplicar la siguiente configuración:
 
Clave: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\dominio
Valor: HTTP (HTTPS si es necesario)
Tipo: REG_DWORD
Información del valor: 00000001
gpo_zona_Intranet_10.jpg
Esto añadirá la url *.asirsl.com a los sitios de Intranet del usuario, pero como véis ahora le permite añadir más sitios en la zona y distintas zonas
gpo_zona_Intranet_12.jpg
(registro de la sesión del usuario) (yo lo tengo configurado para HTTPS, HTTP y FILE)
gpo_zona_Intranet_11.jpg
Ahora si abrimos el navegador para acceder a la URL  http://ca.asirlab.com accederemos sin solicitarnos credenciales, puesto que ya tenemos la url en Sitios de Intranet (la configuración por defecto de esta zona es que se autentiquen con el usuario y contraseña actuales)
gpo_zona_Intranet_7.jpg
Si ahora queremos añadir más dominios a los sitios de intranet podemos hacerlo sin problema
gpo_zona_Intranet_13.jpg
Estas configuraciones son a nivel de dominio completo, pero si quieres configurarlo para un subdominio (https://skydrive.live.com) sería de la siguiten forma:
gpo_zona_Intranet_19.jpg
 
Es bastante sencilla la configuración y nos permitirá añadir las distintas URL a las zonas del Internet Explorer desde una GPO, además de permitir que el usuario final pueda añadir más URL
 
Espero que os sea de utilidad!!!

DirectAccess: Error Network Location Server

diciembre 23rd, 2013 | Posted by Santiago Buitrago in Directivas de Grupo - (0 Comments)

El servicio de ubicación de red en DirectAccess es el encargado de determinar si estamos dentro o fuera de la red corporativa, de ahí la importancia del mismo. Si este servicio no está correctamente configurado los equipos con DirectAccess no tendrán acceso a los recursos internos de la empresa ..

DirectAccess_Error_Network_Location_Server_1.png
El problema viene dado porque el certificado no es el correcto (debe corresponderse con el nombre del servidor), que haya caducado, que no se pueda poner en contacto con la CRL o no está asociado a la interface correta. Teniendo esto en cuenta, únicamente debemos verificar que todo esto lo hemos chequeado y que todo está bien. Si hemos utilizado nuestra CA Internet (Windows Server 2012, Instalación de una CA) debemos configurar correctamente la URL de la publicación de la CRL y además que el cliente pueda tener acceso a él. En el certificado que nos presenta el servidor (el cual hemos configurado previamente) se indica cual es la ubicación de la CRL:
 
DirectAccess_Error_Network_Location_Server_5.png
Esta configuración en vuestra CA se realiza configurando las extensiones
DirectAccess_Error_Network_Location_Server_6.png
 
Una vez que habéis configurado correctamente las extensiones, que podéis resolver a nivel de DNS la URL en donde está la CRL , debemos volver a emitir un certificado al servidor de DiretAccess. Una vez que lo tenemos en el almacén de certificados de equipo local, vamos a configurarlo desde la consola de administración de DirectAccess:
DirectAccess_Error_Network_Location_Server_8.png
Pulsamos en Examinar
DirectAccess_Error_Network_Location_Server_7.png

y seleccionamos el certificado correcto que acabamos de emitir
DirectAccess_Error_Network_Location_Server_9.png

Finalizamos la configuración y desde la consola de administración de DirectAccess nos vamos a la opción Panel de Estado y podremos observar cuando termine de actualizar la configuración que se ha resuelto el problema
DirectAccess_Error_Network_Location_Server_2.png

Como podéis aprecicar no tiene mucha historia este "problema", siempre y cuando tengamos nuestra CA en condiciones a todos lo niveles.

 
Espero que os sea de utilidad!!!