Implementing Kerberos and using claims based Web Applications Part 3

24 April 2012 2 minutes read

This is a live blogging post from the International SharePoint Conference London 2012. So don’t expect well-written proza here.

Troubleshooting

claims delegation is ok inside SharePoint, but most external services don’t yet support it
bridge the gap with the claims to windows token service (c2wts)
to use the c2wts you only need to configure delegation on 2 accounts: the service app pool account & the account running c2wts
the user can even logon to sp with ntlm in this scenario! that’s a really powerful scenario, that’s the protocol transition part (ntlm>kerberos)
only possible with windows claims, not saml claims (SharePoint constraint, WIF can do it) debatable workaround found here
kerberos constrained delegation with protocol transition is needed
downsize to protocol transition: you can’t cross domain boundaries, so the user/resource domain scenario is not possible
c2wts must be running on the app server only
change the c2wts from using localsystem to a named service account
the user that runs the c2wts must be a local admin on the app server and have the “act as part of the os” and “impersonate a client after authn” local security policies
configure delegation for the c2wts service account in AD, you might need to create a dummy spn in order to have the tab available
delegation should use the “use any authn protocol” setting, what means: use protocol transition
don’t forget to perform the exact same steps on the service app pool account
restart the c2wts and iis on the app server to get it working
never configure the spn for the sql alias used in sharepoint