I'm looking for some guidance on auditing Kerberos delegation, specifically for accounts configured for unconstrained delegation. We've got several SQL service accounts that can delegate to any service, which was flagged during a recent security assessment. We're tasked with narrowing down their delegation capabilities because we're unsure where these accounts are currently delegating to. I've searched online for methods to audit this activity or find related event IDs, but I've hit a wall. Has anyone figured out an effective way to monitor or audit where these accounts are delegating?
2 Answers
Looking at Event ID 4769 might help you pinpoint where the delegation is happening. You can filter these events by user account to scale down the scope.
One way to approach this is through whiteboarding. You should start with the service that's running under the unconstrained accounts and see which users are connecting to it. That service will then make a connection to another service, potentially passing through the original user's credentials. If you're unsure about the onward connection, someone with knowledge of your infrastructure should be able to help identify it. If not, it might be worth revoking the delegation and testing how that affects functionality—just be cautious if your environment is critical! Generally, unconstrained delegation can often indicate a lack of understanding in its necessity, especially for SQL accounts; typically, it's web services that use delegation into SQL, not the other way around.
That's not always the case with SQL Server. I've seen unconstrained delegation useful for linked servers where you need to pass through user credentials from one server to another because of the double-hop issue. Without proper delegation, you're forced to use a shared account, which isn't secure.