Office 365 | Planificación de ancho de banda de internet

Hay muchos factores que intervienen en la migración hacia Office 365. Cada organización tiene experiencia y su diferencia se basa en la configuración de su correo actual. El entorno de Exchange existente tiene que estar en algún estándar o cumplir con algunos criterios antes de empezar a moverse a Office 365.  A continuación, se detallan algunos pasos previos antes de realizar cualquier tipo de implementación de Office 365.

Estimando uso de ancho de banda

Hay varias variables que debemos considerar cuando estimamos el tráfico de la red. Algunas de éstas son:

  • Ofertas de Servicio que la organización está suscrito al Servicio de Office 365.
  • Cantidad de estaciones de trabajo conectadas al mismo tiempo.
  • El tipo de tarea de cada equipo cliente se está
  • El rendimiento del software del navegador de Internet.
  • La capacidad de las conexiones de red y segmentos de red asociados a cada equipo cliente.
  • Topología de red de la organización y la capacidad de los distintos elementos de hardware de red.

Calculadoras de ancho de banda que debe utilizar para Office 365

Hay calculadoras disponibles que ayudan con la estimación de los requerimientos de ancho de banda de la red. Estas calculadoras trabajan en las instalaciones, así como despliegues de Office 365. Se puede utilizar la calculadora de ancho de banda de red de cliente de Exchange para estimar el ancho de banda requerido para un conjunto específico de Outlook, Outlook Web App, y los usuarios de dispositivos móviles para la implementación de Office 365. Con la calculadora de 2010 y 2013 de ancho de banda de Skype for Business Server, se introduce la información sobre los usuarios y el Skype for Business Online las prestaciones que desea implementar, dicha calculadora le ayuda a determinar los requisitos de ancho de banda.

  • Exchange Client Network Bandwidth Calculator
  • Lync 2010 and 2013 Bandwidth Calculator
  • OneDrive for Business Synchronization Calculator

Prueba de velocidad de migración

Las pruebas y la validación del ancho de banda de Internet (descarga, carga, y las limitaciones de latencia) son vitales para la comprensión de cómo lograr la migración de alta velocidad de contenido de buzones de correos locales a Office 365 y ambientes de Exchange Online. La conectividad lenta o latente, reduce el número de migraciones de buzones que se pueden realizar durante una ventana de la migración. Asegúrese de realizar los siguientes pasos:

  • Prueba y confirmación que el ancho de banda de Internet de la organización puede gestionar el impacto de red         en migraciones de Office 365
  • Evaluar la disponibilidad de ancho de banda de red interna para eventos de migración de Office 365.
  • Hacer uso de herramientas de red disponibles, tales como:

– Microsoft Network Monitor – Permite capturar el tráfico de red, verlo y analizarlo. Buscar HTTPS/ SSL, tiempos de espera ajustados, muy bajo en Proxy / Firewall / Router y transmisiones excesivas.

– Microsoft Remote Connectivity Analyzer – Chequea la conectividad del ambiente de Exchange Online.

– Office 365 Network Analysis Tool – Ayuda a analizar los problemas relacionados con la red antes de la implementación de servicios de Office 365: Norteamérica: http://na1-fasttrack.cloudapp.net / EMEA: http://em1-fasttrack.cloudapp.net / APAC: http://ap1-fasttrack.cloudapp.net

– Determinar su carga, descarga y latencia entre su control local y el centro de datos de servicios cloud Microsoft más cercano. Las siguientes actividades pueden ayudar en esta tarea: Ping a outlook.com para determinar la dirección IP del centro más cercano a Microsoft datos de los servicios en la nube desde su ubicación. / Consulte a un sitio web de mapas IP de terceros (por ejemplo, iplocation.net) para determinar la ubicación de ese centro de datos. / Use un sitio web prueba de velocidad (por ejemplo speedtest.net) para determinar la carga, descarga y las estadísticas de la latencia entre su entorno local y la ubicación más cercana al centro de datos de servicios cloud Microsoft. / Determinar los períodos en los que el sistema local de Exchange se utiliza en gran medida (por ejemplo, durante las copias de seguridad).

Estrategias para mejorar la velocidad de migración

Para mejorar la velocidad de migración, así como reducir las limitaciones de ancho de banda de su organización, se debe considerar lo siguiente:

  • Reducir el tamaño de los buzones. Mientras más pequeño sea el tamaño del buzón, aumenta la mejora de la               velocidad de migración.
  • Limpieza de carpetas públicas – asegúrese de la limpieza de su público para cumplir con el buzón de                          carpetas públicas en Office 365.
  • Utilice la capacidad de movimiento de buzones con una implementación híbrida de Exchange. Con una                      implementación híbrida de Exchange, el correo sin conexión (.ost) no requiere volver a descargar al migrar a              Exchange Online. Esto reduce significativamente los requisitos de ancho de banda de descarga.
  • Horario del buzón, se mueve al ocurrir períodos de tráfico de Internet y una baja utilización de Exchange                    local. Al programar movimientos, entender que las solicitudes de migración son enviadas al proxy de                          replicación de buzón y pueden no tener lugar inmediatamente.

Para más detalles respecto a la migración, revisar el siguiente link http://go.microsoft.com/fwlink/?LinkId=393510

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Microsoft Advance Threat Analytics

Microsoft Advance Threat Analytics (ATA) es una herramienta enfocada a la seguridad de la plataforma de Active Directory para detectar en tiempo real amenazas, y acciones sospechosas sobre el dominio.

¿Qué es ATA?

Microsoft ATA es una plataforma de seguridad para Active Directory con el fin de detectar amenazas. ATA toma información de los eventos y registros de la red con el fin de aprender comportamiento de los usuarios u otras entidades creando un perfil de comportamiento.

ATA aprovecha un motor de análisis sobre la red para capturar y analizar el tráfico de red de diversos protocolos (Kerberos, DNS, NTLM entre otros), ATA obtiene información de las siguientes maneras:

  • Creación de reflejos de puertos en los DC y servidores de DNS directos hacia la puerta de enlace de ATA.
  • Implementación de ATA Light Gateway (LGW) en los DC.

ATA nos permite detectar actividades sospechosas centrándose en:

  • Reconocimiento
  • Desplazamiento lateral
  • Dominio del dominio (persistencia)

Ademas de actividades sospechosas, ATA permite detectar ataques malintencionados como cuales:

  • Pass-the-Ticket (PtT)
  • Pass-the-Hash (PtH)
  • Overpass-the-Hash
  • PAC falsificado (MS14-068)
  • Golden ticket
  • Replicaciones malintencionadas
  • Reconocimiento
  • Fuerza bruta
  • Ejecución remota

Arquitectura de ATA

ATA analiza el tráfico de red de los controladores de dominio mediante el uso de la creación de reflejo de puerto a una puerta de enlace de ATA con conmutadores físicos o virtuales, o implementando la puerta de enlace ligera de ATA directamente en los controladores de dominio. ATA puede sacar provecho de los eventos de Windows (reenviados directamente desde los controladores de dominio o desde un servidor SIEM) y analizar los datos en busca de amenazas y ataques.

1

Arquitectura de ATA

El siguiente diagrama muestra el flujo de red, captura de eventos y explorar en profundidad para la funcionalidad de los componentes de ATA.

2

Componentes de ATA

  • El ATA Center recibe datos de cualquier puerta de enlace de ATA o puerta de enlace ligera de ATA que implemente.
  • El ATA Gateway se instala en un servidor dedicado que supervisa el tráfico de los controladores de dominio mediante la creación de reflejo del puerto o un TAP de red.
  • La ATA Light Gateway se instala directamente en los controladores de dominio y supervisa el tráfico directamente, sin necesidad de un servidor dedicado ni de una configuración de creación de reflejo del puerto. Es una alternativa a la puerta de enlace de ATA.

ATA Center

El ATA Center cumple la función de administras la configuración de los Gateway de ATA, recibir datos desde los ATA Gateway, detectar actividades sospechosas, ejecutar algoritmos de aprendizajes de comportamiento. El ATA Center recibe el tráfico analizado por el ATA Gateway y la ATA Light Gateway, genera perfiles, lleva a cabo una detección determinista y ejecuta el aprendizaje automático.

ATA Gateway y ATA Light Gateway

El ATA Gateway cumple la función de captura y análisis del tráfico de red en los controladores de dominio, recibir eventos de servidores de Syslog o SIEM, recuperar datos sobre usuarios y dispositivos del dominio, realizar tareas de resolución de objetos y transferir los análisis hacia el ATA Center.

ATA es una herramienta la cual llegó para dar fin a la problemática de seguridad especial para Active Directory, considerando la importancia de esta solución (AD) y que es esencial para el resto de las soluciones Microsoft mantener un control sobre AD era una tarea difícil, con la implementación de ATA en su plataforma, podrá mantener control sobre cualquier tipo de ataque, actividades sospechosas e incluso comunicación entre servidores y AD.

Ernesto León, Consultor Infraestructura, Blue Solutions.

 

Migración de una entidad certificadora desde Windows Server 2003 hacia Windows Server 2012

La migración de una CA de Microsoft es una actividad sencilla, pero debe llevarse a cabo de forma meticulosa, los tiempos de migración y la complejidad de ésta van a ir variado según el entorno al que nos enfrentemos. El primer paso es hacer el backup de la base de datos de la CA y de las configuraciones almacenadas en al registry.

Iniciar sesión en el servidor de origen, luego iniciar la consola de administración de la CA. Hacer click derecho sobre el nodo con el nombre de la CA, luego dirigirse a la opción All Tasks, luego hacer clic sobre Back Up CA.

1

En la sección Welcome to the Certification Authority Backup Wizard, presionar el Next.

2

En la sección Items to Back Up seleccionar Private Key and CA Certificates y Certificate database and certificate database log, luego seleccionar la ubicación en el campo Back up to this location y presionar Next.

3

En la sección Select a Password ingresar la contraseña para proteger la clave privada, presionar Next.

4

En la sección Completing the certification Authority Backup Wizard presionar Finish.

5

NOTA: Verificar que en la ruta seleccionada, existan los siguientes archivos: certbkxp.dat, edb#####.log, and CAName.edb

Desde la consola de comandos ejecutar “net stop certsvc.

6

NOTA: El servicio debe ser detenido para evitar la emisión de certificados adicionales.

El siguiente paso es exportar las claves de registro, para realizar esto desde el menú Run… ejecutar el comando regedit. Navegar hacia la clave HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesCertSvc hacer click derecho sobre Configuration y hacer click en la opción Export. Seleccionar como destino la misma carpeta donde se realizó el backup de la CA, ingresar el nombre del archivo y presionar Save.

7

NOTA: Si la CA de origen usa un archivo CAPolicy.inf personalizado, se debe copiar el archivo en la misma ubicación que los archivos de copia de seguridad fuente de CA.

El archivo CAPolicy.inf se encuentra en el directorio %SystemRoot%, que suele estar en C:Windows.

Copiar la carpeta donde se realizaron los backups al nuevo servidor. Luego desinstalar la CA desde Add/Remove Windows Components Wizard, unir el servidor a un workgroup.

El siguiente paso es la instalación y configuración del rol AD-CS. Una vez instalado el rol AD-CS resta realizar la configuración del rol, para esto desde la consola Server Manager hacer click sobre el icono de notificaciones luego en el enlace Configure Active Directory Certificate Services on the destination server.

8

En la sección Specify credentials to configure roles services presionar Next.

9

En la sección Select Role Services to configure, seleccionar el rol Certification Authority luego presionar Next.

10

En la sección Specify the setup type of the CA seleccionar el mismo tipo de CA que la de origen, presionar Next.

11

En la sección Specify the type of the private key seleccionar la opción Use existing private key luego seleccionar la opción Select a certificate and use its associated private key, presionar Next.

12

En la sección Select an existing certificate for this CA, presionar el botón Import luego presionar el botón Browse… y navegar hasta la ruta donde se encuentra el certificado exportado. En el campo Password ingresar la contraseña para poder acceder a la clave privada por último presionar Next.

13

14

En la sección Specify the database locations verificar la ubicación de la base de datos y del log, presionar Next.

15

En la sección confirmation presionar el botón Configure.

16

En la sección Results presionar Close.

El siguiente paso es restaurar la base de datos de la CA de origen en el servidor de destino. Para llevar adelante esta tarea, ejecutar los siguientes pasos.

Iniciar sesión en el servidor de destino, iniciar la consola de administración de AD-CS hacer click derecho sobre el nodo con el nombre de la CA, dirigirse a la opción All tasks luego a la opción Restore CA…

17

Presionar el botón OK en la ventana que alerta sobre la detención del servicio AD-CS.

18

En la sección Welcome to the Certification Authority Restore Wizard presionar Next.

19

En la sección Items to restore seleccionar la opción Certificate database and certificate database log, luego presionar el botón Browse… y navegar hasta donde se encuentra la carpeta con el backup de la CA de origen, por último presionar Next.

20

En la sección Completing the Certification Authority Restore Wizard presionar Finish.

21

En la ventana Certification Authority Restore Wizard presionar el botón Yes para iniciar el servicio AD-CS.

22

El último paso en esta migración, es importar las claves de registro, antes de hacer esta tarea es importante revisar los siguientes valores, los cuales deben coincidir con los valores de la nueva instalación.

Estos valores de la ubicación del almacenamiento son elegidos durante la configuración de la CA. Estos existen en la clave del Registro de configuración:

  • DBDirectory
  • DBLogDirectory
  • DBSystemDirectory
  • DBTempDirectory

Los siguientes valores en la clave del Registro de configuración{nombre}CA contienen, en sus valores por defecto una ruta local. (Como alternativa, se puede actualizar estos valores después de importarlos mediante el uso de la consola de administración de CA. Los valores se encuentran en la solapa CA properties Extensions).

  • CACertPublicationURLs
  • CRLPublicationURLs

Iniciar la consola de comandos con privilegios de administrador, ejecutar el comando net stop certsvc.

23

Luego ubicados en la carpeta donde se encuentra el archivo .reg que queremos importar ejecutar el comando reg import < nombredearchivo.reg >

24

Por último ejecutar el comando net start certsvc para iniciar el servicio.

25

Con esto podemos finalizar la migración de la CA, finalmente pueden validar el funcionamiento de esta entidad certificadora, integrándolo con algún servicio web o similares para la distribución de certificados.

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.

 

Introducción a Planner

Office 365 Planner ofrece a la gente una manera sencilla y muy visual para organizar el trabajo en equipo. Planner hace que sea fácil para su equipo crear nuevos planes, organizar y asignar tareas, compartir archivos, chat acerca de lo que está trabajando, y obtener actualizaciones sobre el progreso. Planner puede utilizarse para gestionar un evento de marketing, nuevas ideas de productos, seguimiento de un proyecto del colegio, prepararse para una visita al cliente, o simplemente organizar su equipo de manera más eficaz.

Equipo de trabajo organizado

Uno de los aspectos más valiosos de Planner, es que ayuda a los equipos a organizar su trabajo visual. Cada plan tiene su propia tabla, y dentro de cada tabla, cada elemento de trabajo o tarea está representada por una tarjeta que puede tener fechas de vencimiento, los accesorios, las categorías y las conversaciones asociadas con ella. Los miembros del equipo reciben una notificación por correo electrónico cada vez que se les asigna una nueva tarjeta o añadirse a una conversación.

Cada tarjeta puede tener documentos (o imágenes) adjuntos que llegan de forma automática, vistas previas de imágenes, por lo que es fácil de entender la tarjeta de un solo vistazo. Además, éstas se pueden organizar en la Junta en columnas personalizadas llamadas Cubos, que pueden ser priorizadas y etiquetadas de colores.

Trabaja muy bien con todos los productos de Office 365

Como parte de Office 365, Planner está integrado con otros servicios de Office 365, grupos de Office 365, todas las conversaciones en Planner están disponibles en Outlook 2016, Outlook en la Web y las aplicaciones móviles de Outlook.

Planner es también una forma ideal para organizar sus archivos de Office (ofimática). Adjuntar los documentos de Word, Excel y PowerPoint en una tarjeta y comenzar la edición de forma inmediata. Cuando un documento se adjunta a una tarjeta, se almacena en una biblioteca de documentos de SharePoint en línea, que le permite trabajar en ellos de forma Off Line.

¡Ya se encuentra disponible!

Oficina 365 Planner estará disponible en la vista previa de Office 365 (portal nuevo). EL primer lanzamiento será a partir del próximo trimestre, por lo que deben mantener de forma constante una revision en el nuevo portal de Office 365 chequeando que ya este cargado en sus Tenants.

Luis Arancibia, Consultor Cloud, Blue Solutions. 

 

Proteger todas las OU a la vez contra eliminación Accidental

Cada administrador de Active Directory debe saber que existe una configuración por defecto desde que apareció RSAT con Windows Vista y que se activa por defecto al momento de crear una nueva Unidad Organizativa. Esta funcionalidad reside en proteger la OU que vayamos a crear contra eliminación accidental, provocando que el técnico que quiera eliminar la OU deba primero desbloquear la limitación para poder eliminar la OU.

El siguiente paso a paso a explicar es un poco delicado, ya que si no se está seguro o si no se tienen los conocimientos suficientes de Active Directory, más algo de línea de comandos, será un poco extraño y posiblemente difícil de entender.

El procedimiento que vamos a seguir es un comando desde una cmd.exe que bloqueará al usuario (todos o everyone) según idioma contra eliminación de objetos he hijos, para así en caso de que un técnico por error vaya a eliminar una OU, ésta estará protegida contra eliminación.

Lo primero de todo, es diferenciar entre el lenguaje del sistema operativo donde vamos a realizar el comando, ya que en el caso que esté en inglés al usuario que le vamos a quitar los privilegios es “everyone” y si está en español es “todos”.

Crear una OU de pruebas sin marcar el pincho “Proteger objeto contra eliminación accidental”.

Desde una línea de comandos y con las herramientas de Active Directory instaladas, ejecutar el siguiente comando:

for /F “tokens=*” %i in (‘dsquery ou “ou=pruebas,dc=dominio,dc=com” -limit 0’) do dsacls %i /D “todos”:”SDDT;;”

Cuando esté realizado, nos vamos a las propiedades de la OU en el ADUC y comprobamos que el pincho “Proteger objeto contra eliminación accidental” vuelve a estar marcado como en la siguiente imagen:

3

El comando que vamos a usar para modificar los permisos de todas las OU’s del directorio activo para proteger contra eliminación accidental es el siguiente:

For /F “tokens=*” %i in (‘dsquery ou –limit 0’) do dsacls %i /D “everyone”:”SDDT;;”

Con este comando realizamos una búsqueda de todas las OU’s de AD (‘dsquery ou –limit 0’) y por cada resultado se le hace un dsacls para que el usuario everyone no pueda eliminar objetos (SD) y tampoco eliminar los hijos de los objetos (DT).

Recordar cambiar el nombre “everyone” por “todos” si el idioma de sistema operativo está en castellano.

Se mostrará por pantalla todos los permisos de todas las OU’s (este proceso es normal, no se asuste). NO CIERRE LA VENTANA.

El proceso tardará más en función de la organización de AD (Si es muy grande puede tardar alguna hora).

Dentro de las buenas prácticas de Microsoft, todas las OU’s del dominio deben estar con esta configuración, para validar la aplicación de este cambio se recomienda ejecutar un BPA (Best Practice Analyzer) para el rol de AD DS.

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.

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 podemos actualizar el protocolo de replicación de archivos para AD DS en Windows Server 2012 y 2012 R2?

EL protocolo de replicación en archivos en Active Directory Domain Services es imprescindible para el óptimo funcionamiento de la plataforma, de lo contrario existirían problemas de inconsistencia en la información y bases de datos de AD DS. Microsoft al estar consciente de esto, ha decidido crear un nuevo protocolo de replicación de archivos, 15 veces más rápido y mucho más estable que su versión FRS.

En este artículo usted aprenderá a realizar la actualización del protocolo FRS a DFS-R, para aprovechar todas las bondades que ofrecer Windows Server 2012, y 2012 R2.

Lo primero que debemos saber, es si se está usando FRS o DFS-R. No es fácil detectarlo, ya que la interfaz gráfica usada para administrar o configurar el Dominio no cuenta con la información. Sin embargo, existe una opción para averiguarlo y es a través del Registro (registry), debemos utilizar REGEDIT.EXE y encontrar:

”HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters”

Cuando llegamos aquí, tendremos dos posibilidades, que exista o no una sub carpeta “Syvols\Migrating SysVols”.

Opción 1 Subcarpeta SysVols:

“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\Sysvols\Migrating SysVols”

Esto significa que que se está utilizando DFS-R

1q

Opción 2 No existe subcarpeta SysVols:

Sí la subcarpeta SysVols no existe, significa que se está usando FRS.

2Q

La primera figura, que usa DFS-R, está tomada en un Controlador de Dominio donde se ha creado un Dominio y Bosque nuevos directamente con niveles funcionales Windows 2012 R2.

La segunda figura, corresponde a un Dominio que se ha actualizado desde versiones anteriores.

Entonces, ¿Cómo podemos hacer la migración del servicio de replicación de archivos?

1.- Debemos elevar el nivel funcional de Dominio y Bosque a “Windows Server 2012”.

2.- En uno de los Controladores de Dominio debemos abrir una línea de comandos como administrador y pasar al primer estado. Debemos ejecutar:

DFSRMIG /SetGlobalState 1

Y periódicamente verificar si el proceso fue completado con:

DFSRMIG /GetGlobalState

3g

Una vez alcanzado el nuevo estado (Prepared) podemos seguir con el siguiente:

DFSRMIG /SetGlobalState 2

4g

De forma análoga pasaremos al estado 3.

5q

Y si queremos comprobar, podemos verificar en el registro, que aparece la carpeta mencionada al principio de la nota, y además que el estado es 3 (Eliminated).

6.

El cambio de FRS a DFS–R, en muchos casos permanece oculto para los administradores de Active Directory, que suponen erróneamente su actualización automática cuando se actualiza el Domino. Afectando la calidad y el desaprovechamiento de recursos en nuestros servicios al utilizar un protocolo antiguo.

Nicolas Herrera, Consultor de Infraestructura, Blue Solutions

Active Directory Right Management Services (AD RMS) ¿Puede proteger un directorio?

 AD RMS es un servicio que funciona a nivel de dominio, se encarga de proteger el contenido de documentos Office, correos electrónicos y eventualmente otro tipo de documentos como PDF.

Vamos a determinar la posibilidades que tenemos para proteger un directorio con AD RMS, convencionalmente siguiendo la línea Microsoft y según nuestra experiencia las distintas posibilidades de hacer esto efectivo.

Primeramente hablaremos de la solución más común para tratar nuestra interrogante. File Classification Infraestructure es una solución que funciona sobre el servicio de File Server de Windows Server, se encarga de la clasificación de archivos en base a reglas generadas según las necesidades de la organización. Por ejemplo, se puede clasificar los archivos en base al impacto que tiene sobre el negocio la revelación de la información.

Una buena forma de extender el uso de esta solución, es usando AD RMS Bulk Tool como tarea programada dentro de la solución para no solo clasificar la información, sino también agregar derechos sobre los documentos.

Otra herramienta que nos ayuda a responder nuestra interrogante es Active Directory Rights Management Services Bulk Protection Tool, se encarga de proteger los documentos de una carpeta en base a planillas de permisos.

Las plantillas de permisos deben ser generadas en la consola de AD RMS. En la plantilla, se puede asignar permisos por usuario o por grupo.

1

Se deben definir de forma correcta los permisos para que funcione de manera optima.

Al seleccionar permisos que tendrá el usuario o grupo de Active Directory sobre el o los documentos, los privilegios que son dependencias de otros se irán seleccionando automáticamente según su requerimiento.

2

Una vez que la plantilla está creada y disponible en un directorio compartido, se invoca a la herramienta que protege de forma masiva. Esta herramienta debe estar instalada en el  mismo servidor donde están los documentos. Se puede tomar como si fuera un servidor de archivos.

La forma de usar la herramienta es:

RMSBulk [/decrypt location] [/encrypt location rms_template [owner_email]] [/log log_file [/append] [/simple]] [/preserveattributes] [/silent]

3

La herramienta no tiene interfaz gráfica. Deja abierta la posibilidad de crear un script y automatizar el proceso. Mejor aún, crear una tarea programada con la secuencia de comandos.

En conclusión, se puede proteger los documentos contenidos en un directorio. El acceso al directorio se puede manejar en las propiedades de acceso del directorio.

Con una buena organización de directorios y plantillas, se puede automatizar la protección de documentos  a gran escala.

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