Active Directory Resource Account controls

  • 988 Views
  • Last Post 10 August 2016
BrianB posted this 28 July 2016

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      

Order By: Standard | Newest | Votes
bdesmond posted this 28 July 2016

It sounds like you’re describing Authentication Siloes in AD if I follow the question correctly. This was added in WS2012R2.

 



Thanks,

Brian Desmond

 

(w) 312.625.1438 | (c) 312.731.3132



 

show

SmitaCarneiro posted this 28 July 2016

If you can use group Managed Service accounts, you can limit them to certain computers too.

 

Smita

 

show

BrianB posted this 28 July 2016

Thanks Brian.

 

Looks like Authentication Silo’s work for Windows 8 and above. We still have 2008 R2 servers on the network. It also appears that I will need to make possibly hundreds of different silos for different service

accounts and the servers they are allowed to log on to. This looks like a good solution but does not appear to be very scalable.



 

I was hoping there might be a third party applications that could make this happen and that could be delegated to a lower tier like help desk to use when creating the resource/service accounts. Some tools that

have been pitched are overkill for what we want to control, i.e. Dell/Quest Change Auditor and Active Roles to name a few.



 

Brian B.

 

show

bdesmond posted this 28 July 2016

The Protected Users group functionality does require uplevel clients, but, the siloes themselves are implemented on the domain controller. I don’t believe there’s a client dependency

there.


 



Thanks,

Brian Desmond

 

(w) 312.625.1438 | (c) 312.731.3132



 

show

BrianB posted this 29 July 2016

I guess I misunderstood this article then.



http://social.technet.microsoft.com/wiki/contents/articles/26945.authentication-policies-and-authentication-silos-restricting-domain-controller-access.aspx

 

I assumed, based on what I read, that I needed to also configure the clients in the domain as well.



 

Brian B.

 

show

BrianB posted this 29 July 2016

Are the silos separate from membership in the protected users group? I want to effectively limit the ability of a resource account that is not granted any special privileges to AD but rather is a normal account

used to run a service or perform some sort of bind operation for an application to a specific list of servers until such time it is requested to add another server to be added that resource account’s access.



 

I just read about the protected users security group on the Scripting Guy blog located here:



https://blogs.technet.microsoft.com/heyscriptingguy/2014/07/26/weekend-scripter-authentication-silos-part-1/:

 

Members of the protected users group cannot be delegated with constrained or unconstrained delegation. That could present a problem for resource accounts used for SharePoint. Am I missing the point? It’s been

a long week.

 

“It’s also recommended that high-privileged accounts be members of the Protected Users security group. This group has proactive security enhancements designed to prevent credential theft. Members of this group

will not be able to:

•Authenticate with NTLM.

•Use DES or RC4 encryption types in Kerberos preauthentication.

•Be delegated with unconstrained or constrained delegation.

•Renew the Kerberos ticket-granting-tickets (TGTs) beyond the initial four hour lifetime.”

 

              

 

show

barkills posted this 04 August 2016

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

 

show

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



 

show

ken posted this 05 August 2016

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.

 

show

BrianB posted this 05 August 2016

I don’t think that is scalable in our environment and it is very hands on approach. I don’t think this is an option that I would like to take on for our enterprise.



 

Brian B.

 

show

slavickp posted this 06 August 2016

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

show

ken posted this 06 August 2016

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.

 

show

kurtbuff posted this 07 August 2016

We use Thycotic Secret Server, and are very happy with it - it keeps many things for us, beyond just service accounts.
It scales much better than Keepass or PasswordSafe.
Kurt


show

a-ko posted this 08 August 2016

That’s assuming the service account is being used to access network resources. Certainly if you start seeing service accounts attempt to access network resources it’s a problem, but you can usually get this from logs of servers anyway. For the most part, as long as the account doesn’t have Administrator privileges nor is the application running under SYSTEM you’re probably pretty good. As others stated, gMSAs are nice—but very limited in use (for example, if you have an application that has internal LDAP processes/queries/etc) 

show

slavickp posted this 10 August 2016

How do I work out what access account have? I prefer to use data-based aproach too.
If I need to find out who has access to a resource, I inspect the resource ACL. Have a database of all resources and their ACLs, and database of all security rincials, and youre winning.
I have yet to see a firewall that allows me to specify rules such as “User group G has access to alications {A1..An}, files {F1..Fm}, DS containers {OU1..OUo} RW, and databases {DB1..DBp}”. If there is one and we are already in dream land) then we’ll have to a) make users always traverse the firewall; b) manage all the rules, which will require equivalent of the above database available; and c) have enough performance in the firewall to evaluate every acces against such database.
Highly distributed disjoint model is the only one that is practical and scalable These days, we can collect security information and analyse in some sort of big data/big query fashion, but that is useful for oraional analytics and less so for ongoing real time management.
Regards
Slav
MSM-DS

show

ken posted this 10 August 2016

 

show

Close