Consulta con el equipo de Windows : Network

Cómo reconfigurar Windows Time en el antiguo PDC cuando transferimos el rol a otro DC

esplat — Wed, 25 Nov 2009 17:34:00 GMT

Hola a todos,

Como todos sabéis, los Controladores de Dominio de un dominio sincronizan su servicio de tiempos siguiendo la jerarquía del dominio. Generalmente, el PDC Emulator del dominio raíz del bosque se configura para que sincronice su hora con una fuente externa o con su propio reloj hardware, tal y como se indica en el artículo:

816042 How to configure an authoritative time server in Windows Server

Si el rol de PDC Emulator en el dominio raíz del forest se mueve a otro DC, además de configurar el nuevo PDC, también debe indicarse al PDC antiguo que ya no es una fuente de hora autoritativa en el entorno, ya que la operación de transferencia del rol no realiza esta operación sobre el servicio de tiempos.

Si no se realiza la operación, el antiguo PDC sigue anunciándose y actuando como fuente de tiempos autoritativa, lo que hace que el resto de DCs, si no tienen fallos al contactar con él o no realizan de nuevo el proceso selección de una nueva fuente de tiempos, sigan sincronizándose contra esta máquina.

El procedimiento que hay que llevar a cabo en el PDC antiguo se describe en el artículo Change the Windows Time service configuration on the previous PDC emulator y consiste en ejecutar los comandos que aparecen a continuación:

Ejecutar el siguiente comando para configurar el servicio de tiempos para que siga la jerarquía del dominio:

w32tm /config /syncfromflags:domhier /reliable:no /update

Parar y arrancar el servicio de tiempos (W32Time)

net stop w32time && net start w32time

Tras realizar esta modificación, el antiguo PDC deja de anunciarse como fuente de tiempos y, por lo tanto, el resto de los DCs procederán a buscar una nueva fuente de tiempos una vez agotados los tiempos de polling.

Espero que encontréis útil esta información.

Paula Tomás Galed

¿Cómo distribuir los parámetros de configuración para 802.1x cableado?

esplat — Wed, 25 Nov 2009 15:53:00 GMT

Hola a todos.

Frecuentemente recibimos preguntas en soporte relacionadas con la distribución de la configuración 802.1x para los puestos cliente de una infraestructura de red.

Como veremos a continuación, la respuesta a esto depende del sistema operativo sobre el que queramos realizar la configuración:

Windows XP SP3 (válido para Windows Vista, Windows 7 y Windows Server 2008 y R2)

En el caso del Windows XP, necesitaremos crearnos un perfil en un fichero .xml a través de la herramienta netsh.

La idea sería:

1. Realizar la configuración deseada en un puesto cliente.

2. Exportar la configuración a un fichero .xml a través de la siguiente sentencia desde la línea de comandos:

netsh lan export profile folder=c:\Ruta

3. En la ruta seleccionada, encontraremos un fichero .xml

4. Para cargar la configuración en otro equipo diferente, ejecutaríamos lo siguiente:

netsh lan add profile filename=FicheroPerfil.xml

A partir de aquí, podríamos crear un script (o utilizar aplicaciones de distribución de software como System Center Configuration Manager) para ejecutar esta última sentencia en todos los puestos Windwos XP SP3 en los que nos interese configurar 802.1x.

Por políticas de dominio (válido para Windows Vista, Windows 7 y Windows Server 2008 y R2)

A diferencia del punto anterior, para estos sistemas operativos disponemos de políticas de dominio para realizar la configuración deseada en:

Computer Configuration/Windows Settings/Security Settings/Wired Network (IEEE 802.3) Policies

Podéis encontrar más información relacionada con este tema en los siguientes artículos:

Netsh Commands for Wired Local Area Network (LAN) in Windows Server 2008 and Windows Server 2008 R2

929847 - How to enable computer-only authentication for a 802.1X-based network in Windows Vista, in Windows Server 2008, and in Windows XP Service Pack

Esperamos que esta información os haya sido de utilidad.

Un saludo,

Javier Rama.

Demostración de cumplimiento de NAP para DHCP

esplat — Wed, 28 Oct 2009 08:15:32 GMT

Hola a todos.

En el siguiente video, podréis ver una demostración del funcionamiento del cumplimiento de NAP para DHCP en un entorno basado en tres máquinas:

· Un Controlador de dominio

· Un servidor NPS y DHCP

· Un equipo cliente.

Información adicional relacionada con este Screencast en los siguientes documentos:

Demostrate NAP DHCP Enforcement in a Test Lab

http://www.microsoft.com/Downloads/details.aspx?FamilyID=ac38e5bb-18ce-40cb-8e59-188f7a198897&displaylang=en

Technet Magazine: Control Network Access Using DHCP Enforcement

http://technet.microsoft.com/en-us/magazine/2009.05.goat.aspx?pr=blog

Un saludo,

Javier Rama.

Monitorizando el tipo de consultas LDAP que llegan a nuestros DCs

esplat — Tue, 11 Aug 2009 23:25:00 GMT

Hola de nuevo. Volvemos a la “carga” con LDAP. Hoy vamos a hablar sobre cómo obtener un logging detallado de las consultas LDAP llevadas a cabo por un controlador de dominio. Esto puede resultarnos útil a la hora de comprobar el tipo de consultas LDAP que se efectúan, comprobar si están optimizadas en cuanto a objetos recorridos, etc.

Para qué nos sirve

Los datos obtenidos pueden ayudarnos a determinar, por ejemplo, si hay un cliente que está efectuando muchas consultas y que, en principio, no debería estar realizando, lo que puede indicar la presencia de alguna aplicación no deseada.

También puede ayudarnos a determinar si es necesario indexar algún atributo concreto para optimizar un tipo de búsqueda concreta que se realiza de forma frecuente y con un filtro que utiliza un atributo específico no indexado (lo que provoca recorrer innecesariamente múltiples objetos por cada búsqueda).

Es posible que estemos realizando la búsqueda en un scope o ámbito muy amplio y con un DN base muy general cuando podemos restringirla a una OU concreta y no a todo el sub-árbol del dominio: si buscamos usuarios de una oficina concreta que cumplen un requisito y sabemos que todos los usuarios de dicha oficina están en una OU específica, deberíamos utilizar dicha OU como DN base de la búsqueda y no todo el dominio.

Este logging de las consultas LDAP se realiza en el visor de sucesos en forma de eventos. Los eventos generados proporcionan, además de los datos del cliente y la propia consulta, información adicional como el tiempo empleado en las queries LDAP y los objetos recorridos.

Para leer información sobre cómo funcionan las búsquedas LDAP: How Active Directory Searches Work

Cómo configurar este nivel de logging

Para conseguir este nivel de logging, en los DCs hay que hacer varias modificaciones en el registro para:

Definir lo que consideramos una búsqueda LDAP costosa/ineficiente
Habilitar el log de eventos de diagnóstico de Directorio Activo para Field Engineering

En primer lugar hay que definir los límites a partir de los cuales se considera que una consulta es costosa/ineficiente. Estos límites se especifican en términos de objetos recorridos, y sólo se registrarán eventos que superen estos límites.

Una búsqueda costosa es aquella que visita un alto número de objetos. La eficiencia de una búsqueda se mide comparando el número de registros devueltos con respecto al número de registros visitados. Es decir, si la búsqueda devuelve 300 objetos después de recorrer 300 objetos, entonces estamos ante una búsqueda eficiente.

Los límites se especifican con creando o modificando los siguientes valores de la clave de registro que se proporciona a continuación (si se desea que se muestren todas las consultas LDAP, el valor de ambos límites deberá ser 1, aunque esto puede suponer un incremento no deseado de la carga de CPU del DC):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Valor: Expensive Search Results Threshold

Tipo: DWORD

Datos: 10000 (Valor por defecto)

Valor: Inefficient Search Results Threshold

Tipo: DWORD

Datos: 1000 (Valor por defecto)

Con estos valores por defecto, una búsqueda se considerará costosa si el DC recorre más de 10000 objetos (Expensive Search Results Threshold). Una búsqueda se considerará ineficiente si recorre más de 1000 objetos (Inefficient Search Results Threshold) y se devuelve como resultado menos de un 10% de los objetos visitados.

Los valores de Expensive e Inefficient Search Results Threshold son valores subjetivos, por lo que habrá que adecuarlos al entorno y al tipo de consultas que se efectúen en los DCs.

Se puede encontrar más información sobre estos valores en el siguiente enlace:

Creating More Efficient Microsoft Active Directory-Enabled Applications

Hasta aquí ya hemos determinado nuestros valores límite de lo que consideramos una búsqueda costosa o ineficiente. Sin embargo, esto no es suficiente para generar los eventos.

Los eventos de log de actividad LDAP se generan en el visor de sucesos de Directorio Activo en la categoría de Field Engineering. Por lo tanto, tendremos que activar el log de diagnóstico de esta categoría en los DCs en los que queramos monitorizar la actividad LDAP.

Para ello es necesario modificar el siguiente valor de la clave de registro que se muestra a continuación:

HKLM\system\CCS\Services\NTDS\Diagnostics

Valor: 15 Field Engineering

Datos: 5

Nota: Para que los valores sean efectivos no es necesario reiniciar el DC en el que se modifiquen

A partir de dicho momento, por cada query LDAP costosa/ineficiente aparecerá en el Visor de Sucesos de Directory Services un evento 1644 de categoría Field Engineering con la información de la búsqueda, tipo, filtro, ámbito de búsqueda (scope), entradas recorridas, entradas encontradas, etc.:

Event Type: Information

Event Source: NTDS General

Event Category: Field Engineering

Event ID: 1644

Description:

Internal event: A client issued a search operation with the following options.

Client:

127.0.0.1

Starting node:

DC=dominio,DC=com

Filter:

(objectClass=computer)

Search scope:

subtree

Attribute selection:

[types_only]

Server controls:

Visited entries:

3448

Returned entries:

Otro tipo de log de diagnóstico que puede resultar útil es el siguiente, que nos permite obtener información sobre el tiempo empleado en las búsquedas:

Valor: 16 LDAP Interface Events

Datos: 3

Después de habilitarlo obtendremos un evento 1139 de LDAP Interface indicando el tiempo que ha costado realizar cada búsqueda:

Event Type:          Information

Event Source:      NTDS LDAP

Event Category:   LDAP Interface

Event ID:               1139

Description:
Internal event: Function ldap_search completed with an elapsed time of 30 ms.

Para revisar los eventos generados por los DCs y obtener, por ejemplo, todos los eventos con ID 1644 y fuente NTDS General de todos los DCs que estemos monitorizando, podemos usar una herramienta como EventCombMT. La herramienta EventCombMT se puede descargar desde el siguiente enlace:

También es recomendable que aumentemos el tamaño del log de Directory Services, ya que se van a generar varios eventos por cada consulta LDAP registrada, lo que podría provocar que dicho visor de sucesos llegara a su tamaño máximo.

Hasta la próxima.

Paula Tomás Galed

La importancia de instalar las actualizaciones de seguridad (MS 08-067 y el virus Conficker)

esplat — Thu, 22 Jan 2009 12:30:00 GMT

Hola de nuevo, somos Juan Arlandis (Sistema Operativo) y Javier Rama (Directorio Activo / Networking).

En esta ocasión, y sumándonos al mensaje que lanzan nuestros compañeros en LATAM, hablaremos sobre la reciente oleada de casos que hemos recibido con respecto al tema.

El pasado mes de Octubre, Microsoft publicó el siguiente boletín de seguridad (MS 08-067) que corrige una vulnerabilidad en el servicio Servidor.

En caso de no haberlo hecho ya, recomendamos encarecidamente proceder a instalar cuanto antes esta actualización en todos los equipos de vuestros entornos.

958644 MS08-067: Vulnerability in Server service could allow remote code execution

A partir de aquí, y explotando esta vulnerabilidad, han ido apareciendo multitud de virus/gusanos que pueden manifestarse de diversas maneras en el entorno.

Desde Soporte, los síntomas más comunes que hemos observado son:

· Parada de los servicios Server y Browser (casi siempre han sido asociados al virus Conficker.A)

Comportamientos tales como servicios no disponibles, recursos que han dejado de estar compartidos, etc. han sido el síntoma inicial.

Un estudio más en profundidad, suele revelar la existencia de un servicio (con nombres con letras aleatorias tales como qbmmf) extraño instalado en el servidor afectado.

· Bloqueo de múltiples cuentas del dominio (variante del anterior y comúnmente denominada Conficker.B)

Podemos consultar una descripción amplia de este virus, así como un procedimiento para determinar si una máquina está infectada, en el siguiente enlace:

http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm%3aWin32%2fConficker.B

Ante una infección de nuestros sistemas, será necesario tanto proceder a instalar la actualización KB 958644 como eliminar el virus de todas las máquinas.

Para eliminar el virus de las máquinas, podemos utilizar cualquiera de los múltiples software de antivirus existentes en el mercado.

(teniendo el fichero de firmas correspondiente en su versión lo más actualizada posible)

En caso de no ser capaces de detectarlo con él, siempre tenemos disponible el scanner online One Care Live.

Para esta solución, el único requisito es que el equipo afectado tenga conexión a Internet.

Por último comentar que, muy posiblemente, estén surgiendo variantes nuevas de los virus mencionados más arriba.

Por ello, nuevamente advertiros sobre la importancia de mantener nuestros servidores actualizados.

Enlaces relacionados

Esperamos que esta información os haya servido de utilidad,

- Javier Rama del Castillo y Juan Arlandis Villarroya

Directorio Activo, RPC, puertos efímeros y firewalls

esplat — Fri, 28 Nov 2008 00:51:00 GMT

Hola de nuevo. Soy Paula del equipo de Directorio Activo.

Hoy hablaremos sobre el funcionamiento básico de RPC que afecta a diferentes operaciones de Directorio Activo. Como seguramente la mayor parte de vosotros ya sabe, la comunicación utilizada para múltiples operaciones en Directorio Activo es RPC. Estas operaciones incluyen, por ejemplo, la replicación de DA, la replicación FRS, la promoción de un nuevo Controlador de Dominio, etc. También realizan conexiones RPC a los DCs la ejecución del comando dcdiag /v o incluso consultar qué DCs son los maestros de operaciones (mediante el comando netdom query fsmo). También es muy común que tratemos casos con problemas de conectividad RPC en que la replicación de DA y/o FRS no se lleva a cabo de manera satisfactoria o incluso que la replicación de DA funcione perfectamente pero los Controladores de Domino no puedan replicar SysVol por FRS.

En una comunicación RPC, el cliente se conecta al puerto TCP 135 del servidor y solicita un puerto al End Point Mapper (EPM) para comenzar la conversación RPC. El EPM del servidor reserva un puerto (llamado puerto dinámico) para este cliente y se lo envía. A partir de este punto, el cliente abre una nueva conexión TCP a dicho puerto del servidor y comienza la comunicación.

Los puertos dinámicos RPC (o puertos efímeros) que puede utilizar el EPM de RPC (o RPCSS) van del 1025 hasta el 65535, aunque Windows 2000/XP/2003 por defecto utilizan puertos que están comprendidos en el rango 1025-5000 (en total 3976 puertos). En Windows Vista y Windows Server 2008, el rango de puertos por defecto es 49152-65535 (un total de 16384 puertos).

Puede encontrarse más información en el siguiente artículo (muy recomendable para identificar y entender los pasos a seguir cuando nos encontramos ante un problema con el RPC Endpoint Mapper):

839880 Troubleshooting RPC Endpoint Mapper errors using the Windows Server 2003 Support Tools from the product CD

Cuando no se puede establecer la conexión por estos puertos efímeros, al realizar las operaciones que hemos comentado anteriormente podemos recibir errores como el siguiente:

There are no more endpoints available from the endpoint mapper.

Vamos a ver unas trazas de red de ejemplo de un establecimiento de una comunicación RPC fallida debido a que el cliente no puede establecer la sesión al puerto dinámico que le indica el EPM del servidor.

Las trazas de red las podéis capturar con cualquier sniffer, por ejemplo en este caso nosotros hemos utilizado Microsoft Network Monitor 3.2.

Esta es la conversación inicial RPC entre un DC y una máquina desde la que se ejecuta la operación netdom query fsmo:

Fuente	Destino	Protocolo	Descripción
cliente	dc	TCP	TCP:Flags=......S., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721180773, Ack=0, Win=65535 ( ) = 65535
dc	cliente	TCP	TCP:Flags=...A..S., SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375582, Ack=721180774, Win=16384 ( Scale factor not supported ) = 16384
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721180774, Ack=3452375583, Win=65535 (scale factor 0x0) = 65535
cliente	dc	MSRPC	MSRPC:c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
dc	cliente	MSRPC	MSRPC:c/o Bind Ack: Call=0x1 Assoc Grp=0x14EE2 Xmit=0x16D0 Recv=0x16D0
cliente	dc	EPM	EPM:Request: ept_map: NDR, DRSR {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, 0.0.0.0:135 (0x87) [DCE endpoint resolution(135)]
dc	cliente	EPM	EPM:Response: ept_map: NDR, DRSR {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, 10.200.8.59:1025 (0x401) [*1025*]
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...F, SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721181002, Ack=3452375795, Win=65323 (scale factor 0x0) = 65323
dc	cliente	TCP	TCP:Flags=...A...., SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375795, Ack=721181003, Win=65307 (scale factor 0x0) = 65307
dc	cliente	TCP	TCP:Flags=...A...F, SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375795, Ack=721181003, Win=65307 (scale factor 0x0) = 65307
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721181003, Ack=3452375796, Win=65323 (scale factor 0x0) = 65323

En la respuesta del End Point Mapper (EPM) del DC ante la solicitud de conexión del cliente (trazas en rojo), el DC indica que van a continuar hablando por el puerto TCP 1025. Si filtramos el tráfico generado en el cliente con destino el DC y puerto 1025, vemos los siguientes intentos de conexión al mismo:

Fuente	Destino	Protocolo	Descripción
cliente	dc	TCP	TCP:Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535

Como podemos ver claramente en las trazas de red, el cliente trata de conectarse varias veces a dicho puerto en el DC y no recibe respuesta (ver retransmisiones). Si observamos unas trazas de red simultáneas a las anteriores pero obtenidas en el DC (capturar el tráfico en ambos extremos es muy recomendable en este tipo de situaciones), únicamente se observa la conversación inicialmente descrita en la primera tabla. Es decir, el DC no llega a recibir los paquetes que el cliente le envía por el puerto 1025.

Lo más probable en este caso es que haya un firewall que esté bloqueando las comunicaciones. Puede ser un firewall hardware/software, el firewall integrado de Windows o incluso un antivirus con funcionalidad de firewall. (Tened también en cuenta que no todos los problemas relacionados con conectividad RPC se deben a la configuración de los firewalls!!!)

Ante esta situación tenemos dos opciones para evitar el bloqueo:

Abrir los puertos comprendidos entre el 1025 y el 5000 en el firewall para permitir la negociación/tráfico RPC entre las máquinas implicadas
Configurar RPC en el DC para utilizar un rango de puertos específicos y abrir dichos puertos en el firewall para permitir la negociación/tráfico RPC entre dichas máquinas

La desventaja que hay que tener en cuenta es la posibilidad de que en determinados momentos no haya puertos disponibles al estar todos en uso, por lo que habrá que realizar pruebas y verificar cuál es el número de puertos adecuado para el entorno. Hay que tener en cuenta que los DCs utilizan RPC para multitud de funcionalidades, como puede ser la replicación de DA o FRS.
El mecanismo para Windows 2000/XP/2003 se define en el siguiente artículo: 154596 How to configure RPC dynamic port allocation to work with firewalls
El artículo anterior también apunta a mecanismos para configurar si se prefiere, por ejemplo, un único puerto concreto para la replicación FRS en lugar de un rango de puertos.
El mecanismo para Windows Vista/2008 se define en el siguiente artículo: 929851 The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008

Si queréis obtener una lista completa de los puertos necesarios para el correcto funcionamiento de un entorno de Directorio Activo, echadle un vistazo a los siguientes artículos:

Espero que esta información os sirva de utilidad, ya que es uno de los problemas que tratamos más frecuentemente y su detección es relativamente sencilla a partir de unas trazas de red.

- Paula Tomás Galed

Microcortes, el Yeti, Hombres lobo y otros seres imaginarios

esplat — Thu, 27 Nov 2008 17:59:00 GMT

Hola a todos , vamos a tratar un tema que desde que trabajo en soporte en Microsoft siempre me ha llamado la atención ( esto es debido a que como los seres imaginarios que he puesto en el título, al ser desconocidos llaman poderosamente la atención , como cualquier tema esotérico )

El primer ser imaginario que vamos a tratar es el microcorte , como todo ser imaginario tiene una serie de características no muy definidas :

1º Nadie lo ha visto jamás , en 7 años de experiencia en el mundo del soporte ( dentro del grupo de plataformas y en las especialidad de NETWORKING ) nunca he resuelto un caso en el que un microcorte fuera el causante del problema.

2º Tiene un hábitat especial , vive dentro de los cables de red .

3º Son difíciles de cazar ( la causa de esto está en el punto 1 ) , para cazarlos necesitaríamos equipamiento especial , como por ejemplo : El fluke EtherScope II : http://www.flukenetworks.com/fnet/en-us/products/EtherScope+Series+II/

Ahora que conocemos un poco mas nuestro ser imaginario , pasemos a identificar el problema:

Muchas veces este empieza de esta manera , tenemos un problema con nuestro servidor , no podemos llegar a los shares , tenemos microcortes ó El cluster esta balanceando entre los nodos creemos que tenemos microcortes en nuestra red y por esto ocurre este problema.

La pregunta lógica desde un punto de vista de un cazador de mitos o ingeniero de soporte ,seria :

¿Porque creéis que son microcortes? ¿Que herramienta habéis utilizado para ver los mismos?

La respuesta a la segunda es : “ninguna” en el 98 % de las ocasiones , a la primera suele ser más variada:

50 % se desconecta la ( añadir lo que se desee , unidad , share , volumen , nodo )-

25 % hay resets en la red.

25 % hay retrasmisiones en la red.

Aquí normalmente , yo ya empiezo a enfadarme con el termino MICROCORTE , por que el problema no es otro que de terminología , es decir ante lo desconocido , lo llamo MICROCORTE ( al igual que cuando vamos por la nieve , vemos algo grande que se mueve a lo lejos ,,, que es : EL YETI ) .

También ocurre mucho con la lentitud de los equipos , suele darse esta situación .

Me va lento el equipo . -----------> tienes un virus.

Me va lenta la red . ----------------> tienes microcortes.

El microcorte como termino , se ha importado de la red eléctrica :

Un fenómeno particular de los "blackouts" son los micro-cortes de energía o micro-blockouts, estos, como la palabra lo indica son pequeñas desapariciones del suministro eléctrico o caídas a niveles bajísimos, la características principal es que son de cortísima duración, se los ubica en el orden de los mili-segundos (1 a 20). Son tan pequeños que a veces son inocuos e intrascendentes, dependiendo del tipo de carga que alimentan, pueden causar daños irreparables o fallas en el funcionamiento.

imagen de : http://www.alcion.es/DOWNLOAD/ArticulosPDF/en/08articulo.pdf

Así que siendo fieles a la definición microcorte debería ser un problema eléctrico , un problema en el transporte de energía , un problema físico . ( Physical layer en OSI ) .

Para poder detectar un problema real de microcortes deberíamos utilizar un analizador como el comentado en el punto 3 .

Para el resto de problemas de red , vamos a utilizar el NETMON3.2 http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&DisplayLang=en

Por ahora no trataremos el problema en wireless , ya que el problema de los microcortes en este ámbito se transforma en interferencias ( en un futuro articulo se trataran como Hombres Lobos ).

si alguien quiere utilizar el Wireshark: http://www.wireshark.org/ .también puede hacerlo los dos tienen ventajas e inconvenientes , pero eso queda para otra entrada en el blog :-).

Asi que como dice Laura Chappel : “The analyzer should be the first tool used against a problematic network, not the last.”

Hablemos entonces de los otros posibles causantes , RESETs y Retransmisiones:

1º RESETs :

La manera que tiene TCP de manejar las conexiones half-open y otras situaciones problemáticas es incluir una función especial de reset.

Un reset es un segmento TCP que se envía con el Flag RST a 1, hablando de forma general un reset se envía cuando ocurre algo inesperado por TCP.

Algunos de los causas generales de un reset son :

La recepción de un segmento TCP de cualquier dispositivo con el cual no tenemos una sesión TCP iniciada ( cualquier otro que no sea un SYN para iniciar una sesión , se entiende ;-) ).
La recepción de un segmento TCP con un numero de secuencia invalido o incorrecto.
Recepción de un SYN en un puerto donde no hay ningún proceso escuchando ( listener ).

Si vemos reset que no corresponde con estos casos lo mejor es capturar trazas y junto con un NETSTAT – NAO verificar que proceso esta escuchando en ese puerto. ( esto netmon 3.2 lo trae incluido )

2º Retransmisiones:

TCP inicia un temporizador de retransmisión cuando cada segmento se entrega a IP. Si no se no se ha recibido un ACK para los datos de un segmento determinado antes de que caduque el temporizador, este es retransmitido. Para las nuevas solicitudes de conexión, el temporizador de retransmisión se inicia a 3 segundos, y la petición (SYN) es reenviada hasta el valor especificado en TcpMaxConnectRetransmissions ( 2 por defecto ).. En las conexiones existentes, el número de retransmisiones es controlado por el parámetro del Registro TcpMaxDataRetransmissions (5 por defecto). El tiempo de espera de retransmisión se ajusta sobre la marcha para que coincida con las características de la conexión.

Algunos parámetros para controlar el comportamiento de las Retransmisiones ( pudiendo mejorar o empeorar J ) :

TcpMaxConnectRetransmissions

Clave: Tcpip\Parameters
Tipo del valor: REG_DWORD (número)
Intervalo válido: 0 - 0xFFFFFFFF
Valor predeterminado: 2
Descripción: este parámetro determina el número de veces que TCP retransmite una solicitud de conexión (SYN) antes de cancelar el intento. El tiempo de espera de retransmisión se duplica con cada retransmisión sucesiva en un intento de conexión concreto. El valor de tiempo de espera inicial es de tres segundos.

TcpMaxDataRetransmissions

Clave: Tcpip\Parameters
Tipo del valor: REG_DWORD (número)
Intervalo válido: 0 - 0xFFFFFFFF
Valor predeterminado: 5
Descripción: este parámetro controla el número de veces que TCP retransmite un segmento de datos individual (segmento de no conexión) antes de cancelar la conexión. El tiempo de espera de retransmisión se duplica con cada retransmisión sucesiva en una conexión. Se restablece cuando se reanuda la respuesta. El valor de tiempo de espera de base se determina de forma dinámica mediante el tiempo de ida y vuelta medido en la conexión.

Un saludo desde el cable y cuidado con los seres imaginarios…

Alberto Camina Alvarez

Técnico de Soporte Microsoft Premier

Cómo configurar el Firewall de Windows para el perfil de dominio excluyendo un interfaz de red

esplat — Fri, 26 Sep 2008 12:47:00 GMT

Hola, soy Javier Rama, del equipo de Directorio Activo / Networking. En algunas ocasiones hemos tenido casos en los que el cliente necesita configurar el Firewall de Windows a través de GPO en su dominio.

Como sabemos, tenemos multitud de settings para configurarlo desde la consola de edición de Políticas de Grupo en:

Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall

Sin embargo, puede haber ocasiones en que necesitemos deshabilitar todas las reglas y excepciones que aplicamos en el Firewall para un interfaz de red concreto del equipo.

Esto no podemos conseguirlo directamente con el conjunto de parámetros que podemos configurar a través de GPO.

Para conseguirlo, debemos realizar los siguientes pasos:

1. Deshabilitar la siguiente política en el perfil de Dominio, Windows Firewall: Protect all network connections

Gracias a este setting , habilitamos o deshabilitamos el Firewall de Windows.

El inconveniente que nos encontramos estableciéndolo es que, además de habilitar el Firewall, también lo configuramos para que aplique todas las reglas en todos los interfaces de red disponibles en la máquina destino.

Por tanto, lo deshabilitaremos estableciéndolo a Disabled y ,como veremos a continuación, activaremos el Firewall gracias a la herramienta netsh.

2. A continuación, crearemos un script de inicio para el equipo con el siguiente contenido:

netsh firewall set opmode mode=enable profile=domain (Habilitar el Firewall de Windows para el perfil de dominio)

netsh firewall set opmode mode=enable interface=”Red” (Proteger este interfaz de red con el Firewall de Windows)

netsh firewall set opmode mode=disable interface=”Red Externa” (No aplicar las reglas del Firewall para este intefaz)

…

(Continuar con todos los dispositivos poniéndolos a enable o disable según nos interese)

Como vemos, es necesario especificarle el nombre completo de cada interfaz de red.

Tras la aplicación de este script, conseguiremos el siguiente efecto:

3. El resto de parámetros que queramos configurar, tales como reglas específicas o excepciones, podemos hacerlo normalmente a través de GPO.

- Javier Rama del Castillo

Ocultando ficheros y carpetas de un share con ABE en Windows Server 2003

esplat — Mon, 22 Sep 2008 17:50:00 GMT

Hola, soy Javier Rama, del equipo de Directorio Activo / Networking.

Hace algunos días, un cliente nos preguntaba cómo ocultar las carpetas y ficheros de un share a los usuarios que no tienen permisos para acceder a ellos.

Para acometer dicha tarea, tenemos disponible la tecnología ABE (Access Based Enumeration) gracias a la cual, el servidor de ficheros ocultará las carpetas y ficheros en función de los permisos del usuario que accede a dicho recurso.

ABE es una funcionalidad que está incluida en Windows Vista y en Windows Server 2008, pero además está disponible como descarga para Windows Server 2003 en el siguiente enlace:

Microsoft Download Center: Windows Server 2003 Access-based Enumeration

http://www.microsoft.com/downloads/details.aspx?FamilyId=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en

Antes de habilitar ABE sobre cualquier recurso compartido, debemos tener en cuenta las siguientes consideraciones:

· ABE está pensada únicamente para shares de red, por ejemplo \\servidor\carpeta. Sin embargo, si accedemos a través del explorador (ruta C:\carpeta por ejemplo) esta tecnología no nos servirá.

· Además, también es oportuno apuntar que, habilitar ABE sobre una carpeta compartida añade una carga extra de CPU al servidor (el cual comprobará los permisos del usuario que intenta acceder con el contenido de la carpeta, y determinar así qué elementos mostrar). En escenarios en los que se produzcan muchos accesos a los recursos, será necesario tener en cuenta este punto.

CONFIGURANDO ABE

1- Una vez instalado ABE, será necesario habilitarlo en cada uno de los shares que deseemos. Para ello podemos proceder de dos maneras:

a) A través de la interfaz gráfica de usuario (Clic derecho sobre el share -> Propiedades -> Pestaña Access Based Enumeration -> Marcar checkbox Enable Access-based Enumeration in this shared folder ).

b) Desde línea de comando a través de la herramienta abecmd

Se puede encontrar información detallada sobre este comando en en siguiente enlace:

Windows Server 2003 Access-based Enumeration

http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx

2- Una vez habilitado ABE sobre un share y, habiendo configurado los permisos oportunos para los distintos usuarios, conseguiremos el efecto que aparece en las siguientes capturas (los ejemplos que aparecen a continuación corresponden al enlace anterior):

Figura 1 - Recurso compartido “Customer Accounts” con ABE deshabilitado.

Como vemos en la Figura 1, el usuario puede ver todo el contenido del share independientemente de tener permisos de acceso para cada elemento o no.

Con el checkbox Enable access-based enumeration on this folder habilitado desde las propiedades de la carpeta “Customer Accounts” , el usuario únicamente ve las carpetas a las cuales puede acceder (Figura 2).

Figura 2 - Recurso compartido “Customer Accounts” con ABE habilitado.

- Javier Rama del Castillo

Cómo auditar la creación y el borrado de zonas DNS integradas en DA

esplat — Thu, 18 Sep 2008 13:43:00 GMT

Hola, soy Paula, del equipo de Directorio Activo. Hoy vamos a hablar de cómo habilitar la auditoria para poder disponer de información en el caso de que se cree o elimine una zona DNS integrada en Directorio Activo.

Habilitar la auditoría va a conllevar que el log de eventos de Seguridad registre una cantidad mayor de eventos, con lo que requerirá mayor espacio en disco (para no perder eventos, se puede incrementar el tamaño del log).

Los pasos a seguir para habilitar la auditoría son los siguientes:

1. Habilitar la auditoría al acceso a los servicios de directorio (Directory Service Access):

a. Editar la política Default Domain Controllers Policy o crear una nueva GPO en la OU de los controladores de dominio. Si se tienen varios dominios y se desea auditar la actividad en todos dependiendo del tipo de replicación de la zona, habrá que habilitar la auditoría en todos ellos.

b. Habilitar Success (también se puede auditar Failure) en la siguiente ruta de la GPO:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit directory service access

2. Establecer la auditoría sobre el objeto de Directorio Activo que deseemos. Esta operación se puede realizar, por ejemplo, mediante ADSIEdit:

a. Acceder a la partición que se desee auditar (Botón derecho sobre la raíz "ADSI Edit" y seleccionar Connect to...). Como se comentó anteriormente aquí, las zonas DNS pueden albergarse bajo el contenedor MicrosoftDNS en tres particiones diferentes en Directorio Activo dependiendo de su configuración de replicación:

CN=MicrosoftDNS,CN=System,DC=domain,dc=com -> Partición del dominio: La zona está configurada para replicar a todos los DCs del dominio

CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=com -> Partición de aplicación DomainDNSZones: La zona replica a todos los servidores DNS del dominio

CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=com -> Partición de aplicación ForestDNSZones: La zona replica a todos los servidores DNS del bosque

b. Acceder a las propiedades de la partición ForestDNSZones (por ejemplo) > Seguridad > Avanzadas > Auditoría

Agregar al usuario Everyone (o al usuario/grupo que se desee auditar)

Aplicar a Container objects

Tipo de acceso Create dnsZone Objects y Delete dnsZone Objects

Una vez se habilite, esta configuración es homogénea para todo el dominio, es decir, todos los DCs van a auditar estos accesos. Siempre es recomendable que se realicen algunos tests en un entorno de pruebas para comprobar que la auditoria cumple los requisitos que se necesitan.

Un ejemplo del evento que se generan al crear una nueva zona:

Event Type: Success Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 566

Date: 9/18/2008

Time: 1:17:42 PM

User: HALEDOMAIN\paula

Computer: HALEDC01

Description:

Object Operation:

Object Server: DS

Operation Type: Object Access

Object Type: container

Object Name: CN=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com

Handle ID: -

Primary User Name: HALEDC01$

Primary Domain: HALEDOMAIN

Primary Logon ID: (0x0,0x3E7)

Client User Name: paula

Client Domain: HALEDOMAIN

Client Logon ID: (0x0,0x226DB)

Accesses: Create Child

Properties:

Create Child

dnsZone

Additional Info: DC=prueba.com,cn=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com

Additional Info2: DC=prueba.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com

Access Mask: 0x1

Ejemplo de una eliminación:

Event Type: Success Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 566

Date: 9/18/2008

Time: 1:31:20 PM

User: HALEDOMAIN\paula

Computer: HALEDC01

Description:

Object Operation:

Object Server: DS

Operation Type: Object Access

Object Type: dnsZone

Object Name: DC=..Deleted-prueba.com\0ADEL:39fd87f0-46f8-4474-8a53-1392aaf34a95,CN=Deleted Objects,DC=ForestDnsZones,DC=haledomain,DC=com

Handle ID: -

Primary User Name: HALEDC01$

Primary Domain: HALEDOMAIN

Primary Logon ID: (0x0,0x3E7)

Client User Name: paula

Client Domain: HALEDOMAIN

Client Logon ID: (0x0,0x226DB)

Accesses: DELETE

Properties:

DELETE

dnsZone

Additional Info:

Additional Info2:

Access Mask: 0x10000

Esperamos que esta información os sirva en caso de que necesitéis auditar la creación/borrado de zonas DNS.

- Paula Tomás Galed

W2k8 Days - Rol de Network Policy and Access Services (NPAS)

esplat — Thu, 31 Jul 2008 19:17:00 GMT

Hola a tod@s,

La presentación de nuestro compañero Javier Rama del Castillo que publicamos hoy trata sobre el rol Network Policy and Access Services (NPAS). Este rol es una agrupación lógica de las siguientes tecnologías de acceso a la red:

Routing and Remote Access
Network Policy Server (NPS)
Health Registration Authority (HRA)
Host Credential Authorization Protocol (HCAP)

Esperamos que os resulte interesante :)

Saludos.

W2k8 Days Novedades en la tecnología Clúster NLB

esplat — Tue, 03 Jun 2008 16:12:00 GMT

Hola a tod@s,

Hoy publicamos la presentación que realizo nuestro compañero de soporte Eduardo Díez respecto a las novedades incluidas en el servicio de Clúster NLB y sus opciones de configuración y administración.

Espero que a los administradores tanto de la parte servidora como de la red os resulte interesante y de utilidad en las tareas diarias.

Saludos.

W2k8 Days Novedades en el Servicio DNS

esplat — Tue, 27 May 2008 10:40:00 GMT

Hola de nuevo,

Continuando con las novedades en W2008 pasamos ahora a un servicio que afecta a dos elementos de administración fundamentales en cualquier entorno como son la parte de red y Directorio Activo.

Nos referimos a DNS, un protocolo con bastante veteranía pero que ha sufrido algunas modificaciones y mejoras en esta nueva versión de sistema operativo.

En el link adjunto tenéis acceso a la presentación que realizó nuestra compañera Paula Tomás Galed para que podáis comenzar a trabajar con estar novedades.

Saludos y esperamos que os resulte de utilidad.