2

The official Microsoft docs strongly discourage the practice of user accounts employed as service accounts. Instead, they recommend using service principals or managed identities.

Leaving aside MI's for the time being, I just had a question about this. Why is there such a strong recommendation against user accounts as service accounts in AAD? Consider the alternative of a service principal:

  • Both require some kind of secret to authenticate, whether a user password or client secret. Since this is a service account that won't see interactive use, presumably we can generate a strong random password for it, so the level of security should be the same.

  • A service principal requires application permissions in AAD, which are very strong due to not being linked to a specific identity. Eg if I give my app the Files.ReadWrite permission, I can mess with the OneDrives of ALL users in my org. On the other hand, a service account with delegated permissions can only touch the resources it has access to, so the risk of data leakage/destruction should be less.

  • The service account uses the resource owner password flow to authenticate, which isn't supported by all auth providers. Still, if I'm only using pure AAD this won't be a problem.

Why are service accounts considered harmful?

Improve this question

1 Answer 1

Reset to default
1

I am with you on this one. I did this kind of research myself and came to the same conclusion: currently service accounts are much secure option than service principals.

Major issues with service principals are:

  • lack of permissions granularity
  • lack of Azure AD Conditional Access rules support
  • weak actions logging

The only real benefit I found for using service principal, is that you don't need a license to access Office 365 data, like files or emails. This has nothing to do with security though.

To be fair, I guess certificate authentication scenario is a valid case of distinct security feature which is not available for AAD service accounts. But again, there are no means to secure service principals any further

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .