Category Archives: Uncategorized

Remote Credential Guard combined with LAPS and JiT

Leave a reply

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”

2 Replies

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 →

NLA + RDP SSO + RDGW + Restricted Admin Mode + Protected Users group = True

2 Replies

RDP is one of the most used protocols for managing servers and jumping around in the IT infrastructure environment. This is a 3-part series about how to protect it and use it with different delegation models.
This is part one where we look at how to configure SSO and use Restricted Admin mode and other technologies minimizing our credential exposure.

Network Level Authentication
Lets start with Network Level Authentication (NLA) which should be enabled on all servers.

As per MS documentation: Configure Network Level Authentication for Remote Desktop Services Connections

Network Level Authentication completes user authentication before you establish a remote desktop connection and the logon screen appears. This is a more secure authentication method that can help protect the remote computer from malicious users and malicious software. The advantages of Network Level Authentication are:

  • It requires fewer remote computer resources initially. The remote computer uses a limited number of resources before authenticating the user, rather than starting a full remote desktop connection as in previous versions.
  • It can help provide better security by reducing the risk of denial-of-service attacks.

Another thing that should be mentioned is that it also provides protection against Man In The Middle (MITM) attacks. With Kerberos or TLS it can perform a mutual authentication verifying the servers identity as well. Continue reading →

Time-based groups

Leave a reply

This is a follow up on earlier post about JIT and will cover the Time-based groups part.

Expiring links is a new feature in Windows Server 2016 and makes it possible to set Time-To-Live (TTL) values on all linked attributes. In the case of Time-based groups it’s possible to set a TTL value on the member forward link.

It’s up to the domain controller to manage this links and remove them when the TTL limit is reached. This also works well with replication because the TTL value end time is replicated and the link will be deleted locally on all domain controllers.

In conjunction to this there has also been some Kerberos enhancements to really be able to take advantage of Time-based groups.
When the KDC creates tickets it restrict Kerberos ticket lifetime to the lowest possible time-to-live (TTL) value. If a user has 15 minutes left until the TTL on a group membership expires, the KDC will only create TGT/TGSTs that is good for another 15 minutes. When the tickets has expired and new ones is requested, the SID of the expired group memberships will not be in the PAC anymore.

Continue reading →

DC userAccountControl 0x81000

2 Replies

Got a question from a friend about a weird problem when trying to promote a 2012R2 Domain Controller.

The error is in the prereq test before promoting:

Verification of outbound replicaton failed. Error reading the NTDS settings on replication source domain controller 2k3dc.secid.local. Domain Controller data not found for the specified Active Directory domain controller. Continue reading →

Alternate Login ID for ADFS

Leave a reply

This is a most welcome update to ADFS that comes packaged with the Update for Windows 2012R2 servers: KB 2927690 – Update enables an alternative logon ID in AD FS in Windows Server 2012 R2.

A big challenge for many companies in their on-prem AD is that the UPN suffix doesn’t have a publicly routable domain name which is a requirement for e.g. O365, AAD and is preferred/recommended when using any cloud services. Continue reading →

Mixed DC 2003 2012R2 Domain logon problems.

Leave a reply

A good post about Kerberos Authentication problems with mixed 2003 and 2012R2 Domain Controllers – Ask DS Team

The Kerberos client depends on a “salt” from the KDC in order to create the AES keys on the client side. These AES keys are used to hash the password that the user enters on the client, and protect it in transit over the wire so that it can’t be intercepted and decrypted. The “salt” refers to information that is fed into the algorithm used to generate the keys, so that the KDC is able to verify the password hash and issue tickets to the user.

When a Windows 2012 R2 DC is promoted in an environment where Windows 2003 DCs are present, there is a mismatch in the encryption types that are supported on the KDCs and used for salting. Windows Server 2003 DCs do not support AES and Windows Server 2012 R2 DCs don’t support DES for salting.

 

repadmin trace user changes

Leave a reply

Have you ever had problems with account lockouts, changes occur on objects but you don’t know where it came from? There are good tools you could download and use for this kind of things but there is a built in tool that can help us immediately.

Repadmin is a tool for managing and troubleshooting replication between DC/DSAs. It’s built in in Windows server 2008 and later, it comes with 2003 Server if you promote it to a DC. You could also add it through RSAT.

If you open a command prompt and run repadmin /? It will present us a lot of options. In this case we are interested in the /showobjmeta option.

Showobjmeta: Displays the replication metadata for a specified object stored in Active Directory, such as attribute ID, version number, originating and local Update Sequence Number (USN), and originating server’s GUID and Date and Time stamp.

With this information we could track different type of changes in the domain by running:

repadmin /showobjmeta [DC Name] [distinguished Name] Continue reading →

When is a user definitely deleted/disabled?

Leave a reply

I read some news a while ago which inspired me to write this post.

http://www.darkreading.com/deactivated-user-accounts-die-hard/d/d-id/1251034
http://www.securityweek.com/windows-authentication-protocol-allows-deactivated-user-accounts-live-report

It’s about a flaw in Kerberos and how Windows handles user account revocation. The flaw makes is possible for a user to have access to systems up to 10 hours after the account has been, disabled, deleted or locked out.

This is no direct news, and I believe that the 10 hours could be much greater if you look outside Kerberos and take the replication convergence in consideration.

When a user is deleted, disabled or locked out this has to be replicated to all replicas in the domain, meaning all the DCs needs to be updated with this information. Continue reading →