Best Practices O365 Admin Roles

Steel Contributor

For large Enterprises, what's the recommendation for assigning Admin Roles within O365 (Global Admin, Billing Administrator, SharePoint Administrator, etc) -- do you assign individual names as Administrators or use more of a RBAC and assign say the SharePoint Admin role to a shared AppID instead of individuals?

19 Replies

Principle of least privileges always applies. You probably wont be able to get away with just 2 or 3 global admins, but you should keep the number at minimum. Give individual roles, use scoped RBAC roles where needed, etc. Dont forget to also enable MFA for each admin account.

 

I would avoid using shared accounts where possible, auditing their usage quickly becomes a nightmare (and you dont want to be investigating which of the 10 users behind adminXXX@domain.com removed that license from the C*O :)). They're best used for automating scripts, so you dont end up with dozen different admins each used to run a single script. Oh, and please dont hardcode passwords into script files, every time I see something like this I switch to uncensored mode :)

Re. PowerShell.. Remember that MFA doesn't work for some modules (like Exchange Online) so you'll need an account that is not MFA-enabled for that work. And follow Vasil's advice and avoid passwords in scripts. That's more than the mind can cope with...

For large enterprises you should use personalized accounts instead of serviceaccount names too. If you want to differ admin permissions in services like SharePoint online you can create Groups or use Office Groups in the future. And please avoid Passwords in PS Scripts.

Quick tip: Dont use MFA for Office 365 Admins because you have a lot of trouble with it in PowerShell. Use strong and generated passwords!!!

I have a tenancy where there are two domains. Is it possible to have a password administrator that is restricted to just one domain?

I have 5 clients that are Fortune 500 companies, all of them assign individual users names to the Admin roles. Only one of them had separate "admin" account for their staff to login with when the were performing Admin functions, While this is a pain in the neck, it a good idea that should be used more often.

 

Accounts should never be shared because this does not provide a good audit trail.

 

 

You may also be interested in the Advanced Security Management features  https://support.office.com/en-us/article/Get-started-with-Advanced-Security-Management-d9ee4d67-f2b3... and

this poster does a very nice job of presenting the numerous information protection options https://docs.com/officeitpro/3899/information-protection-for-office-365

Here's a support.office.com article about the different roles and how to assign them that may be useful for reference:

 

https://support.office.com/en-us/article/About-Office-365-admin-roles-da585eea-f576-4f55-a1e0-87090b...

We are a tenant of around 100 users. Three of us are Global Admins and we each use separate admin accounts from our normal user accounts. We also do this for on-prem.

I would also recommend to keep use of Global Admin and other Admin roles at a minimum and always assign separate accounts for Admin rolls. I the admin panel under users it is also good to make a report that fast can give you an overview of who has the different rolls assigned.

If you not already have a good tool for reporting I could recommend https://www.cogmotive.com/ that have saved us both hours of work but also a lot of money. On a monthly basis I have sat up different reports that goes automatically both to us at IT but also to our different managers at our locations spread all around the country. They can then easely see who are assigned licenses and if they still have assigned users that should have been removed.

 

2016-08-26_07-41-30.png

 

I don´t work for Cogmotive, just love their tools :)

 

BR Marius

I respectfully disagree with Steven's tip. I belive O365 Admin accounts should use MFA.  For interactive admin scripting I created a separate admin account that has a strong password, and I disable it when not in use.  If you need a service account that runs PowerShell scripts, that's a different need for which I would agree that you don't want MFA.  However, when feasible, change the password periodically and if you can audit the use of the account, all the better. 

So, there use to be this mentality, or framework, for Office services on-premises, of pursuing least-privileged access design in your administration and services. And, with the the changes in O365, and the symbiotic integration with Azure AD, there is some much lacking community content on that. So, I started writing about this, especially as all Office 365 services are essentially going to be controlled by Office 365 groups as the focal identity. That will change the stack of who needs what role and permission in Office 365 Administration. Anyways, I'll be adding content to it as I can, Office 365 Lessons in Least Privileged Security

I think it is an overstatement to say that "all Office 365 services are essentially going to be controlled by Office 365 Groups". That smacks of drinking too much Kool-Aid.

 

Office 365 Groups are an important infliuence on the service right now and have provided an excellent way for new applications to establish a common identity and access model for members, but extending that to essential control is a stretch that I cannot see for now.

Hi,

very intersting topic and replies.

WE are a tenant of 100 users and we have 3 global admins, with separate admin accounts.

 

Things work pretty much fine (including MFA), we have an issue though with 2 things:

 

1) Granularity of admin roles managed in Office 365 vs managed in Azure AD, there seem to be some little tiny differences that can prevent admin to their job.

2) Licenses: in principle an Admin needs no license, but ther are some actions that you can't perform with an adequate license (in Exchange Online or Intune).

 

We can sort point 1, but I am quite upset with point 2.

 

I recently attended an Ask The Expert session, during which the the MSFT guru suggested the elevation of "normal users" to "admin role" based on specifc time frame or on demand, but i could not find any hint in this sense.

 

If you have any, and want to share, feel free!

Nicola

 

 

 


 

I recently attended an Ask The Expert session, during which the the MSFT guru suggested the elevation of "normal users" to "admin role" based on specifc time frame or on demand, but i could not find any hint in this sense.

 

 

This means that you assign administrative permission to users for the duration of time needed for them to perform administrative work and remove the permission once the time elapses. It is the way that many large enterprises operate. However, given your size, I think it would probably generate too much overhead to do this. Instead, good auditing practice to make sure that any inappropriate actions by administrators are detected and questioned is probably a better path for you to take. A tool like Cogmotive's DIscover and Audit https://www.cogmotive.com/discoverandaudit/ would help (it's cheaper than paying for Microsoft's Advanced Security Management).


@Guarino Nicola wrote:

 

 

I recently attended an Ask The Expert session, during which the the MSFT guru suggested the elevation of "normal users" to "admin role" based on specifc time frame or on demand, but i could not find any hint in this sense. 

 


Sounds like they were referring to the feature called Privileged Identity Management, which can temporarily elevant permissions based on specific conditions and approvals.

Is this what you are referring to?

What is Azure AD Privileged Identity Management?

 

That's the one, and is even better now compared to 3 months ago :)

Utilize a two-factor password vault on their primary account to access the administrative account for elevated access, and be sure the administrative account has a 24 hour reset. This ensures that when the primary account is disabled, they no longer have access to the administrative account and it's password has been automatically changed. It's additional overhead but highly secure.