0

We have a customer who wants their users to use different user accounts for SharePoint Online and Exchange/Office 365 mail (as weird as it sounds there is a legitimate reason for this). All the accounts are in the same domain and the customer has configured ADFS with their tenant. All the articles and posts I can find online deal with the exact opposite of this scenario (either SSO or multi-domain with one tenant).

What I am wondering is if we can configure SharePoint Online and Exchange with different realm ID's (or something similar) so that ADFS can be triggered to use a different authentication mechanism for one realm vs. the other.

****Edit****

Per comments below here is a little more color to the reason for needing two realm ID's (or any other mechanism to solve the issue). The customer has essentially two kinds of user accounts in their organization. Most are standard run-of-the-mill user accounts who access O365 via SSO provided by ADFS.

The other types of users do not normally log into workstations and do not have assigned desks of their own. These users use shared workstations that are constantly logged in under generic, communal accounts. When these users access the shared workstations (I referred to them as kiosks in the comments below but that is a slight misrepresentation) and then try to access O365, ADFS is logging the users in as the generic account. This is fine when the users go to SharePoint Online for the main portal page (when going to secured sub sites the users get a access denied page but there is an option to log in as another user) but not for when they try to access email (they get a error page because the generic account does not have a inbox and there is no means to re-authenticate).

My initial thinking was if we could use two IdP's (or one ADFS server with two RP's) then we could use SSO/WIA for the SharePoint realm, and then use forms auth for the Exchange realm. Another thought I had was using a claim rule in ADFS (they are on ADFS 3/2012R2) to force forms auth if the user's UPN matched a pattern. A final punt solution I had was to use GPO to disable SSO in IE for the communal accounts.

  • You could create two different accounts in AD for each user, one meant for SPO and the other for Exchange Online, then assign both accounts licenses, use separate UPN suffixes, and maybe disable access to Exchange for the SPO account and vice-versa. Seems like a waste of licenses and lots of hard work. The reason to do this might be legitimate, but that's not the same as compelling when compared to the cost and administrative burden of trying to make Office 365 do something it wasn't meant to do. – Todd Wilcox Jul 7 '15 at 14:47
  • Its actually more of a generic communal account that is logged into Windows (sort of like a kiosk) and each user has an 'real' account used for mail and whatnot. The kiosk account will be used to access the portal page on SPO and that is about it. – Lane Goolsby Jul 7 '15 at 14:54
  • Ok now I don't understand the question. Just make the kiosk account and configure the kiosk to log it on and keep it logged on. It will only need an E1 license. – Todd Wilcox Jul 7 '15 at 15:54
  • They have setup on-prem ADFS for integrated auth for authenticating the non-kiosk users via SSO. This is what's causing the issue. ADFS is authenticating the users that use the kiosks as the kiosk user, which is fine for SPO, but the session needs to be killed when going to OWA since the kiosk users do not have inboxes. – Lane Goolsby Jul 7 '15 at 18:21
  • Have you tried unchecking the Exchange license from the kiosk user account? I'm not sure what happens if someone clicks on "Mail" if they have no license for Exchange Online. – Todd Wilcox Jul 7 '15 at 18:51
1

Answer is courtesy of Jesper Stahle.

You will need to play with IE zones to break the authentication token on the kiosk machines, you can easily achieve this using Group Policy.

Explanation: your users will try to access Office 365, they will be redirected to ADFS for authentication, ADFS will read their Kerberos TGT-ticket, create a token and forward it to Office 365 for further processing.

  • For users in on their dedicated machines: this process will follow through smoothly, the token sent to Office 365 from ADFS will authentication them and they're allowed access to their mailboxes based on the account logged into the machine.
  • For the kiosk machines: the problem here is that ADFS will always send the token of the logged in account to Office 365 for further processing, regardless of who is the actual user sitting on front of the machine, which will always cause the logged in mailbox to open.

Solution: To avoid sending the token of the logged in user on the kiosk machines from ADFS to Office 365, you will need to tell IE NOT to send the logged in username/password to ADFS, but instead to open a login box for the user sitting on front of the machine to use their own specific username/password, this can be achieved by:

  • For users on their dedicated machines: place the ADFS links in the "Local Intranet Zone", SSO will be enabled if you do this.

  • For the kiosk machines: place the ADFS links in the "Trusted Sites" zone, this will break SSO and users will be asked to provide a username/password whenever they visit Office 365.

For the matter of using Group Policy to place sites into zones, I would recommend to use "Registry" enteries using the following:

Key Location: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\YOURADFSLINK

Value Name: http

Value Type: REG_DWORD

Value Data: 1 or 2

The "Value Data" 1 means "Local Intranet Zone, 2 means "Trusted sites Zone"

  • This is pretty much the same end solution I came up with. Thanks for the feedback and detailed answer. – Lane Goolsby Jul 30 '15 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.