Forum Discussion
AD Sync not strictly required?
Hi AlexPawlak ,
The AD Connect will sync the user accounts from your Windows AD to Azure AD, so that the user can authenticate when starting the WVD client (web or installed client)
Those clients will authenticate against Azure AD first, requiring the users to live in Azure AD in the same way the live in Windows AD (same password, upn, etc)
Regarding the working deployment: is the user you test with created in both Azure AD & Windows AD with the same credentials & UPN?
If you create a new user in Azure AD, the user will be able to authenticate in the clients, but will not be able to start an application.
If you create a new user in Windows AD, this user will not be able to authenticate in the clients, and never start an application through WVD.
Hope this makes things clear for you 
michawets Thanks for response!
That I did is that I duplicated identities - there is an account name "john@domain.com" coming from Windows Server AD and same account "john@domain.com" in Azure AD. AAD tenant is linked to WVD Tenant, user authenticates with their AAD credentials. Then, upon opening an app, they are prompted once again for credentials - this time for Windows Server AD.
To give my testing a bit more context - I'd like to publish WVD to very small, non-technical organizations who have no IT infrastructure at all. I prefer to keep their identities in AAD only, but since Windows Server doesn't (hopefully yet!) support AAD join, it needs to be comboed that way. To keep things resilient to failure I do not want to build Windows Server AD - so I want to make it as basic as possible.
I was worried that there might be some licensing check/enforcement to see if user entity is linked to RDP CAL with SA (or CSP one), but I don't think that's the case and these licenses need to be inventoried and linked as "classic" Server CALs ?
Thanks!
Alex P
Hi AlexPawlak ,
As I already thought and stated, the UPN & password hashes do match in Windows AD & Azure AD, making it possible for the user to sign in.
But as soon as Windows AD or Azure AD changes, it would fall apart.
Therefor, AD Connect syncs the useraccounts from Windows AD to Azure AD, keeping passwords in sync (with Writeback capabilities).
Azure AD DS goes a step further, it starts from Azure AD, and makes a Windows AD available in your VNET, also keeping it in sync.Regarding the licensing: it could be possible to connect without proper license, but this is not guaranteed. I would recommend to assign an eligible license to the user(s) which are listed here at the FAQ.
https://azure.microsoft.com/en-gb/pricing/details/virtual-desktop/
OK 🙂 So that kind of makes it clear - AD Connect is preferred method of making password sync, but if I want to keep entities separate, I just need to make sure the password remains the same 🙂
The licenses are bought, with VLSC or CSP, and only assigned as "entitlement" on paper, contrary to "classic" RD Licensing - where the licenses have had to be technically activated on license server - is this the right approach?
Thanks!
