Hello Frank89789797,
Thanks for posting your query here!
1) This
blog talks about "sync & federate". What is there to federate here when sync itself is brining the user and password information to Azure AD.
A: There are still some reasons why some customers will still prefer sync and federate. These include:
- ADFS can be configured such that users who are already logged on to a domain joined and connected machine do not require any password re-entry to sign in at Office 365. This gives you true single sign-on since re-entry of the password is not required. With
DirSync and password hash synchronization a user must still re-enter their password, although it will be the same password as they use on-premises.
- ADFS allows for client access filtering, which restricts access to Exchange Online to users based on their IP address.
- ADFS will honor Active Directory configured login time restrictions for users.
- ADFS can include web pages for users to change their passwords while they are outside the corporate network.
- With ADFS the authentication decision is always made on-premises and no password hashes are synchronized to the cloud. This may be obvious but can be sometimes a security policy requirement.
- With ADFS an administrator can immediate block a user to remove access where-as DirSync synchronizes these changes every three hours. Only password changes are synchronized by DirSync every two minutes.
- ADFS permits use of on-premises deployed multi-factor authentication products. Note that Azure AD supports multi-factor authentication but many third party multi-factor authentication products require on-premises integration.
- Where Microsoft Forefront Identity Manger (FIM) is required for some other FIM capability. FIM directory synchronization does not include password hash synchronization so ADFS will still be required for SSO login.
- Some on-premises to cloud hybrid scenarios require ADFS such as hybrid search.
If you need any of these then Active Directory Federation Services is still the best option.
2) To keep the same user login for both Azure AD and on-premise, do I need to add a custom domain which is my on-premise domain and verify it ? Otherwise users are getting mapped with the .onmicrosoft.com suffix
A: I don't think it is required. Please follow the tutorial which guides on Syncing An On Premise AD with Azure Active Directory.
http://blogs.technet.com/b/canitpro/archive/2014/05/14/step-by-step-syncing-on-premise-ad-with-azure-active-directory.aspx
3) How does Azure AD support authentication from multiple companies ?
A: To help you understand this little better let me share an example, ADFS can be used in an infra when say a company contoso.com utilizes just an application developed by fabrikam.com. We cannot setup trusts between both tenants but contoso.com needs
access to that application. IdP (Claims Provider) (the owner of the identity repository - in this case AD) and the RP (Relying Party) which is the application that wishes to utilize AD of contoso.com as IdP.
AAD is an identity provider on cloud (Azure).
Take a look at the references below:
http://cloudidentityblog.com/2013/06/16/azure-ad-as-idp-with-ad-fs-as-rp/
http://stackoverflow.com/questions/30495565/connecting-adfs-to-windows-azure-active-directory
Hope this clarifies your questions!
Best Regards
Sadiqh Ahmed
________________________________________________________________________________________________________________
If a post answers your question, please click Mark As Answer on that post and Vote as Helpful.
