Bloquear el acceso de usuarios a cuentas de Microsoft 365
Múltiples técnicas disponibles para evitar que las personas se conecten
Actualizado el 20 de febrero de 2024
Un artículo reciente sobre el uso de PowerShell para controlar las políticas de acceso condicional de Entra ID me hizo empezar a pensar en las técnicas utilizadas para bloquear el acceso de los usuarios a Office 365. Hace cuatro años, consideré el problema en un artículo de Petri.com inspirado en una ley francesa para permitir que la gente desconecte durante el fin de semana. En otros lugares además de Francia, la necesidad de preservar el espacio entre el tiempo personal y el laboral se hizo más evidente cuando la pandemia de Covid-19 obligó a muchas personas a trabajar desde casa. Algunos trabajaron más, otros trabajaron menos y la línea entre el tiempo personal y el laboral se volvió borrosa. Ahora, el avance del tiempo y el desarrollo de la tecnología se combinan para que sea razonable volver a abordar el problema.
Actualización: Microsoft ha implementado una evaluación de acceso continuo (CAE) para eventos críticos como cambios de contraseña o bloqueos de cuentas en todos los inquilinos. El efecto neto de CAE es que privar al usuario del acceso a una cuenta funciona mucho más rápido (casi de inmediato).
Detener conexiones de correo electrónico de forma temporal o permanente
La cuestión de inhabilitar el servicio a los usuarios no se trata sólo de impedir que las personas trabajen durante el fin de semana o cuando están de vacaciones. También se aplica cuando las personas abandonan una empresa. A lo largo de los años, han evolucionado diferentes técnicas, originalmente para la conectividad del correo electrónico, porque ahí fue donde surgió el problema por primera vez.
Dado que Exchange Online admite un amplio conjunto de protocolos de conectividad para buzones de correo, puede deshabilitar protocolos individuales ejecutando el cmdlet Set-CASMailbox. En este ejemplo, deshabilitamos la conectividad móvil para un buzón tanto para Exchange ActiveSync (EAS) como para la tecnología de sincronización de Microsoft utilizada por Outlook móvil:
Set-CASMailbox -Identity Ken.Bowers@Office365itpros.com -ActiveSyncEnabled:$False
Set-CASMailbox -Identity Ken.Bowers@Office365itpros.com -OutlookMobileEnabled:$False
¿Por qué desactivar ambos protocolos? Outlook mobile utiliza la tecnología de sincronización de Microsoft para habilitar muchas funciones avanzadas, como el acceso delegado a los buzones de correo, pero otros clientes, como las aplicaciones de correo incluidas en los sistemas operativos iOS y Android, utilizan EAS para la conectividad básica del correo electrónico con Exchange Online. Si no desactiva ambos, crea una situación en la que un usuario aún puede conectarse a su buzón con una aplicación diferente. De hecho, para que esté completo, también debes desactivar los protocolos IMAP4 y POP3 para eliminar cualquier posibilidad de que un dispositivo móvil pueda conectarse a un buzón.
La debilidad de concentrarse en deshabilitar protocolos es que aún puede ocurrir cierta fuga de información. Tomemos el ejemplo de Outlook móvil. Puede desactivar la tecnología de sincronización de Microsoft para evitar que los clientes envíen mensajes y descarguen mensajes al dispositivo, pero tanto iOS como Android utilizan servicios para notificar a los usuarios sobre la llegada de nuevos mensajes. Las notificaciones contienen fragmentos sobre mensajes nuevos para permitir a los usuarios decidir si necesitan leer el mensaje completo. Estas notificaciones siguen llegando después de desactivar el protocolo de sincronización.
En realidad, si realmente quiere controlar los dispositivos móviles, necesita implementar una solución de administración de dispositivos móviles (MDM) como Intune, que le permite borrar de forma remota los datos corporativos del dispositivo cuando sea necesario.
Detener el acceso a Office 365
El correo electrónico no es la única aplicación que roba tiempo durante el fin de semana. Teams, Planner, Yammer, SharePoint Online y OneDrive for Business consumen horas si las personas lo permiten. El método clásico para bloquear el acceso es bloquear la cuenta de alguien. Esto se puede hacer a través del centro de administración de Microsoft 365 seleccionando la cuenta y eligiendo Bloquear inicio de sesión (Figura 1).
Al bloquear la cuenta, la propiedad AccountEnabled se establece en False. Cuando una cuenta está deshabilitada, el usuario no puede iniciar sesión en su cuenta:
Forzar cierres de sesión en aplicaciones
Al bloquear el inicio de sesión de una cuenta también se establece la propiedad RefreshTokensValidFromDateTime de la cuenta en la fecha y hora en que ocurrió la acción. El efecto es invalidar los tokens de actualización emitidos para las aplicaciones de un usuario y los tokens emitidos para las cookies de sesión en los navegadores y obliga al usuario a volver a autenticarse para continuar usando las aplicaciones. El centro de administración de Microsoft 365 incluye una opción para cerrar la sesión de un usuario en todas las sesiones, por lo que puede hacerlo sin bloquear una cuenta.
También puede forzar el cierre de sesión de una cuenta con PowerShell ejecutando el cmdlet Revoke-MgUserSignInSession:
$RevokeStatus = Revoke-MgUserSignInSession -UserId $User.IdAl restablecer los inicios de sesión de una cuenta, se establece RefreshTokensValidFromDateTime en la fecha y hora actuales y AccountEnabled en True. El usuario ahora puede iniciar sesión. Cuando esto sucede, los navegadores y las aplicaciones reciben nuevos tokens válidos. Pueden pasar hasta 15 minutos antes de que el usuario pueda iniciar sesión en todas las aplicaciones.
Bloquear cuentas con PowerShell
El cmdlet Update-MgUser bloquea el acceso a una cuenta de usuario:
Update-MgUser -UserId 'Ken.Bowers@office365itpros.com' -AccountEnabled:$False
El enfoque recomendado es ejecutar Update-MgUser para bloquear la cuenta seguido de Revoke-MgUserSignInSession para garantizar que la cuenta esté bloqueada con un cierre de sesión forzado para todas las aplicaciones.
Implementación de un bloque de fin de semana
Volviendo al problema original, que es cómo desconectar a las personas de Microsoft 365 por una razón u otra. Supongamos que solo queremos que esto suceda para una determinada categoría de usuarios, como aquellos que trabajan en un país específico. Si esas personas son miembros de un grupo, podemos utilizar ese grupo para impulsar el proceso de desconexión. En este ejemplo, una lista de distribución define las cuentas que se desconectarán:
[Array]$Accounts = Get-DistributionGroupMember -Identity "BlockWeekend" | Select WindowsLiveID, ExternalDirectoryObjectId
ForEach ($Account in $Accounts) {
Write-Host "Turning Off Office 365 Access for" $Account.WindowsLiveID
Update-MgUser -UserId $Account.ExternalDirectoryObjectId -AccountEnabled:$False
$RevokeStatus = Revoke-MgUserSignInSession -UserId $Account.ExternalDirectoryObjectId }
Una lista de distribución dinámica podría ser una mejor opción porque la membresía depende de propiedades como el país o la ciudad. Para recuperar el conjunto de usuarios de una lista de distribución dinámica, utilizamos el filtro de destinatarios de la lista para encontrar los miembros:
$AccountFilter = (Get-DynamicDistributionGroup -Identity "French Country Users").RecipientFilter
[Array]$Accounts = Get-Recipient -RecipientPreviewFilter $AccountFilter | Select-Object WindowsLiveID, ExternalDirectoryObjectId
Por supuesto, puede utilizar el cmdlet Get-MgGroupMember para obtener detalles de los miembros del grupo si lo prefiere. Por ejemplo:
[array]$GroupId = (Get-MgGroup Filter "DisplayName eq 'BlockWeekend'").Id
[array]$GroupMembers = Get-MgGroupMember -GroupId $GroupId | Select-Object additionalProperties
$GroupMembers.displayNameEsta sintaxis funciona con listas de distribución, grupos de seguridad, grupos de Microsoft 365 y grupos dinámicos de Microsoft 365. No funciona con listas de distribución dinámicas porque estos objetos no existen en Entra ID
La tarea de desconectar a los usuarios es sencilla. Todos los viernes por la noche ejecutamos el script de PowerShell para deshabilitar el acceso y ejecutamos otro script para revertir el proceso el lunes por la mañana. La gran desventaja es la forma en que Teams procesa las cuentas bloqueadas para eliminarlas de las listas del equipo (sin afectar la membresía del grupo). Si puede vivir con este problema mientras Microsoft considera cómo mejorar la situación, entonces bloquear cuentas por períodos cortos podría funcionar para su organización.
Uso de una política de acceso condicional
Las políticas de acceso condicional se ejecutan después de que un usuario se autentica correctamente para decidir si puede conectarse al recurso solicitado. La membresía de un grupo es una de las condiciones admitidas, lo que significa que es fácil crear una política para bloquear el acceso a las aplicaciones de un grupo. Debido a que lo que queremos bloquear es el acceso de fin de semana, podríamos agregar otra condición para decir que el acceso está bien si el usuario se encuentra en una ubicación corporativa, pero no si está en casa o en cualquier otro lugar.
La Figura 3 muestra las líneas generales de dicha política. Cualquier persona especificada en la lista de distribución de fin de semana bloqueado (también puede usar un grupo de seguridad o un grupo de Microsoft 365) está bloqueada si intenta acceder a una aplicación de Office 365:
Cuando un intento de usuario de acceder a una aplicación es bloqueado por una política de acceso condicional, se le informa que su inicio de sesión fue exitoso (la autenticación funcionó), pero que no tiene permiso para acceder al recurso:
Si ya están conectados a una aplicación y la aplicación intenta renovar su token de acceso, la política de acceso condicional bloqueará la emisión del token. La Figura 5 muestra lo que ve el usuario cuando esto sucede en Teams (¡la aplicación es muy educada!):
Control de políticas de acceso condicional con PowerShell
Las políticas de acceso condicional permiten a las organizaciones ejercer un control granular sobre el acceso que tienen los usuarios a las aplicaciones. En nuestro escenario, queremos permitir el acceso gratuito durante la semana. Podríamos deshabilitar la política de acceso condicional durante la semana laboral y habilitarla solo durante el fin de semana. Esto se hace fácilmente editando la política en el centro de administración de Entra o con PowerShell. Por ejemplo, aquí se explica cómo habilitar la política:
$Policy = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'Block Weekend Access'"
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $Policy.Id -State 'Enabled'
Para deshabilitar la política después del fin de semana, ejecute:
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $Policy.Id -State 'Disabled'Cambiar las condiciones de la política de acceso condicional
Pero como queremos ilustrar las posibilidades que existen para trabajar con políticas de acceso condicional a través de PowerShell, supongamos que la política siempre está activa porque se usa durante la semana para limitar el acceso de algunos usuarios (identificados por un grupo) a ciertas ubicaciones. Durante el fin de semana, necesitamos actualizar la política con un grupo diferente.
Los usuarios bloqueados por una política de acceso condicional se definen como una condición de política. Para ver a qué usuarios afecta una póliza podemos examinar sus condiciones. Aquí vemos que se incluye un único grupo en la póliza:
((Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $PolicyId).Conditions).Users | Format-List
IncludeUsers : {}
ExcludeUsers : {}
IncludeGroups : {468a9356-cf88-4189-bf85-40b096e3c37f}
ExcludeGroups : {}
IncludeRoles : {}
ExcludeRoles : {}
Sabemos que se trata de un grupo y no de un usuario individual porque aparece en la condición IncludeGroups. Se hace referencia al grupo mediante su identificador único (un GUID). Para saber qué grupo aparece en la lista, ejecute el cmdlet Get-MgGroup:
Get-MgGroup -GroupId 468a9356-cf88-4189-bf85-40b096e3c37f
DisplayName Id MailNickname Description GroupTypes
----------- -- ------------ ----------- ----------
Users Blocked for Weekend Access 468a9356-cf88-4189-bf85-40b096e3c37f BlockWeekend {}
Para cambiar un grupo por otro en una política, debemos crear una tabla hash que especifique el identificador del grupo que se incluirá en la política y luego llamar al cmdlet Update-MgConditionalAccessPolicy para realizar el cambio.
A continuación se muestra un ejemplo de código para actualizar nuestra política de acceso condicional. Puede ver que el GUID de un grupo diferente está escrito en el conjunto de condiciones:
# Update the policy with a new group
$UpdateSettings = @{
Conditions = @{
users = @{
includeGroups = @(
"5c011293-7cc7-41c4-a0fc-3e3bb98db834"
)
}
}
}
Update-MgIdentityConditionalAccessPolicy -BodyParameter $UpdateSettings -ConditionalAccessPolicyId $Policy.IdEn unos minutos, la política de acceso condicional actualizada entra en vigor y el bloqueo está implementado.
Para revertir el proceso una vez finalizado el fin de semana, actualice la política con el GUID del grupo original. Consulte este artículo para obtener más información sobre cómo administrar políticas de acceso condicional con PowerShell.
Opciones y elecciones
Las políticas de acceso condicional requieren licencias Entra ID P1. Si ya tiene estas licencias y, por lo tanto, ha invertido en acceso condicional, no es difícil agregar una nueva política para controlar el acceso los fines de semana. Poder controlar las políticas con PowerShell facilita la activación o desactivación automática del acceso.
Por otro lado, si no tienes licencias Entra ID P1, aún puedes bloquear cuentas de usuario con unas pocas líneas de PowerShell. Y si no desea bloquear el acceso y simplemente recordarle a la gente que deberían trabajar menos durante el fin de semana, tal vez la técnica de utilizar una regla de transporte para sellar avisos de exención de responsabilidad sobre el “derecho a desconectarse” en el correo interno sea una buena manera de hacerlo.
La elección es buena…