Azure AD no almacena una propiedad de nombre de dominio
Me preguntaron si los nombres de dominio se pueden usar con ámbitos adaptables para cuentas de usuario. El motivo de la solicitud es que un inquilino admite usuarios con múltiples dominios para diferentes empresas operativas. Quieren aplicar un procesamiento de retención específico a ciertas empresas y pensaron que los alcances adaptables podrían ayudar. Es una petición razonable y lógica.
La respuesta simple es «no», porque Azure AD no mantiene una propiedad para contener el nombre de dominio de un usuario. Azure AD almacena nombres de dominio en las propiedades de nombre principal de usuario (UPN) y dirección de correo electrónico (Correo). Sin embargo, Azure AD no divide la parte del nombre de dominio del UPN o la dirección de correo electrónico y la almacena en una propiedad separada. Como tal, el portal de cumplimiento de Microsoft Purview no admite un método para seleccionar un nombre de dominio como propiedad filtrable, por lo que los ámbitos adaptables no funcionarán.
El mismo problema surge con los filtros de destinatarios personalizados para las listas de distribución dinámicas. Microsoft admite un conjunto mucho más amplio de propiedades filtrables para las listas de distribución dinámicas que el que está disponible para los ámbitos adaptables, pero los nombres de dominio tampoco aparecen allí. Parece que el filtrado basado en la parte del dominio de una dirección de correo electrónico sería útil, pero cuando pregunté sobre esta omisión en el pasado, Microsoft dijo que se necesita un procesamiento complejo para extraer e indexar los nombres de dominio. Probablemente exista el mismo problema para los ámbitos adaptables.
Los atributos personalizados son la solución
Para resolver el problema, necesitamos usar una propiedad de cuentas de usuario disponible para ámbitos adaptables. Azure AD admite quince atributos de valor único personalizables. Es fácil actualizar estos atributos con nombres de dominio mediante los cmdlets de Exchange Online. Esto es lo que hice para encontrar todos los buzones de correo de los usuarios y escribir el nombre de dominio para el nombre principal del usuario de la cuenta en el atributo personalizado 8:
[array]€Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited -PropertySets Custom ForEach (€M in €Mbx) { €UserDomain = €M.UserPrincipalName.Split("@")[1] If (€UserDomain -ne €M.CustomAttribute8) { Set-Mailbox -Identity €M.UserPrincipalName -CustomAttribute8 €UserDomain } } La verificación del conjunto de cuentas con un determinado nombre de dominio se realiza de la siguiente manera:
Get-ExoMailbox -Filter {CustomAttribute8 -eq "Office365itpros.com"} -Properties CustomAttribute8 | Sort-Object DisplayName | Format-Table DisplayName, UserPrincipalName, CustomAttribute8 Actualización de atributos personalizados con Graph SDK
Quizás se pregunte por qué uso los cmdlets Get-ExoMailbox y Set-Mailbox para actualizar el atributo personalizado. Los cmdlets Get-MgUser y Update-MgUser del SDK de Microsoft Graph PowerShell también funcionarán, pero son más difíciles de manejar. Este es el código equivalente para buscar cuentas de usuario (el filtro busca cuentas con licencia) y actualizar el atributo personalizado con el dominio del nombre principal de usuario de cada cuenta:
[array]€Users = Get-MgUser -Filter "assignedLicenses/`€count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All ForEach (€User in €Users) { €UserDomain = €User.UserPrincipalName.Split("@")[1] If (€UserDomain -ne €User.onPremisesExtensionAttributes.ExtensionAttribute8) { Update-MgUser -UserId €User.Id -OnPremisesExtensionAttributes @{'extensionAttribute8' = €UserDomain} } } Este código obtiene el mismo conjunto de cuentas de usuario y enumera el nombre para mostrar y el atributo personalizado 8 para cada cuenta. No ejecute esto inmediatamente después de realizar las actualizaciones, ya que probablemente no verá el nombre de dominio en el atributo personalizado 8. Deje que el almacenamiento en caché de Graph funcione y espere un momento antes de verificar.
[array]€Users = Get-MgUser -Filter "assignedLicenses/`€count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All €Users | Where-Object {€_.UserPrincipalName -Like "*Office365itpros.com"} | Select-Object DisplayName,onPremisesExtensionAttributes -ExpandProperty onPremisesExtensionAttributes | Format-Table DisplayName, ExtensionAttribute8 La actualización de un atributo personalizado en las cuentas de usuario con un valor utilizado para algo como un ámbito adaptable debe realizarse periódicamente. Un runbook de Azure Automation es una buena opción para asegurarse de que las cuentas nuevas y las cuentas que cambian su nombre principal de usuario tengan el valor correcto en el atributo personalizado. Tanto el módulo de administración de Exchange Online como el SDK de Microsoft Graph PowerShell admiten identidades administradas por Azure Automation para hacer que los trabajos programados sean aún más seguros.
Creación de un ámbito adaptable
Después de asegurarnos de que las cuentas tengan los valores correctos en el atributo personalizado, podemos crear un ámbito adaptable. Microsoft Purview admite ámbitos adaptables para usuarios y grupos y para sitios de SharePoint. Los ámbitos adaptables para usuarios y grupos dependen de las propiedades de Azure AD para encontrar objetos de destino, por lo que ese es el tipo que usamos.
La consulta de alcance es donde ocurre la magia. En este caso, la consulta es simple: haga coincidir cualquier cuenta de usuario que tenga un determinado nombre de dominio en el atributo personalizado 8. La Figura 1 muestra cómo se ve la consulta de alcance en el portal de Purview.
Figura 1: la consulta de ámbito adaptable para buscar cuentas según el nombre de dominio
La ventaja de un alcance adaptativo es que sigue el ritmo de los cambios realizados en las cuentas de usuario. En este caso, la consulta de alcance controlará situaciones como cuando una organización actualiza los nombres principales de usuario para un conjunto de usuarios debido a la reestructuración de la empresa u otro motivo.
Trabajar con un alcance adaptativo es un ejercicio que requiere tiempo y paciencia. Después de crear el ámbito adaptable, un proceso en segundo plano resuelve la consulta de ámbito para determinar el conjunto de cuentas de destino. No puede controlar cuándo se ejecuta el proceso en segundo plano. Todo lo que puede hacer es esperar al menos un día y luego verificar si hay resultados disponibles. Seleccione el alcance adaptativo y seleccione Detalles del alcance (Figura 2).
Figura 2: Comprobación de los detalles del alcance adaptable
Esta acción solicita a Purview que abra una nueva pestaña del navegador para mostrar el conjunto de objetos identificados por la consulta de alcance. Si ve «No hay datos disponibles», significa que el proceso en segundo plano no se ha ejecutado, o que sí, y la consulta de alcance no encontró ningún objeto. Con la esperanza de que lo primero sea el caso, cierre la pantalla y espere otro día antes de volver a comprobar.
Es importante recordar que los resultados de la consulta pueden aparecer en lotes. En otras palabras, verifica y encuentra que algunos de los buzones esperados están allí, pero no todos. Esperar unas horas más puede mostrar que la consulta de alcance ha encontrado algunos buzones más. Finalmente, la consulta de alcance finaliza su búsqueda y Purview enumera un conjunto completo de buzones (Figura 3). Puede comparar los resultados que muestra Purview con el conjunto recuperado por PowerShell. Idealmente, los dos conjuntos deberían coincidir. Si no lo hacen, es posible que el procesamiento de la consulta de alcance no esté completo o que la consulta sea incorrecta.
Figura 3: Visualización del conjunto de cuentas encontradas por la consulta de ámbito adaptable
Crear una política de retención
Cuando esté satisfecho de que la consulta de ámbito encuentre el conjunto correcto de cuentas de usuario, puede continuar y crear una nueva directiva de retención de Microsoft 365 y usar el ámbito adaptable. La figura 4 muestra la configuración de una directiva de retención con el ámbito adaptable seleccionado para procesar elementos en los buzones de correo de Exchange Online y las cuentas de OneDrive para empresas.
Figura 4: agregar el ámbito adaptable a una política de retención de Microsoft 365
Licencias E5 requeridas para Adaptive Scopes
Recuerde que el uso de ámbitos adaptables requiere licencias de cumplimiento de Office 365 E5 o Microsoft 365 E5. Si no tiene estas licencias, es posible usar PowerShell para actualizar las ubicaciones de una política de retención estática con los detalles de los usuarios de un dominio específico. Por ejemplo:
Set-RetentionCompliancePolicy -Identity "Office 365 IT Pros Retention Policy" -AddExchangeLocation "Peter.Bridges@infotecnologia.com"
Como se mencionó anteriormente, un runbook de Azure Automation es un buen método para asignar cuentas de usuario con el valor relevante para el atributo personalizado. El mismo runbook podría incluir fácilmente código para actualizar una política de retención. En este caso, la política de retención tiene un alcance estático, lo que significa que Purview no actualiza automáticamente las ubicaciones bajo el control de la política mediante un alcance adaptable. En su lugar, las ubicaciones de las políticas permanecen estáticas hasta que un administrador las actualice (de forma interactiva o ejecutando PowerShell).
El uso de un runbook de Azure Automation significa que trabaja más para desarrollar y mantener el código de PowerShell, pero no necesita licencias E5. Todo lo que se necesita es un poco de trabajo adicional para asegurarse de que las políticas de retención procesen las cuentas correctas.
