Kerberos Without Line of Sight

Diagnose before choosing. The symptom set is diagnostic: office users work, remote users fail, and the only difference is reachability to a domain controller. The session host cannot obtain a Kerberos ticket for cifs/<storageaccount>.file.core.windows.net, so the FSLogix attach fails. This is a ticket problem, not a permissions problem, so re-ACLing the share will not help.

Options, ranked:

1. Restore line of sight (VPN or ExpressRoute). Three lines of firewall change versus a re-platform. It directly contradicts the VPN retirement decision, so it is a business argument, not a technical one.
2. Microsoft Entra Domain Services, re-joining hosts to the managed domain. Works, keeps the AD DS Kerberos model, but adds a managed domain, requires password hash synchronisation, DNS repointing, and a full re-join. It also does not advance the CISO's goal.
3. Entra-joined session hosts plus Microsoft Entra Kerberos on the storage account. No domain controller in the path for file access, supports hybrid and cloud-only identities, and is the target state the CISO wants anyway.

Prerequisites for option 3: enable Microsoft Entra Kerberos on the storage account (this creates the Kerberos server object), confirm the storage account and clients are in the same tenant, re-provision or re-join hosts as Entra joined, and assign share-level RBAC (Storage File Data SMB Share Contributor or higher). Note the model shift: access is share-level RBAC, not granular per-user NTFS ACLs, so check that the existing directory permissions do not lock users out of creating their own container folder.

Pilot validation: one Entra-joined host, one pilot user, run klist to confirm a ticket exists for the file service, then confirm FSLogix attaches and the logon duration matches the office baseline. Profile data does not need to move; the VHDX stays where it is.

First, the constraint that shapes everything. Conditional Access sees a sign-in to the Azure Virtual Desktop first-party application. It cannot target a host pool, an application group, or a session host. Every policy you write applies to all AVD resources the user can reach, so you segment by user group, never by resource. If someone asks for 'MFA on the CAD pool only', the answer is no; you use RBAC on the application group for visibility and in-session controls for behaviour.

Employees (700):

• Require multifactor authentication, and pair it with a device control: require the device to be compliant or Microsoft Entra hybrid joined, using 'require one of the selected controls' so a compliant personal device is not automatically excluded.
• Block legacy authentication, enable a sane sign-in frequency with persistent browser sessions for the AVD client so users are not re-prompted mid-shift, and consider token protection.

Contractors (200, unmanaged laptops):

• A compliant-device requirement will lock them out, because compliance cannot be evaluated on a device they do not manage. Do not 'fix' this by exempting them from MFA.
• Give them a separate policy: require MFA with a stronger authentication strength, shorter sign-in frequency, named-location restrictions if they work from fixed sites, and monitoring of their sign-ins. Accept that the compensating control is authentication strength plus session limits, not device trust.
• Do not use 'Require Microsoft Entra hybrid joined device' as a control here; the CISO's target state has no on-premises domain to join.

The other thing CA cannot do: enforce MFA inside the RDP session. There is no per-session MFA; the control is at the Entra sign-in, and a disconnected session stays authenticated until the token or session policy ends. Use idle and disconnect time limits for that, not CA.

Enumerate by dependency, not by guesswork.

• Azure Files Kerberos - must move to Microsoft Entra Kerberos, with the share-level RBAC model replacing per-user NTFS ACLs.
• Group Policy - FSLogix configuration, drive mappings, printer deployment, security baseline, and any logon scripts. All of it moves to Intune Settings Catalog, custom OMA-URI, or PowerShell deployed via the platform. Capture the current effective policy (gpresult or a registry export) so you can prove parity afterwards.
• Windows Integrated Authentication from inside the session to on-premises SQL, IIS, or file servers. Entra-joined devices cannot get an AD Kerberos TGT by default. The mitigation is Cloud Kerberos Trust: configure Microsoft Entra ID Kerberos against AD (AzureADKerberos module) so hybrid identities keep SSO to on-prem resources. Verify the domain controller functional level and that the user objects are the hybrid ones.
• Local administration and delegation - helpdesk admin groups, LAPS, local Administrators membership; all through Intune now.
• Device management plumbing - Intune auto-enrolment keys off Entra join, so this actually gets simpler; confirm the MDM authority and enrolment restrictions before cutover.

Verification plan: a pilot pool running the real golden image with real apps and 10-20 real users for at least a week. Success criteria: zero Kerberos failures in the security event logs (klist, 4768/4769 events), FSLogix attach success rate equal to baseline, every GPO-derived setting confirmed present on the pilot host, and each on-prem-integrated app tested by a user, not by an admin account. Only then decommission the domain-join step in the image pipeline.