Use KCD to secure your infrastructure

In todays world, working remotely, and accessing information from outside the corporate network, is a demand. One huge problem with many solutions today is that this will make us expose our domain password on un-secure clients like mobile phones and internet café’s. On these un-secure devices it is very hard for us to know if there is some kind of password snatcher, and if the password is stolen this can often be used to logon to our corporate resources.

KCD (Kerberos Constrained Delegation) makes it possible for us to build solutions that do not require the domain password to access resources like ActiveSync, OWA and Sharepoint. Microsoft ForeFront UAG and TMG are two great products that can make use of KCD to secure your infrastructure.

How to make it work…
What you do is that you configure TMG/UAG to authenticate using a method that do not require the users domain password. This could be an OTP (One Time Password) for example. You then configure delegation to use KCD and UAG/TMG will request a Kerberos ticket on behalf of the user and present that as credentials to the service. In many scenarios you will find that UAG´s more flexible authentication options will make this much easier using UAG then TMG.

The ActiveSync example…
ActiveSync is widely used to access email based on Microsoft Exchange. Usually this means the username and password of the domain account is stored in the device. A mobile phone, no matter how “smart”, is not a secure platform. What you can do is to configure a second identity store where the username and “activesync password” is stored. You then use UAG/TMG to authenticate against that store and then use KCD to get the users data from Exchange. This way the password stored in the device is not the same as the domain password and you can also enforce a different password complexity and change policy.

Prerequisites…
First of all we need to understand that in order for KCD to work there are some demands on the infrastructure.

  • The UAG/TMG server must be a member of the same domain as the resource the user tries to access.
  • UAG/TMG needs to be trusted for delegation for the specific service
  • The username needs to be the same if using multiple identity stores.
  • The resource needs to accept Kerberos authentication.

More to come…
I am currently working on a more detailed article to show how to configure the ActiveSync example using UAG and AD LDS as the ActiveSync user store. I might even throw in a section on how FIM (ForeFront Identity Manager) can be used to automate the process of managing the second identity store required in this example.