Cómo desplegar Azure Virtual Desktop con Entra ID Join, Cloud Kerberos y FSLogix

Una guía práctica, paso a paso, para montar un entorno de Azure Virtual Desktop sin Active Directory on-premise, con perfiles persistentes en Azure Files. Incluye los dos errores que casi siempre rompen este tipo de despliegues y cómo resolverlos.

Introducción

Azure Virtual Desktop (AVD) con Microsoft Entra ID Join es una de las formas más limpias de entregar escritorios virtuales en la nube: no necesitas un domain controller, ni VPN hacia tu Active Directory, ni sincronización híbrida. Pero tiene un par de detalles que, si no los conoces, te van a costar horas de diagnóstico: la autenticación Kerberos contra Azure Files y el manejo de perfiles persistentes con FSLogix.

En este post documento el despliegue completo de un entorno AVD desde cero, tal como lo hice en un proyecto real, incluyendo:

• Red, host pool y session hosts.
• Permisos y licenciamiento.
• FSLogix sobre Azure Files con Microsoft Entra Kerberos.
• La clave crítica CloudKerberosTicketRetrievalEnabled (el detalle que casi nadie documenta).
• Los errores 50055 y 1265 y cómo se resuelven.

Convención de nombres usada en esta guía. Reemplázalos por los de tu organización:

• Resource group: rg-avd-lab
• VNet / Subnet: vnet-avd-lab / snet-avd
• Host pool: hp-avd-lab · Workspace: ws-avd-lab
• Session hosts: avdlab-0 / avdlab-1 / avdlab-2
• Storage account: stavdlabprofiles · Share: profiles
• Grupo de acceso (Entra): DPMX LabUsers

---

Requisitos previos

• Una suscripción de Azure con rol Owner o Contributor.
• Global Administrator (o Privileged Role Administrator) en Entra ID, necesario para dar admin consent a la app del storage account.
• Cuota suficiente de la familia de VM elegida en la región destino.
• Licencias elegibles para los usuarios (Microsoft 365 E3/E5/A3/A5/F3/Business Premium, Windows E3/E5, o AVD por usuario).
• Un grupo de seguridad de Entra ID con los usuarios finales (aquí: DPMX LabUsers).
• PowerShell con el módulo Az, o usar Azure Cloud Shell (ya viene autenticado).

---

Fase 1 — Fundamentos de red

Creamos una red aislada para que el lab no interfiera con recursos existentes. AVD con Entra Join no necesita DNS personalizado.

1.1 Resource group

1. Portal → Resource groups → Create.
2. Nombre rg-avd-lab; elige la región donde tengas cuota.
3. Agrega tags env=lab, purpose=avd → Review + create.

1.2 Red virtual y subnet

1. Portal → Virtual networks → Create. Resource group: rg-avd-lab.
2. Nombre vnet-avd-lab. En la pestaña Security, deja VNet encryption, Bastion y Firewall apagados (son servicios de pago, no necesarios).
3. Pestaña Address space: define 10.50.0.0/24 (verifica que no se solape con otra VNet existente).
4. Edita la subnet → nombre snet-avd, rango 10.50.0.0/25.
5. Desmarca “Enable private subnet” — los hosts necesitan salida a internet por defecto para registrarse en el servicio de AVD. Deja NAT gateway / NSG / Route table en None. DNS: Azure default.
6. Review + create.

Por qué importa la salida a internet. Los session hosts deben alcanzar el control plane de AVD y Entra ID por internet para registrarse, hacer el join y descargar el agente. Una private subnet sin NAT gateway bloquea esto y los hosts se quedan atascados en “registrando” o fallan al desplegar.

---

Fase 2 — Host pool y session hosts

Creamos el host pool, las VMs, el workspace y el desktop app group en una sola pasada del asistente.

2.1 Datos básicos del host pool

1. Portal → Azure Virtual Desktop → Create a host pool. Resource group: rg-avd-lab.
2. Nombre del host pool hp-avd-lab; Location (metadata) = región permitida más cercana.
3. Validation environment: No. Preferred app group type: Desktop.
4. Host pool type: Pooled.
5. Create Session Host Configuration: No (gestión clásica del ciclo de vida).
6. Load balancing algorithm: Breadth-first. Max session limit: 20.

2.2 Session hosts (pestaña Virtual Machines)

1. Add Azure virtual machines = Yes. Resource group: rg-avd-lab.
2. Name prefix avdlab (genera avdlab-0/1/2). VM location: misma región que la VNet.
3. Availability options: No infrastructure redundancy required (lo más simple para un lab), o elige Availability Zones si quieres redundancia.
4. Security type: Trusted launch (secure boot + vTPM + integrity monitoring, todos marcados).
5. Image: Windows 11 Enterprise multi-session 24H2 + Microsoft 365 Apps (Gen 2). Debe ser multi-session y Gen 2 para Trusted launch.
6. VM size: D8s_v5 / D8ds_v7 (8 vCPU / 32 GB). Number of VMs: 3.
7. OS disk: Premium SSD (128 GiB por defecto). Boot diagnostics: habilitado con managed storage account.
8. Network: vnet-avd-lab / snet-avd. Public inbound ports: No.
9. Domain to join: Microsoft Entra ID. Enroll VM with Intune: No (salvo que MDM esté listo).
10. Cuenta de administrador local: crea un admin (p. ej. avdadmin) con contraseña fuerte y guárdala de forma segura. Deja vacío el campo de script de configuración personalizada.

2.3 Workspace

1. Pestaña Workspace → Register desktop app group = Yes.
2. To this workspace → Create new → ws-avd-lab en rg-avd-lab.
3. Salta Management/Tags (los valores por defecto están bien) → Review + create.

Lo que el asistente NO hace. La pasada única crea el host pool, las 3 VMs, el desktop app group y el workspace. No asigna usuarios ni concede permisos de inicio de sesión: eso es la Fase 3. El despliegue de las 3 VMs tarda unos 15-25 minutos.

---

Fase 3 — Acceso, permisos y licenciamiento

Estos pasos son obligatorios con Entra Join. Sin ellos, el usuario puede ver el escritorio pero no puede iniciar sesión (o ni siquiera lo ve).

3.1 Verificar que los hosts se desplegaron

1. Host pools → hp-avd-lab → Session hosts. Confirma que avdlab-0/1/2 estén en Available.
2. Opcional: Entra ID → Devices, los 3 hosts aparecen como Microsoft Entra joined.

3.2 Asignar usuarios al Application Group

1. Azure Virtual Desktop → Application groups → hp-avd-lab-DAG.
2. Assignments → + Add → selecciona el grupo DPMX LabUsers → Add. Esto controla quién ve el escritorio.

3.3 Conceder permiso de inicio de sesión (crítico)

1. Resource groups → rg-avd-lab → Access control (IAM) → Add → Add role assignment.
2. Rol: Virtual Machine User Login → Members: DPMX LabUsers → Review + assign.
3. (Opcional, para admins) repite con el rol Virtual Machine Administrator Login para tu grupo de administradores.

La causa #1 de “todo se ve bien pero nadie puede entrar”. Ser Owner o Global Admin NO otorga inicio de sesión en una VM Entra-joined. El rol Virtual Machine User Login es un permiso aparte y obligatorio. Asígnalo a nivel de resource group para que cubra todos los hosts actuales y futuros.

3.4 Propiedad RDP para clientes web / no-Windows

1. Host pools → hp-avd-lab → RDP Properties → pestaña Advanced.
2. Agrega targetisaadjoined:i:1 a las propiedades personalizadas (separa con ; si ya hay otras) → Save.

Esto es necesario para que los clientes web, macOS, iOS y Android (y Windows no Entra-joined) puedan autenticarse contra hosts Entra-joined. Estas conexiones quedan limitadas a inicio de sesión con usuario y contraseña.

3.5 Beneficio de licencia AVD (verificar, normalmente automático)

El asistente de despliegue normalmente lo aplica automáticamente. Verifícalo con PowerShell:

powershell

# Conectar (omítelo en Cloud Shell, ya estás autenticado)
Connect-AzAccount
Set-AzContext -Subscription "<NOMBRE DE TU SUSCRIPCIÓN>"

# Verificar el estado actual
Get-AzVM -ResourceGroupName "rg-avd-lab" | Select-Object Name, LicenseType

Si LicenseType devuelve Windows_Client, ya está aplicado. Si está vacío, aplícalo a todos los hosts:

powershell

$vms = Get-AzVM -ResourceGroupName "rg-avd-lab"
foreach ($vm in $vms) {
    $vm.LicenseType = "Windows_Client"
    Update-AzVM -ResourceGroupName "rg-avd-lab" -VM $vm
    Write-Host "Licencia aplicada a $($vm.Name)" -ForegroundColor Green
}

Notas de licencia. Usa Windows_Client para Windows 10/11 multi-session, nunca Windows_Server. Es solo metadata: no reinicia las VMs. Declara que tienes una licencia elegible para que Azure no cobre la tarifa RDS adicional. El cumplimiento de licenciamiento de los usuarios finales sigue siendo tu responsabilidad.

---

Fase 4 — Perfiles FSLogix en Azure Files

En un host pool Pooled, cada inicio de sesión puede caer en un host distinto. FSLogix guarda cada perfil como un VHDX en un share de Azure Files para que el perfil siga al usuario. Con hosts Entra-joined, el share autentica usando Microsoft Entra Kerberos.

4.1 Crear el storage account

1. Portal → Storage accounts → Create. Resource group: rg-avd-lab; región = misma que las VMs.
2. Nombre dpmxavdprofiles (minúsculas/números, 3-24 caracteres). Primary service: Azure Files.
3. Performance / Media tier: Premium (SSD); File share billing: Provisioned v2.
4. Redundancy: LRS. Zone options: None. Deja Advanced/Networking/Encryption por defecto → Review + create.

Las demás opciones restantes las dejamos tal cual y creamos el recurso.

4.2 Crear el file share

1. Abre el storage account → Data storage → File shares → + File share.
2. Nombre profiles; tamaño aprovisionado 100 GiB (suficiente para un lab; elástico después). Protocol: SMB. Salta Backup para un lab → Create.

Regla de dimensionamiento. Calcula entre 5 y 15 GB por perfil de usuario. 100 GiB sobra para un lab; súbelo en producción según el número de usuarios y la carga. Premium cobra por capacidad aprovisionada, así que no sobre-asignes.

4.3 Habilitar Microsoft Entra Kerberos en el storage account

1. Storage account → panel File service → Identity-based access → clic en “Not configured” (o Security + networking → Identity-based access).
2. Elige Microsoft Entra Kerberos → el checkbox lo habilita. Deja Domain name / Domain GUID vacíos (solo se necesitan para NTFS vía Explorador; FSLogix/icacls no los requiere) → Save.

NO elijas AD DS ni Entra Domain Services. Para hosts Entra-joined puros, la fuente de identidad correcta es Microsoft Entra Kerberos. AD DS y Entra Domain Services son para despliegues basados en dominio.

4.4 Conceder admin consent (el paso que más se olvida)

Habilitar Kerberos auto-registra una app para el storage account que necesita admin consent.

1. Entra ID → App registrations → All applications.
2. Abre [Storage Account] stavdlabprofiles.file.core.windows.net.
3. API permissions → Grant admin consent for <tenant>. Confirma que openid / profile / User.Read muestren el check verde en Status.

Sin este consent, el montaje del perfil falla en silencio y los usuarios caen a un perfil local temporal.

4.5 Permisos a nivel de share (RBAC)

1. Storage account → Identity-based access → Step 2, o IAM → Add role assignment.
2. Rol: Storage File Data SMB Share Contributor → asígnalo a DPMX LabUsers.
3. Para un lab puedes en su lugar habilitar “permissions for all authenticated users and groups” con el mismo rol. Para producción, acótalo al grupo vía IAM.

Elección del rol. Storage File Data SMB Share Contributor da lectura + escritura de datos, correcto para FSLogix. Elevated Contributor (puede cambiar ACLs NTFS) es solo para admins; Reader es solo lectura y rompería la escritura del perfil.

4.6 Aplicar la configuración de FSLogix en cada session host

Estas claves de registro le dicen a cada host dónde guardar los perfiles. Aplícalas con Run Command desde el portal (se ejecuta como SYSTEM, sin RDP ni asignaciones de AVD). Repite en avdlab-0, avdlab-1 y avdlab-2.

Portal → Virtual machines → avdlab-X → Operations → Run command → RunPowerShellScript

powershell

$key = "HKLM:\SOFTWARE\FSLogix\Profiles"
New-Item -Path $key -Force | Out-Null
New-ItemProperty -Path $key -Name "Enabled" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path $key -Name "VHDLocations" `
    -Value "\\dpmxavdprofiles.file.core.windows.net\profiles" -PropertyType String -Force
New-ItemProperty -Path $key -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path $key -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWORD -Force
Write-Host "FSLogix configurado en $env:COMPUTERNAME" -ForegroundColor Green

Clave	Propósito
Enabled = 1	Activa los contenedores de perfil de FSLogix.
VHDLocations	Ruta UNC al share de Azure Files que contiene los VHDX de perfil.
DeleteLocalProfileWhenVHDShouldApply = 1	Evita conflictos cuando existe un perfil local previo del usuario.
FlipFlopProfileDirectoryName = 1	Nombra las carpetas como usuario_SID (más legible) en vez de SID_usuario.

4.7 Habilitar Cloud Kerberos en cada session host (el fix crítico)

Habilitar Entra Kerberos en el storage account no es suficiente: cada host también debe recibir la instrucción de obtener los tickets Kerberos desde Entra ID. Sin esto, FSLogix falla con el error 1265 (“no puede contactar un domain controller”) y cae a un perfil local, dejando el share vacío.

Run Command en avdlab-0, avdlab-1 y avdlab-2:

powershell

$key = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters"
New-Item -Path $key -Force | Out-Null
New-ItemProperty -Path $key -Name "CloudKerberosTicketRetrievalEnabled" `
    -Value 1 -PropertyType DWORD -Force
Write-Host "CloudKerberosTicketRetrievalEnabled aplicado en $env:COMPUTERNAME" -ForegroundColor Green

Requiere reinicio. El cambio de Kerberos surte efecto solo tras reiniciar. Reinicia cada host (portal → VM → Restart, o Restart-Computer -Force vía Run Command) y luego haz que los usuarios inicien sesión fresca. Aplícalo a TODOS los hosts del pool: con Breadth-first, un usuario puede caer en cualquier host, y uno sin la clave fallará con el error 1265.

---

Fase 5 — Primer inicio de sesión, MFA y validación

5.1 Preparar al usuario (evitar el bloqueo del primer login)

Las cuentas nuevas de Entra suelen quedar marcadas con “debe cambiar contraseña en el próximo inicio de sesión”. El cliente web de AVD no maneja ese flujo, así que la primera conexión se cuelga con el error 50055.

1. Haz que el usuario inicie sesión una vez en un portal normal primero, por ejemplo https://office.com, para cambiar la contraseña y registrar su método MFA.
2. Confirma que el usuario sea miembro de DPMX LabUsers (esto otorga tanto la asignación del escritorio como el permiso de inicio de sesión).

5.2 Conectarse a AVD

1. Abre https://client.wvd.microsoft.com/arm/webclient (o la app Windows App / Remote Desktop).
2. Inicia sesión con las credenciales del usuario y completa MFA.
3. Abre SessionDesktop para lanzar el escritorio en uno de los hosts.

5.3 Verificar Conditional Access / MFA (si aplica)

1. Entra ID → Sign-in logs → filtra por el usuario. Abre el evento de AVD → pestaña Conditional Access para ver qué política aplicó.
2. Si exiges MFA vía CA, apunta a las apps correctas: Azure Virtual Desktop, Microsoft Remote Desktop y Windows Cloud Login. NO apuntes a la app “Azure Virtual Desktop ARM Provider”.
3. Asegúrate de que cada usuario tenga al menos un método MFA registrado, o no podrá completar el inicio de sesión.

5.4 Verificar que FSLogix esté montando los perfiles

Identifica en qué host cayó el usuario (Host pool → Session hosts) y ejecuta Run Command en esa VM:

powershell

Write-Host "=== Claves de registro ===" -ForegroundColor Cyan
Get-ItemProperty "HKLM:\SOFTWARE\FSLogix\Profiles" |
  Select-Object Enabled, VHDLocations | Format-List

Write-Host "=== Servicio FSLogix ===" -ForegroundColor Cyan
Get-Service frxsvc | Select-Object Name, Status

Write-Host "=== Volúmenes de perfil montados ===" -ForegroundColor Cyan
Get-Volume | Where-Object FileSystemLabel -like "*Profile*" | Format-Table

Write-Host "=== Sesiones activas ===" -ForegroundColor Cyan
quser

El éxito se ve así: Enabled=1, frxsvc Running, y un volumen montado llamado Profile-<usuario> (Healthy/OK). Luego revisa el share profiles: una carpeta <usuario>_<SID> con un Profile_<usuario>.vhdx lo confirma de extremo a extremo.

Tambien se puede verificar dentro de Storage Account, Browser el VHD Creado

5.5 Probar la persistencia

1. En la sesión del usuario, crea un archivo en el escritorio.
2. Cierra sesión completamente (Sign out, no solo desconectar).
3. Vuelve a iniciar sesión: el archivo debe seguir ahí, confirmando que el perfil se guarda en el share y sigue al usuario entre hosts.

---

Referencia de solución de problemas

Síntoma	Causa y solución
El escritorio no aparece en el feed	Usuario no asignado al Application Group (3.2), o no está en DPMX LabUsers.
“La sesión finalizó debido a un error” tras lanzar	Falta el rol Virtual Machine User Login (3.3), o falta targetisaadjoined:i:1 (3.4).
Error 50055 / login se cuelga la primera vez	Contraseña expirada o marcada para cambio. Cámbiala primero en office.com (5.1).
Error 1265 / el share queda vacío	CloudKerberosTicketRetrievalEnabled no aplicado o host sin reiniciar (4.7). FSLogix cayó a perfil local.
El perfil no persiste	Claves FSLogix ausentes en el host donde cayó el usuario (4.6), o faltan permisos del share / consent de Kerberos (4.4-4.5).
Host atascado en Unavailable	Problema de agente/registro: revisa la salida a internet desde snet-avd y el token de registro.

Comandos rápidos de verificación

powershell

# Beneficio de licencia en todos los hosts
Get-AzVM -ResourceGroupName "rg-avd-lab" | Select-Object Name, LicenseType

# Ruta de red al share desde dentro de un host (Run Command)
Test-NetConnection stavdlabprofiles.file.core.windows.net -Port 445

# Últimas líneas del log de perfil de FSLogix (Run Command)
Get-ChildItem "C:\ProgramData\FSLogix\Logs\Profile" |
  Sort-Object LastWriteTime -Descending | Select-Object -First 1 |
  Get-Content -Tail 40

---

Hacer la configuración duradera

Las claves de FSLogix y la de Cloud Kerberos se aplican por host vía Run Command, así que viven solo en las VMs actuales. Si agregas un host, reimaginas o reconstruyes, se pierden y el error 1265 regresa. Para cualquier cosa más allá de un lab desechable, intégralas mediante:

• Imagen custom: configura un host, captúralo, y las nuevas VMs heredan los ajustes.
• Perfil de configuración de Intune / Settings catalog: se auto-aplica a cualquier host que se una (requiere enrollment de Intune).
• GPO: solo si más adelante introduces AD DS; no aplica al caso de Entra Join puro.

Onboarding de un nuevo usuario (estado estable)

1. Agrega al usuario al grupo DPMX LabUsers de Entra ID.
2. Haz que inicie sesión en office.com primero para configurar MFA y cambiar la contraseña.
3. Que se conecte en https://client.wvd.microsoft.com/arm/webclient y complete MFA. No hay configuración por usuario más allá del grupo.

---

Máquinas Virtuales Administradas por Intune

sí pusiste atención dentro de las primeras configuraciones seleccionamos que las máquinas virtuales fueran administradas por Intune por lo que este proceso Tambien concluye de manera satisfactoria.

Conclusión

Montar AVD con Entra ID Join es totalmente viable sin Active Directory, pero la diferencia entre “parece que funciona” y “funciona de verdad” está en los detalles finos: el rol de inicio de sesión, la propiedad targetisaadjoined, y sobre todo la cadena de Entra Kerberos + CloudKerberosTicketRetrievalEnabled que hace que FSLogix pueda autenticar contra Azure Files. Una vez que conoces estos puntos, el despliegue es reproducible y limpio.

Espero que esta guía te ahorre las horas de diagnóstico que a muchos nos ha costado. Si la replicas en tu entorno, me encantaría saber cómo te fue.

Felices Despliegues!!!!!