So many of you probably have been wondering what type of 2FA I am using for my tests. Instead of setting up internal servers, dealing with encryption keys and various tokens, I stumbled upon a cloud service that handles all of this for you. Now before we dive into the “commercial” part (although I did not see any money from them) the basics for configuring TMG with radius are also covered in this post, so if you prefer another vendor, your own radius/2FA solution, this post still applies.
Part one, setting up Cryptocard
Indeed the title gave it away.. in this post I am using cryptocard cloud services for the 2FA. It means setting up a directory replication engine, assigning users and their tokens. First of all, you’d need a tenant setup from cryptocard. You can call them or send them an e-mail and your service will be ready. Now for the actual configuration. Login to the webservice and you will see your tenant’s name. Go to the comms module under the virtual servers node. There you will find the configuration options for the LDAP sync agent and Radius authentication modules.
LDAP Sync Agent
First of all we need the LDAP sync agent. This ensures that users from the internal Active Directory are provisioned to the crypto services and that we can assign users with a token. The LDAP agent is available from cryptocard (x86, x64). Install this piece of software on a machine (does not have to be the domain controller) and then we have some small configuration actions to perform. Now I’m using this against Active Directory, but as far as I know, it can also be used to sync Novell, or other LDAP directory. (note that you have to open the console with administrative privileges, or it will crash (bugfix?). To begin the configuration you’d need a BMC file. This file contains the tenant configuration details and can be downloaded from the CryptoCard web administration tool. In the comms module, select LDAP Sync Agent Settings and select the download button. The BMC file will be downloaded for you.
Click add in the LDAP Sync Agent console and point to the BMC file. Now go to configuration to configure the Directory integration. Click Config after the LDAP configuration and you will be guided through a series of pages to configure the LDAP connection. This includes, the Domain Controller name, the OU’s you wish to select for replication. Note that all entries are based on LDAP CN names. Thus the user that will connect to the AD must be entered as a full CN in the window, not just the username.
Although the agent will automatically select containers, it is usually better to manually edit the selection and only provide the Distinguished Name of the OU (including subs) that will be synchronized. In my case I have created a separate OU called O365 where all my Office 365 users are located. Using adsiedit I can get the DN of the OU (as well as the CN of the user) easily. My DN for the OU looks like: OU=O365,OU=Services,DC=Domain,DC=local.
Next configure the groups that are to be replicated. These are the groups where users who are a member can actually use the token, and are replicated. Note that the agent has a security mechanism where the number of users synchronized must match the number of users your tenant can cope with. If you buy a 10 license, you can only sync 10 users. The configuration is done, and select start to start the actual synchronization.
Assigning a token
Now the users should become visible in the cryptocard web console. Go to assignment and search for a user. Select the user and click provision. Select a token (get help from crypto if not sure which one) and follow the instructions. I chose MP which allows me to use the cryptocard token on my iPhone. The user will receive an e-mail with instructions on how to activate the token.
Radius setup
So now we have a user with a token, now to connect our TMG to the cryptocard services. The cryptocard service can use Radius authentication which works just as any other radius server. So in TMG we can configure the Radius servers, but before we do that, we need to have a secret between TMG and cryptocard to make sure only TMG is authorized to validate users. Again go to the comms webpage and there select Authentication Agent settings. Under auth node click add and a new section on the page will appear. Type the a descriptive name, the FQDN of the server and the external IP address. In case you have only 1 TMG server with 1 external IP, type the IP in both fields. Next click on generate to create a Radius secret. Copy this secret because we will use it in TMG. Click on save and the configuration is finished.
Part two, TMG setup
Now we move to the TMG server. In order to use the Radius authentication we first need a web listener. In TMG go to Toolbox (available when Firewall policy is selected) and create a new web listener. In my case I already have a web listener thus I open that one to fill in the radius properties. In the authentication window select HTML form, so users will receive a nice form where they have to enter their credentials instead of a stupid pop-up. Next select radius as the provider and click on configure validation servers.
Now Cryptocard has provided two Radius servers:
rad1.cryptocard.com
rad3.cryptocard.com
So click on add, type the names, leave the ports at 1812 and click on change to enter the secret (that was copied earlier). Click ok and add the 2nd radius server. Click ok to close the web listener properties.
TMG is by default only allowed to authenticate users using radius in the internal network, thus we need to setup TMG to be able to externally connect to the radius servers. For this we need to edit the system policy. Right click the Firewall policy node, select all tasks, system policy and select edit system policy. Go to the radius entry and select the “to” tab. Now add external network (or in case you want more security add two computer in the toolbox with the radius names and add these two separately) and click ok.
Now TMG is able to externally validate the user. But we need a web publishing rule to actually initiate the authentication part. Go to firewall policy and on the right pane, click Tasks and select publish websites. Now remember I already setup a web listener with a certificate (in my case a wildcard cert for my “test” domain), so we will be using that one. Follow the instructions in the wizard as you would normally do. Enter FQDN of external URL, enter the internal URL (or external URL with a specified server), paths etc. But as soon as you hit authentication delegation, switch the mode to Kerberos constrained delegation. This will allow TMG to receive a kerberos ticket from the domain controller to access the website on behalf of the user. Note the SPN below and write that down, as we will need it later on.
And click next, next, next, next, next, etc to finish the wizard.
Kerberos delegation
So we now have TMG ready, but it needs to be authorized to request kerberos ticket on behalf of the user for a specified service. For this we need to do two things:
* Set the SPN on the webserver we are trying to access
* Allow Kerberos constrained delegation (any protocol) to the SPN
For this we need to logon to the domain controller (or via a workstation) with domain admin credentials. The SPN will be set to a computer account (or service account) using the following command:
setspn -A HTTP/myURL.mydomain.local MYSERVER
This will register the SPN on the server object. In case your website uses a service account (for example SharePoint) then the SPN must be registered to the service account and not the computer object. More information on this will be available with the implementation guides of the service you are trying to publish.
Now in Active Directory users & computers, dive to the TMG server object, open the properties and select the delegation tab, click on Kerberos Constrained and select Any protocol. Click add and type the name of the webserver or service account. When clicking OK you will see a list of all the registered SPN’s and select the right one. Click ok and click ok to close the properties.
If you have not done so already, click Apply in the TMG server to make the firewall rules active, if you did already, you need to reboot the TMG to allow kerberos to work.
Web server config
The webserver must be configured to use Windows authentication, else the Anonymous access will be the initial security mechanism chosen and access will be denied. In this example the IIS7 website is set to only allow Windows Authentication.
Open the IIS manager, browse to the website and when selected click Authentication. In the right pane click on Anonymous and click disable. click windows authentication and click enable (note that the IIS role feature Windows authentication in the security hyve must be selected).
And thats it!.. Two factor authentication with Kerberos logon to backend webservers