Hi everyone,

We have a scenario where I'm having trouble nailing a high level design so wanted to post here, see if I can get some answers and also share.

Scenario:

- only working with identities from Microsoft AD and Azure AD

- Account self service features and other identity sources are of low importance 

- New'ish Resource Forest

- Several user forests from which users will most likely be migrated to the resource forest at some future date (typical merger scenario)

- Requirement for shadow accounts in resource domain for Lync and possibly Exchange at a later date

- 2 new Azure tenants (geographical/political reasons), probably two more at a later date

- User UPN's dont match email address and not viable at this time to change the UPN within AD

- Requirement to do Password hash to Azure

Originally we were envisaging FIM in the resource domain to bring the identities together and create the shadow accounts.

We would also use inbound rules to transform the email address to UPN.

Then use 2 x AADSync installs to sync users to the tenants (UPN eu.company.com to tenant 1 and UPN na.company.com to tenant 2). 

I have learnt that FIM doesn't do password hash to Azure, a must have for us, so initially I was thinking I'd have to wait for MIM but am now asking myself if I actually need MIM for this scenario.

Can AAD Connect do what I want ... transform email to UPN, password hash to Azure and create shadow accounts in the resource domain?

Thanks,

Aengus

• Edited by AengusM 4 hours 42 minutes ago

AAD Connect performs a similar role to AAD Sync. At this stage there is no setup to update on-premises identities other than the standard "attribute writeback" from Azure AD. If your primary issue is around password sync, you could deploy an AD FS farm as a solution. AAD Connect simplifies this and guides your through the process in the GUI. 

Your other option is to continue with the 2xAADSync/Connect installs to do the user and password synchronization into Azure AD. 

From my understanding, while the Azure AD connector is supported in FIM/MIM, Microsoft won't be putting in any further development on the connector. The recommended approach is to leverage their default tools. 

Thanks Cameron,

We have a solid AD FS implementation and utilised it for a small Azure/O365 pilot deployment but we like the password hash because it does remove the AD FS as a point of failure.

So it sounds like I am looking at AAD Connect to sync users and passwords to the tenants and FIM/MIM to look after managing account sync to the resource domain? 

That leads to the question, would AAD Connect sync from the user domains to Azure or from the resource domain using the identities created by FIM/MIM?

As I understand it FIM/MIM cant do a password hash for the shadow accounts (in the Resource domain), so AAD Connect would need to go from the user forests ... or do I have that wrong?

Thanks for help, ultimately we will pull in some Identity consultants to finalise design and assist with implementation but looking to square this in my head first.

• Edited by AengusM 1 hour 21 minutes ago

AAD Connect lets you choose whether the users are only represented once or multiple times across forests. Take a look here (this is AAD Sync but similar thing in AAD Connect): https://msdn.microsoft.com/en-us/library/azure/dn757602.aspx#BKMK_AccountJoin

AAD Connect would only need connectivity to the other forest, ports for LDAP and a service account in the target forest with the relevant permissions. 

Thats great, thanks again.

For others ... to note that the Azure Connector in FIM/MIM doesn't support any password management.

Also, I was thinking that maybe it would be better to have AADSync/Connect sync shadow user accounts in the resource domain rather than from the user domains but that then causes problems for password write back from Azure.
I think I have my design now, essentially AADSync and FIM/MIM in parallel rather than tiered.