Configuración ambiente híbrido Exchange 2013 con O365

Este artículo tiene como finalidad dar a entender cómo se realiza un ambiente híbrido entre la organización de Exchange Server 2013 on-premise con la plataforma de Exchange Online. Se entregarán detalles sobre los pre-requisitos necesarios para la implementación, y los pasos a seguir para una configuración exitosa.

Antes de comenzar con la implementación del ambiente híbrido, se deben cumplir ciertos requisitos, esto con el fin de mantener una plataforma dentro de las mejores prácticas.

  • Dominios verificados
  • Sincronización con el directorio
  • Certificado CA válida
  • Servicios de Exchange 2013 públicos
    • Autodiscover
    • EWS
  • Cuentas privilegios de administrador
    • Office 365
      • Global Administrator
    • On-premise
      • Enterprise Administrator
      • Domain Administrator
      • Schema Administrator
      • Organization Management

Sincronización con el directorio

Antes de comenzar, es necesario tener la plataforma de Office 365 sincronizada con el Active Directory on-premise, esta sincronización se logra a través de una herramienta llamada Azure AD Connect, la cual se obtiene desde el portal de office 365.

Dominios aceptados

Para poder coexistir la plataforma de Exchange on-premise con Exchange Online, es necesario verificar los dominios que se mantengan en la plataforma. Para lograr esto, desde la consola de administración de Exchange 2013, debemos dirigirnos al menú de organización y habilitar el federation trust.

11

Una vez habilitado, a través de PowerShell de Exchange debemos obtener el registro DNS para validar la autenticidad del dominio a través del script get-federatedDomainProof -DomainName <midominio.cl>.

Este script nos otorgará una visión del registro que necesitaremos ingresar en el DNS público para validar el dominio.

22

En el valor DnsRecord nos otorgará el nombre del dominio, el tipo de registro, el cual es un registro TXT, y el valor otorgado para el registro.

33

Una vez añadido el registro, podemos comenzar la configuración del ambiente híbrido.

Habilitar ambiente híbrido

Para poder habilitar el ambiente híbrido, una vez realizado los pasos anteriores, desde la consola de administración de Exchange 2013, en el menú de hybrid habilitaremos la configuración dando click en enable.

44

Solicitará iniciar sesión en Office 365 con credenciales de Administrador Global.

55

Una vez iniciada sesión, nos descargará el Hybrid Configuration Wizard (HCW), el cual debemos instalar en una máquina que se encuentre dentro de la red de los servidores, de esta forma detectará automáticamente los servidores óptimos a utilizar.

66

77

Luego de seleccionar el servidor de Client Access a utilizar, debemos dar click en next y nos solicitará credenciales con privilegios de administrador de la plataforma on-premise y cloud.

88

Es necesario que estas cuentan cumplan con los roles de administradores específicos, ya que serán verificadas para poder continuar con la configuración.

99

Una vez validadas las cuentas, se seleccionará el servidor que se utilizará para la seguridad de transporte de correos entre las plataformas, esto puede realizarse a través de un servidor de Client Access o de un servidor de Edge Transport.

10

111

Nota: En caso de utilizar un servidor de Client Access, la configuración es exactamente la misma.

Para finalizar con la configuración, se debe seleccionar el certificado de una CA válida, el cual será utilizado para crear una conexión segura entre ambas plataformas y el nombre con el cual los servicios EWS fueron publicados, por ejemplo mail.midominio.cl.

222

333

Una vez finalizado el HCW podremos acceder a la consola de administración de Exchange Online, a través de la misma consola de Exchange 2013.

444

Y desde el menú de organization podremos ver que se está compartiendo la información con Exchange Online.

555

Ernesto León, Consultor Infraestructura, Blue Solutions.

Advertisements

Servidor KMS Windows Server 2008 R2

KMS es un servicio que permite que se activen los sistemas operativos de la red desde un servidor donde se haya instalado el servicio de KMS. Con KMS se elimina la necesidad de activar de manera individual cada uno de los equipos. KMS no requiere un sistema dedicado y se puede hospedar en un sistema que también proporcione otros servicios. Las ediciones por volumen de los sistemas operativos de servidor y cliente de Windows se conectan de forma predeterminada a un sistema que hospeda el servicio KMS para solicitar la activación.

a) Instalación de servicio KMS

El proceso de instalación, en un servidor Windows 2008 R2 es el siguiente:

  1. Clic derecho sobre Command Prompt y ejecutar como administrador
  2. En la consola de comandos escribir cd C:\Windows\system32 y luego presionar la tecla enter
  3. Ejecutar cscript.exe slmgr.vbs /ipk KMS-Host-Key, donde KMS-Host-Key es la clave KMS para el sistema operativo que se desea activar, esta clave KMS no es una licencia estándar de Windows ni una licencia MAC, es una licencia especial para este tipo de servicios. Además la licencia para el servicio de KMS no puede ser una licencia de Windows 8 o superior, para eso existe desde Windows server 2012 R2 un servicio llamado Active Directory-Based.

A2

a.1) Habilitación de servicio en Firewall de Windows

Para que el servicio atienda a los clientes, debe permitirse en el firewall de Windows del servidor donde instalaremos el servidor de KMS, para esto realizaremos las siguientes configuraciones en el firewall.

  1. Clic en Windows Firewall
  2. Clic en Allow a program of feature trough Windows Firewall
  3. Clic en Key Management Service y luego marcar la columna de Domain
  4. Clic en OK

Debe quedar configurado como muestra la imagen.

a3

a.2) Creación de registro DNS

Para que los equipos clientes puedan encontrar al servidor que provee la activación en la red interna, se debe crear un registro DNS de tipo SRV. Por omisión los clientes buscarán este registro y solicitarán la activación al servidor correspondiente.

Para crear el registro DNS:

  1. Ingresar al servidor DNS
  2. Abrir la consola DNS
  3. Expandir Forward Lookup Zones
  4. Expandir la zona DNS correspondiente al dominio de los equipos.
  5. Clic derecho sobre _tcp y clic en Other New records
  6. En la lista hacer clic sobre Service Location (SRV) y luego en botón Create Record
  7. Llenar los siguientes campos:
    1. Service = _VLMCS
    2. Protocol = _tcp
    3. Priority = 0
    4. Weight = 0
    5. Port Number = 1688
    6. Host offering this service = “nombre fqdn del servidor kms, por ejemplo: KMS.Contoso.com”
    7. Clic en OK

La habilitación del servicio de KMS hasta Windows server 2008 R2 es algo compleja pero útil, si bien no presenta la misma simplicidad de la interfaz gráfica que su actual actualización en Windows server 2012, KMS en Windows server 2008 R2 cumple a la perfección con la necesidad de aplicar licenciamiento a los equipos en el entorno de red, y no necesita hardware adicional.

Ernesto León, Consultor Cloud, Blue Solutions.

Síganos en LinkedIn Blue Solutions Chile.

 

 

 

6 Tips para troubleshooting de AD DS

1.- Determinar la salud del DNS

Lo primero que debemos determinar cuándo realizamos una asesoría en AD es la salud del DNS. Una falla en el DNS puede causar muchos problemas en la autentificación, fallo en las aplicaciones, exchange, replicaciones, problemas de respuesta en LDAP, entre otros.

Como describimos anteriormente la revisión del DNS es crítica, para poder determinar el estado de salud de la plataforma, detallaremos unos CMDLET para complementar el Dcdiag.exe, el cual es:

dcdiag /test:DNS /e /v

La opción /e indica que la prueba correrá en todos los servidores de DNS, y /v indica una salida detallada de texto para el resultado de esta prueba. En un ambiente amplio, esto puede tardar un tiempo, pero vale la pena esperar.

Siempre comienzo leyendo desde el final del reporte, donde aparece una tabla como table 1. DCdiag ejecuta 6 pruebas diferentes: Authentication (Auth), Basic Connectivity (Basc), Forwarders (Forw), Delegation (Del), Dynamic Registration Enabled (Dyn) y Resource Record Registration (RReg). La tabla además lista la prueba de External (Ext), la conexión a internet, pero este comando no realiza esa prueba.

Captura de pantalla 2016-01-28 a la(s) 16.59.57

En la salida de la tabla 1, muestra cada servidor DNS (El cual usualmente también son los Domain Controlers) del bosque listado por dominio. Lo bueno de eso es que muestra la configuración de dominio del bosque, la cual es de mucha ayuda si eres consultor o ingeniero de soporte y no estas familiarizado con la infraestructura. En los datos de lectura de la tabla, los resultados son:

  • PASS: El servidor DNS completa el test.
  • FAIL: El servidor DNS falla el test.
  • N/A: La prueba no fue ejecutado. Esto ocurre generalmente por una falla en alguna prueba anterior, por lo que no tiene sentido realizar una prueba sobre un servicio que ya sabe que está fallando.

En la tabla 1 podemos ver el valor de esta prueba. Inmediatamente podemos ver los lugares conflictivos. En un bosque de multiple dominio, debes ejecutar este comando con credenciales de Enterprise Admin, u obtendrás resultados fallidos en todas las pruebas de los servidores DNS por que no tienes los privilegios suficientes. Esto es lo que sucede para el dominio EMEA en la tabla 1.

Al termino del reporte se presenta una lista completa de las fallas, donde se pueden ver todos los detalles. Por ejemplo puedo ir a la parte superior del reporte y buscar por Corp-DC02, y obtener los detalles que son mostrados en figure 1.

En este primer paso se presenta muy buena información, se puede construir la configuración del DNS Resolve para cada servidor DNS. Lo principal en este paso, es que se muestra el porque la prueba de Forwarder nos entregaba N/A en la tabla 1. Usando este método podemos elegir el camino entre los resultados “warning”, “failure” y “N/A” de la tabla 1. Y por supuesto lo mejor de todo esto, es que tienes la información de todos los servidores DNS del bosque en un archivo, generado por un solo comando.

Captura de pantalla 2016-01-28 a la(s) 17.03.19.png

2.- Determinando la salud de la replicación del AD

 La herramienta de soporte para Windows Server incluye la opción en Repadmin llamada /replsum. Similar al comando DCdiag /test:dns del Tips 1, /replsum colecciona la información de replicación de todos los DC del bosque. Esto muestra el reporte de en qué momento ocurre la replicación entre los DC, el comando debe ser ejecutado en cada uno de los DC del bosque. Aquí están las opciones más usadas:

Repadmin /replsum /bysrc /bydest /sort:delta

  • /bysrc indica la colección de datos de los DC que han replicado en otros DC.
  • /bydest indica la colección de datos de los DC que han replicado en otros DC.
  • /sort:Delta muestra los resultados en orden decendiente

Un ejemplo de esto se ve en table 2. Aquí se muestran seis DC y gracias a delta se muestran por orden de su última replicación. Aquí podemos ver fácilmente la salud del dominio, excepto para WTEC-DC2, el cual no ha sido replicado de hace cinco días, que arroja el error 1722. Yo sé que este DC se encuentra apagado ya que está siendo movido a un nuevo Data Center.

Captura de pantalla 2016-01-28 a la(s) 17.06.49

3.- Detalle de replicación para todos los DC del bosque.

 Esta técnica (similar a la del tips número 2) nos entrega mayor detalle. El comando es /repadmin /showrepl * /csv>showrepl.csv. Esta opción de salida en formato CSV, como se muestra en table 3.

Me gusta este comando por que frecuentemente muestra un error en mayor detalle qué el comando /replsum. Además, ofrece un reporte de distintos errores (o errores adicionales, código de error y más) y especifica los datos que /replsum no entrega.

Captura de pantalla 2016-01-28 a la(s) 17.08.03

4.- Diagnóstico NTDS

Este punto es esencial para obtener información adicional de los datos en el visor de eventos de Directory Service (DS). Está habilitado por registro en HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NTDS\Diagnostic. Es bastante sencillo. Aquí hay una variedad de atributos que, cuando son habilitados entregan información adicional en los logs de eventos para ayudarte en las tareas de troubleshooting. Los datos válidos de estos registros es una variable de 0 a 5. El valor por defecto es 0, significando una entrega de datos mínima, y añadiendo 5 entrega más datos de los que quieres. Generalmente configuro 3 y reviso si es que llegase a necesitar más información. En ciertos casos, si necesito mayor detalles en la replicación, al valor de “5 replication event” lo cambio a 3, para reproducir el problema. Asegúrate de cambiar el valor a 0 cuando las labores de troubleshooting finalicen.

Los valores más comunes que utilizo son:

  • 1 Knowledge Consistency Checker
  • 10 Performance Counters
  • 13 Name resolution (Relacionado con el DNS)
  • 15 Field Engineering
  • 18 Global Catalog
  • 2 Security Events
  • 5 Replication Events
  • 8 Directory Acces
  • 9 Internal Processing

El valor 9 Internal Processing es útil para obtener información adicional sobre el DS event, esto indica que error interno está ocurriendo. Esto a menudo muestra eventos adicionales que ayudarán en el diagnóstico del problema. Es común añadir un valor mayor a 1. Realizando troubleshooting de replicación, es buena idea habilitar el valor 1 Knowledge Consistency y 5 Replication Events.

El valor 15 Field Engineering entregará diversa información adicional a los logs de DS. A diferencia de los otros diagnósticos, este debe ser ajustado a cinco para que entregue información relevante. Específicamente, esto genera los eventos 1644 y 1643, que mostrarán la ineficiencia en las consultas a LDAP, incluyendo a los clientes que generan las consultas, el tipo de consulta, y la raíz de la consulta. Esto es importante, ya que uno de los dolores de cabeza relacionados con el AD, es el proceso Local System Authority Subsystem Services (LSASS), que se encuentre utilizando suficientes recursos para colgar, o crashear nuestro DC, causando una lentitud en el ingreso del usuario. Una ineficiencia en las consultas a LDAP de parte de los usuarios o aplicaciones puede suponer una enorme carga en LSASS. Habilitando este diagnóstico podemos identificar de manera más rápida al culpable según su nombre o dirección IP. Algunos administradores dejan este diagnóstico habilitado permanentemente en organizaciones ocupadas, pero de nuevo, esto llenará nuestros logs de eventos, y posiblemente esconda o sobre escriba otros eventos importantes en los logs de DS.

5.- Reportes HTML y consola de administración de políticas de grupo.

Seguramente todos los administradores de AD han usado esta herramienta en algún momento, pero pensé que valdría la pena mencionar los valores de los reportes HTML. Aquí hay dos tipos de reportes que uso frecuentemente cuando trato con entornos con los cuáles no estoy familiarizado y por lo general quiero probar las configuraciones de las Group Policy Object (GPO), así como los resultados en un cliente en particular o clientes.

Obtener un reporte de las GPO es valioso, incluso si eres el administrador de la plataforma, ya que muestra exactamente las configuraciones definidas (de hecho, solo muestra las configuraciones definidas), por lo que no tendrás dificultades para investigar en el editor de políticas para encontrar las que se encuentran establecidas. Esta es una manera rápida de ver si la GPO está definida como esperas que lo esté. Incluso muestra los links, filtros aplicados y otros detalles. Los reportes HTML para la Default Domain Policy son simples de leer y pueden ser expandidos o cerrados por sección según lo necesites, ya que se encuentran en formato HTML. Para obtener este reporte, de click derecho sobre la GPO y selecciona “save report”.

Uno de los problemas a solucionar en las GPO está relacionado con un cliente el cuál molesta al usuario, quien se encuentra a cientos de kilómetros de distancia para ingresar y obtener un GPOResult. Si el usuario ha ingresado en al menos una estación de trabajo, la consola de administración de políticas de grupos (GPMC) puede entregar con un formato HTML el resultado del GPResult que se produce cuando el usuario ingresa.

6.- Diagnóstico de rendimiento para Active Directory.

Si bien hay muchos otros tips para troubleshooting que pude haber añadido, este es uno que probablemente, no del todo conocido. En el troubleshooting del rendimiento de los servidores, hay un conjunto estándar de objetos, incluidos el procesador, disco lógico, memoria del servidor, sistema y así entre otros. Sin embargo hay un objeto de NTDS que nos proporciona contadores relevantes del AD como, DRA, Kerberos, LDAP y contadores incluso relacionados con eventos en NTLM. Además podemos recopilar valores importantes de los datos de nuestro AD mediante el monitoreo de los procesos de LSASS. Recomiendo habilitar los siguientes:

  • Object: Process
    • Contadores: % de tiempo de procesado, conjunto de trabajo, y pico de conjunto de trabajo.
  • Object: NTDS
    • Contadores: Todos los contadores.

Desafortunadamente hay poca información disponible dentro de lo aceptable. El más útil encontrado es la guía de implementación para la rama de Microsoft Office. Si bien hay muchos contadores y puedes o no estar familiarizados con ellos, aquí hay algunos significados.

  • DRA Pending Replication Synchronization: Este es el directorio de sincronización de las colas y los retrasos en la replicación, Microsoft dice que estos valores deben ser lo más bajo posibles y que el hardware está retrasando la replicación. Estos son indicios de que los recursos del DC tienen un alto porcentaje de utilización.
  • LDAP Cliente Sessions: Este es el número de sesiones abiertas simultáneamente por clientes LDAP. Esto es útil para determinar la actividad de los clientes de LDAP y si el DC está habilitado para soportar esa carga. Por supuesto los picos se registran durante la autenticación de los clientes lo cual no es un problema necesariamente, pero en largos periodos los altos valores significan un exceso de trabajo para el DC.
  • LDAP Bind Time: Este es el tiempo en milisegundos que es necesario para completar la unión de LDAP. La documentación de Microsoft indica que esto debe tener el menor tiempo posible, pero si corres un análisis a través de los logs de análisis de rendimiento (PAL), indicara 15 sobre milisegundos como un warning, y sobre 30 como un error.

En el diagnóstico de procesos LSASS, como en cualquier análisis de rendimiento, debe haber una base establecida. Una nota en el DS blog de Microsoft indica que si una base no está establecida, debe ser utilizado el 80%. Es decir los contadores LSASS no deben superar el 80% de consumo, ya que sobre el 80% indicará una sobre carga, lo que podrá traer una alta demanda de consultas a LDAP, o la falta de recursos en el servidor. La solución es aumentar los recursos del servidor, o disminuir la demanda de consultas, pero tenga en cuenta que el alto uso de recursos puede causar un impacto en el rendimiento del dominio.

Si desea solucionar problemas de recursos, utilize una plataforma x64 en los DC, con diversos procesadores, y 32GB de Ram. Es sorprendente cuanta memoria realmente puede utilizar los recursos LSASS.

Espero que estos tips sean de gran utilidad a la hora de realizar un troubleshooting de AD DS.

Ernesto León, Técnico en Soporte, Blue Solutions.

¿Cómo se debe configurar el SPN para la migración de File Server?

No hay migración de servicios que no esté acompañada de dolores de cabeza. Especialmente si son servicios críticos para las organizaciones, como es el caso de los servidores de archivos.

Nunca hay que creer cuando comentan que la migración de un File Server es solo mover los archivos de un lugar a otro usando Robocopy y luego hacer el cambio en el servidor DNS para que siga conservando el mismo nombre que el servidor de origen y el cambio sea transparente a los usuarios.

Antes de explicar el cambio de SPN, me gustaría que se entendiera el concepto de SPN en su definición más fundamental.
SPN viene de la sigla de Service Principal Name.
Éstos deben estar asociados a un objeto de Active Directory (cuenta de usuario, grupo o computador) en el cual el servicio se ejecuta. Su función principal es soportar la autenticación mutua entre un cliente y un servicio.

Entonces, la configuración de un SPN consiste en la asociación de un servicio a un objeto de AD. Un objeto de AD puede tener varios SPN asociados, pero un SPN solo puede estar asociado a un objeto de AD. En el caso de que se duplique un SPN, vendrán los problemas.

Cuando se realiza una migración de File Server y posteriormente se hace el cambio en el DNS para que el antiguo servidor apunte al nuevo y se intenta acceder a la ruta, el visor de eventos mostrará un error así:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SRV-NUEVO$. The target name used was cifs/SRV-VIEJO. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMINIO.CL) is different from the client domain (DOMINIO.CL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server. 

Como el SPN no estaba configurado de forma correcta, no es posible hacer ni mantener la autenticación, por lo tanto, da error.

Para configurar el SPN, se debe hacer con una cuenta con privilegios sobre el dominio.

Eliminando un SPN
Antes de asignar un SPN a un objeto, hay que eliminarlo  del objeto al cual estaba asignado. Se debe seguir la sintaxis:
setspn -D servicio/host ObjetoAD Por ejemplo:

setspn -D host/srv-viejo.midominio.cl srv-viejo

setspn -D host/srv-viejo srv-viejo
setspn -D cifs/srv-viejo.midominio.cl srv-viejo
setspn -D cifs/srv-viejo srv-viejo

De esta forma se elimina los SPN asociados al file server del objeto srv-viejo.

Asociar un SPN
Una vez desasociados los SPN al antiguo objeto, se debe asociar al nuevo objeto. La sintaxis es:
setspn -S servicio/host ObjetoAD Por ejemplo:

setspn -S host/srv-viejo.midominio.cl srv-nuevo
setspn -S host/srv-viejo srv-nuevo
setspn -S cifs/srv-viejo.midominio.cl srv-nuevo
setspn -S cifs/srv-viejo srv-nuevo

De esta forma, el servicio podrá autenticar y mantener la autenticación. El recurso compartido es accesible desde los clientes. Hay que tener un especial cuidado con los clientes con Windows XP. Por que aparte de configurar los SPN correspondientes, también hay que hacer un cambio en el editor del registro de Windows. Seguir la documentación de este link: https://support.microsoft.com/en-us/kb/281308

Más información sobre la herramienta setspn se puede encontrar en: https://technet.microsoft.com/en-us/library/cc961723.aspx

Podemos concluir que las migraciones de File Server, no son tan sencilla ni con pocos pasos como afirman algunos, hay que realizarlas de manera cuidadosa para no incurrir en errores.

Maximiliano Marín, Consultor de Infraestructura, Blue Solutions.