Office 365 User Permissions Gotcha!

Congratulations! You convinced your client to sign up for Office 365. They subscribed to licenses for various apps like SharePoint Online and SQL Azure. The wireframes look good. You've created the SharePoint site structure. Wonderful! You're off to a great start. But… get ready for a big "gotcha!"

You decide to make use of the Content Type Syndication Hub. Wise move. You go into the SharePoint online site, activate the Hub and click on the link to the Hub… bzzzzzzzzzzzz! Access Denied.

Uh oh.

You've run into a little known gotcha in Microsoft Office 365.

According to the small-print regarding Permissions in Office 365, "The person who signs up for Office 365 for his or her organization automatically becomes the 'top-level administrator.'" Notice, though, this says nothing about the fact that it's also the only person/account who can access certain features of the Office 365 products.

At the time of this writing, the Content Type Hub and the Search Center are the only two features known to be provisioned with a default administrator (I've only encountered this in SharePoint Online so far). The Search Center is provisioned automatically when the root site collection is set up (the first time Office 365 is logged into by the person who created the account). The Content Type Hub is provisioned when the feature is activated in the Site Collection Features.

Microsoft's logic is that, like an on-premises server hosted at your facility, roles need to be delegated such that no single person (except the domain admin) has access to every role and resource. This is essential for many reasons, security being the biggest.

But unfortunately, this becomes illogical when you move to the cloud. Now, instead of increasing security, you're actually committing an IT sin by creating a single point of failure. When you're hosting your own server, you probably have access to the domain admin account (or at least to someone who does). But if you're in the cloud, you probably don't. And even if you do, you don't have access to the administrative console on Office 365.

Needless to say, as a SharePoint consultant, having to ask your client for permission to do things on the "very-first-ever" account is less than ideal. What if you lose access to that person at a critical juncture? (In my case, they went to the Carribean for two weeks, yay!)

When we discovered this problem, the client was small and the need for the Content Type Hub was not particularly urgent. No harm, no foul. If your client's business depends on a web site that hosts thousands of transactions per day, you can see where that could make for some trouble all the way around.

Microsoft, unfortunately, says they will not reassign this account under any circumstances without explicit orders from the portal creator. But what if the Portal account is deleted by mistake? What if the account creator quits the business, leaves the country, or gets hit by a bus?

Just ask this guy what happens. Not pretty.

According to Microsoft, best practice is to delegate this control to other admins. Agreed!

But, your client may not be that savvy - or that motivated. Or your client may be a control freak. Maybe, like many of our clients, they only became your client *after* they created their O365 free trial account and got in over their head. I can list a million reasons this creates risk, but mostly, it's the reasons I can't think of that usually kill me.

So how to handle this issue? The best way would be to change this policy system-wide.

It's Microsoft, so don't hold your breath.

Another way is to ask the client to share their credentials with you after they've created the portal. This is also risky, and, like I said, some clients are reluctant to give up so much control.

A third way is to ask your client to let you create the portal for them. This is fairly low-risk and should work in many cases, but there's always those situations where you got involved at a point where it's too late - or control issues, yet again.

The last reasonable solution is to ask the client to create a dummy Windows Live account (such as 365Admin), which they can use to create the portal and which they'll be comfortable sharing with you or any other vendor. We recommend doing this from the beginning; it is slightly more painful, but possible, to rename the "primary" account after the fact (and create a new account for the CEO).

Got any more ideas to improve these best practices or know of any other features in SharePoint Online or other Office 365 components that would have this issue? Post them in the comments and I'll stick them into a follow-up post. Hope this helps some of you avoid this weird gotcha. Getcha next time!