Tag Archives: Delegation

What is required to delete Domain Admin accounts?

What is required to delete admin accounts that is member of a protected group like Domain Admins or Enterprise Admins?

The most common answer is whoever has the Delete Right on the user object. But when it comes to ACLs in Active Directory it’s not always that easy. ACLs is a powerful and complex thing in Active Directory.
If we read the Microsoft documentation on how the system evaluates if a Security Principal is allowed and denied access: Discretionary Access Control Lists (DACLs) and Access Control Entries (ACEs)

When access is requested to an Active Directory object, the Local Security Authority (LSA) compares the access token of the account that is requesting access to the object to the DACL. The security subsystem checks the object’s DACL, looking for ACEs that apply to the user and group SIDs referenced in the user’s access token. The security subsystem then steps through the DACL until it finds any ACEs that allow or deny access to the user or to one of the user’s groups. The subsystem does this by first examining ACEs that have been explicitly assigned to the object and then examining ones that have been inherited by the object. The following illustration shows the important parts of an access token and a DACL when a request is evaluated.

If an explicit deny is found, access is denied. Explicit deny ACEs are always applied, even if conflicting allow ACEs exist. Explicit allow ACEs are examined, as are inherited deny and allow ACEs. The ACEs that apply to the user are accumulated. Inherited deny ACEs overrule inherited allow ACEs but are overruled themselves by explicit allow permissions. If none of the user SIDs or group SIDs in the access token match the DACL, the user is denied access implicitly.

Now to the fun part, when talking about deletion you must consider a little more than just this logic to determine the effective permissions granting a user to delete a Domain Admin user.  Continue reading

Remote Credential Guard combined with LAPS and JiT

This is the third and last part about RDP, protecting credentials and delegation models.
This time it’s about Remote Credential Guard, pros and cons and how to model this with LAPS and Just in Time Admin Access.
I haven’t had much time to write this so I will keep it short and simple with a few examples.

Remote Credential Guard

Remote Credential Guard (RCG) was introduced in Windows Server 2016 and Windows 10 version 1607. It’s a new way to protect your RDP session from credential thefts like Pass the Hash, some Pass the Ticket and other LSASS dumps on the target computer. It provides SSO and your credentials is never exposed on the remote machine. This helps in a way that if a admin of any level connects to a compromised machine, his domain credentials won’t be exposed on the target machine preventing lateral movement in that way.
It relies on Kerberos and all service ticket requests in the RDP session on the server is routed to the client. Continue reading

Having fun with RDGW, SDI and MFA creating “where am I now admins”

This is part two of my RDP series on how to protect the communication, minimize the credentials exposure and how to use it in different delegation models.
This time we will have a look at an interesting delegation model using RDGW and RDP Restricted Admin mode.

I want to have a user dynamically/temporary member of an admin group. I don’t have JIT or JEA implemented so what can I do with built-in tools in the OS platform?
With RDPRA we have the possibilities to be a special admin depending on which server we jump to. It can look something like this:

In this example, we will grant a user Domain Admin rights temporarily, and in other cases he will just be a regular user.

In part one I wrote about RDPRA and how it flips the users identity to the servers identity he logon to. If a user RDP to a server with Restricted Admin mode, he will thru that machine connect to other resources in that context. If we make that server a member of Domain Admins the user will become a Domain Admin only by landing on that machine, and it happens automatically only thru RDP.

So, we start with stealing the setup from part one and add the server to Domain Admins group. Now when my user Tony connects to the server he is effectively a Domain Admin.
Sure, we need to step up our game on logging and correlations of event logs to get a clear picture of who did what. This isn’t about Auditing, so I will save that for some other time. Continue reading

Implementing LAPS – My way

Local Administrator Password Solution (LAPS) has been around for a while and last year it became an official supported tool by Microsoft (don’t know if my tweaks are though) and there is a lot of articles about implementing LAPS, which is a no brainer and it works great.

Since there are so many articles about it, I would like to share my tweaks. Consider this article more about having fun and exploring the possibilities.

If your new to it and want to read more about LAPS, you can go here: Microsoft Security Advisory 3062591 and here: Security Thoughts: Microsoft Local Administrator Password Solution (LAPS, KB3062591)

And a mini threat model by Jessica Payne: Local Administrator Password Solution (LAPS) Implementation Hints and Security Nerd Commentary (including mini threat model)

Here’s my view on it. Continue reading