AD Minimization: How ready are organizations for the journey?
Microsoft's direction around Active Directory minimization is an interesting and important part of the broader cloud transformation journey. Moving more identity and device management toward Microsoft Entra ID can help organizations gradually reduce their dependency on traditional on-premises Active Directory and move towards a more cloud-first environment. What I particularly like about Microsoft's approach is that this is positioned as a journey rather than something that needs to happen overnight. For many organizations, Active Directory has been part of the environment for 20+ years. Over that time, a lot of dependencies may have been built around it, such as: Legacy applications, Group Policies, Domain-joined Windows devices, LDAP, Kerberos or NTLM dependencies, File servers and other infrastructure, Scripts and operational processes linked to AD. Moving new users, applications and devices towards a cloud-first approach is one part of the journey. The more interesting challenge is how organizations modernize the existing environment while minimizing disruption to users and day-to-day operations. This is where I think Microsoft's phased approach makes a lot of sense. Organizations can gradually identify and reduce AD dependencies while continuing to modernize identity, endpoint management and applications at a pace that works for their environment. I would be interested to hear from others who are already working towards AD minimization. Where is your organization in this journey today? Are you already actively reducing your dependency on on-premises AD? And what has been the biggest area to address so far, legacy applications, Group Policy, existing Windows devices, authentication dependencies, or something else? It would also be interesting to hear which Microsoft technologies or approaches have helped you most during this transition.
Single-Sign On
After troubleshooting an issue for a customer, we determined that the prerequisites for enabling SSO at the AVD host pool level is not strictly enforced when a user goes to execute the SSO workflow from MSRDC or the Windows App. Meaning, that if an administrator does not enable the -IsRemoteDesktopEnabled flag on the Service Principals "Microsoft Remote Desktop" and "Windows Cloud Login" respectively. Setup: Deploy Entra ID Joined session hosts to a host pool and enable the "Microsoft Entra single sign-on" RDP property to "Connections will use Microsoft Entra authentication to provide single sign-on" or update the RDP connection string with 'enablerdsaadauth:i:1'. Result: User will not receive the 'Windows Security' dialog box to access the session host with their Entra ID credentials. Caveat: Be aware that to sign in with Entra ID credentials, minimally, the host pool RDP settings must contain 'targetisaddjoined:i:1'. Microsoft states this is going away and blending into 'enablerdsaadauth:i:1', which also enables SSO. It seems a bit odd of a move in my opinion and having two separate RDP properties makes sense if a company does not want SSO. But it is in alignment with Microsoft's push for passwordless authentication. For the Microsoft AVD team, why does this behavior exist and is it on the roadmap to be fixed if it's a known gap?