Cynthia
posted this
05 August 2016
We use keepass to keep track of our service accounts and their pw’s as well as include full descriptions of why they were created.
We also note the group\individual that needed it created.
Maybe that would help you in your situation?
Cynthia Erno

From: ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]
On Behalf Of Brian Arkills
Sent: Thursday, August 04, 2016 6:22 PM
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Active Directory Resource Account controls
ATTENTION: This email came from an external source. Do not open attachments or click on links from
unknown senders or unexpected emails.
|
We’ve been talking about doing something similar for over a year, partly in the context of pass the hash but also because we’ve never been happy with the lack of a cohesive solution to control service accounts.
For example, when someone in IT leaves, you often lose all knowledge about service account X (or maybe dozen to hundreds of service accounts).
We’ve talked about all of the suggested technologies you’ve heard, but we also included per system permissions like user rights (logon locally, etc) and local admin in the scope of our imagined solution. We have
an imagined scheme for systematically creating groups to represent all of the controls we’d want and leveraging group policy to enforce them (although maybe we’ll move to DSC where possible). The groups provide a dual purpose—they are access controls but also
documentation of what permissions a given service account should have.
But we haven’t yet had time to put it all together into a process and implement--but that’ll come. If and when we have something more to show from our efforts, I can report back.
J
Brian
From:
ActiveDir-owner@xxxxxxxxxxxxxxxx [
mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]
On Behalf Of Britt, Brian
Sent: Thursday, July 28, 2016 10:28 AM
To:
ActiveDir@xxxxxxxxxxxxxxxxSubject: [ActiveDir] Active Directory Resource Account controls
All:
To piggyback off of my last question, we are now looking at a way to manage more granularly the resource/service accounts in our AD. What I mean by that is that we want to be able to:
1.
Limit the systems that a resource account can log in to.
2.
Keep resource / service accounts from sprawling to other applications that we are unaware of.
We have lifetimes assigned by our Identity Management system for resource accounts so that we don’t have these abandoned accounts existing forever. There are times when a resource account has exceeded its lifetime and has not been renewed
in time before being disabled. When the account is disabled, obviously the services that were using this resource account fail. If a resource account is used and re-used for many, many applications then the effect can be pretty bad.
As well, we are unable to know all of the applications that are implemented on our network if resource accounts can be used for multiple applications.
Is there a tool that can help us limit the ability for resource accounts to authenticate to anything that is not authorized or approved? I do realize there is an ability to set the “Log Into” setting on the account itself but it would be
helpful to have the ability for a self-service registration such that the application owners can authorize the account on more IP/Machines and provide us with visibility of what a resource account is used for.
Brian Britt