Delegation is used when a server or service account needs to impersonate another user. For example, front-end webservers impersonate users when accessing backend databases, providing seamless access to data users are allowed to view or edit. Active Directory (AD) provides delegation for scenarios like this.
Unconstrained Delegation is Risky
Microsoft added unconstrained delegation to Active Directory in Windows Server 2000. When unconstrained delegation is configured on a server, it can impersonate connecting users because their Ticket-Granting Ticket (TGT) is placed into the service ticket if the Service Principal Name (SPN) is included in the Ticket Granting Server (TGS) request. SPNs define what services can run under a given user or computer account.
Attackers can compromise credentials when unconstrained delegation is configured. Imagine a situation where a domain administrator uses an IIS website that has its application pool account set for unconstrained delegation. If Windows Authentication is enabled on the site, it will be able to get a service ticket from a domain controller and authenticate to any service it likes as a domain admin. While that service should probably be a database, if the website or database is compromised, it could easily be a malicious application or even a domain controller instead. Once connected to a domain controller, the KRBTGT account password could be changed or the user could add themselves to the Enterprise Admins group, allowing the malicious actor to own the AD forest.
Constrained Delegation
Introduced in Windows Server 2003, constrained delegation allows system administrators to limit the services to which an impersonated account can connect. So, in the scenario I described above, a domain admin account logging in to an IIS website could be restricted to accessing specific services. And while not a perfect solution, it is less risky than unconstrained delegation.
But constrained delegation is difficult to implement because it relies on Service Principal Names (SPNs) to identify which services can receive delegated credentials. System administrators must register SPNs on the security principal that runs the front-end app and make sure that there are no duplicate SPNs in the forest. Because constrained delegation is managed on front-end servers, backend server administrators lose control over who gets access to their resources. Moreover, domain admin rights are required to manage constrained delegation, adding another layer of administrative complexity. Constrained delegation is also limited to security principals in the same domain, i.e. there’s no cross-domain or cross-forest scope.
Resource-Based Constrained Delegation
Resource-based constrained delegation in Windows Server 2012 improves on the constrained delegation model by removing the dependency on SPNs, the need for domain admin rights, allows the resource owner to control delegation, and provides for cross-domain delegation. It works on computer accounts, user accounts, and service accounts.
Instead of using an allow list of SPNs, Windows Server 2012 controls delegation using security descriptors. Backend server administrators define which security principals can request Kerberos tickets for another user. When a backend service receives a request from a frontend server to grant access on behalf of another user, the AD Key Distribution Center (KDC) checks the security descriptor in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the security principal running the backend service, and if it matches the descriptor under which the frontend service runs, access is granted. Resource-based constrained delegation is managed using Windows PowerShell.
Unlike constrained delegation, resource-based constrained delegation works regardless of the domain functional level. But you must have at least one domain controller running Windows Server 2012 or later in the same domain as the frontend server and one in the same domain as the backend server. And the frontend server must be running Windows Server 2012 or later.
Securing Active Directory
You should check that unconstrained delegation isn’t being used in your domain. Microsoft has a PowerShell script on TechNet that you can use to find accounts that are set up for unconstrained delegation. The script finds user accounts, computer accounts, and managed service accounts that are configured for all types of delegation.
If you find accounts that use unconstrained delegation, it might be as simple as changing the type of delegation. But if you decide to use constrained or resource-based constrained delegation, you need to thoroughly test that your app still works. Not all apps play nice with constrained delegation. If moving away from unconstrained delegation isn’t an option, there are several things you can do to reduce the risk.
Accounts can be individually configured in Active Directory Users and Computers (ADUC) to block all kinds of delegation using the ‘Account is sensitive and cannot be delegated’ flag. You could set this flag for sensitive accounts, like domain administrators. Sensitive accounts that are added to the Protected Users group are also blocked from using Kerberos delegation. But NTLM authentication and cached logons are also blocked for members of this group. For more information on Protected Users, see Protect Privileged Credentials in Windows Server 2012 R2 using the Protected Users Group on Petri. Authentication Silos can provide additional protection by restricting the devices that members can authenticate to. Check out Restrict Privileged Accounts with Authentication Silos in Windows Server 2012 R2 on Petri for more details on Authentication Silos.
Microsoft suggests enabling Kerberos auditing in advanced audit policy on all domain controllers and monitoring tickets from delegated accounts to unsanctioned services. Finally, set outbound firewall rules on servers using the unconstrained delegated account.
The post Understanding Kerberos Delegation in Windows Server Active Directory appeared first on Petri.