Home

AD Sync not strictly required?

%3CLINGO-SUB%20id%3D%22lingo-sub-872009%22%20slang%3D%22en-US%22%3EAD%20Sync%20not%20strictly%20required%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-872009%22%20slang%3D%22en-US%22%3E%3CP%3EHey%20there!%3CBR%20%2F%3E%3CBR%20%2F%3EI'm%20experimenting%20with%20WVD%20deployments.%20Currently%20I%20managed%20to%20build%20WVD%20RDS%20session%20host%20as%20WinServer2019%20Smalldisk%2C%20that%20is%20also%20a%20domain%20controller%20for%20itself.%20Upon%20creation%2C%20I%20created%20ADDS%20VM%20side%20by%20side%2C%20it%20domain%20joined%2C%20then%20I%20promoted%20RDSH%20to%20DC%20itself%20and%20demoted%20the%20original%20DC.%20I%20changed%20the%20AD%20to%20have%20the%20matching%20UPN%20with%20my%20tenant%20but%20didn't%20sync%20them%20with%20AD%20Connect.%20From%20what%20I%20can%20tell%20-%20it%20works%20just%20fine%3F%20Is%20there%20a%20strict%20requirement%20to%20sync%20the%20directories%3F%20If%20any%2C%20what%20components%20depend%20on%20the%20sync%20functionality%20(aside%20from%20SSO%20which%20is%20already%20documented%2C%20but%20not%20needed%20in%20my%20scenario)%3F%20Could%20it%20be%20that%20Licensing%20Service%20needs%20it%3F%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EThanks%20for%20any%20insight%20on%20that%20one%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EAlex%20Pawlak%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-873252%22%20slang%3D%22en-US%22%3ERe%3A%20AD%20Sync%20not%20strictly%20required%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-873252%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F186680%22%20target%3D%22_blank%22%3E%40Aleksander%20Pawlak%3C%2FA%3E%26nbsp%3B%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20AD%20Connect%20will%20sync%20the%20user%20accounts%20from%20your%20Windows%20AD%20to%20Azure%20AD%2C%20so%20that%20the%20user%20can%20authenticate%20when%20starting%20the%20WVD%20client%20(web%20or%20installed%20client)%3C%2FP%3E%3CP%3EThose%20clients%20will%20authenticate%20against%20Azure%20AD%20first%2C%20requiring%20the%20users%20to%20live%20in%20Azure%20AD%20in%20the%20same%20way%20the%20live%20in%20Windows%20AD%20(same%20password%2C%20upn%2C%20etc)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegarding%20the%20working%20deployment%3A%20is%20the%20user%20you%20test%20with%20created%20in%20both%20Azure%20AD%20%26amp%3B%20Windows%20AD%20with%20the%20same%20credentials%20%26amp%3B%20UPN%3F%3C%2FP%3E%3CP%3EIf%20you%20create%20a%20new%20user%20in%20Azure%20AD%2C%20the%20user%20will%20be%20able%20to%20authenticate%20in%20the%20clients%2C%20but%20will%20not%20be%20able%20to%20start%20an%20application.%3C%2FP%3E%3CP%3EIf%20you%20create%20a%20new%20user%20in%20Windows%20AD%2C%20this%20user%20will%20not%20be%20able%20to%20authenticate%20in%20the%20clients%2C%20and%20never%20start%20an%20application%20through%20WVD.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHope%20this%20makes%20things%20clear%20for%20you%26nbsp%3B%3CIMG%20class%3D%22lia-deferred-image%20lia-image-emoji%22%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Fhtml%2Fimages%2Femoticons%2Fsmile_40x40.gif%22%20alt%3D%22%3Asmile%3A%22%20title%3D%22%3Asmile%3A%22%20%2F%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-873948%22%20slang%3D%22en-US%22%3ERe%3A%20AD%20Sync%20not%20strictly%20required%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-873948%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F298270%22%20target%3D%22_blank%22%3E%40michawets%3C%2FA%3E%26nbsp%3BThanks%20for%20response!%3CBR%20%2F%3E%3CBR%20%2F%3EThat%20I%20did%20is%20that%20I%20duplicated%20identities%20-%20there%20is%20an%20account%20name%20%22john%40domain.com%22%20coming%20from%20Windows%20Server%20AD%20and%20same%20account%20%22john%40domain.com%22%20in%20Azure%20AD.%20AAD%20tenant%20is%20linked%20to%20WVD%20Tenant%2C%20user%20authenticates%20with%20their%20AAD%20credentials.%20Then%2C%20upon%20opening%20an%20app%2C%20they%20are%20prompted%20once%20again%20for%20credentials%20-%20this%20time%20for%20Windows%20Server%20AD.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3ETo%20give%20my%20testing%20a%20bit%20more%20context%20-%20I'd%20like%20to%20publish%20WVD%20to%20very%20small%2C%20non-technical%20organizations%20who%20have%20no%20IT%20infrastructure%20at%20all.%20I%20prefer%20to%20keep%20their%20identities%20in%20AAD%20only%2C%20but%20since%20Windows%20Server%20doesn't%20(hopefully%20yet!)%20support%20AAD%20join%2C%20it%20needs%20to%20be%20comboed%20that%20way.%20To%20keep%20things%20resilient%20to%20failure%20I%20do%20not%20want%20to%20build%20Windows%20Server%20AD%20-%20so%20I%20want%20to%20make%20it%20as%20basic%20as%20possible.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EI%20was%20worried%20that%20there%20might%20be%20some%20licensing%20check%2Fenforcement%20to%20see%20if%20user%20entity%20is%20linked%20to%20RDP%20CAL%20with%20SA%20(or%20CSP%20one)%2C%20but%20I%20don't%20think%20that's%20the%20case%20and%20these%20licenses%20need%20to%20be%20inventoried%20and%20linked%20as%20%22classic%22%20Server%20CALs%20%3F%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks!%3C%2FP%3E%3CP%3EAlex%20P%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-875425%22%20slang%3D%22en-US%22%3ERe%3A%20AD%20Sync%20not%20strictly%20required%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-875425%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F186680%22%20target%3D%22_blank%22%3E%40Aleksander%20Pawlak%3C%2FA%3E%26nbsp%3B%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAs%20I%20already%20thought%20and%20stated%2C%20the%20UPN%20%26amp%3B%20password%20hashes%20do%20match%20in%20Windows%20AD%20%26amp%3B%20Azure%20AD%2C%20making%20it%20possible%20for%20the%20user%20to%20sign%20in.%26nbsp%3B%3CIMG%20class%3D%22lia-deferred-image%20lia-image-emoji%22%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Fhtml%2Fimages%2Femoticons%2Fsmile_40x40.gif%22%20alt%3D%22%3Asmile%3A%22%20title%3D%22%3Asmile%3A%22%20%2F%3E%3C%2FP%3E%3CP%3EBut%20as%20soon%20as%20Windows%20AD%20or%20Azure%20AD%20changes%2C%20it%20would%20fall%20apart.%20%3CIMG%20class%3D%22lia-deferred-image%20lia-image-emoji%22%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Fhtml%2Fimages%2Femoticons%2Fflushed_40x40.gif%22%20alt%3D%22%3Aflushed%3A%22%20title%3D%22%3Aflushed%3A%22%20%2F%3E%3CBR%20%2F%3ETherefor%2C%20AD%20Connect%20syncs%20the%20useraccounts%20from%20Windows%20AD%20to%20Azure%20AD%2C%20keeping%20passwords%20in%20sync%20(with%20Writeback%20capabilities).%3CBR%20%2F%3EAzure%20AD%20DS%20goes%20a%20step%20further%2C%20it%20starts%20from%20Azure%20AD%2C%20and%20makes%20a%20Windows%20AD%20available%20in%20your%20VNET%2C%20also%20keeping%20it%20in%20sync.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegarding%20the%20licensing%3A%20it%20could%20be%20possible%20to%20connect%20without%20proper%20license%2C%20but%20this%20is%20not%20guaranteed.%20I%20would%20recommend%20to%20assign%20an%26nbsp%3B%3CSPAN%3Eeligible%26nbsp%3Blicense%20to%20the%20user(s)%20which%20are%20listed%20here%20at%20the%20FAQ.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fazure.microsoft.com%2Fen-gb%2Fpricing%2Fdetails%2Fvirtual-desktop%2F%26nbsp%3B%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fazure.microsoft.com%2Fen-gb%2Fpricing%2Fdetails%2Fvirtual-desktop%2F%26nbsp%3B%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-875501%22%20slang%3D%22en-US%22%3ERe%3A%20AD%20Sync%20not%20strictly%20required%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-875501%22%20slang%3D%22en-US%22%3E%3CP%3EOK%20%3A)%3C%2Fimg%3E%20So%20that%20kind%20of%20makes%20it%20clear%20-%20AD%20Connect%20is%20preferred%20method%20of%20making%20password%20sync%2C%20but%20if%20I%20want%20to%20keep%20entities%20separate%2C%20I%20just%20need%20to%20make%20sure%20the%20password%20remains%20the%20same%20%3A)%3C%2Fimg%3E%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EThe%20licenses%20are%20bought%2C%20with%20VLSC%20or%20CSP%2C%20and%20only%20assigned%20as%20%22entitlement%22%20on%20paper%2C%20contrary%20to%20%22classic%22%20RD%20Licensing%20-%20where%20the%20licenses%20have%20had%20to%20be%20technically%20activated%20on%20license%20server%20-%20is%20this%20the%20right%20approach%3F%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3EThanks!%3C%2FP%3E%3C%2FLINGO-BODY%3E
Aleksander Pawlak
Contributor

Hey there!

I'm experimenting with WVD deployments. Currently I managed to build WVD RDS session host as WinServer2019 Smalldisk, that is also a domain controller for itself. Upon creation, I created ADDS VM side by side, it domain joined, then I promoted RDSH to DC itself and demoted the original DC. I changed the AD to have the matching UPN with my tenant but didn't sync them with AD Connect. From what I can tell - it works just fine? Is there a strict requirement to sync the directories? If any, what components depend on the sync functionality (aside from SSO which is already documented, but not needed in my scenario)? Could it be that Licensing Service needs it? 

Thanks for any insight on that one 


Alex Pawlak

4 Replies

Hi @Aleksander Pawlak ,

 

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 :smile:

@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 @Aleksander Pawlak ,

 

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. :smile:

But as soon as Windows AD or Azure AD changes, it would fall apart. :flushed:
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!

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
35 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies