What if...the UPN suffix in your AD does not match with the registered domain in Office 365? E.g. ad.local does not match to crypto-live.org.
Might you want start with a small group of users, might a trial. And you do not want change the UPNs for your 1000, 25.000 or 300.000 users? Why would I care about the number of users if it is just a pilot for now?
In this post I am speaking about federated identities in Office 365. Technically means that, that you have a directory synchronisation (dirsync) and a federation server (ADFS) for authentication services.
Federated identities do not have passwords on Office 365 system itself, all authentication is provided by the companies Active Directory credentials via ADFS, also for IMAP etc. see my other post.
It is important to know that the actual dirsync setup will sync all objects with e-mail address and all security groups to Office 365. The sync has only a basic filter. Changing the dirsync configuration is not support from MS Online. At least not for now.
So what to do? Changing the UPN is risky in larger organizations. Might you can live with unsupported dirsync and wait till the Online team is providing documentation how to deal with UPN changes.
Dirsync is based on ILM 2007 and the dirsync install includes also the management console to modify the management agents. You need only to modify the attribut flow for UPN on the Source AD MA. You can change it to read from mail and write to UPN in the ILM metaspace. Virtually you can use any attribut in AD as long as it is a valid logon name in Office 365.
So dirsync syncs per default a UPN with lutz@AZ to Office 365. And Office 365 says: ooops, I do not know that identity and creates a online id lutz@cryptolive.onmicrosoft.com. Besides that is a really ugly id (and way to long for users) ADFS does not know how to find the corrosponding user account in AD. Okay claim rules are your friend, but wait...
E-mail addresses became an identity factor in the last years. Before e-mail address where changed like other people changing clothes (metaphor alarm!). Seriously if you exchange data today with Dropbox or on GoogleApps the identity key is the e-mail address (a have a post about this as well). That is also true for MS Rights Management Services. So e-mail is a good attribut to use for the identity, just make sure that all your e-mail addresses (mail attribute) are unique. AD does not enforce that and it is not to complicated to change the e-mail address.
Dirsync is changed but the user can still not logon to Office 365. Not yet. We need first to modify the claim rule from UPN to email via ADFS 2.0 MMC.
We can logon now! With any browser or Outlook. Not rocket design but close :-)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment