Jun 01 2021 02:41 PM
I couldn't figure out why I was unable to connect to my Win 10 session hosts using the credentials I used to join the session hosts to the domain during deployment.
I see now that this account, which is part of the AAD DC Administrators group in Azure AD and AADDS, is not a member of Domain Admins in the AADDS domain, and therefore it doesn't automatically have remote desktop connection rights to the session host. Is that by design or did I do something wrong? Is it a bad idea to manually add this account to the Domain Admins group?
And how is it that standard users automatically get these remote desktop connection rights? The account that's denied access is part of the same Azure AD security group that has an assignment to the Desktop Application Group for the Host Pool. So why can an ordinary user log in but not an account with the power to join a machine to the domain?
Jun 01 2021 11:40 PM
Jun 02 2021 06:18 AM
Jun 02 2021 09:51 AM - edited Jun 02 2021 09:54 AM
SolutionIf I recall correctly there should be a standard GPO in the AADDS domain that adds the AAD DC Admin group to the local admins of a sessionhost. It's applied on the AADDC Computers OU so perhaps you moved your VM's to another OU? Try applying that GPO there as well.
I believe it's called "AADDC Computers GPO" but I'm not sure!
Jun 02 2021 11:43 AM
Jun 02 2021 01:02 PM
Feb 01 2024 09:23 AM
@YannickJanssens1986 This helped me out. Thank you! Same issue, using a separate OU and didnt think to link this GPO.
Jun 02 2021 09:51 AM - edited Jun 02 2021 09:54 AM
SolutionIf I recall correctly there should be a standard GPO in the AADDS domain that adds the AAD DC Admin group to the local admins of a sessionhost. It's applied on the AADDC Computers OU so perhaps you moved your VM's to another OU? Try applying that GPO there as well.
I believe it's called "AADDC Computers GPO" but I'm not sure!