Ir al contenido principal

Preparar dominio no enrutable para sincronizar con Azure AD

   Esta semana estoy preparando nuestro dominio para conectarlo con Office365. Uno de los pre-requisitos que se deben cumplir para poder hacerlo, consiste en que tu Dominio local debe ser enrutable en internet (link). Desgraciadamente, el dominio de mi actual empresa es un dominio .local, así que no cumplimos este prerrequisito. Afortunadamente, existe una forma sencilla de sortear este problema, evitando tener que renombrar tu dominio, un proceso que es bastante complejo (ya tuve que hacerlo una vez hace años, y no me apetece repetirlo). Lo que hay que hacer es básicamente añadir un segundo sufijo de dominio a nuestro directorio. Para ello, haremos los siguiente:
   Abrimos el complemento de administración de  Dominios y confianzas y pulsamos con el botón derecho en dominios y confianzas y luego en propiedades:
clip_image001
   En la ventana que se nos abre, escribiremos un sufijo alternativo para nuestro dominio (obviamente, que sea enrutable) y después pulsaremos en añadir:
clip_image002clip_image003
   Y listo. Bueno no, aun no, ¿pero a que ha sido fácil hasta ahora? En realidad, si miramos en las propiedades de la cuenta de un usuario cualquiera, podremos ver como su nombre de usuario no ha cambiado:
clip_image004
   La diferencia es que ahora, podemos desplegar con la flechita el sufijo de dominio, y si habéis seguido los pasos anteriores, os aparecerá el sufijo que hemos añadido antes:
clip_image005clip_image006
   El cambio de sufijo hay que hacerlo para todos los usuarios que vayamos a sincronizar, por lo que, para facilitar vuestra labor, aquí os dejo un pequeño script en powershell:


Import-Module ActiveDirectory
#Cambia estas variables para adaptarlas a tu entorno
$oldSuffix = "contoso.local"
$newSuffix = "contoso.com"
$ou = "OU=usuarios,DC=contoso,DC=local"
$server = "dc1.contoso.local"

get-aduser -SearchBase $ou -filter * | select userprincipalname
Get-ADUser -SearchBase $ou -filter * | ForEach-Object {
     $newUpn = $_.UserPrincipalName.Replace($oldSuffix,$newSuffix)
     $_ | Set-ADUser -server $server -UserPrincipalName $newUpn
}

get-aduser -SearchBase $ou -filter * | select userprincipalname





NOTA: Este cambio ES TRANSPARENTE PARA EL USUARIO (mas o menos). Lo que estamos cambiando es el sufijo principal del usuario, pero este seguira pudiendo logarse con el sufijo viejo.

Saludos!





Comentarios

Entradas populares de este blog

Error id 12294, La base de datos SAM no pudo bloquear la cuenta de administrador...

Últimamente hemos estado teniendo un problema de esos que a todo administrador de sistemas le trae de cabeza... Al menos hasta que lo ha solucionado una vez. Para aquellos de vosotros que habéis llegado hasta aqui después de toparos con el en vuestro trabajo diario y no sabeis muy bien que hacer, voy a indicaros paso por paso como solucionarlo. El error consiste en el intento reptitivo de bloqueo de la cuenta de Administrador del dominio por parte de una maquina del dominio. Estos errores se generan en el registro de eventos de sistema con el id 12294 y con origen Directory-Services-SAM si es Windows 2008 o SAM si es Windows 2003 o anterior. El error en si no aunque parece grave, no debe preocuparnos tanto, ya que la cuenta de administrador de dominio nunca se bloquea. Lo que si nos molestara mas, es el hecho de que estos errores saturan nuestro log de eventos de sistema, así como el registro de seguridad del DC. El problema que nos encontramos cuando intentamos ...

Solucionar Error 8344 “Insufficient access rights to perform the operation.” En Azure AD connect

Ayer termine de instalar y configurar Azure AD connect. Para los que no lo sepáis, Azure AD connect es el programa que se utiliza para sincronizar objetos de tu directorio activo local con el directorio activo de azure. Podéis acceder a la estupenda documentación de Microsoft aquí. El caso es que después de terminar la configuración, estuve repasando que las primeras sincronizaciones fueran correctas cuando vi que aparecía una tarea con errores en Azure AD sync service. El fallo era el siguiente: Como podéis ver, esta tarea de export, que ya os voy diciendo que era una sincronización de contraseñas, falla por un problema de permisos. La verdad es que era un poco confuso, ya que había seguido la documentación de Microsoft para la implementación al pie de la letra y cumplido todos los prerrequisitos. ¿Se me escapaba algo? Al final, la respuesta era bastante sencilla. Este directorio activo no lo desplegué yo, así que hay algunas cosillas “heredadas”. Una de ellas es que una Unidad Organi...

Formas de cerrar la sesion de un usuario Windows en remoto

   Recientemente he tenido que hacer limpieza de restos debido a la baja de un compañero administrador. Unos días después, mi script de chequeo de logs todavía me cantaba errores que podían estar relacionados con el uso de su cuenta de administrador. Lo mas probable es que hubiera sesiones remotas abiertas con su usuario (ya deshabilitado), desperdigadas por los servidores de la compañía. Para buscarlas, hay varias formas de hacerlo. A continuación, os muestro dos de ellas.    THE OLD WAY, usar los comandos quser y logout    Primero necesitamos ver que usuarios están logados en el servidor remoto y con que id de sesión para después, poder hacerles logof remotamente. Para ello, usaremos el comando quser de la siguiente forma: Quser /server:servername     Este comando devuelve la lista de usuarios logados en un equipo remoto, indicando el nombre, el id de la sesión, el estado y los tiempos de logon y de inactividad. Una vez que teng...