Skip to content

Access O365 on Demand, Part 2

November 16, 2013

This is the second installment on extending access to O365, read the first installment to get a better idea of what I’m discussing here. In the first part I shared what type of functionality this customer wanted and asked if there are any ways to do it.

So before we dig deep into any type of solution solving their needs we need to examine how O365 authenticates users and see if we can use it in our solution.

Probably the main thing to understand about authentication into O365 SharePoint is that it must start at O365 site: and you must have an account with O365. You can’t start authentication into it from other portals or identity providers (if you know how I’m all ears!).

So the most basic configuration to access the site is to have an account in it and authenticate with this account into the site. The O365 subscription administrator would create such account for the user and provide initial password. The account can be in two different formats:

  1. <yourname>@<tenantid>
  2. <yourname>@<customerdomainname>

Most customers would add their <customerdomainname> as the suffix in the account name. This is what my customer is doing with their O365 at this moment as well. They create accounts for external users and communicate account information to them. As I discussed in the first part, they would like to get out of manual account creation and account management.

The next possible authentication solution for O365 is the integration with customer on-premises AD DS via DirSync. The DirSync is installed on one of the on-premises servers and it is used to synchronize accounts from on-premises AD DS into the Azure Active Directory. The latest version of the DirSync even can synchronize passwords. User is still authenticating into O365 via O365 based accounts, by typing their user account and password. The good part here is that those users use the same user account (their UPN) and password as they would use on their internal network. With this option, account must be in the form of yourname>@<customerdomainname>, this is required for DirSync functionality.

As you can see, it does not provide any benefit to the problem that my customer is trying to solve. They would still have to create accounts manually and deal with password management.

The third possible authentication solution is to enable federation between O365 and the customer on-premises environment. This is probably most used option in enterprise environments. Federation is added to the configuration with DirSync already in place (in large environments FIM 2010 R2 is used often as well). After federation is added, when user types their user account at O365 logon page, they are redirected to the Identity Provider STS implemented at on-premises customer environment. If user is connected to the internal on-premises environment then they’ll more likely get single sign on (SSO) experience. If they are outside, then they will be prompted to authenticate to their company Identity STS and then they’ll get into O365. The most commonly used STS is AD FS 2.0, but other vendor products supported as well (like Shibboleth).

So we have three options to authenticate into O365. The first option is what my customer is using right now. The second option will not solve their problem. The third option might provide a foundation for what they are trying to do with their strategy to provide access to their O365 SharePoint environment.

The question is, can we do another hop in federation and extend the third option to external trusted Identity providers?

In the next installment I’ll share what I have learned so far in my trial and errors of extending federated O365 to second level Identity Providers.

  1. Hi Dimitri,

    I am dealing with the exact same shortcomings as you are with your client. Very interested to see what you come up with. I really think MSFT needs to figure out how to enable o365 clients to share with their adfs federated partners.


Trackbacks & Pingbacks

  1. Access O365 on Demand, Part 3 | Security and Identity in the Cloud

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: