In complex environments, that won't always work. There are many nuances to the attribute discussion, but generally we recommend using UPN where possible. If ADFS dies for some reason, run the PowerShell cmdlet to flip the domain from federated to managed, and people will be back up and working with, at work, a prompt to log in to O365. If not, you can federate AND do password sync. Though you should consider high availability/load balancing if possible. If you've never configured ADFS before, have no fear - AADC will point to an ADFS server and configure it for you. If they're external and not on VPN, they'll get a form logon. If the user is on-prem, they'll use Kerberos. When I go to Office 365 and sign in, the Microsoft login page says "oh, is at for auth" and redirects the browser there. With ADFS, you configure your domain as federated. And, as /u/reorx15 mentioned, they'll not have the SSO experience many people want. When you use AADConnect and enable password sync, users will authenticate against Azure AD, assuming you don't also configure federation. It isn't really involved in the auth process, only of syncing the user object to AAD as well as the hash of the password hash (that's an important difference for a lot of people since they think AAD has a reversible hash of a plaintext password - it's a non-reversible hash of a non-reversible hash of a plaintext password). AAD Connect is the identity synchronization engine. The general recommendation we received from an onsite consultation with Microsoft was to go with ADConnect unless you have a business requirement that necessitates AD FS. However, ADConnect is the faster growing usage scenario. The general trend reported by Microsoft is that most organizations (approx. We have spent quite a bit of time over here discussing exactly how that should work in our environment with three distinct account forests but only one resource forest with a primary email address. They recommend the UserPrincipalName attribute (and it is the default), but you choose what attribute is used during the setup process. ![]() With the UPN issues, ADConnect allows you to configure what attribute will be used to define how a user logs into O365. Because the authentication to O365 happens in the cloud, users can still access their email even if your AD servers are down. They can use the same user name and password in O365, but they have to log into it again after logging into the computer. This gives your users the ability to use the same sign-on, but not single sign-on. It doesn't synchronize the actual password, just a hash of the password. If AD FS goes down, you can't login to anything.ĪDConnect puts your authentication in the cloud by synchronizing your passwords with your O365 environment. AD FS has advantages like allowing for a true single sign-on experience with O365, but it requires much more infrastructure than ADConnect and has to be highly available. Your users will get a token from your AD FS server that is used to connect to the O365 environment. Let me see if I can clarify the AD FS vs ADConnect for you:ĪD FS keeps your authentication on-prem. With our setup, would it be best if I did one of the following:ġ) Went whole-hog and synced to Azure using ADConnect to get our security groups to be usable by Azure RMS, orĢ) Kept the two environments separate and mirrored the construction of our local security groups to Azure/Office 365 One thing that might be a holdup is our use of a different UPN for our on-prem AD ( ) versus what is used for our email addresses ( ). We don't have any on-prem fileservers, as our documents are hosted in 365 through SharePoint.Īdditionally, we've been interested in syncing our AD to Azure through ADConnect or ADFS (I'm still a bit confused on their relationship despite reading this a few times). Azure RMS was implemented to a test group (IT) before I showed up and hasn't been expanded in scope yet. ![]() We've got an on-prem AD that is running on two 2008r2 DCs, plus an already-active Office 365 subscription (E3) for all staff. We're looking to further implement rights management through Microsoft Azure RMS.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |