Kerberos: Threats and Countermeasures
Now the assignment is to brief our security group on the impact of our Kerberos configuration might have "downstream" specificially relating to "threats and countermeasures."
I guess the theory is that by trusting accounts and servers for delegation, security holes may arise in unexpected ways. Also, the specific configurtations may impact non-SharePoint web applications that are hosted on servers alongside SharePoint web applications.
Also, when we last looked at Kerberos, we were operating in our spiff new Server 2003 domains and, this being 2009, those domains look considerably less spiffy. So, to maintain sufficient spiffiness, we'll be working in our spiffy new Server 2008 domains.
We have the TechNet content re: Server 2008 here: http://technet.microsoft.com/en-us/library/dd349791.aspx
Here we find a link to download a document titled: Threats and Countermeasures: Security Settings in Windows Server 2008 and Windows Vista
The only relevant content here relates to providing permission to set the "Trusted for Delegation" property for user and computers in the Active Directory domain.
The main point of this content is that if you provide this permission to a user then you have the possibility that user can be hacked and some nefarious agent can then set the permissions, and establish authentication that will be trusted by the coputers that use this permission.
One excellent point it make is "Delegation of authentication is a capability that multitiered client and server applications use. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, both client and server must run under accounts that are trusted for delegation.
The impact here is that user account that get hacked can create a problem that would extend to data sources that trust the account even if that datasource itself is not hacked. The countermeasure is to use "constrained delegation" to llimit the access of trusted delegates.
As I see it, this means I log into Windows and I'm me. I visit my team site and SharePoint interacts with the content database using its service account and renders my selected page. On my page, there's a web part that queries an extenal datasource; since the service account is trusted for delegation and the web server is trusted for delegation, the service account and the web server are able to carry my ID to the external datasource and, essentially, log me it. As a result, the query result will be security trimmed for me. Obviously, if I can establish users and computers that are trusted for delegation, I can make the service account and the web server carry my credentials to an external datasource and gather the answer to a query that the service account itself may not have permission to see.
Second, elsewhere on TechNet (http://technet.microsoft.com/en-us/library/cc782684.aspx) tells us: Misuse of this user right, or of the Trusted for Delegation setting, could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.
Third, Kerberos Authentication uses Active Directory and our new best friend, Tim, has two great posts on the way Kerberos works in AD here:
http://blogs.technet.com/ad/archive/2007/12/17/t2a4d-concidentally-what-i-would-name-a-droid-if-i-had-one.aspx
and
http://blogs.technet.com/ad/archive/2008/05/09/trusted-for-delegation-in-services-for-user-s4u.aspx
Tim gives us this clever tidbit:
The T2A4D setting has no actual check box or radio button which is intuitively titled “Click Here for Trust To Authenticate for Delegation”. Instead the setting is integrated with the constrained delegation settings interface on a computer account.
So, if we want to boost our credibility with the security team, we might suggest that we are, in fact, addressing the constrained delegation countermeasure we mentioned above.
-robot
Tags: