August 29, 2016 at 1:26 pm
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.
August 29, 2016 at 1:48 pm
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.
August 30, 2016 at 2:10 am
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.
August 31, 2016 at 4:39 am
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.
August 31, 2016 at 4:50 am
A fair point Marcus, duly edited. :blush:
August 31, 2016 at 10:47 am
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.
Viewing 6 posts - 46 through 50 (of 50 total)
You must be logged in to reply to this topic. Login to reply