Cerrar
InicioAzureMicrosoft Teams, conceptos y tecnología (Parte X)

Microsoft Teams, conceptos y tecnología (Parte X)

Seguramente, a muchos de vosotros os ha ocurrido que los usuarios de Office 365 se han dado cuenta que tienen algún aplicación disponible  y se han puesto a utilizarla sin más. Desde un punto de vista de actitud de los usuarios está genial, porque los vemos comprometidos con la idea de participar en los nuevos retos que supone una transformación digital. Pero desde el punto de vista de IT o de la compañía esto puede representar un gran problema de gestión de recursos y me explico. Si dejamos a los usuarios acceder a herramientas de Office 365 sin controlar que pueden y no puedo hacer, no podemos encontrar en dos semanas que tenemos cientos de grupos en nuestro tenant. Sino tenemos el control, tenemos varios problemas:

  • Múltiples grupos creados sin control
  • Nomenclatura no estandarizada
  • Permisos sin control
  • Etc..

A todos los que ya llevamos un tiempo gestionando diferentes tenants, seguramente lo hayamos vivido en alguna ocasión y sabemos el caos que esto genera. Aunque las herramientas están pensadas (por lo menos por parte de MSFT) para colaborar, tenemos que hacerlo con cierto criterio:

  • Quien los puede crear
  • Debemos estandarizar la nomenclatura de los mismos, imaginaros un grupo de Teams que se llame CEO & Directors …
  • Gestión de permisos, aunque en Teams están bastante limitados, debemos ajustarlos

Ahora mismo y por defecto, cualquier usuario de nuestro tenant podría crear grupos de Outlook y Teams y de forma muy sencilla. Pues bien, hoy voy a mostrarnos como podemos definir que usuarios pueden crear grupos en Office 365 para evitar este tipo de problemas. Pero antes de nada, comentaros que con esta configuración evitaremos (y de momento no podemos hacerlo de otra forma) que se puedan crear grupos no sólo en Teams o en Outlook, sino también en las siguientes herramientas:

  • Outlook
  • SharePoint
  • Yammer
  • Microsoft Teams: usuarios y administradores no podrían crear grupos
  • StaffHub: usuarios y administradores no podrían crear grupos
  • Planner: usuarios no podrían crear nuevos planes
  • PowerBI

Esta configuración no aplicará a los usuarios que sean miembros de los siguientes grupos:

  • Office 365 Global admins
  • Mailbox Administrator
  • Partner Tier1 Support
  • Partner Tier2 Support
  • Directory Writers

De tal forma que estos usuarios, siempre podrán crear grupos sin problema. Pero claro, como tenemos diferentes perfiles de técnicos/consultores que gestionan nuestro tenant, entiendo que queremos seguir controlando esta segregación de responsabilidades pero que  puedan crear grupos. Pues bien,  lo que haremos será definir un grupo de seguridad sobre el cual configuraremos que puedan crear grupos aún no siendo miembros de alguno de los grupos de seguridad de más alto nivel. En mi caso, como tenemos mi entorno federado con Office 365, lo que haré será crear un grupo de seguridad en On-Premises, sincronizarlo con mi tenant y utilizarlo en dicha configuración de restricción de creación de grupos. Ahora bien, porque lo hago así? Porque si necesitamos saber a que recursos tiene acceso un usuarios del Directorio Activo, simplemente veo su membresia  y ya reconozco a que servicios tiene acceso, ahora os lo muestro. Si os fijáis ya por el nombre del grupo ya se puede saber que tipo de permisos gestiona:

  • ACL: Access Control list, esto permite saber que es un grupo para aplicar permisos
  • O365: donde aplica, en este caso en Office 365
  • Crear Grupos: esto es el proceso que gestiona

De ahí que así, sólo viendo las membresías del usuario ya sé a que recursos tiene acceso. Además, si vienen o queremos añadir nuevos usuarios a gestionar este recurso, simplemente lo añadimos en On-Premises a este grupo y desde el primer momento tiene los permisos necesarios. De otra forma, al tener el Grupo en Office 365, tenemos que ir Tenant y revisarlo, yo lo veo mucho más claro y rápido en On-Premises (ahora cada uno que haga lo que considere):

Pues dicho esto, vamos a iniciar sesión en AzureAD vía PowerShell, para ello debemos tener los módulos instalados (sino lo haremos vía Install-Module AzureADPreview). Una vez que tengamos todo listo desde el equipo en el cual haremos la conexión a AzureAd, simplemente ejecutamos Connect-AzureAD y hacemos login con alguna cuenta que sea Global Admin del tenant:

Una vez hayamos introducido correctamente las credenciales, nos conectaré y debemos ver una ventana similar a esta:

Como os comentaba anteriormente, yo he creado un grupo de seguridad (Universal)  en mi Directorio Activo On-Premises y lo primero que voy a ver es si ya está sincronizado con O365 (también podéis utilizar grupos de seguridad de Office 365).  Para ello, desde la sección de grupos lo busco y aquí lo tenemos:

Ahora, lo que haré será buscar el grupo que hemos creado, pero simplemente para identificar el ObjectID (que aunque no necesitamos utilizarlo, si es bueno tenerlo a mano y así verificar que se aplica la configuración de forma correcta). Para esto, debemos ejecutar el siguiente cmdlet: Get-AzureADGroup -SearchString “<nombre_del_grupo>”

Pues ahora debemos ejecutar el siguiente script para verificar que ya tenemos todo preparado para continuar con la configuración:

$Template = Get-AzureADDirectorySettingTemplate | where {$_.DisplayName -eq ‘Group.Unified’}
$Setting = $Template.CreateDirectorySetting()
New-AzureADDirectorySetting -DirectorySetting $Setting

Si todo está bien, os devolverá algo similar a esto, si por el contrario o devuelve algún error (A conflicting object xxx) es que ya lo teníais preparado:

Por último nos queda aplicar la configuración de restricción de creación de grupos para todos los usuarios, a excepción del grupo de seguridad que hemos creado y los grupos de seguridad comentados:

$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value “Group.Unified” -EQ).id
$Setting[“EnableGroupCreation”] = $False
$Setting[“GroupCreationAllowedGroupId”] = (Get-AzureADGroup -SearchString “ACL O365 Crear Grupos“).objectid
Set-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value “Group.Unified” -EQ).id -DirectorySetting $Setting
(Get-AzureADDirectorySetting).Values

Y si todo ha ido bien, pues tendremos el siguiente resultado, como vemos nos muestra el campo GroupCreationAllowedGroupId con el ObjectID  que hemos comprobado antes:

Ahora lo único que toca es probar a crear algún grupo desde Outlook y Teams con algún usuario que no sea miembro del grup de seguridad y ver que todo funciona según lo esperado. Pues bien, primero nos vamos a Outlook (este es OWA pero para la prueba nos vale igual) y le damos a Nuevo – Grupo

Y le mostrará el siguiente mensaje al usuario: La persona que administra su correo electrónico ha desactivado la posibilidad de crear grupos:

Si vamos a Teams y no hemos accedido nunca, os muestra un pequeño asistente y termina sugiriendo que creemos y un grupo y … tampoco puede:

Si el usuario ya tenía acceso a Teams, tendrá el botón disponible pero no funciona, puede pulsar en él pero no hace nada:

Si ahora nos vamos a Planner, más de lo mismo sino hemos accedido nunca, nos indicará que creemos un nuevo plan .. cuando pulsamos en Crear plan volverá al hub de Planner y no ha creado nada:

Y si ya hemos entrado con anterioridad, veremos nuestros Planners pero poco más, tendremos el botón disponible pero nunca podremos crear un plan:

Ya sabéis, ahora os toca a vosotros probarlo!!

Microsoft Teams, con
Microsoft Teams, con
1 COMENTARIO
  • Alvaro / 7 marzo, 2018

    ¡Genial!
    Era un quebradero de cabeza que cualquiera pudiera crear grupos “a su antojo”, más ahora que crear un grupo de O365 es casi lo “predeterminado” y cuando un usuario simplemente quiere crearse una Grupo de distribución en su Outlook, lo que solía crear es un Grupo de O365…

    En fin, problema resuelto. Muchas gracias. Ya lo tengo implementado en todos mis Tenan

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies