Theoretical question - AD / Azure deployment

%3CLINGO-SUB%20id%3D%22lingo-sub-997270%22%20slang%3D%22en-US%22%3ETheoretical%20question%20-%20AD%20%2F%20Azure%20deployment%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-997270%22%20slang%3D%22en-US%22%3E%3CP%3ELet's%20say%20we%20have%20an%20organization%20on-prem%20with%20AD%20(company.com)%20and%20all%20the%20usual%20services.%3CBR%20%2F%3EThis%20company%20has%20a%20lot%20of%20clients%20who%20need%20access%20to%20some%20applications%20such%20as%20SAAS%20that%20can%20be%20implemented%20in%20Azure.%20Let's%20say%20company's%20clients%20include%20several%20hundreds%20companies%20and%20its%20corresponding%20users.%20So%20each%20client%2C%20would%20have%205-10%20users%20who%20need%20access%20to%20the%20applications%20provided%20by%20company.com.%3C%2FP%3E%3CP%3ESuch%20external%2C%20outside%20users%20can%20and%20probably%20should%2C%20be%20maintained%20in%20a%20separate%20directory%20(clients.com).%20Let's%20say%20this%20is%20going%20to%20be%20an%20active%20directory%20which%20exists%20on-prem%20and%20maintains%20one-way%20trust%20with%20company.com%20AD%20environment.%20Or%20completely%20separated%2C%20not%20really%20that%20significantly%20important%20I%20think.%3C%2FP%3E%3CP%3ECompany.com%20maintains%20their%20own%20Azure%20tenant.%20Also%2C%20for%20the%20clients%2C%20they%20can%20setup%20a%20separate%20tenant%20or%20create%20a%20separate%20directory%20in%20their%20own%20Azure%20tenant%20and%20sync%20users%20from%20clients.com.%20Each%20external%20company%2C%20would%20be%20represented%20by%20their%20own%20OU%20with%20users%20for%20such%20company%20synced%20from%20on-prem%20clients.com%20AD%20directory%20to%20the%3A%20either%20same%20tenant%20as%20comany.com%20under%20a%20different%20directory%20or%20synced%20from%20clients.com%20AD%20to%20the%20clients.onmicrosoft.com%20tenant.%20Multiple%20%22sync%20profiles%22%20can%20be%20created%20within%20the%20AADConnect%20tool%20to%20sync%20specific%20OU%20to%20the%20specific%20directory%20in%20the%20tenant%2C%20which%20basically%20would%20results%20to%20something%20like%20this%20-%20user1%40client1.clients.onmicrosoft.com%2C%20user10%40client2.clients.onmicrosoft.com%2C%20etc.%3CBR%20%2F%3EI%20hope%20this%20makes%20sense.%3C%2FP%3E%3CP%3EIs%20that%20something%20practical%20and%20realistic%3F%3CBR%20%2F%3EAre%20there%20any%20better%20or%20more%20functional%20approaches%20for%20such%20design%3F%3CBR%20%2F%3E%3CBR%20%2F%3EThank%20you%20for%20your%20time%20and%20feedback.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-997270%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EHybrid%20Cloud%20Management%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1007233%22%20slang%3D%22en-US%22%3ERe%3A%20Theoretical%20question%20-%20AD%20%2F%20Azure%20deployment%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1007233%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F436715%22%20target%3D%22_blank%22%3E%40VickVega%3C%2FA%3E%2C%26nbsp%3Byour%20ideia%20might%20work%20but%20not%20as%20you%20expect.%20Look%2C%20there's%20some%20supported%20topologies%20that%20you%20can%20deploy%20using%20Azure%20AD%20Connect%20and%20that%20will%20enable%20your%20customer%20to%20have%20their%20credentials%20(and%20password)%20synchronized.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHave%20you%20read%20this%20doc%20already%3F%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fhybrid%2Fplan-connect-topologies%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fhybrid%2Fplan-connect-topologies%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESince%20your%20customer's%20clients%26nbsp%3B%3CSTRONG%3Emust%3C%2FSTRONG%3E%20connect%20using%20their%20own%20credentials%2C%20I%20think%20is%20worthy%20to%20take%20a%20look%20at%20that%20documentation.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAlso%2C%20creating%20a%20structure%20like%20*%40client1.clients.onmicrosoft.com%20is%20currently%20not%20supported%2C%20since%20you%20will%20only%20have%20access%20to%20clients.onmicrosoft.com%20domain.%20What%20you%20can%20do%20instead%20is%20using%20a%20custom%20domain%20like%26nbsp%3B%3CEM%3Eclient1.clients.com%3C%2FEM%3E%20and%20then%20assign%20the%20users%20this%20domain%20as%20their%20UPN%20like%20%3CEM%3Euser1%40client1.clients.com%3C%2FEM%3E.%20The%20problem%20with%20that%20is%20that%20you%26nbsp%3B%3CSTRONG%3Emust%3C%2FSTRONG%3E%20have%20a%20separate%20domain%20exclusively%20to%20do%20this%20and%20you%20must%20be%20sure%20that%20you%20won't%20have%20any%20conflicts%20with%20users%20credentials%20(this%20might%20be%20a%20real%20headache).%3CBR%20%2F%3E%3CBR%20%2F%3ELast%20thing%20is%3A%20is%20the%20application%20ready%20to%20be%20integrated%20with%20social%20accounts%3F%20would%20the%20application%20be%20compatible%20with%20Facebook%2C%20Google%2C%20etc%3F%20If%20so%2C%20you%20could%20try%20using%20Azure%20B2C%20for%20your%20customer%20to%20solve%20this.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHope%20you%20find%20this%20useful.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECheers!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1038881%22%20slang%3D%22en-US%22%3ERe%3A%20Theoretical%20question%20-%20AD%20%2F%20Azure%20deployment%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1038881%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F134246%22%20target%3D%22_blank%22%3E%40Carlos%20Oliveira%3C%2FA%3E%26nbsp%3BThank%20you%2C%20I%20have%20seen%20that%20article%20and%20the%20closest%20that%20can%20be%20done%20is%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fhybrid%2Fplan-connect-topologies%23each-object-only-once-in-an-azure-ad-tenant%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%22%3Ethis%3C%2FA%3E%20approach.%20(Each%20object%20only%20once%20in%20an%20Azure%20AD%20tenant)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Contributor

Let's say we have an organization on-prem with AD (company.com) and all the usual services.
This company has a lot of clients who need access to some applications such as SAAS that can be implemented in Azure. Let's say company's clients include several hundreds companies and its corresponding users. So each client, would have 5-10 users who need access to the applications provided by company.com.

Such external, outside users can and probably should, be maintained in a separate directory (clients.com). Let's say this is going to be an active directory which exists on-prem and maintains one-way trust with company.com AD environment. Or completely separated, not really that significantly important I think.

Company.com maintains their own Azure tenant. Also, for the clients, they can setup a separate tenant or create a separate directory in their own Azure tenant and sync users from clients.com. Each external company, would be represented by their own OU with users for such company synced from on-prem clients.com AD directory to the: either same tenant as comany.com under a different directory or synced from clients.com AD to the clients.onmicrosoft.com tenant. Multiple "sync profiles" can be created within the AADConnect tool to sync specific OU to the specific directory in the tenant, which basically would results to something like this - user1@client1.clients.onmicrosoft.com, user10@client2.clients.onmicrosoft.com, etc.
I hope this makes sense.

Is that something practical and realistic?
Are there any better or more functional approaches for such design?

Thank you for your time and feedback.

2 Replies

@VickVega, your ideia might work but not as you expect. Look, there's some supported topologies that you can deploy using Azure AD Connect and that will enable your customer to have their credentials (and password) synchronized. 

 

Have you read this doc already? https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies

 

Since your customer's clients must connect using their own credentials, I think is worthy to take a look at that documentation. 

 

Also, creating a structure like *@client1.clients.onmicrosoft.com is currently not supported, since you will only have access to clients.onmicrosoft.com domain. What you can do instead is using a custom domain like client1.clients.com and then assign the users this domain as their UPN like user1@client1.clients.com. The problem with that is that you must have a separate domain exclusively to do this and you must be sure that you won't have any conflicts with users credentials (this might be a real headache).

Last thing is: is the application ready to be integrated with social accounts? would the application be compatible with Facebook, Google, etc? If so, you could try using Azure B2C for your customer to solve this.

 

Hope you find this useful.

 

Cheers!

@Carlos Oliveira Thank you, I have seen that article and the closest that can be done is this approach. (Each object only once in an Azure AD tenant)