Eliminar grupos en Azure AD de forma masiva

martes, 13 de septiembre de 2016


Hola a todos, en este artículo vamos a ver cómo borrar grupos en Azure Active Directory de forma masiva, he decido escribir este post debido a que en una sincronización de identidades desde Active Directory local hacia Azure AD todos los grupos locales fueron sincronizados, lo cual era algo que no deseaba en principio, adicionalmente que se trataba de una gran cantidad de grupos como veremos más adelante. A continuación una imagen de los grupos vistos desde el portal clásico de Azure (nótese que hasta el grupo domain admins se encuentra allí)


Bien, para solucionar esto y no tener que eliminar los grupos uno por uno, vamos a recurrir a nuestro amigo PowerShell. Si no tienes el módulo de PowerShell para Azure Active Directory te recomiendo ver el siguiente vídeo dónde explico cómo hacerlo: Channel 9 - PowerShell para Azure AD. Una vez cargado el módulo de PowerShell nos conectamos a los servicios en línea de Microsoft usando el cmdlet 

Connect-Msolservice



Ahora ya podemos explorar objetos tales como usuarios, grupos y contactos. En este caso vamos a consultar por todos los grupos de seguridad existentes usando el siguiente cmdlet:


Get-MsolGroup -GroupType "Security"


Como lo indica la instrucción traerá todos los grupos de seguridad


Si cuento los grupos usando el siguiente cmdlet: (Get-MsolGroup -GroupType Security).count


Podemos ver que se trata de bastantes: 281 para ser más exactos.

Mi intención es borrar todos estos grupos, pero probablemente la suya no lo sea, es decir pueden existir ciertos grupos que deseemos conservar, por ejemplo los grupos de los servicios de sincronización o algún otro dependiendo de cada necesidad, si queremos hacerlo no queda más remedio que hacer las respectivas excepciones utilizando operadores para el manejo de cadenas en PowerShell. Por ejemplo veamos como es el caso donde queramos conservar los grupos que se crean para la sincronización.

En la siguiente imagen se puede apreciar que dichos grupos inician con la palabra ADSync


Con lo cual en el "where" podemos utilizar comodines para lograr nuestro propósito, y la instrucción quedaría dela siguiente forma:

Get-MsolGroup -GroupType “Security” | Where-Object {$_.DisplayName -NotLike “ADSync*”}

Nos arrojará todos los grupos de seguridad que su nombre no empiece por ADSync (-NotLike “ADSync*”)


Bien ahora que ya tenemos listados los grupos a eliminar, solo nos hace falta pasar el cmdlet que hace la tarea: Remove-MsolGroup

Con esto, la instrucción final queda  de la siguiente manera:

Get-MsolGroup -GroupType “Security” | Where-Object {$_.DisplayName -NotLike “ADSync*”} | Remove-MsolGroup -Force


Después de ejecutar lo anterior, podemos usar la siguiente instrucción para consultar todos los grupos existentes: Get-MsolGroup -All


Allí podemos ver que hay muchos grupos ADSync, pues se trata de diversas integraciones con directorios que he realizado en mi tenant, si se dan cuenta hay nombres de grupos repetidos, los cuales son diferenciados por el objectId

Pero si lo que queremos es borrar todos los grupos, en mi caso incluyendo los de sincronización de directorios, basta con ejecutar los siguiente: Get-MsolGroup -All | Remove-MsolGroup -Force


Después de hacerlo, volvemos a listar todos los grupos y como se puede ver ya no aparece ninguno, hemos borrado absolutamente todos los grupos.

Y si vamos al portal de Azure nos encontramos con lo siguiente:


Bien, como dato adicional les dejo algunos comandos útiles para Office 365:

Remover todos los usuarios sin licencia:

Get-MsolUser -All -UnlicensedUsersOnly | Remove-MsolUser -Force

Remover todos los contactos:

Get-MsolContact -All | Remove-MsolContact -Force

Como siempre, espero esta información les sea de utilidad. Hasta la pròxima!

Grupo de estudio: Active Directory virtual

sábado, 3 de septiembre de 2016


Este trimestre, en la comunidad ITPros-DC lanzamos nuestro primer grupo de estudio virtual, la oportunidad fue para Active Directory. La primer sesión se llevó a cabo el pasado jueves 1 de septiembre, este grupo a diferencia de los presenciales se lleva a cabo entre semana, los grupos de estudio presenciales si continúan los sábados.

Se ha creado un Meetup donde todos mantendremos al tanto del desarrollo del grupo . Las sesiones están siendo llevadas a cabo gracias a la tecnología de Citrix GoToTraining



Durante esta primera sesión vimos los siguientes temas:

Fundamentos de Active Directory (base de datos, Dominios, árboles, bosques, GC)
Instalación y puesta en marcha de un controlador de dominio.

Bien, la cita es el próximo jueves a las 8:00 pm. Los espero!

Microsoft Cloud Summit Exito total!


El pasado Jueves 25 de Agosto se llevó a cabo en Bogotá el evento Microsoft más importante del año Microsoft Cloud Summit.

Sin lugar a dudas un evento al mejor estilo de Microsoft donde los asistentes vieron las grandes ventajas que la nube de Microsoft nos ofrece. Muchas gracias a los que asistieron a este evento y un saludo todavía más especial para los que asistieron a mi charla :-) A continuación algunas imágenes del evento.






Evento: Microsoft Cloud Summit

martes, 23 de agosto de 2016


Hola a todos, en esta ocasión escribo para invitarlos al evento más importante de Microsoft para este año, se trata del Cloud Summit, un evento que en la mañana tendrá sesiones de negocio, y por la tarde viene el evento técnico, en esta ocasión Microsoft me ha invitado para hablar sobre su solución de recuperación de desastres como servicio DRaaS en Azure. Este evento se realiza en seis países de latam, y el turno para Colombia es el próximo Jueves 25 de Agosto en la Calle 74 # 14 - 25 Lugar: Hall 74. Serán 4 tracks cada uno con contenidos muy interesantes. A continuación los datos de mi charla. La agenda completa la pueden encontrar aquí: http://www.microsoftcloudsummit.com


Por alguna extraña razón el sitio del evento no tiene el enlace al registro, así que lo dejo por aquí: http://aka.ms/MSCloudSummitCOL

En el evento también estará mi buen amigo y MVP Julián Castiblanco y también estará el gran colega Germán Ruiz. Espero puedan acompañarnos, seguro será una excelente tarde llena de conocimiento.

Configuración de inicio de sesión con Azure AD Connect

sábado, 9 de julio de 2016


Hoy en día es bastante común utilizar Azure AD Connect para sincronizar las identidades locales con Azure AD con el fin de poder utilizar el inicio de sesión único o SSO con Office 365 particularmente, y una de las primeras tareas que debemos llevar a cabo es la configuración de un UPN "ruteable" en Internet y que efectivamente coincida con el nombre de dominio verificado en el directorio en Azure.

En este post vamos a ver las opciones que incorpora el asistente de instalación de Azure AD Connect para facilitarnos el proceso de configuración.

Si el asistente detecta que el UPN de nuestras identidades locales no coinciden con el que se encuentra en el directorio de Azure mostrará la siguiente advertencia:


Como se puede apreciar el asistente claramente indica que no es posible iniciar sesión en Azure AD con las mismas credenciales locales (on-premises), lo cual es cierto ya que mi dominio local se llama itpros-dc.loc y mi dominio registrado en Azure AD es cesarherrada.com tal como se muestra en la imagen a continuación:



Veamos solo el recuadro principal para mejor comprensión.


En la columna de la izquierda tenemos los UPN que el asistente encontró, si se están preguntando porque aparte de mi UPN local itpros-dc.loc muestra el UPN cesarherrada.com. Ocurre de este modo debido a que tengo configurado a nivel de Active Directory dicho UPN, veamos cómo se hace esto:

Abrimos la consola Active Directory Domains and Trusts y hacemos clic derecho sobre la raìz y seleccionamos Properties


En la siguiente ventana podemos agregar el sufijo UPN que necesitemos, en mi caso he agregado el UPN cesarherrada.com


Después de hacer esto, nuestro dominio consta de más de un sufijo UPN, lo cual también nos permite cambiarlo directamente sobre los usuarios,tal como se muestra a continuación:


Con esto podemos cambiar el UPN de nuestros usuarios y establecer uno valido en Internet, lo cual vamos a requerir por ejemplo si queremos sincronizar las identidades para usar las mismas locales en Office 365 por ejemplo. Si desea saber más sobre la sincronización de identidades con Office 365 puede consultar el siguiente artículo: Identidad sincronizada con Office 365

Y ahora si, teniendo claro esto, entendemos porqué muestra dos sufijos UPN la tabla del asistente de instalación de AD Connect, y también podemos ver que el UPN cesarherrada.com lo muestra como Verified en Azure AD mientras que el UPN itpros-dc.loc aparece en estado Not Added. Ahora comprendamos mejor el significado de estos estados:

Verified: Esto significa verificado, es decir; encontró que el UPN que vamos a usar cuenta con un dominio verificado en Azure AD, verificado significa que hemos comprobado la propiedad de ese dominio y por lo tanto podemos hacer uso del mismo, en este caso no es necesaria ninguna acción y es lo que generalmente deseamos que aparezca en el asistente-

Not Verified: Esto significa que el asistente encontró un dominio en Azure AD que coincide con el UPN pero aún no ha sido verificado, lo cual significa que debemos completar el proceso de verificación para poder usar dicho dominio, si no lo hacemos el UPN que se establecerá en la nube tendrá el sufijo ".onmicrosoft.com", 

Not Added: Azure AD Connect no encontró un dominio en Azure AD que coincida con el UPN que tenemos, como se puede apreciar, este es precisamente mi caso con el sufijo itpros-dc.loc, claramente este es mi sufijo local no ruteable en Internet, por ende no tengo ningún dominio configurado en Azure AD que coincida con este nombre, y tampoco lo vamos a hacer, para ello he agregado un sufijo UPN adicional que sí coincide con mi nombre de dominio público cesarherrada.com 

Ahora bien, la primera pantalla que puse de AD Connect es la que aparece cuando nos vamos con la configuración Express, pero si elegimos la opción personalizada tendremos la opción de elegir un atributo diferente al UPN, como por ejemplo la dirección de correo electrónico.


Si deseamos usar un atributo alternativo, tenemos que tener en cuenta ciertas restricciones especialmente si vamos a usar Office 365. Por lo cual recomiendo leer el siguiente articulo: Configuring Alternate Login ID

Bien, esto es todo por ahora, y como siempre espero les sea de utilidad.

Agregar contactos a un grupo de Active Directory con PowerShell

jueves, 16 de junio de 2016


Si depronto te has visto en la necesidad de poblar un grupo con objetos de tipo contacto por ejemplo para crear una lista de distribución y deseas usar el cmdlet Add-ADGroupMember te puedes encontrar con el siguiente mensaje de error:


En la imagen anterior utilice lo siguiente para intentar agregar un contacto a un grupo de distribución.

Add-ADGroupMember "Test Group" -Members "CN=testContact,OU=Contacts,OU=Usuarios,DC=lab,DC=loc"
Con lo anterior deseo: Agregar el contacto testContact al grupo Test Group

El cmdlet en este caso no sirve, dado que solo trabaja con principales de seguridad, es decir, objetos que contengan identificador de seguridad (SID), y los objetos tipo contacto no lo tienen.

Por lo cual debemos recurrir a VBScript utilizando ADSI


$contact = [adsi]"LDAP://CN=Test Group,OU=Group,OU=Usuarios,DC=lab,DC=loc"
$contact.Member.Add("CN=testContact,OU=Contacts,OU=Usuarios,DC=lab,DC=loc")
$contact.psbase.CommitChanges()

Para lo anterior abrimos Windows PowerShell ISE y pegamos las líneas de código anteriores, después de ejecutar tenemos el siguiente resultado:


Después de esto efectivamente tenemos ya el contacto e nuestro grupo de distribución.



Esto es todo, y como siempre espero les sea de utilidad.

Enterprise Mobility Suite (EMS) - Parte 2

lunes, 30 de mayo de 2016


Bien continuamos con la segunda parta de esta serie. A continuación el enlace a otras partes de esta serie:

Enterprise Mobility Suite (EMS) - Parte 1

En esta nueva entrega vamos a revisar el primer componente de EMS (Azure Active Directory Premium)

Es importante saber que una suscripción a Microsoft Azure no incorpora la edición Premium de Active Directory sino la gratuita, con una suscripción a EMS si contamos con la edición más avanzada que es la Premium. Al tratarse de la edición más completa incluye características muy interesantes, nombremos algunas de ellas: Reportes avanzados, Grupos de autoservicio, Grupos dinámicos, Cambio de contraseña de autoservicio con replicación on-premise y muchas otras que se pueden revisar en detalle en este enlace.

Azure AD es parte clave para EMS ya que mediante este se gestiona todo el tema de identidades, los administradores pueden crear y modificar usuarios, otorgarles permisos para acceso a las aplicaciones, también es posible sincronizar las identidades que tengamos en nuestro sitio local (Windows Server AD) hacía Azure AD con lo cual se ofrece una experiencia de SSO. Más adelante revisaremos cómo se realiza la sincronización de identidades, o puede revisar los vídeos a continuación para ver una demostración.

Si desea conocer más sobre Azure AD lo invito a ver mi vídeo: Introducción a Azure AD

También para comprender más sobre el tema de identidades los invito a ver el vídeo: Modelos de Identidad

Si cuenta con una suscripción a Office 365, todos los usuarios que allí se creen están siendo almacenados en un directorio de Azure AD.

Ahora veamos como asignar una licencia de EMS que Azure AD a un usuario en particular. La siguiente demostración asume que ya cuenta con una suscripción a EMS.

Ingresamos al portal de administración de Azure https://manage.windowsazure.com

De las extensiones de la parte izquierda seleccionamos Active Directory



Luego seleccionamos el directorio sobre el cual hemos configurado EMS, esto en caso de tener más de un directorio.

En el menú de la parte posterior, seleccionamos Licencias




Allí podemos observar que contamos con un plan de EMS y adicionalmente tenemos varias columnas donde veremos la cantidad de licencias activadas y las asignadas.


Al ubicarnos sobre el plan de licencia, en la parte inferior podemos apreciar la opción para asignar y quitar licencias


Una vez hacemos clic en Asignar, nos muestra la lista de usuarios seleccionamos el usuario al cual deseamos asignar la licencia y listo.



También podemos hacerlo ingresando al plan, en la parte posterior vemos la opción Usuarios y Grupos de manera predeterminada se mostrarán los usuarios que tienen licencias asignadas.


El cuadro desplegable Mostrar: nos ofrece la posibilidad de ver todos los usuarios independiente de si tienen o no licencias asignadas, y también permite mostrar grupos en el caso que deseemos asignar licencias a un grupo determinado de usuarios,

En este caso vamos a seleccionar Todos los usuarios y del resultado que nos arroje asignaremos una licencia a cualquier usuario.

En la imagen a continuación notemos que el único usuario con licencia asignada es el primero de la lista, ya que si nos fijamos en la columna Método vemos la palabra Directo esto significa que asignamos la licencia directamente sobre el usuario sin utilizar ningún grupo, de lo contrario mostraría el nombre del grupo desde el cual el usuario heredó la licencia.


Algo que no alcancé a mostrar en la imagen anterior, pero que voy a mostrar en la siguiente, es la columna Estado de la asignación donde nos muestra en este caso Habilitado en caso contrario mostrará error por ejemplo si no hay licencias suficientes.


Para asignar una licencia, basta con ubicarse sobre el usuario que requiera la licencia, y en la parte inferior del portal encontramos la opción Asignar del mismo modo, si lo que necesitamos es quitar la licencia se activará la opción Quitar sobre un usuario que ya posea licencia.

Veremos la respectiva notificación.


Y listo, esto es todo lo que debemos hacer para un usuario tenga su licencia de EMS, con la cual no solamente podrá hacer uso de Azure AD Premium y las características que mencionamos, sino que además podrá hacer uso del resto de servicios que conforma EMS y que hemos visto en la parte 1 de esta serie.

Bien, esto es todo por hoy,nos vemos en la próxima entrega para revisar el segundo componente de EMS, Microsoft Intune.

Activación basada en Active Directory

miércoles, 25 de mayo de 2016


A partir de Windows Server 2012 tenemos la posibilidad de realizar activación de las máquinas del dominio a través de Active Directory, lo cual significa que una vez unamos los equipos al dominio, al iniciar sesión la máquina se activará de manera automática sin ningún tipo de intervención, los objetos de activación son almacenados en AD, los equipos permanecerán activados mientras sean miembros del dominio, para poder hacer uso de este rol de servidor, es necesario que se cumplan los siguientes requisitos:

  1. Nivel funcional del bosque debe ser Windows Server 2012 o posterior
  2. Solo funciona con máquinas Windows 8, Windows 8.1, Windows Server 2012 y Windows Server 2012 R2

Es importante aclarar que si en el entorno existen máquinas con versiones de sistema operativo diferentes a la soportada por Active Directory Based-Activation (ADBA) se debe seguir utilizando un servidor KMS para la activación de las mismas.

Ahora veamos el paso a paso de la instalación.

En Server Manager abrimos instalar roles y características y seleccionamos Volume Activation Services y hacemos clic en Next



Agregamos todas las características sugeridas


En la pantalla Volume Activation Services hacemos clic en Next


y luego clic en Install


Al finalizar la instalación podemos abrir de manera inmediata el asistente haciendo clic en Volume Activation Tools


A continuación seleccionamos Active Directory-Based Activation y hacemos clic en Next


Ahora ingresamos la clave KMS para la activación y opcional-mente el nombre para mostrar que llevará el objeto de activación en Active Directory, luego hacemos clic en Next


Seleccionamos el método de activación de la clave KMS, para este ejemplo lo haré en línea y hacemos clic en Commit


Aparecerá un mensaje que nos indica que se creará un objeto de activación en Active Directory. Hacemos clic en Yes



Atención en la siguiente pantalla, pregunta que se deseamos eliminar objetos de activación debemos hacer clic en Next, en caso contrario hacer clic en Close, como en este caso estamos es creando el objeto debemos hacer clic en Close


Y listo, esto es todo...

Ahora cualquier equipo con la versión soportada del sistema operativo una vez se una al dominio será activado de manera automática, si el equipo ya se encuentra en el dominio y simplemente deseamos activar, basta con ejecutar slmgr.vbs /ato desde una consola de comandos.


Un saludo, y como siempre espero sea de utilidad.
 

MVP Award

MVP Award
Microsoft Azure

Lo más visto

Certificaciones

Comunidad

Comunidad
Comunidad Técnica

Sobre mi

Mi foto
Microsoft Azure MVP MCT|MCSE|MCSA

Visitantes


flags.es