Why is an AAD DC Administrator not a Domain Admin?


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?

5 Replies
AADDS has several limitations. One of them is that you can never be a Domain Administrator in the managed domain. So you can't add that account manually either:

That's interesting. So how do you perform administrative functions on the session hosts -- always as the local admin?
best response confirmed by David Schrag (Contributor)

@David Schrag 

If 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!


Excellent catch! There is indeed a GPO called AADDC Computers GPO, applied to the AADDC Computers OU, that does just what you described. I have been putting my session hosts in a separate OU so I could apply WVD-specific policies to them. I linked the GPO to my WVD Host OU, ran gpupdate /force on a session host, and got in with my not-really-a-domain-admin account. :) Thanks!
Glad you got it sorted out!