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.
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)
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
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
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 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.
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:
Time: 1:31:20 PM
Object Type: dnsZone
Object Name: DC=..Deleted-prueba.com\0ADEL:39fd87f0-46f8-4474-8a53-1392aaf34a95,CN=Deleted Objects,DC=ForestDnsZones,DC=haledomain,DC=com
Accesses: DELETE
DELETE
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
Hola, somos Tolu Igbon y Paula Tomás. Hace unos días tuvimos un caso en el que se utilizaba un script para realizar una consulta LDAP (utilizando el proveedor LDAP y determinar los miembros del grupo Domain Admins. Este script devolvía únicamente parte de los miembros del grupo, mientras que, a través de la consola de Usuarios y Equipos de Directorio Activo (dsa.msc) se obtenía un número mayor de miembros (la totalidad de ellos).
Se observó que la misma consulta en otro script que utilizaba el proveedor WinNT sí devolvía efectivamente todos los miembros del grupo Domain Admins, así como también los devolvía la ejecución del comando Net Group “Domain Admins”
Sin embargo, tanto ADSIEdit como LDP.EXE devolvían resultados parciales iguales a los que se recibían utilizando el script con el proveedor LDAP.
Ejecutamos el comando LDIFDE para obtener un volcado completo del contenedor USERS del dominio donde residen nuestros usuarios y grupos:
LDIFDE –d “CN=Users,DC=Nombredominio,DC=com” –f ARCHIVOSALIDA.TXT
En el archivo de salida vimos que, de nuevo, sólo aparecía parte de los usuarios en el atributo member del grupo Domain Admins.
dn: CN=Domain Admins,CN=Users,DC=Dominio,DC=com
changetype: add
objectClass: top
objectClass: group
cn: Domain Admins
description: Designated administrators of the domain
member: CN=User1,CN=Users, DC=Dominio,DC=com
member: CN=User2,CN=Users, DC=Dominio,DC=com
member: CN=User3,CN=Users, DC=Dominio,DC=com
member: CN=User4,CN=Users, DC=Dominio,DC=com
Posteriormente, comparamos los atributos de los usuarios que SÍ aparecían como miembros del grupo Domain Admins con los de los usuarios que NO aparecían.
Averiguamos que los usuarios que no aparecían tenían el atributo PrimaryGroupID establecido a 512. Este valor corresponde al grupo “Domain Admins”.
dn: CN=User5,CN=Users, DC=Dominio,DC=com
objectClass: person
objectClass: organizationalPerson
objectClass: user
…………………………….
memberOf: CN=Enterprise Admins,CN=Users, DC=Dominio,DC=com
memberOf: CN=Administrators,CN=Users, DC=Dominio,DC=com
…………………………
primaryGroupID: 512 Sin embargo, los demás usuarios que sí aparecían como miembros del grupo “Domain Admins” tenían el atributo PrimaryGroupID establecido a 513, correspondiente al grupo “Domain Users”.
dn: CN=User1,CN=Users, DC=Dominio,DC=com
memberOf: CN=Group1,CN=Users, DC=Dominio,DC=com
memberOf: CN=Domain Admins,CN=Users, DC=Dominio,DC=com
primaryGroupID: 513 Este comportamiento es por diseño, y aparece descrito en el siguiente artículo:
275523 Setting Primary Group Excludes the User from the Group Membership in Active Directory http://support.microsoft.com/default.aspx?scid=kb;EN-US;275523
A traves de LDAP/ADSI, un usuario no aparece como memberOf (miembro de) su grupo primario. Dicho grupo tampoco muestra los member (miembros) que lo tengan como grupo primario.
Del mismo modo, y por diseño, los usuarios no aparecen como miembros del grupo “Domain Users”, al ser éste el grupo primario de la mayoría de los usuarios por defecto.
Para que los usuarios deseados aparezcan como miembros del grupo “Domain Admins” a través de ADSI/LDAP, hay que cambiar su grupo primario a través de la consola Usuarios y Equipos de Directorio Activo y establecerlo a “Domain Users”, por ejemplo.
Se puede encontrar más información en los siguientes artículos de KB:
321360 How to use native ADSI components to find the primary group http://support.microsoft.com/default.aspx?scid=kb;EN-US;321360
297951 How to use the PrimaryGroupID attribute to find the primary group for a user http://support.microsoft.com/default.aspx?scid=kb;EN-US;297951
Esperamos que os haya resultado interesante.
- Tolu Igbon && Paula Tomás Galed
Hola, soy Tolu Igbon, del equipo de Directorio Activo. Hoy vamos a hablar sobre cómo habilitar trace logging para diferentes componentes relacionados con Directorio Activo tanto en Windows Vista como en Windows Server 2008.
La herramienta Tracelog: http://msdn.microsoft.com/en-us/library/ms797927.aspx se introdujo con el kit de recursos de Windows 2000.
Esta utilidad permite habilitar “event trace logging”, (un especie de logging detallado) de distintos componentes de Windows a la hora de intentar resolver problemas (por ejemplo autenticación Kerberos, acceso LDAP, etc).
Para interpretar los “event trace logs” (.etl) generados se necesitan otras herramientas como:
La novedad real para Vista/2008 es que ha aumentado de manera significativa el numero de proveedores con los cuales podemos realizar este tipo de “logging”.
Aquí os proporcionamos unos ejemplos de cómo generar logging para componentes relacionados con Directorio Activo.
Cliente LDAP
En primer lugar, creamos una nueva clave de registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ ldap\Tracing\ProcessName
ProcessName es el nombre del proceso que queremos “tracear” (por ejemplo MMC.exe).
Dentro de esta clave, podemos crear un valor opcional de tipo DWORD llamado PID. (Si establecemos este valor a un PID concreto, solo se traceará la instancia de la aplicación con este PID).
Para habilitar el tracing, ejecutamos el siguiente comando:
tracelog.exe -start <sessionname> -guid #<guid for ldap tracing provider> -f <filename> -flag <traceFlags>
sessionname es un nombre arbitrario que utilizamos para identificar la session de tracing (tendremos que hacer referencia al mismo identificador cuando terminemos la sesión). El GUID para el proveedor de tracing LDAP es "099614a5-5dd7-4788-8bc9-e29f43db28fc". filename especifica el archive de registro donde se generarán los logs. traceFlags puede ser una combinación de los siguientes valores: DEBUG_TRACE1 0x00000001 DEBUG_TRACE2 0x00000002 DEBUG_REFCNT 0x00000004 DEBUG_HEAP 0x00000008 DEBUG_CACHE 0x00000010 DEBUG_SSL 0x00000020 DEBUG_SPEWSEARCH 0x00000040 DEBUG_SERVERDOWN 0x00000080 DEBUG_CONNECT 0x00000100 DEBUG_RECONNECT 0x00000200 DEBUG_RECEIVEDATA 0x00000400 DEBUG_BYTES_SENT 0x00000800 DEBUG_EOM 0x00001000 DEBUG_BER 0x00002000 DEBUG_OUTMEMORY 0x00004000 DEBUG_CONTROLS 0x00008000 DEBUG_BYTES_RECEIVED 0x00010000 DEBUG_CLDAP 0x00020000 DEBUG_FILTER 0x00040000 DEBUG_BIND 0x00080000 DEBUG_NETWORK_ERRORS 0x00100000 DEBUG_SCRATCH 0x00200000 DEBUG_PARSE 0x00400000 DEBUG_REFERRALS 0x00800000 DEBUG_REQUEST 0x01000000 DEBUG_CONNECTION 0x02000000 DEBUG_INIT_TERM 0x04000000 DEBUG_API_ERRORS 0x08000000 DEBUG_ERRORS 0x10000000
sessionname es un nombre arbitrario que utilizamos para identificar la session de tracing (tendremos que hacer referencia al mismo identificador cuando terminemos la sesión).
El GUID para el proveedor de tracing LDAP es "099614a5-5dd7-4788-8bc9-e29f43db28fc".
filename especifica el archive de registro donde se generarán los logs.
traceFlags puede ser una combinación de los siguientes valores:
DEBUG_TRACE1
0x00000001
DEBUG_TRACE2
0x00000002
DEBUG_REFCNT
0x00000004
DEBUG_HEAP
0x00000008
DEBUG_CACHE
0x00000010
DEBUG_SSL
0x00000020
DEBUG_SPEWSEARCH
0x00000040
DEBUG_SERVERDOWN
0x00000080
DEBUG_CONNECT
0x00000100
DEBUG_RECONNECT
0x00000200
DEBUG_RECEIVEDATA
0x00000400
DEBUG_BYTES_SENT
0x00000800
DEBUG_EOM
0x00001000
DEBUG_BER
0x00002000
DEBUG_OUTMEMORY
0x00004000
DEBUG_CONTROLS
0x00008000
DEBUG_BYTES_RECEIVED
0x00010000
DEBUG_CLDAP
0x00020000
DEBUG_FILTER
0x00040000
DEBUG_BIND
0x00080000
DEBUG_NETWORK_ERRORS
0x00100000
DEBUG_SCRATCH
0x00200000
DEBUG_PARSE
0x00400000
DEBUG_REFERRALS
0x00800000
DEBUG_REQUEST
0x01000000
DEBUG_CONNECTION
0x02000000
DEBUG_INIT_TERM
0x04000000
DEBUG_API_ERRORS
0x08000000
DEBUG_ERRORS
0x10000000
Para detener el tracing, ejecutamos el siguiente comando:
tracelog.exe -stop <sessionname>
Ejemplo práctico
Un administrador recibe un error inesperado en una aplicación que establece contraseñas para cuentas de Usuario.
Decide habilitar tracing para APP1.exe mediante los siguientes pasos:
1. Crear la clave de registro
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ ldap\Tracing\App1.exe y habilitar una session de tracing mediante el siguiente comando: C:\>tracelog.exe -start ldaptrace -guid #099614a5-5dd7-4788-8bc9-e29f43db28fc -f .\ldap.etl -flag 0x80000
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ ldap\Tracing\App1.exe
y habilitar una session de tracing mediante el siguiente comando:
C:\>tracelog.exe -start ldaptrace -guid #099614a5-5dd7-4788-8bc9-e29f43db28fc -f .\ldap.etl -flag 0x80000
2. Una vez ejecutado este comando, se escribirán mensajes de tipo DEBUG_BIND en el log .\ldap.etl.
3. Ejecutamos App1.exe para reproducir el comportamiento inesperado.
4. Detenemos la session de tracing:
C:\>tracelog.exe -stop ldaptrace
5. Eliminamos la clave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ ldap\Tracing\App1.exe para que ningún otro usuario pueda obtener información de tracing de App1.exe.
6. Utilizamos otra herramienta como Tracerpt.exe para interpreter la información del log de tracing generado:
C:\>tracerpt.exe .\ldap.etl -o -report
Autenticación Kerberos
Habilitar el “tracing detallado” de kerberos mediante el siguiente comando
tracelog.exe -kd -rt -start kerb -guid #6B510852-3583-4e2d-AFFE-A67F9F223438 -f .\kerb.etl -flags 0x43 -ft 1
Para detener el logging, una vez reproducido el problema, ejecutar el siguiente comando:
tracelog.exe -stop kerb
Autenticación NTLM
Para habilitar el logging:
tracelog.exe -kd -rt -start ntlm -guid #5BBB6C18-AA45-49b1-A15F-085F7ED0AA90 -f .\ntlm.etl -flags 0x15003 -ft 1
Para detener el logging:
tracelog -stop ntlm
KDC
Para habilitar logging en el KDC (el servicio de validación y distribución de tickets kerberos en un DC):
tracelog.exe -kd -rt -start kdc -guid #1BBA8B19-7F31-43c0-9643-6E911F79A06B -f .\kdc.etl -flags 0x803 -ft 1
tracelog.exe -stop kdc
Usando el editor del registro
Tambien podemos habilitar el logging a través del registro de Windows:
Method
Registry key setting
NTLM
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
· Value name: NtLmInfoLevel
· Value type: DWORD
· Value data: c0015003
Kerberos
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
· Value name: KerbDebugLevel
· Value data: c0000043
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos
· Value name: LogToFile
· Value data: 00000001 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
· Value data: 00000001
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
· Value name: KdcDebugLevel
· Value data: c0000803
Ubicación de los ficheros de salida
Si habilitamos el logging mediante tracelog.exe se generarán los archivos correspondientes de registro, kerb.etl/kdc.etl/ntlm.etl en el directorio desde donde hemos ejecutado el comando
Si lo hemos habilitado en el registro, los archivos se generarán en las siguientes ubicaciones:
Esperamos que esta información os pueda resultar de utilidad a la hora de buscar las posibles causas de problemas relacionados con Directorio Activo.
Tolu Igbon
Hola a todos,
Una de las nuevas tecnologías que tenemos con Windows Server 2008 es la de virtualización mediante Hyper-V.
Pero esto nos plantea una cuestión muy importante en los entornos de alta disponibilidad o que resulten claves en la producción, ¿como hago BackUp de las máquinas virtuales que tengo afectando lo menos posible a mis usuarios?
Para esto tenemos nuestro software de BackUp DPM 2007 (Data Protection Manager) o herramientas desarrolladas por terceros que están pensadas específicamente para este entorno.
Pero investigando un poco me encontré con un post de mi compañero Rob Hefner que os traduzco esperando que os resulte de utilidad.
Para habilitar el BackUp basado en VSS de Hyper-V en la utilidad Windows Server BackUp se deben añadir las siguientes claves al registro de Hyper-V VSS. La clave WindowsServerBackUp no es generada cuando se instala la utilidad Windows Server BackUp en la máquina. Se debe crear esta clave manualmente:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT \CurrentVersion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}
Una vez creada la clave se necesitaran incluir un String Value con los campos:
Name: Application Identifier Type: REG_SZ Value: Hyper-V
Cuando este completado, deberán verse como esto:
La utilidad Windows Server Backup solo soporta el BackUp de volúmenes, por esto cuando se realicen los BackUps de las máquinas virtuales se deben seleccionar todos los volúmenes donde los datos de las MV estén guardados.
Por ejemplo, si se esta empleando la ubicación por defecto de los ficheros de configuración (C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines) y el disco VHD esta en otro volumen se deberán seleccionar los dos volúmenes en el BackUp.
Cuando se inicie la restauración del BackUp seleccionar en “Application Restore” la opción de Hyper-V, si no se selecciona este método no se podrá restaurar ficheros de las MV en funcionamiento. Como parte del proceso de restauración las MV actuales serán paradas y borradas, siendo sustituidas y registradas por las del BackUp en Hyper-V.
Hay algunas limitaciones y comportamientos que se deben conocer antes de decidirse por este método:
1. Si la máquina virtual contiene discos dinámicos no puede ser salvada mediante VSS, solo se soportara el BackUp con la máquina parada (Offline BackUp). Otra opción seria realizar el BackUp mediante un software de BackUp local en la máquina como cualquier máquina física.
2. En el caso de máquinas virtuales que no soporten VSS, como son W2000, Windows XP o máquinas sin Integration Services instalados, entraran en estado "salvada" (saved state) mientras se hace el Snapshot y se restauraran tras terminar la operación, por lo que el proceso supone una parada en la máquina (cosa que normalmente evita VSS).
Se experimentará este mismo comportamiento si se deshabilitar Integration Services en la máquina como se muestra a continuación:
3. Cuando se realiza la restauración desde el BackUp se debe restaurar todo el volumen, la restauración de máquinas virtuales independientes no esta soportada con Windows Server BackUp.
4. Si la máquina virtual tiene 2 o más Snapshots la restauración fallará. Para poder solucionarlo:
El post completo, en Ingles, lo podéis localizar en
Espero que os resulte de utilidad.
Raúl del Moral Guirado
Técnico de Soporte Microsoft Premier
Este post pretende ser el primero de una serie de post sobre los problemas más habituales que observamos día a día los ingenieros de soporte de cluster, el primero de ellos estará centrado en el cambio de firmas de los discos de cluster.
El servicio de cluster reconoce e identifica los discos por su firma. Las firmas de los discos están almacenadas en el disco físico en el Master Boot Record (MBR). El MBR es un registro que utiliza el servicio de cluster para mantener todos los discos que administra, es decir utiliza el MBR para realizar un seguimiento de los discos.
Durante el transcurso de las operaciones del servicio de cluster (arranque, reinicio, failover…), si el servicio de cluster no puede encontrar un disco que está identificado con una firma en concreto, no podrá poner online el disco.
El componente de cluster que específicamente detecta esta condición y añade el error en el cluster.log es el cluster disk filter driver (clusdisk.sys).
En la imagen de abajo se puede ver un ejemplo de la firma de un disco en el MBR.
La firma del disco en el MBR está en formato Little endien, con lo que los bytes esta al revés con lo que la firma que aparece en la imagen en la rama de registro de cluster estará como 0XA3D9A3D9.
El primer paso para en el troubleshooting de firmas de discos en cluster es verificar si la firma del disco ha cambiado.
Como determina si la firma del disco ha cambiado
Síntomas
· El servicio de cluster no arranca en ninguno de los nodos.
· El servicio de cluster arranca pero algún disco no se pone online.
Comprobaciones rápidas
Los siguientes pasos pueden facilitar una rápida evaluación para detectar si los fallos de disco se deben a un cambio de firmas. Si las firmas cambian clusdisk.sys las ignorara permitiendo al sistema operativo montar el disco.
1. Revisa el visor de eventos en busca del siguiente evento
Identificador de sucesos: 1034 Origen: ClusDisk Descripción: No se pudo encontrar el disco asociado a recurso de disco de clúster <DriveLetter>. La firma esperada del disco fue <DiskSignature>.
2. Si el evento anterior no está en el visor de sucesos continuar al paso 3 y si esta pasar a la sección “como arreglar firmas de discos que han cambiado”
3. Navegar por el Explorer y verificar si alguno de los discos compartidos que fallen aparecen listados.
4. En caso de que aparezcan intentar acceder a ellos.
5. Crear una carpeta en el disco compartido.
6. Cierra el explorer, reábrelo, conecta con la unidad y verifica que la carpeta sigue presente.
7. Si la carpeta aun está presente en el disco verifica el clusdisk.sys está cargado y ejecutándose
a. Botón derecho en MI PC selecciona administrar.
b. Selecciona administrador de dispositivos.
c. En el menú ver del administrador de dispositivos selecciona Mostrar dispositivos ocultos.
d. En la parte derecha del administrador de dispositivos, despliega dispositivos que no son plug and play
e. Doble clic en Cluster Disk Driver para abrir la ventana de propiedades
f. En la pestaña de general verificar que Utilizar este dispositivo está habilitado, si no habilítalo
g. En la pestaña Driver verifica que el tipo de arranque sea Sistema, si no selecciona system verifica que el estado sea Arrancado
h. Si el driver de disco de cluster ha sido deshabilitado o el tipo de arranque esta en manual y no esta ejecutándose configúralo de manera correcta y reinicia el nodo y verifica que el servicio de cluster este arrancado, si no está arrancado y aun puedes acceder a los discos a través del Explorer continua con el siguiente paso
8. SI los disco son accesible verifica que si ambos nodos del cluster están arrancados, si lo están apagad uno de ellos para reducir la posibilidad de corrupción de datos antes de reparar las firmas.
Como reparar las firmas que han cambiado
Cuando un recurso de disco físico es creado, la firma del disco es almacenada en el GUID del recurso en la subclave Parameters en el hive de cluster
Las siguientes imágenes muestran el GUID de un recurso de disco físico de un disco de Quorum y la subclave de parameters donde esta almacenada la firma,
Para reemplazar las firmas hay 2 herramientas:
Cluster recovery tool
1. Añade de nuevo el disco en el administrador de cluster
2. Utiliza la herramienta cluster recovery la cual reconstruirá las dependencias del disco y asignara a la nueva unidad la letra correspondiente.
3. Borra el recurso de disco fallido
Dumpcfg.exe
1. Utiliza dumpcfg.exe para reemplazar la firma del disco siguiendo los pasos de el siguiente articulo 280425 Recovering from an Event ID 1034 on a Server Cluster.
Juan Bautista Arlandis
Tecnico de Soporte Microsoft Premier.
Administrando Roles, Role Services y Features desde línea de comandos
Para realizar esta operación utilizaremos la herramienta ServerManagerCmd que en todos los casos lanzaremos con privilegios elevados desde una ventana de línea de comandos.
Consultando Roles, Role Services y Features instalados
Empezaremos por mostrar los Roles, Roles services y Features instalados ejecutando servermanagercmd –query y obtenido una salida del tipo que parece más abajo, donde aparecen en color verde las distintas partes instaladas.
Como en versiones de anteriores podemos redireccionar la salida del comando a un fichero de texto, con tan solo utilizar el símbolo de redirección “>”
ServerManagerCmd –query > ServerConfig_17Agosto2008.txt
Otra posibilidad es obtener la salida en un fichero xml, para ello basta con escribir a continuación del modificador –query el nombre del fichero. Esta posibilidad facilita la manipulación de los ficheros cuando estamos automatizando tareas.
ServerManagerCmd –query Mifichero.xml
Instalando Roles, Role Services y Features
La sintaxis es sencilla, ServerManagerCMD –install “NombredelComponente” donde el nombre de componente será el nombre del componente a instalar (ver tabla más abajo). Así mismo podemos instalar componentes subordinados utilizando el parámetro –AllSubFeatures del modo siguiente:
ServerManagerCmd –install fs-dfs –allsubfeatures
Como se puede ver el comando anterior instala el Role service “Distributed File System” así como sus subordinados “DFS Namespaces” y “DFS Replication”. Si el resultado es correcto obtendremos una salida similar a esta:
Si para completar la instalación fuera preciso un reinicio, podemos utilizar el modificador –Restart.
Otra posibilidad que se ofrece es simular el resultado que se obtendría si se ejecutara el comando, esta opción se suministra mediante el parámetro -Whatif.
En caso de intentar instalar componentes ya instalados, obtendremos un mensaje similar a este:
Si por algún motivo ServerMangerCmd no fuera capaz de realizar la operación solicitada nos
mostrará un error en color rojo. Por defecto ServerManagerCmd escribe la información detallada de cada operación realizada en la ruta %SystemRoot%\logs\servermanager.log, siendo posible cambiar esta ubicación mediante el parámetro –LogPath o su versión abreviada –L.
ServerMangerCmd –install fs-dfs –allfeatures –logpath c:\logs\install.log
Otro error común es el relativo al uso de argumentos inválidos, en este caso seremos informados mediante un mensaje de salida.
Eliminando Roles, Role Services y Features
La sintaxis es similar a la de instalación ServermangerCmd –remove NombreComponente, con el parámetro –allsubfeatures para desinstalar también los componentes subordinados.
ServerManagerCmd –remove –fs-dfs –allsubfeatures
Al igual que en el proceso de instalación, si fuera necesario un reinicio para completar la eliminación se podría incluir el parámetro –Restart y simular el resultado del comando mediante el parámetro –Whatif
Paloma García Martín
En un porcentaje elevado de los casos de soporte es necesaria la obtención, o el análisis, de un volcado de memoria de la máquina para llegar a conocer quien o quienes pueden ser los responsables de una caída inesperada de la máquina, un bloqueo o una degradación en su rendimiento.
Lo mas conveniente es tener el servidor configurado de forma que, en caso de caída inesperada, se genere un volcado automático y este pueda ser analizado con posterioridad.
Para configurar la máquina habremos de seguir los siguientes pasos:
Cómo seleccionar opciones de volcado de memoria
Se pueden generar tres tipos de archivos de volcado de memoria. Seleccione uno antes de desencadenar el archivo de volcado manualmente. Para ello, siga estos pasos:
1. Haga clic con el botón secundario del ratón en Mi PC y, a continuación, haga clic en Propiedades.
2. En la ficha Opciones avanzadas, haga clic en el botón Configuración de Inicio y recuperación.
3. Haga clic en Escribir información de depuración y, a continuación, seleccione Volcado de memoria completa o la opción que deseemos configurar.
También podemos configurar aquí donde quedará guardado el fichero definitivo.
Hemos de tener en cuenta que se generará un fichero temporal en la unidad de sistema, y durante el inicio de la máquina, tras el volcado, este fichero pasará a la ubicación indicada en esta opción, por lo que deberemos de tenerlo en cuenta a la hora de administrar el espacio en disco.
Por esto es muy importante tener al menos un archivo de paginación con el tamaño de la memoria física en la unidad de sistema, si se encuentra en otra unidad no podrá generar el temporal no obteniendo el volcado.
Estas mismas opciones están en el registro, en la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
Con los valores:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl CrashDumpEnabled REG_DWORD 0x0 = None CrashDumpEnabled REG_DWORD 0x1 = Complete memory dump CrashDumpEnabled REG_DWORD 0x2 = Kernel memory dump CrashDumpEnabled REG_DWORD 0x3 = Small memory dump (64KB)
Algunos valores adicionales CrashControl:
0x0 = Disabled 0x1 = Enabled AutoReboot REG_DWORD 0x1 DumpFile REG_EXPAND_SZ %SystemRoot%\Memory.dmp LogEvent REG_DWORD 0x1 MinidumpDir REG_EXPAND_SZ %SystemRoot%\Minidump Overwrite REG_DWORD 0x1 SendAlert REG_DWORD 0x1
Se necesita un reinicio para habilitar las opciones configuradas con antelación.
Obtenido de:
307973 How to configure system failure and recovery options in Windows
http://support.microsoft.com/default.aspx?scid=kb;EN-US;307973
254649 Overview of memory dump file options for Windows Server 2003, Windows XP, and Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;EN-US;254649
274598 Complete memory dumps are not available on computers that have 2 or more gigabytes of RAM
http://support.microsoft.com/default.aspx?scid=kb;EN-US;274598
En los casos en que se queda la máquina bloqueada se puede generar un volcado mediante el teclado que nos permita analizar que estaba haciendo en el momento de cuelgue y cuál puede ser el causante.
También se puede emplear para comprobar si el volcado se realiza correctamente en caso de no estar seguros que este correctamente configurado, la forma de configurarlo está reflejado en el artículo siguiente.
Habilitar el Scroll Lock dump –
Para lanzar el volcado de memoria se deberá pulsar la siguiente combinación de teclas:
CTRL+SCROLL LOCK+SCROLL LOCK
Esta opción se habilita en un equipo que utiliza un teclado PS/2, siguiendo estos pasos:
1.Inicie el Editor del Registro.
2.Busque la siguiente sub clave del Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
3.En el menú Edición, haga clic en Agregar valor y agregue la entrada siguiente del Registro:
Nombre: CrashOnCtrlScroll Tipo de datos: REG_DWORD Valor: 1
4.Cierre el Editor del Registro y reinicie el equipo
Para el caso de teclado USB se precisa una versión especial del driver Kbdhid.sys, el cual solo está desarrollado para sistemas servidor y disponible como hotfix.
En el momento que se pulse la combinación aparecerá nuestra querida pantalla azul con el siguiente mensaje:
*** STOP: 0x000000E2 (0x00000000,0x00000000,0x00000000,0x00000000) The end-user manually generated the crashdump.
Habrá que esperar a que el contador llegue a cien y se reinicie la maquina (en caso de estar seleccionado el reinicio en las opciones del volcado) para que se genere el volcado complete de memoria al disco.
244139 Windows feature lets you generate a memory dump file by using the keyboard
http://support.microsoft.com/default.aspx?scid=kb;EN-US;244139
Cuando no se genera el volcado a pesar de estar la máquina correctamente configurada es muy importante revisar que no tenga configurado o habilitado opciones como Automatic System Restart (ASR) de Compact o elementos similares de otros proveedores, estos se suelen administrar desde las opciones de la BIOS de la máquina.
También se tiene que cumplir la siguiente condición en cuanto a la configuración del disco y el archivo de paginación:
Si se selecciona la opción volcado de memoria completa, se debe tener en el volumen de arranque del sistema un archivo de paginación que sea suficiente para contener toda la memoria física RAM mas 1MB (megabyte). Por defecto el volcado de memoria completa se escribe en el fichero %SystemRoot%\Memory.dmp.
Esto es debido a que en la partición del sistema se aloja el fichero temporal donde se vuelca la memoria hasta el inicio de la máquina y copiado a la unidad seleccionada en las propiedades de la máquina.
Se pueden realizar las mismas opciones para las máquinas virtuales, en este articulo se especifica cómo hacerlo para Virtual Server 2005.
928839 How to use the keyboard to generate a memory dump file on a Virtual Server 2005 guest computer
http://support.microsoft.com/default.aspx?scid=kb;EN-US;928839
Toda esta información aplica a las versiones de W2000, Windows 2003 y Windows 2008 Server.
Espero que esta información facilite la obtención de datos para poder solucionar situaciones que, en algunos casos, resultan críticas para una empresa.
Técnico de Soporte Premier
En repetidas ocasiones, hemos tenido casos en los que se nos pregunta cómo administrar aquellos atributos de una cuenta del DA que no son accesibles desde la consola Active Directory Users and Computers. Lo que veremos a continuación es cómo, a través de un script .vbs, nos ayudaremos de los menús contextuales de la consola para acceder a un atributo determinado y darle el valor que nosotros deseemos.
Lo expuesto a continuación no agregará ningún campo adicional en ninguna de las pestañas del cuadro Propiedades de la cuenta seleccionada.
A modo ilustrativo, tomaremos como ejemplo el atributo EmployeeID (ya existente en el esquema del DA).
En primer lugar, necesitaremos el siguiente script:
eid.vbs
Dim oVar
Dim oUsr
Dim tmp
Set oVar = Wscript.Arguments
Set oUsr = GetObject(oVar(0))
tmp = InputBox("The Employee ID of the user is: " & oUsr.employeeID &vbCRLF & vbCRLF & "If you would like enter a new
number or modify the existing number, enter the new number in the textbox below")
if tmp <> "" then oUsr.Put "employeeID",tmp
oUsr.SetInfo
Set oUsr = Nothing
WScript.Quit
1. Abrir la consola Active Directory Services Interfaces (ADSI) Edit (adsiedit.msc), desplegar la partición de Configuración CN=Configuration,DC=midominio,DC=local, y navegar hasta CN=C0A, CN=DisplaySpecifiers,CN=Configuration,DC=midominio,DC=local.
Este paso es dependiente del lenguaje de nuestro sistema operativo. Para el caso del Español su código correspondiente es C0A, para el Inglés es 409, etc…
Podéis encontrar una relación de los idiomas con su correspondiente código aquí.
2. En el panel de la derecha, hacer clic derecho sobre CN=user-Display y seleccionar Propiedades.
3. En la lista de atributos, hacer clic sobre adminContextMenu, pulsar el botón Editar y agregar lo siguiente (sin las comillas):
“,&Employee ID..., C:\Ruta\eid.vbs”
Nota: Debemos asegurarnos de tener el script .vbs en la ruta indicada en la máquina desde la que utilizaremos la consola Active Directory Users and Computers.
4. Al abrir la consola Active Directory Users and Computers y al pulsar botón derecho sobre las propiedades de una cuenta de usuario, tendremos disponibles una nueva opción (“Employee ID…”) en el menú contextual desde donde podremos consultar/editar el atributo:
5. Dado que inicialmente no podemos agregar estos dos atributos desde el menú Ver-> Añadir/Eliminar Columnas, para poder realizar listados de las cuentas por EmployeeID, es necesario realizar lo siguiente:
· Abrir consola ADSI Edit
· Localizar y doble clic en organizationalUnit-Display bajo CN=C0A, CN=DisplaySpecifiers,CN=Configuration,DC=midominio,DC=local.
· Modificar el atributo extraColumns y agregar lo siguiente employeeid,Employee ID,1,100,0
Nota: Nótese que lo estamos haciendo a nivel de Unidad Organizativa. Si deseamos disponer de listados a nivel de Contenedor (como por ejemplo Users o Computers), será necesario realizar los mismos pasos para el atributo container-Display.
Una vez realizados estos pasos, ya estará disponible el atributo employeeID en el menú Ver-> Añadir/Eliminar Columnas para poder obtener un listado como este:
Hola de nuevo,
Hoy veremos dónde se almacena la información correspondiente a las zonas integradas en Directorio Activo.
Para ello, antes tenemos que recordar que en Windows Server 2003 se introdujeron las nuevas Particiones de Aplicación. Las dos particiones de aplicación que se crean por defecto para DNS son ForestDNSZones y DomainDNSZones. También es posible crear nuevas particiones de aplicación mediante las herramientas ntdsutil y dnscmd.
Cuando se crea/configura una zona DNS integrada en DA en Windows Server 2003 y Windows Server 2008, por defecto hay tres opciones disponibles para el ámbito de replicación:
1. To all DNS servers in the Active Directory forest midominio.local
Si seleccionamos esta opción, la información de la zona midominio.local se almacena en la partición de aplicación ForestDNSZones bajo el contenedor MicrosoftDNS:
CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=local
Esta información va a ser replicada por todos los servidores DNS (que también sean DCs) del bosque.
2. To all DNS servers in the Active Directory domain midominio.local
Si optamos por esta segunda opción, la información de la zona midominio.local se almacenará en la partición de aplicación DomainDNSZones bajo el contenedor MicrosoftDNS:
CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=local
Esta información va a ser replicada por todos los servidores DNS (que también sean DCs) del dominio.
3. To all domain controllers in the Active Directory domain midominio.local
La tercera opción corresponde a la forma clásica (Windows 2000) de almacenar las zonas DNS en Directorio Activo. Concretamente, la información de la zona midominio.local se almacenará en esta ocasión en la propia partición del dominio, bajo el contenedor MicrosoftDNS dentro de System:
CN=MicrosoftDNS,CN=System,DC=domain,DC=local
Esta información va a ser replicada por todos los Controladores de Dominio (DCs) del dominio así como por todos los DCs que sean Catálogos Globales (GCs) en el bosque.
Existe una cuarta opción disponible una vez se han creado nuevas particiones de aplicación: To all domain controllers specified in the scope of the following application directory partition. De esta manera, podremos seleccionar qué DCs específicos replican dicha partición y que sean ellos, por tanto, los que sirvan la zona DNS en la que se ha especificado que el ámbito de replicación corresponda a dicha partición.
Recomendaciones generales
Las recomendaciones generales (siempre habría que tener en cuenta las peculiaridades del entorno particular) en cuanto al almacenamiento de zonas en Directorio Activo son las siguientes:
· Si algún servidor DNS es Windows 2000 Server, habría que configurarlas para que replicaran a todos los DCs del dominio, por lo que la zona se almacenaría en la partición de dominio. De esta manera, los servidores DNS Windows 2000 Server podrían almacenar, cargar y servir dicha zona.
· Si todos los servidores DNS son Windows Server 2003, se recomienda que las zonas se almacenen en las nuevas particiones de aplicación que presenta Windows Server 2003:
o Las zonas que deban estar en todos los servidores DNS del dominio se almacenarán en la partición de aplicación DomainDNSZones
§ Para las nuevas zonas DNS creadas a partir de Windows Server 2003, esta es la configuración por defecto
§ Se recomienda configurar las zonas correspondientes a cada dominio con este tipo de replicación, de tal manera que todos los DNS de dicho dominio tengan la zona y no se replique a los GC del bosque, evitando así replicación y almacenamiento innecesarios.
§ Con esta configuración también se logra separar la información propia de AD (usuarios, equipos, grupos, etc.) de los datos de las zonas DNS
o Las zonas que deban estar en todos los servidores DNS del bosque se almacenarán en la partición de aplicación ForestDNSZones
§ Se recomienda configurar de este modo la zona _msdcs.midominio.local para que puedan cargarla todos los servidores DNS del bosque
Los datos de una zona almacenada en una partición de aplicación de DA no se replican a los GC del bosque, mientras que los datos almacenados en la partición del propio dominio sí se replican a los GC. Al utilizar particiones de aplicación, por tanto, se reduce el tráfico generado en la red así como la cantidad de datos replicados, ya que sólo los DCs que sean servidores DNS van a llevar a cabo la replicación de dichas particiones, dependiendo además del dominio/bosque al que pertenezcan.
Se puede encontrar más información sobre la configuración de la replicación de las zonas DNS y las recomendaciones generales en los siguientes enlaces:
· DNS zone replication in Active Directory
· Use DNS Application Directory Partitions
Dado que muchos de nuestros sistemas están en otros idiomas diferentes al inglés (español fundamentalmente) este es una situación que se nos puede presentar con facilidad.
Para solventar esta situación se ha publicado el artículo referente a MDT 2008 al que se puede acceder desde http://support.microsoft.com/?id=952573
En resumen, este error se debe a que el script Ztibcdutility.vbs se queda esperando un “Successfully” tras la ejecución de BcdEdit y si el sistema no esta en US.English esto no ocurre, por lo que la fase de edición del arranque no es correctamente actualizada.
Para solucionarlo habrá que modificar el script Ztibcdutility.vbs del siguiente modo:
1. En MDT 2008 en la carpeta de distribución abrir la carpeta "scripts".
2. Editar el script Ztibcdutility.vbs
3. Localizar el código que contiene la función CreateNewRamDiskEntry
If iRetVal <> Failure Then
arrTemp = split(iRetVal, " ")
sNewGuid = arrTemp(2)
Else
CreateNewRamDiskEntry = iRetVal
Exit Function
End If
Borrar el código original y cambiarlo por el siguiente:
Dim aGuidTemp
arrTemp = split(iRetVal, "{")
aGuidTemp = split(arrTemp(1), "}")
sNewGuid = "{" & aGuidTemp(0) & "}"
4. Localizar la function RunBCDEdit
5. Utilizar el siguiente código para reemplazar la función original de RunBCDEdit
Function RunBcdEdit (sCommand, bCapture)
Dim iRetVal, oExec, sLine,oExec1, sLine1,arrTemp1
Dim re
sBcdEdit = oEnv.Item("SystemRoot") & "\system32\bcdedit.exe"
If not oFSO.FileExists(sBcdEdit) Then
SetBcdError ("Unable to locate bcdedit.exe")
RunBcdEdit = Failure
sCommand = sBcdEdit & " " & sCommand
Set oExec = oShell.Exec(sCommand)
sLine = oExec.StdOut.ReadLine
if bCapture = True Then
iRetVal = sLine
iRetVal = Success
RunBcdEdit = iRetVal
End Function
Espero que esta información ayuda a solucionar algunas situaciones comprometidas a la hora de preparar una instalación distribuida de nuestros sistemas en otros idiomas.
Tecnico de Soporte Premier España
Soy Paula, del equipo de Directorio Activo. Recientemente tuvimos un caso en el que un usuario deshabilitado podía realizar una conexión a LDP y no recibía ningún error (aunque posteriormente no podía navegar por el árbol de la partición del dominio).
A la hora de realizar el BIND mediante la herramienta LDP.EXE, el mensaje recibido era el siguiente (indicando aparentemente que se había realizado la autenticación con las credenciales del usuario deshabilitado user1):
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='user1'; Pwd= <unavailable>; domain = 'haledomain'.}
Authenticated as dn:'user1'.
Si obtenemos unas trazas de red de dicha conexión, se muestra un BIND exitoso:
Hora
Origen
Destino
Prot
Detalles
12:59:07.370
192.168.1.1
192.168.1.2
LDAP
LDAP:Search Request, MessageID: 32, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
12:59:07.380
LDAP:Search Result Entry, MessageID: 32
12:59:14.269
LDAP:Search Request, MessageID: 33, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
12:59:14.280
LDAP:Search Result Entry, MessageID: 33
12:59:14.770
LDAP:Bind Request, MessageID: 35, Version: 3
12:59:14.780
LDAP:Bind Response, MessageID: 35, Status: Sasl Bind In Progress
12:59:14.790
LDAP:Bind Request, MessageID: 36, Version: 3
12:59:14.981
LDAP:Bind Response, MessageID: 36, Status: Success
En condiciones normales, un usuario deshabilitado no puede realizar una conexión LDAP a Directorio Activo ya que se deniega su acceso indicando que sus credenciales son inválidas:
Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: 8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece
Este mensaje de red se puede observar también en la respuesta obtenida del DC (servidor LDAP) en las trazas de red:
13:12:04.417
LDAP:Search Request, MessageID: 73, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
LDAP:Search Result Entry, MessageID: 73
13:12:12.208
LDAP:Bind Request, MessageID: 76, Version: 3
LDAP:Bind Response, MessageID: 76, Status: Sasl Bind In Progress
LDAP:Bind Request, MessageID: 77, Version: 3
13:12:12.278
LDAP:Bind Response, MessageID: 77, Status: Invalid Credentials
Revisando el visor de sucesos de Seguridad del DC de nuestro entorno de pruebas tras realizar el intento de conexión con el usuario deshabilitado user1, observamos la siguiente secuencia de eventos:
Event Type: Failure Audit
Event Category: Account Logon
Event ID: 672
Date: 8/14/2008
Time: 1:09:24 PM
User: NT AUTHORITY\SYSTEM
Authentication Ticket Request:
User Name: user1
Supplied Realm Name: haledomain
User ID: -
Service Name: krbtgt/haledomain
Service ID: -
Ticket Options: 0x40810010
Result Code: 0x12
Ticket Encryption Type: -
Pre-Authentication Type: -
Client Address: 127.0.0.1
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
Event Category: Logon/Logoff
Event ID: 552
User: HALEDOMAIN\administrator
Logon attempt using explicit credentials:
Logged on user:
User Name: administrator
Domain: HALEDOMAIN
Logon ID: (0x0,0x27F79)
Logon GUID: {94b7a00d-5198-8f5c-d90b-566add369611}
User whose credentials were used:
Target User Name: user1
Target Domain: haledomain
Target Logon GUID: -
Target Server Name: HALEDC01.haledomain.com
Target Server Info: HALEDC01.haledomain.com
Caller Process ID: 3256
Source Network Address: -
Source Port: -
Event ID: 680
Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: user1
Source Workstation: HALEDC01
Error Code: 0xC0000072
Event ID: 531
Logon Failure:
Reason: Account currently disabled
Domain: haledomain
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: HALEDC01
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 192.168.1.1
Source Port: 2768
En cambio, en el visor de sucesos del DC del entorno que aparentemente autenticaba al usuario deshabilitado se podían ver los siguientes eventos:
Time: 1:06:53 PM
User: HALEDOMAIN\Guest
Logon account: Guest
Error Code: 0x0
Los tres primeros eventos son iguales en ambos casos:
· El evento 672 indica que se ha intentado realizar una autenticación por KERBEROS con el usuario user1 y se ha devuelto el error 0x12. Este código de error se traduce al siguiente mensaje que indica que el usuario ha sido “revocado”:
KDC_ERR_CLIENT_REVOKED à Clients credentials have been revoked
· El evento 552 indica que se está intentado realizar una conexión al DC utilizando el usuario user1.
· A continuación se muestra el evento 680 indicando que el intento de autenticación del usuario user1 ha resultado fallido y proporciona el código de error 0xC0000072 correspondiente al siguiente mensaje (cuenta de usuario deshabilitada):
STATUS_ACCOUNT_DISABLED à The referenced account is currently disabled and may not be logged on to.
El evento que aparece a continuación de los anteriores es distinto en ambas situaciones:
· En el primer caso (el usuario no puede realizar la conexión LDAP – comportamiento esperado), se recibe el evento 531 indicando que la cuenta de usuario está actualmente deshabilitada: Account currently disabled
· En el entorno que aparentemente permite la conexión del usuario aparece el mismo intento fallido de autenticación pero se observa que, inmediatamente después, existe un intento exitoso de autenticación del usuario Invitado o Guest (evento 680).
Por lo tanto, en realidad no es el usuario user1 el que se está autenticando en el BIND de la conexión LDAP (aunque sea esa la percepción desde el cliente LDAP), sino que su autenticación es denegada y automáticamente se realiza otra autenticación con el usuario Invitado porque dicho usuario se encontraba HABILITADO en el entorno.
La razón de que el usuario posteriormente no pudiera acceder a los datos de la partición del dominio era precisamente por haber realizado la autenticación con la cuenta Invitado, ya que por defecto esta cuenta no tiene permisos de lectura sobre AD.
Es importante resaltar que la recomendación es que la cuenta Invitado permanezca deshabilitada por motivos de seguridad.
Más información sobre la cuenta Invitado (Guest):
User and computer accounts
Threats and Countermeasures. Chapter 5: Security Options
Microsoft Security: Windows 2000 Server Baseline Security Checklist
Ante el paso de máquinas virtuales de los sistemas actuales de virtualización a Hyper-V se deben tener en cuenta una serie de factores antes de incluir directamente los vhd en un servidor el rol habilitado y arrancar las máquinas en él, con esto nos evitaremos sorpresas y algún que otro quebradero inesperado.
Aparte de las recomendaciones habituales del manual como no tener las máquinas en estado guardado, encontrarse todas en el estado apagado, … estas son algunas situaciones en las que nos podremos encontrar tras la actualización.
1. Licenciamiento ante el cambio a Hyper-V
Algo que debemos de tener en cuenta ante el cambio a Hyper-V es que el sistema operativo de la máquina cliente (child partition) deja de emplear los driver genéricos de virtualización y el hardware emulado para pasar a emplear, a través del bus de Hyper-V, los recursos físicos de la máquina W2K8.
Esto supone que se registran una serie de modificaciones en el hardware de la máquina que pueden obligar a volver a activar la licencia , es conveniente tenerlo en cuenta ya que el proceso de activación puede requerir un acceso a internet o, en caso de no disponer de este acceso, una activación por teléfono.
Por si surge el caso, para la activación por teléfono bastara con marcar esta opción de activación y aparecerá el teléfono de contacto según el país en el que nos encontremos.
2. Que ocurre con los archivos de configuración de la máquina
Con el paso a Hyper-V cambia el formato de los archivos de configuración de las máquinas virtuales siendo este .xml.
Esto supone que los archivos de configuración de la maquina (memoria, red, ...) deben ser generados de nuevo para que se apliquen a la antigua máquina virtual.
El formato del vhd sigue siendo compatible, con lo que el fichero vhd antiguo no precisa ninguna modificación para que sea aceptado por Hyper-V.
3. Como actuar cuando la antigua máquina tiene Virtual Machine Additions
En este punto hay que ser especialmente cuidadoso ya que podemos dejar la antigua maquina en un estado inestable.
Siempre se deben desinstalar la virtual machine additions antes del paso a Hyper-V.
Esto es así ya que, en caso de tener la maquina estas instaladas no se permite la instalación de las Integration Services .
Pero una vez que la maquina esta en Hyper-V las virtual machine additions no pueden ser desinstaladas, ya que, al emplear los drivers nuevos para hyper-v la maquina se considera física, no virtualizada, y da un error a la hora de proceder a su desinstalación.
4. ¿Y si mi máquina virtual es W2K3 SP1?
Las versiones soportadas con Hyper-V se pueden comprobar en el artículo siguiente:
http://support.microsoft.com/kb/954958/en-us
la pregunta es, ¿cómo es que W2K3 no aparece que este soportado como sistema cliente su versión con SP1?
Esto no supone que no funcione esta version en Hyper-V, supone que no ha sido testeado y las mejoras de cara a su administración incluidas en los Integration Services, como integrar el ratón en sesiones de administración establecidas mediante terminal server, y otras, no están disponibles para esta versión ni pueden ser instaladas.
Soporte Core Premier España
Continuamos con las novedades de Windows Server 2008. Como muchos ya sabréis, Server 2008 incluye un rol que nos permite promocionar un nuevo tipo de Controlador de Dominio (DC): el Read-Only DC (RODC).
En el enlace adjunto podéis descargar la presentación de nuestro compañero Raúl González sobre los RODC. Esperamos que esta información os ayude a comprender la funcionalidad y finalidad de este nuevo tipo de Controlador de Dominio.
Un saludo a tod@s
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:
Esperamos que os resulte interesante :)
Saludos.
Retomamos la serie de novedades en Windows Server 2008 con la presentación que realizó nuestro compañero Tolu Igbon sobre las nuevas "Fine Grained Password Policies".
Esta novedad cubre una funcionalidad que se ha pedido durante largo tiempo y que finalmente tenemos disponible y consiste en la posibilidad de definir diferentes políticas de contraseñas y bloqueo de cuentas para distintos usuarios en el dominio.
Ahora, con Windows Server 2008, ya podemos establecer distintas políticas de este tipo para distintos usuarios en un mismo dominio.
Un saludo.
Continuando con las presentaciones que realizamos respecto a las novedades en W2K8 hoy publicamos la presentación realizada por nuestro compañero Francisco Fraile sobre los múltiples cambios que se han producido en esta tecnología con el nuevo sistema operativo.
Os la dejo en el link adjunto.
Hasta la próxima tecnología.
Hola a tod@s de nuevo.
Hoy publicaremos la presentación de realizó nuestro compañero Raúl del Moral sobre las novedades, que son muchas, en el área de instalación, automatización de la instalación y nuevas formas de activación de los sistemas operativos Vista SP1 y W2k8.
Esperamos que esto ayude a aclarar muchas de las consultas que estamos recibiendo, no olvidéis revisar la última parte de la presentación, en ella esta los accesos a la documentación disponible con la información de las novedades y ejemplos de configuración.
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.
Hoy vamos a publicar la presentación realizada por nuestra compañera Paloma Garcia Martin sobre las novedades que presenta Windows 2008 en cuanto a la administración de Clúster.
Esperamos que esta os resulte de utilidad para poder administrar con mas facilidad estas funcionalidades añadidas o modificadas en esta nueva versión.
Un saludo a tod@s.
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.
Hola a todos de nuevo.
Continuando con las presentaciones de las nuevas herramientas incluidas en W2K8 para la administración del sistema, hoy publicamos la presentación que realizo nuestro compañero de soporte Juan Bautista Arlandis sobre las nuevas herramientas que se incluyen para la administración de impresión.
Esperamos que os resulte de utilidad y aclare las nuevas funcionalidades de Windows 2008 que esperamos ayuden a simplificar esta tarea de administración.
Hola,
Como primer post técnico vamos a subir una presentación que hizo nuestra compañera Yolanda Muñoz Muñoz sobre la herramienta Database Mounting Tool en Windows Server 2008. Esta herramienta nos permite generar y examinar "fotos" de los datos almacenados en AD DS o AD LDS sin reiniciar los Controladores de Dominio o Servidores de AD LDS.
Para poder acceder a la presentación, basta con hacer click sobre en enlace de Attachments bajo el post.
Esperamos que os sirva de ayuda para comenzar a utilizar la herramienta.
Hola, somos el equipo de soporte Microsoft a plataformas a nivel empresa de España, y hemos creado este blog para comenzar a presentaros información sobre las nuevos Sistemas Windows Vista SP1 y Windows Server 2008.
En breve comenzaremos a incluir información sobre las novedades que estos sistermas presentan y todas las funcionalidades relacionadas con el Core del Sistema, Directorio Activo y Redes, que son las áreas que fundamentalmente soportamos como grupo.