This is just a small note of a feature that was new in Windows 10 v1507 and Windows Server 2016.
In the early days (Windows 2000, XP and 2003) it was possible to configure Service Principals Names (SPNs) with IP addresses. And then in Windows Vista and Windows Server 2008 it was removed in the Kerberos client and IP addresses on services didn’t work.
Since then if a client tries to connect to e.g. a share by its IP address it would fall back to NTLM.
I don’t know why that changed, but the good news is that they have reintroduced that functionality and you can configure the Kerberos clients to request a service ticket based on a IP hostname SPN. Continue reading →
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 →
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 →
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.
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 →
Shadow Principals is a new cool feature in Active Directory 2016. It’s part of the Optional Feature Privileged Access Management. I have covered the basic concept with Just In Time Admin Access two years ago, and I also wrote about time-based groups a year ago.
The first article is kind of outdated and everything wasn’t fully implemented yet. Missing pieces was Shadow Principals and PIM Trusts. So, I decided to write an article about it and how to test it with basic built-in functionality.
Just a quick background if you don’t want to read earlier posts:
A while back Microsoft release a guidance of Securing Privileged Access.
In step three they include creating one and even two new forests for managing privileged admin accounts (in this example we will use one). You can read more about it here: ESAE Administrative Forest Design Approach.
The idea is: to secure the existing production domain, a shadow forest will be created and is a single domain forest built on Windows Server 2016, it is hardened and locked down from day one. By using the new PAM feature we can create Shadow Principals based on the production domain and grant time limited access (which also is integrated in Kerberos).
The administrative groups in the production domain will be empty and kind of remove the map of admins in the domain. The shadow admins will only have administrative access in the production domain when needed providing just-in-time administration (JIT).
With this, Microsoft Identity Manager also comes in to play with its PAM feature managing this in the Shadow Forest, where users can request admin access.
In this example, we won’t use MIM, we will look at the Shadow Principal and test the PAM feature in Active Directory at its core basics. Continue reading →
When I upgraded a domain to Windows Server 2016 DCs I noticed a bug in the adprep program that I have reproduced in my lab and wanted to share it here.
In Active Directory 2016 there is two new groups introduced.
Enterprise Key Admins
If you create a new domain with Windows Server 2016 the groups will be created and given Read and Write access to the ms-DS-Key-Credential-Link attribute on all child objects from the domain root.
There isn’t much public documentation about this attribute, and that isn’t what this blog post is about.
But it seems to have something with Windows Hello for Business providing key-based or certificate-based authentication. That is still not fully implemented in Active Directory, it’s on the roadmap for future release. You can read more about it here: Manage identity verification using Windows Hello for Business
I have also noticed the ADFS 4.0 installation wizard tries to add the service account as member of the Enterprise Key Admins group. You can read about it here: Upgrading the ADFS farm behavior level
When I upgraded a domain, and ran adprep.exe to prepare the domain for Windows Server 2016 DCs I noticed after running adprep.exe /domainprep two new SIDs representing the two new groups. Continue reading →