Separate Accounts

Question

Separate Accounts

Viewing 6 posts - 46 through 50 (of 50 total)

You must be logged in to reply to this topic. Login to reply

RonKyle SSC-Dedicated Points: 31556 More actions · Answer 1

But, you say, I'd know which services were using that account, so it shouldn't matter, right?

Actually, I wouldn't have said that. I agree that is a downside to the Managed Service Accounts. But the folder to which the machine account has access doesn't contain particularly sensitive information. It will be interesting to see if MS takes the accounts a little further. Still, there is a huge upside to having accounts that are impossible to use as login account and don't require password maintenance.

jasona.work SSC Guru Points: 50117 More actions · Answer 2

RonKyle (8/29/2016)
But, you say, I'd know which services were using that account, so it shouldn't matter, right?
Actually, I wouldn't have said that. I agree that is a downside to the Managed Service Accounts. But the folder to which the machine account has access doesn't contain particularly sensitive information. It will be interesting to see if MS takes the accounts a little further. Still, there is a huge upside to having accounts that are impossible to use as login account and don't require password maintenance.

Sorry, I wasn't trying to imply that would be something you would or would not say, I tend to write sometimes as though I'm having a conversation (often with myself.)

And yes, I do agree that MSAs / gMSAs are a wonderful thing for managing service account passwords. But the paranoiac in me wants to prevent any possible foot in the door and would prefer not to use a machine account for accessing a share.

Alex Gay SSCrazy Points: 2217 More actions · Answer 3

Jason Markantes (8/29/2016)
My question is, what are people's naming conventions? Generally we prefix a service account with "svc_" and the rest depends on the application, service type, and if it's dev/test/prod. For example:
svc_dw_sql_prd

I always insist on separate accounts for each service of each instance, this can create a lot of accounts, but when I can see which server/service combination is causing problems it makes diagnosis Much faster.

When I was a novice DBA having 1 account for all servers seemed like a good idea. It isn't, you have no idea what is causing an error when the message just says that the user is [domain\SQLServer].

We have standardised name that identifies them as services, a service identifier and then the server name. This means that when looking for an account they are all grouped together, and I know at a glance where that account is used.

Summer90 SSC-Dedicated Points: 32891 More actions · Answer 4

As far as the naming of the accounts work with the team that creates these and come up with a simple, easy to remember template/method. One that you can look at it and say it is a service account for this server. However, I wouldn't specifically come on a forum and tell the world what your naming standard is either.

Alex Gay SSCrazy Points: 2217 More actions · Answer 5

Alex Gay

SSCrazy

Points: 2217

August 31, 2016 at 4:50 am

#1898491

A fair point Marcus, duly edited. :blush:

Jason Markantes SSC Rookie Points: 39 More actions · Answer 6

I pondered that for a moment before posting, but really not too worried if the world might know service account names. No different than actual user accounts (easily pulled from email), service accounts can't have interactive sessions, and it's a far cry from knowing a service account name to actually somehow getting on the one machine that can even connect to that particular server with that particular service account. I don't intend to sound over confident, just following best practices resulting in a lot of layers.