Active Directory Resource Account controls

Sent: Saturday, August 6, 2016 07:55
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Active Directory Resource Account controls But even once you know what processes are running under a service account, how do you work out what access those accounts have? Unless you audit exactly what the process has access to on the server, you have no idea what access it has to anything else. Worse, it could just host an application, which internally can connect to just about anything, which you can’t determine unless you look at the application’s configuration or source code (if custom developed). This is where I think identity-aware firewalls may help. For a given service account “srv-myApplication”, you can see that it only has permissions to connect from Server1 -> SQLServerAAG1:1444 and to NASServer1:445, which then tends to make it easier to audit access – it has access to some database in the SQL Server AAG running on 1444, and it some files on NASServer1. All the other FW rules extending outward from Server1 must be for other identities that can logon to that server. The tricky bit, still, is whether srv-myApplication should have that access or not. It’s one thing to audit the “as-is” state, it’s another to determine whether that should be the state or not. From: ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx] On Behalf Of sl@xxxxxxxxxxxxxxxx
Sent: Saturday, 6 August 2016 10:41 AM
To: activedir@xxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Active Directory Resource Account controls About identity-aware firewalls, colour me sceptical. Don’t think a robust technology exist, nor I think it’s really needed. I think group-managed service accounts in Windows Server 2012 AD is a fine attempt at solving this. One problem with that is lack of support from non-MS systems, which calls for traditional service accounts. And then we have issues with lastLogonTimestamp not always updates (case in point: Vintela/QAS on UNIX)…. The problem with service accounts boils down to knowing what processes are running under the service account, and where. Determining that used to be quite laborious, still is, but these days tools for collectong operational data and operational analytics at significant scale are quite common. Better view at accounts’ use is but one benefit. Regards Slav MCM-DS     From: Ken Schaefer
Sent: ‎Friday‎, ‎5‎ ‎August‎ ‎2016 ‎10‎:‎38‎ ‎PM
To: activedir@xxxxxxxxxxxxxxxx The difficulty of implementing anything seems to grow with the scale of the organisation – many things seem to rely on manual documentation, and auditability of actual permissions across every system and application (especially when the app doesn’t use Windows authentication libraries) is lacking. Maybe this is an opportunity for NextGen firewalls and micro-segmentation. User/identity access between systems is documented in the FW rules. Whether that access should be allowed, however, is the problem we always seem to be grappling with. From: ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Brian Arkills
Sent: Friday, 5 August 2016 8:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Active Directory Resource Account controls  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@xxxxxxxxxxxxxxxx
Subject: [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