Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with tweny-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The eleventh one in the series is the “Unsecure Kerberos delegation” recommended action.
Introduction
You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.
- Resolve unsecure domain configurations
- Resolve unsecure account attributes
- Remove dormant accounts from sensitive groups
- Protect and manage local admin passwords with Microsoft LAPS
- Configure VPN integration
- Reduce lateral movement path risk to sensitive entities
- Stop clear text credentials exposure
- Disable Print spooler service on domain controllers
- Stop weak cipher usage
- Remove unsecure SID history attributes from entities
- Modify unsecure Kerberos delegations to prevent impersonation
- Install Defender for Identity Sensor on all Domain Controllers
- Set a honeytoken account
- Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
- Accounts with non-default Primary Group ID
- Change Domain Controller computer account old password
- Reversible passwords found in GPOs
- Unsafe permissions on the DnsAdmins group
- GPO assigns unprivileged identities to local groups with elevated privileges
- Remove access rights on suspicious accounts with the Admin SDHolder permission
- Remove local admins on identity assets
- Remove non-admin accounts with DCSync permissions
- GPO can be modified by unprivileged accounts
- Built-in Active Directory Guest account is enabled
- Change password for krbtgt account
- Change password of built-in domain Administrator account
- Ensure that all privileged accounts have the configuration flag
Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Modify unsecure Kerberos delegations to prevent impersonation.”
Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.
Kerberos Delegation
Kerberos delegation allows resources to access data or other resources on behalf of an identity. A good example is a web server as a front-end server and a database server as its back-end. When a user accesses a web server, the web server requests data from the database server on behalf of the user.
There are three essential types of delegation.
- Unconstrained delegation
- Constrained delegation
- Resouce-Based Constrained Delegation
Unconstrained Delegation
With unconstrained delegation, the web server can access any service within the domain on behalf of the user. To enable unconstrained delegation, check the following option in Active Directory.
What happens with the Kerberos flow is as follows.
If Unconstrained Delegation is enabled, when requesting a Ticket Granting Service ticket (TGS), the Domain Controller adds the user’s Ticket Granting Ticket (TGT) to the TGS. Once the service receives the TGS, it extracts it and saves the user’s TGT in its memory. Imagine hundreds of users accessing the web server application; there will be hundreds of TGTs in the web server’s memory. Once the web server is compromised, a malicious actor can act as hundreds of users within the entire domain. To mitigate this risk, Microsoft came up with constrained delegation.
Note: Domain Controllers always have an unconstrained delegation set and are not identified by Microsoft Defender for Identity as an exposed entity.
Constrained Delegation
With constrained delegation, the web server can access specified services within the domain on behalf of the user. To enable constrained delegation, check the following option in Active Directory.
If constrained delegation is enabled, when requesting a TGS, the Domain Controller sends the TGS to the user, and the user sends the TGS to the web server. The web server can request a TGS for the database server, but ONLY for the database server and its service.
If the web server is compromised, yes, a malicious actor does have valid tickets, but only for a particular server and service. Sure, it is still bad, but not as bad as hundreds of valid TGTs that a malicious actor uses to request a TGS for anyserver and service.
Resource-Based Constrained Delegation
Resource-Based Constrained Delegation (RBCD) is similar to constrained delegation. The difference is that with RBCD, resources like computer objects are configured to whom they can trust. However, constrained delegation tells the object what resources it can delegate to.
Unsecure Kerberos Delegation
Microsoft Defender for Identity identifies identities with unconstrained delegation. Microsoft recommends changing unconstrained delegation to constrained delegation or removing any delegation by changing the option to “Do not trust this computer for delegation” on the identity.
Suppose any identity is using Unconstrained Delegation. In that case, I recommend changing it to Constrained Delegation, or if it is a user account and not a service account, remove delegation altogether. Unconstrained delegation is probably unnecessary, but checking which service the account needs access to is easy.
Conclusion
Besides the Domain Controllers, no object within Active Directory needs to use Unconstrained Delegation. Change the Unconstrained Delegation to Constrained Delegation or remove any delegation by setting the option “Do not trust this computer for delegation” on the object itself. Microsoft Defender for Identity helps identify identities with an unsecured delegation set.
Microsoft Security Blog 