Buscar

Mostrando entradas con la etiqueta Active Directory. Mostrar todas las entradas
Mostrando entradas con la etiqueta Active Directory. Mostrar todas las entradas

Windows: Instalar dfsrdiag

En este post veremos como instalar el comando dfsrdiag en Windows Server.

Contraseña KRBTGT - Active Directory

¿Qué es la cuenta KRBTGT?

La cuenta de usuario: KRBTGT es una cuenta que se crea automáticamente al promocionar el primer controlador de dominio del dominio (DC).

PowerShell: Copiar grupos de un usuario a otro

En este post veremos cómo copiar la membresía de grupos de seguridad de un usuario a otro.

Windows: Zona DNS _msdcs ¿Qué es?

En la consola de administración de DNS en Active Directory, veremos la zona con el nombre del dominio y una segunda zona con el nombre _msdcs seguido del nombre de dominio.

Active Directory: Delegar restablecer contraseña

En ciertas ocasiones, nos vemos con la necesidad de delegar la posibilidad de restablecer la contraseña a un usuario.

En entornos de Active Directory, podemos delegar la administración de una unidad organizativa a un usuario o grupo especificando las funciones a delegar.

Active Directory: Usuario no puede cambiar password

Una consulta técnica muy interesante que me han realizado es la siguiente:

Escenario:

En un entorno de Active Directory:

- Un usuario no puede cambiar el password, en cambio el administrador si puede hacerlo.

- La opción de la ficha del usuario: "El usuario no puede cambiar la contraseña" (*) está desmarcada.

(*) Usuarios y equipos de Active Directory (dsa.msc), propiedades sobre un usuario, pestaña "Cuenta", apartado "Opciones de cuenta", opción: "El usuario no puede cambiar la contraseña". 

VMWare: Añadir ESXi al dominio de Active Directory

A partir de VMWare ESXi 4.1 podemos integrar nuestros hosts VMWare ESXi a un dominio de Active Directory.

De esta forma podremos utilizar credenciales de cuentas de Active Directory para iniciar sesión en los hosts ESXi o Virtual Center.

Para añadir un host VMWare ESXi a un dominio de Active Directory, en primer lugar deberemos configurar el TCP/IP de la red de management, concretamente:

- IP y máscara de subred que disponga de conectividad con nuestro o nuestros controladores de dominio (DC).

- DNS Server: La dirección IP del DNS Server del dominio de Active Directory.

Podemos configurar el TCP/IP de la red de management utilizando la consola del host VMWare ESXi:

F2 > Introducimos las credenciales > "Configure Management Network":

Vista consola host ESXi, cambio del TCP/IP

Windows: Buscar administradores locales

Como administradores de sistemas, una de las configuraciones que debemos tener controladas en nuestra red son los usuarios con permisos de administrador local en los equipos

Un usuario con derechos de administrador local en un equipo podría causar daños importantes en el equipo, para evitar este problema siempre se recomienda que el usuario disponga de derechos de usuario y no de administrador en su equipo.

Sin embargo, existen aplicaciones que requieren derechos de administrador en el equipo. Este tipo de aplicaciones, posiblemente diseñadas de forma incorrecta, nos pueden forzar a que el usuario requiera permisos de administrador sobre el equipo.

En estos casos es buena idea documentar los usuarios que disponen de derechos de administrador en su equipo.

Para ello, podemos utilizar la GPMC (Group Policy Management Console) y crear GPOs (Políticas, preferencias o scripts) que otorguen los permisos de administrador a ciertos usuarios sobre ciertos equipos, de esta forma tendremos documentado en la GPMC los usuarios que disponen de derechos de administrador sobre sus equipos.

Si no disponemos de documentación, una opción es utilizar la siguiente herramienta gratuita:

Get Local Admins GUI

La herramienta puede descargarse se forma gratuita en:


Esta herramienta de entono gráfico, nos permite buscar administradores locales en todos los equipos.

Vista resultado de su ejecución:

Vista herramienta: Get Local Admins GUI

Veamos su funcionamiento:

Después de instalar la herramienta en un equipo añadido al dominio de Active Directory, ejecutamos la herramienta con credenciales de administrador del dominio.

La idea es que la herramienta disponga de los permisos suficientes para conectar a cada equipo del dominio y realizar una consulta de quienes pertenecen al grupo local "Administradores".

Si el usuario con el que ejecutamos la herramienta está dentro del grupo "Administradores del dominio", no tendremos ningún problema, la herramienta podrá conectar a todos los equipos del dominio.

Si el usuario con el que ejecutamos la herramienta no está dentro del grupo "Administradores del dominio", podemos ejecutar la herramienta como otro usuario: pulsamos mayúsculas y botón derecho sobre el acceso directo, a continuación veremos la opción de: "Ejecutar como otro usuario"

Una vez cargada la herramienta, veremos el botón "Import from Active Directory".

Con esta opción, podremos seleccionar la unidad organizativa o contenedor donde están ubicados los equipos, a partir de aquí, se generara una lista.

Al pulsar "Start", se realizarán pings a cada equipo y se conectará a cada uno de ellos en busca del grupo local "Administradores" y nos mostrará los miembros de este grupo.

También puede que nos aparezca la siguiente ventana con errores:

Vista herramienta: Get Local Admins GUI - Equipos no encontrados

Esto significa que una serie de equipos o bien están apagados o bien no responden a ping o bien han sido retirados del dominio y el objeto continua en Active Directory.

Una vez obtenidos los resultados, en la pestaña "Export" del programa, podremos exportar los resultados a CSV o HTML.

La herramienta, también nos ayudará a detectar cuentas locales con derechos de administrador tipo: "Admin", etc fruto de la instalación manual del sistema operativo.

Windows: Reset password administrador del dominio

Especialmente en sistemas heredados, nos podemos encontrar con la necesidad de tener que cambiar el password de administrador del dominio sin poder iniciar sesión previamente en el controlador o controladores de dominio.

Veamos la ubicación donde se guarda la contraseña:

- En entornos de Active Directory, el password de administrador del dominio queda guardado en la base de datos de Active Directory, por defecto en: C:\Windows\NTDS\NTDS.dit. La ruta de la base de datos es definida en el proceso de promoción del equipo a controlador de dominio.

- En entornos de workgroup o cuentas locales, el password de administrador queda guardado en el registro de Windows en la rama de seguridad.

Existen herramientas de terceros de Windows para realizar un reset del password.

Este tipo de herramientas puede que no funcionen sobre sistemas con Active Directory, ya que estas herramientas, conectan con el registro de Windows y eliminan el hash correspondiente al password de una cuenta de usuario.

De todas formas, como norma general: Hemos de entender que cualquier sistema operativo donde disponemos de acceso local al mismo, siempre podremos restablecer el acceso de una forma o de otra.

Veamos un procedimiento para realizar un reset del password de administrador del dominio:


* Este procedimiento será valido tanto para realizar un reset del password de cuentas de usuario locales como para cuentas de usuario de dominio, incluida la cuenta de administrador.

Idea: Acceder al sistema de ficheros NTFS de un controlador de dominio (DC), substituir el fichero de la lupa (magnify.exe): "opciones de accesibilidad" por el cmd.exe, reiniciar normalmente y antes de iniciar sesión, ejecutar la lupa. 

Dispondremos de una shell de CMD con permisos de SYSTEM, con los servicios de Active Directory levantados. A partir de aquí, podremos hacer un reset del password de administrador del dominio.

1) Accedemos al sistema de ficheros NTFS:

Una de las formas para acceder al sistema de ficheros NTFS es iniciar el equipo desde un DVD/ISO de Windows Server o Windows cliente.

No es necesario que el DVD/ISO sea la misma versión de sistema Windows que la que tenemos instalada en el controlador de dominio (DC), ya que tan solo necesitamos poder escribir en el sistema de ficheros NTFS.

Veamos como iniciar desde el DVD/ISO de Windows Server 2012 R2 y obtener una consola de CMD:

Iniciamos el DVD, seleccionamos idioma, seleccionamos "Reparar equipo", "Solucionar problemas", "Símbolo del sistema":

Windows: Administrador del dominio reset password

VMWare y AD: "La relación de confianza entre esta estación de trabajo y el dominio principal falló"

Al iniciar sesión en un equipo añadido al dominio, nos podemos encontrar con el siguiente error:

En castellano:

"La relación de confianza entre esta estación de trabajo y el dominio principal falló"

En inglés:

"The trust relationship between this workstation and the primary domain failed"

El problema es grave, ya que no es posible iniciar sesión con ningún usuario del dominio.

¿Cómo solucionamos problema?

Si buscamos en el technet de Microsoft, veremos como solucionar el problema:

  • Iniciar sesión como administrador local.
  • Configurar el equipo en un WORKGROUP.
  • Añadir de nuevo el equipo al dominio.

Aquí tenéis otro artículo que explica cómo añadir o quitar un equipo del dominio de Active Directory, utilizando PowerShell: 

Windows: Añadir o quitar equipo del dominio con PowerShell (SYSADMIT.com)

Problema resuelto.

Pero...

¿Por qué ocurre?

En resumen, sucede por que el password de equipo almacenado en el DC (Controlador de dominio), no coincide con el password almacenado en el equipo.

En un entorno de Active Directory, el administrador de sistemas acostumbra a tener controlado la expiración de passwords de usuarios, pero no la de los equipos.

La renovación de los passwords de equipo es un proceso transparente para el usuario y el administrador, ambos no realizan ninguna acción.

Por defecto, el valor de renovación del password de equipo se produce cada 30 días desde Windows 2000.

Es el servicio NETLOGON el encargado de realizar el proceso.

Si el proceso es transparente y automático y nos aparece el error ... ¿Por qué ocurre?

Por que hemos retrocedido en el tiempo un equipo añadido al dominio más de 30 días utilizando alguna de estas técnicas:

  • Para equipos físicos: Restore utilizando una imagen.
  • Para equipos virtuales (VDI o servidores miembro virtuales): "Revert to snapshot" o "Restore de la VM" utilizando el software de backups.

¿Cómo evitamos el problema?

Con una GPO de equipo, podemos desactivar la expiración del password de equipo, para equipos añadidos al dominio:

VMWare y AD: password de equipo

Si el DC está en inglés:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options

  • Domain member: Disable machine account password changes
  • Domain member: Maximum machine account password age

Si el DC está en castellano:

Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Opciones de seguridad

  • Miembro de dominio: deshabilitar los cambios de contraseña de cuentas de equipo

  • Miembro de dominio: duración máxima de contraseña de cuenta de equipo

El tratarse de una GPO de equipo que modifica la seguridad, debemos aplicarla a nivel de dominio.

En la ayuda de cada GPO, encontramos la siguiente información:

Miembro de dominio: deshabilitar los cambios de contraseña de cuentas de equipo 

Determina si un miembro de dominio cambia periódicamente su contraseña de cuenta de equipo. Si esta configuración está habilitada, el miembro del dominio no intenta cambiar su contraseña de cuenta de equipo. Si está deshabilitada, el miembro de dominio intenta cambiar su contraseña de cuenta de equipo del modo especificado en la configuración de Miembro de dominio: duración máxima de contraseña de cuenta de equipo, cuyo valor predeterminado es de 30 días.

Valor predeterminado: deshabilitada. 

Notas

Esta configuración de seguridad no debe habilitarse. Las contraseñas de cuenta de equipo se usan para establecer canales de comunicación seguros entre miembros y controladores de dominio y, dentro del dominio, entre los propios controladores de dominio. Una vez establecido, el canal seguro se usa para transmitir información confidencial necesaria para tomar decisiones de autenticación y autorización.

Esta configuración no debe usarse para intentar compatibilizar escenarios de arranque dual que usen la misma cuenta de equipo. Si desea realizar un arranque dual de dos instalaciones unidas al mismo dominio, asigne un nombre de equipo distinto a cada instalación.

Miembro de dominio: duración máxima de contraseña de cuenta de equipo 

Esta configuración de seguridad determina la frecuencia con que un miembro del dominio intentará cambiar la contraseña de su cuenta de equipo.

Valor predeterminado: 30 días.

Importante

Esta configuración se aplica a equipos con Windows 2000, pero no está disponible a través de las herramientas del Administrador de configuración de seguridad en esos equipos.

Más información en:

  • El libro: GPOIT - Group Policy Objects para administradores de IT, para el uso de las directivas de grupo.
  • El libro: ADIT - Active Directory para administradores de IT, sobre los passwords de equipo y otras consideraciones acerca de Active Directory en entorno virtualizado como la prevención de "USN Rollback".

Windows: Server 2016 sin nivel funcional 2003 ni FRS

En este post anterior vimos algunas novedades introducidas en la primera Technical Preview sobre Windows Server 2015/2016:


En Windows Server 2016 las siguientes funcionalidades sobre Active Directory quedan obsoletas (deprecated):

  • Nivel funcional Windows Server 2003.
  • Réplica de SYSVOL FRS (File Replication Service). 

Quedan obsoletas, significa que en la próxima versión de Windows Server serán eliminadas.

Por lo tanto, con la versión final de Windows Server 2016: Es posible migrar un DC Windows Server 2003 a Windows Server 2016.

El proceso de migración de DC a DC, lo encontraremos detallado en el libro sobre Windows Server 2016: WS2016LABS

Libro Windows Server 2016: WS2016LABS (SYSADMIT.com)

Recordando conceptos sobre Active Directory:

  • Ademas de funcionalidades adicionales, el nivel funcional de un dominio o bosque de Active Directory, determina la versión mínima de Windows Server en los controladores de dominio (DC): Por ejemplo, el nivel funcional Windows Server 2008, puede contener controladores de dominio: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, etc pero no Windows Server 2003.
  • Las GPO (directivas de grupo) se almacenan en carpetas y ficheros en el SYSVOL de los DC. La carpeta SYSVOL es replicada en todos los DC utilizando el sistema de réplica FRS (File Replication Service) o DFS-R (Distributed File System Replication). Si en algún momento en el dominio hubieron DC con Windows Server 2003 o anteriores y no se realizó una migración de FRS a DFS-R de forma manual, la replicación que tendremos configurada para el SYSVOL será FRS.

Podemos obtener más información sobre Active Directory y GPOs en los libros:

  • ADIT - Active Directory para administradores de IT
  • GPOIT - Group Policy Objects para administradores de IT 

Referencias:


Apartado: Deprecation of File Replication Service (FRS) and Windows Server 2003 functional levels



Active Directory: Mover los roles FSMO con PowerShell

La herramienta para transferir los roles FSMO (Flexible Single Master Operations) entre controladores de dominio (DC) es ntdsutil.

La herramienta ntdsutil está integrada en todas las versiones de Windows Server.

Con ntdsutil podemos realizar un transfer o un seize. 

El seize solo debe ejecutarse cuando el DC que disponía de los roles FSMO está caído y no será conectado nuevamente a la red.

Siempre los procedimientos de seize van acompañados de una limpieza de Active Directory, DNS, etc.

Active Directory: Mover los roles FSMO con PowerShell

Sin embargo también disponemos del cmd-let de PowerShell: 

Move-ADDirectoryServerOperationMasterRole que también permite la transferencia de roles FSMO de forma más rápida.

Active Directory: Mover los roles FSMO con PowerShell

Ejemplo de procedimiento de TRANSFER con PowerShell:

*El controlador de dominio DC2 será el DESTINO: DC2 recibirá los roles FSMO.

Move-ADDirectoryServerOperationMasterRole -Identity "DC2" -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator

Ejemplo de procedimiento de SEIZE con PowerShell:

*El controlador de dominio DC2 será el DESTINO: DC2 recibirá los roles FSMO.

Move-ADDirectoryServerOperationMasterRole -Identity "DC2" -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator -force

En vez de utilizar nombres, podemos utilizar números para identificar los roles FSMO:

Esta es la equivalencia de números con nombres de los roles FSMO:

0    PDCEmulator
1    RIDMaster
2    InfrastructureMaster
3    SchemaMaster
4    DomainNamingMaster

Ejemplo de TRANSFER de los cinco roles FSMO al DC2 utilizando números para identificar los roles:

Move-ADDirectoryServerOperationMasterRole -identity "DC2" -OperationMasterRole 0,1,2,3,4

Problemas para cambiar la contraseña desde Windows 8.1 y DCs Windows Server 2003


Si disponemos de controladores de dominio (DC) con Windows Server 2003 SP2 y experimentamos problemas con el cambio de contraseña desde el lado cliente sobre sistemas operativos Windows 8.1, podemos revisar si disponemos de los siguientes parches:

En el lado servidor (DC Windows Server 2003 SP2):

Problemas para cambiar la contraseña desde Windows 8.1 y DCs Windows Server 2003


En el lado cliente (Windows 8.1):

Problemas para cambiar la contraseña desde Windows 8.1 y DCs Windows Server 2003


http://support.microsoft.com/kb/2845626/es
 

Active Directory: Ver todos los atributos que son guardados en el catálogo global (GC)

Active Directory: Ver todos los atributos que son guardados en el catálogo global (GC) 
 
Ejemplo de ejecución del comando dsquery sobre el dominio D1.local: 

dsquery * "cn=Schema,cn=Configuration,dc=D1,dc=local" -filter "(&(objectCategory=AttributeSchema)(IsMemberOfPartialAttributeSet=TRUE))" -attr LDAPDisplayName -limit 0
 
Active Directory: Ver todos los atributos que son guardados en el catálogo global (GC)

Active Directory: Mostrar todas las propiedades de un usuario con PowerShell

Con el siguiente cmd-let podemos ver todas las propiedades de un usuario (Xavi) de Active Directory:

Get-AdUser Xavi -Properties *|more

Ejemplo de ejecución sobre un DC con Windows Server 2012:

Active Directory: Mostrar todas las propiedades de un usuario con PowerShell


Siguiente página:

Active Directory: Mostrar todas las propiedades de un usuario con PowerShell

Siguiente página:

Active Directory: Mostrar todas las propiedades de un usuario con PowerShell

Con todas las propiedades podemos realizar filtros.

Algunos ejemplos:

1) Teléfono de la oficina del usuario Xavi.

Get-AdUser Xavi -Properties OfficePhone

2) Teléfono de la oficina y código postal de todos los usuarios.

Get-AdUser -Filter * -Properties OfficePhone, PostalCode

Si vais a utilizar tuberías (pipes) entre distintos cmd-lets, os recomiendo una lectura del siguiente post:

Windows: Powershell propiedad calculada (SYSADMIT.com)

Active Directory: Ver los SID de todos los equipos del dominio

Active Directory: Ver los SID de todos los equipos del dominio

Get-ADComputer -Filter {Name -like "*"} | Select Name,SID

Active Directory: Ver los SID de todos los equipos del dominio