Dmitrii blog : PKI

Claim Based Authentication IV

lezine — Mon, 05 Oct 2009 05:14:56 GMT

In previous three posts we examined how claim authentication flow works for users in the same domain as SharePoint site and for users from other organizations. As we have seen, the value for Role claim was based on the Active Directory group membership. For instance, Frank Miller from Fabrikam was given role of DrugTrial1Auditors in Contoso SharePoint site because he was member of DrugTrial1Auditors AD group in Fabrikom.com domain. With current configuration Contoso has no say which users from Fabrikam have DrugTrial1Auditors role on Contoso SharePoint site. Contoso trusts Fabrikam administrators to ensure that only authorized employees for DrugfTrial1Auditors belong to the Fabrikam DrugTrial1Auditors group. This can be perfect in some situations, but sometimes it might be not the best solution. What if Contoso wants to control what type of access users from Fabrikam should have to the Contoso SharePoint site, but at the same time they do not want to manage or create accounts for Fabrikam users? There is a great solution for it and step 8 in the demonstration shows a sample on how we can use SQL server database as source for external attributes for claim values. Figure 1 shows example tables for this solution.

Figure 1. External data source for user information

Table dbo.TS contains information about which SharePoint site belongs to which drug trial.

Table dbo.URT contains a list of e-mail addresses of users, the role that they have, and the drug trial that they belong to.

Table dbo.RS maps the roles in the database to the roles in the Contoso SharePoint site.

To accommodate data in these tables we had to modify SharePoint site. It was reconfigured with new roles: Role#sp_admin and Role#sp_visitor. DrugTrial1Auditor role and DrugTrial1Admin role were removed from the portal. Also, new datasource was added: “HOL Doctors Role” database.

Three new rules were created on the Contoso SharePoint RP. Each rule is using one of the database tables. Check out this site for ADFS v2 rule language format:

http://technet.microsoft.com/en-us/library/dd807118(WS.10).aspx

The first rule check which trial the https://docs.contoso.com/ site belongs to:

=> add(store = "HOL Doctors Role", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/trial"), query = "select trial from dbo.TS where dbo.TS.SharePointSite = {0}", param = "https://docs.contoso.com/");

In second rule, we use the previously queried trial information with the user’s e-mail address and discover which role the user belongs to:

c1:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
&& c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/trial"]
=> add(store = "HOL Doctors Role", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/incomingtrialrole"), query = "select role from dbo.URT where dbo.URT.Trial = {1} and dbo.URT.UserName={0}", param = c1.Value, param = c2.Value);

In the third rule, we use a previously queried role claim to query the SharePoint role claim and assign the value to the outgoing role claim:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/incomingtrialrole"]
=> issue(store = "HOL Doctors Role", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "select dbo.RS.SharePointGroup from dbo.RS where dbo.RS.Role = {0}", param = c.Value);

Lets take a look at how claim flow will work in this new configuration. Figure 2 shows slightly modified flow of authentication to Contoso SharePoint site from Fabrikam user.

Figure 2. Authentication by Fabrikam user to Contoso SharePoint site

Fabrikam user Frank Miller will access Contoso SharePoint site.

In step 1, Frank opens his browser and opens https://docs.contoso.com site. SharePoint site will provide its policy information a redirect Franks browser to a trusted STS.

In step 2, Franks browser will access https://sts1.contoso.com and reads its policy. At this point Frank must select his home realm. If Information Card was already configured in Fabrikam forest for Contoso SharePoint site, the home realm discovery would automatically redirect his browser to his home STS. Without Information Card, he would be required to choose his STS server in the drop down list. At this point no claims yet have been exchanged and all authentication been done via anonymous authentication mechanism.

In step 3, Franks computer will authenticate to the STS. Since our STS is running on the same computer as Domain Controller, it is already authenticated to it, so it just presents existing Kerberos ticket, which will have all required information in it, such as list of groups this user belongs to (list of SIDs of those groups).

In step 4, Fabrikam STS will create and process new claim for Frank Miller. The first rule will create the following claim:

Outgoing Claim Type	Claim Value
E-Mail Address	frankm@fabrikam.com
Role	DrugTrial1Auditors Purchaser Domain Users

Next, it will pass this claim onto second and 3rd rules. Second rule allows to pass all claims with any E-Mail Address. 3rd rule will check value of the Role claim type and it will discard 2 values out of this claim. The final outgoing claim from Fabrikam STS for user Frank Miller should have the following information:

Outgoing Claim Type	Claim Value
E-Mail Address	frankm@fabrikam.com
Role	DrugTrial1Auditors

In step 5 this claim is delivered back to Franks computer.

So now Frank has his claim from Fabrikam STS. Can he present this claim to Contoso SharePoint site? It would not work because Contoso SharePoint site does not trust Fabrikam STS, it only trusts Contoso STS and it would accept claims only from Contoso STS.

In step 6, Franks computer will deliver his claim to Contoso STS.

Now it is up to Contoso STS to evaluate incoming claim and decide what to do with it. In steps 7, 8 and 9 Contoso STS receives incoming claim from Fabrikam STS and it will pass it onto Fabrikam IDP rule set configured on Contoso STS. If you remember, those rules will evaluate incoming claim values and will pass claims only if their E-Mail Address value ends with @fabrikam.com and its role value is equal to DrugTrial1Users. Incoming claim from Frank satisfies both criteria. At this point Contoso STS accepted incoming claim, it is not going back out yet to the user computer. The value of this claim should be the same as it came in:

Outgoing Claim Type	Claim Value
E-Mail Address	frankm@fabrikam.com
Role	DrugTrial1Auditors

Next, it will pass this claim onto Relying party rule set to create outgoing claim suitable for the SharePoint. Now Contoso SharePoint RP is configured with five rules for incoming claims. First one will pass Role claim type without any changes to its Role type. Second rule is a transformation rule. It will change the E-mail Address claim type to Name claim type, but will keep its value the same. The 3rd rule will identify that DrugTrial1 trial belongs to https://docs.contoso.com site. The forth rule will identify that Frank has Admin role in DrugTrial1 trial. And finally, the fifth rule will identify that Admin for DrugTrial1 mapped to sp_admin role in SharePoint site.

The final claim for Frank Miller, coming out from Contoso STS destined for SharePoint RP should look like this:

Outgoing Claim Type	Claim Value
Name	frankm@fabrikam.com
Role	sp_admin

OK, to recoup, lets compare claim originated at Fabriakm STS and final claim delivered to Contoso SharePoint:

Claims Based Authentication – Part III

lezine — Sat, 03 Oct 2009 17:06:46 GMT

This is continuation of two previous posts. Please check them out first, otherwise this one might not make much sense at all.

Step 6 in step-step guide configures Fabrikam STS with Relying Party and shows how to configure Information Cards to automate home realm discovery. I’m not going to talk about Information Cards yet, for now we stick with STS configuration and claims flow.

Afetr the RP for Contoso STS was created we configured three claim rules. The first rule is using AD as the directory source. It should be easy to predict the mappings in this rule. Just take a look back at how Fabrikam IDP on Contoso STS was configured. It expects certain type of incoming claims. This rule has the following mappings:

LDAP Attribute	Outgoing Claim Type
mail	E-Mail Address
tokenGroups	Role

This could be configured to just send this claim out to the relying party, but it was not. Fabrikam STS Administrator decided to provide some extra checks and only send out claims that match certain criteria.

The following table shows two new rules:

Rule #	Rule Type	Incoming Claim Type	Pass Through All Claim Values	Pass Through only a specific Claim Value	Pass through only claim values that end in a specific value	Pass through only claims that start with specific value
1	Pass Through Incoming Claim	E-Mail Address	Yes
2	Pass Through Incoming Claim	Role		DrugTrial1Auditors

The first rule will pass any E-Mail Address claim, but the second rule will filter out all claims that do not have DrugTrial1Auditors in its value.

At this point users from Fabrikam are ready to access Contoso SharePoint site.

What is the single qualifying requirement for Fabrikam user to get access to the Contoso site? Fabrikam user must be member of DrugTrial1Auditors Active Directory group.

Lets examine the entire authentication flow for Fabrikam user. Figure 1 provides steps in this process.

Figure 1. Authentication by Fabrikam user to Contoso SharePoint site

Fabrikam user Frank Miller will access Contoso SharePoint site.

In step 1, Frank opens his browser and opens https://docs.contoso.com site. SharePoint site will provide its policy information a redirect Franks browser to a trusted STS.

In step 4, Fabrikam STS will create and process new claim for Frank Miller. The first rule will create the following claim:

Outgoing Claim Type	Claim Value
E-Mail Address	frankm@fabrikam.com
Role	DrugTrial1Auditors Purchaser Domain Users

Outgoing Claim Type	Claim Value
E-Mail Address	frankm@fabrikam.com
Role	DrugTrial1Auditors

In step 5 this claim is delivered back to Franks computer.

In step 6, Franks computer will deliver his claim to Contoso STS.

Now it is up to Contoso STS to evaluate incoming claim and decide what to do with it. In step 7, Contoso STS receives incoming claim from Fabrikam STS and it will pass it onto Fabrikam IDP rule set configured on Contoso STS. If you remember, those rules will evaluate incoming claim values and will pass claims only if their E-Mail Address value ends with @fabrikam.com and its role value is equal to DrugTrial1Users. Incoming claim from Frank satisfies both criteria. At this point Contoso STS accepted incoming claim, it is not going back out yet to the user computer. The value of this claim should be the same:

Outgoing Claim Type	Claim Value
E-Mail Address	frankm@fabrikam.com
Role	DrugTrial1Auditors

Next, it will pass this claim onto Relying party rule set to create outgoing claim suitable for the SharePoint. Contoso SharePoint RP is configured with two rules for incoming claims. First one will pass Role claim type without any changes to its Role type. Second rule is a transformation rule. It will change the E-mail Address claim type to Name claim type, but will keep its value the same.

The final claim for Frank Miller, coming out from Contoso STS destined for SharePoint RP should look like this:

Outgoing Claim Type	Claim Value
Name	frankm@fabrikam.com
Role	DrugTrial1Auditors

In step 8, this claim is send back to Franks computer, in step 9 it is delivered to Contoso SharePoint site. SharePoint site will authenticate Frank Miller (frankm@fabrikam.com) at gives him appropriate rights configured for Role#DrugTrial1Auditors. Just like that simple and easy.

In next post we’ll look at how role membership information can be outsourced to SQL database.

Claims based Authentication – Part II

lezine — Fri, 02 Oct 2009 19:07:57 GMT

In previous post we started examination of the authentication process in our demo environment. Lets examine what happens in step 5 of the step-step guide. During this step Contoso STS was configured to work with Fabrikam STS. There were three primary steps in this process:

Add Fabrikam STS as Identity Provider (IDP)
Configure rules for incoming claims from Fabrikam IDP.
Configure RP rules to process claims after they pass through the IDP rules.

Fabrikam IDP is configured with two rules:

Rule #	Rule Type	Incoming Claim Type	Pass Through All Claim Values	Pass Through only a specific Claim Value	Pass through only claim values that end in a specific value	Pass through only claims that start with specific value
1	Pass Through Incoming Claim	E-Mail Address			@fabrikam.com
2	Pass Through Incoming Claim	Role		DrugTrial1Auditors

So what does it mean? We are saying that Contoso STS will accept two types of claims from Fabrikam STS:

E-Mail Address
Role

Also, it will evaluate the value of incoming claim and will pass only claims with specific identified values. One thing we have to keep in mind here is that some time in the design process folks from Contoso and Fabrikam have actually discussed the type of claims will be exchanged between each STS. Because if Fabrikam STS is configured to send different types of claims to Contoso, nothing will work. Also, IDP rules are not sending incoming claims to actual RP or the user browser, they are received, evaluated and if they pass the filter, they are passed through onto the configured STS RP.

So next, RP rules must be modified to evaluate incoming claims and perform some action on them. Contoso SharePoint RP already has one rule set configured on it. Two new rules must be configured, one for each incoming claim type from Fabrikam IDP.

Contoso SharePoint RP is configured with two additional rules:

Rule #	Rule Type	Incoming Claim Type	Outgoing Claim Type	Pass Through All Claim Values	Pass Through only a specific Claim Value	Pass through only claim values that end in a specific value	Pass through only claims that start with specific value
1	Pass Through Incoming Claim	Role		Yes
2	Transform Incoming Claim	E-Mail Address	Name	Yes

The first rule will pass through any “role” claim type, it doesn’t care about its value.

The second rule will take the value of the “E-Mail Address” claim and pass this value but in a different claim type – in this case as claim type of “Name”. This is powerful stuff. Contoso SharePoint needs to identify a user by its name and it does so via claim type of “Name”. Fabrikam on the other hand does not send this type of claim from its STS. If we could not do claim transformation then this solution would not work or both parties would have to agree on every single claim and its syntax, and every application would be required to comply with those requirements. Claim transformation eliminates this limitation and gives us a lot of flexibility.

Lets examine how one specific claim would go through Fabrikam IDP and then through Contoso SharePoint RP. In this example Fabrikam STS send the following Claim to Contoso STS:

Incoming Claim Type	Claim Value
E-Mail Address	markw@fabrikam.com
Role	DrugTrial1Auditors

Fabrikam IDP rules will examine this claim and since both conditions are met it will pass through it.

Next, the Contoso SharePoint RP will evaluate this claim. After it goes through its rules the resulting claim should have the following information:

Outgoing Claim Type	Claim Value
Role	DrugTrial1Auditors
Name	markw@fabrikam.com

This data will be send to the end user and then presented to the SharePoint site for authentication.

Key Learning's

Before configuring rules on the IDP you need to identify what type of claims IDP STS will be sending to your STS.
Rules configured on the IDP can be used to filter out incoming claims and pass through only ones that pass specific criteria.
Rules configured on IDP and rules configured on RP are independent from each other.
It is easy to do a simple transformation of one claim to another while keeping the value of the claim the same.

In the next post we’ll examine how Fabrikam STS will construct outgoing claims and look at the whole flow of this process.

Claims based Authentication - Part I

lezine — Fri, 02 Oct 2009 15:39:19 GMT

Claims based authentication is getting more ground and with more practical applications we’ll see more and more adoption of this technology. Recently I downloaded and went through step-step demonstration on using Microsoft Office SharePoint Server 2007 and Active Directory Federation Services v2 (ADFS v2) beta 2 software. You can download this great demo at this location (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=57602615-e1ee-4775-8b79-367b7007e178).

I have done simple implementations with ADFS v1 in the past and have read a good amount on ADFS v2 and in general on Claims based authentication, so I’m not new to this concept and technology in general. It doesn’t take long to go through all of the steps in this demonstration and it actually fairly easy and everything works. After going through all of the specified steps I scratched my head and thought, hmm, how is it exactly working, what is happening there, what kind of claims are going between IDP and RP, how are they configured and how can I modify this configuration to do other things? I like to visualize things, if it at all possible. This way I can see it, visually touch it and can get much better long term understanding on how this solution is actually working. So I decided to walk through this configuration and try to document some of those parts needed for better understanding of the entire message workflow.

If you are new to Claims based authentication, this post might not make much sense to you. There are a lot of resources on this subject. At the the of this post I provide some links to blogs and white papers that I think are very informational and educational.

First, I want to review the design of this demonstration. Figure 1 shows both Fabrikam and Contoso environments.

Figure 1. Base configuration of Fabrikam and Contoso

If you didn’t have a chance to review step-step document then here is a quick review of this solution. Contoso is doing business with Fabrikam and as part of their business environment they need to provide a secure collaboration portal. Contoso is using SharePoint 2007 to share documents between Contoso and Fabrikam. Contoso does not want to manage Fabrikams user accounts and Fabrikams does not want to have more than one user account and would like to have single sign on to access resources on Contoso SharePoint portal. Access to resources must be controlled via assigned roles. Some users should have only read access, some contributor access and some full access to the content.

As you can see, each company has its own Active Directory environment. They do not have Active Directory Forest or domain trusts and users in one environment can’t authenticate to other environment via AD trusts. Contoso AD does not have duplicate accounts for Fabrikam users.

Fabrikam users will access resources in Contoso SharePoint portal via Claims based authentication and they will have certain rights (roles) based on the assigned group membership in their own Fabrikam AD environment.

In step-step guide, in step 4 you’ll be asked to authenticate as Contoso\Administrator to the https://docs.contoso.com and add new roles to the site. In prior steps you configured this site to use “Role#Domain Admins” as site administrator and configured ContosoSRV01 ADFS with RP for SharePoint site with couple claim rules.

So what happens during this authentication and what type of claim is actually provided to the SharePoint site to give Contoso\Administrator administrative rights on the site? Figure 2 shows authentication steps.

Figure 2. Authentication by Contoso user

In step 1, Administrator accesses https://docs.contoso.com site, his browser reads the policy on the SharePoint site, discovers that it need to get a Claim from sts1.contoso.com and get redirected to it.

In step 2, he chooses to use Windows Integrated Authentication to authenticate to STS.

In step 3, he will get required claim from STS. STS is configured with the following rules:

LDAP Attribute	Outgoing Claim Type
Mail	*Name
tokenGroups	*Role
mail	E-Mail Address

Based on these rules, the content of this claim will be the following:

Claim Type	Claim Value
Name	administrator@contoso.com
Role	Domain Admins Administrators Domain Users Enterprise Admins Group Policy Creator Owners Schema Admins AD RMS Enterprise Administrators
E-Mail Address	administrator@contoso.com

In step 4 this claim is send back to the https://docs.contoso.com SharePoint site.

Sharepoint site will take the claim, evaluate it and will find that one of the values in Claim Type Role is “Domain Admins” which matches its own configured Role type (“Role#Domain Admins”). Based on this match SharePoint will give our Administrator administrative rights to this site.

OK, this is fairly easy stuff. One to one matching and we are in business. As we can see Administrator Role Claim value has multiple groups in it. Obvious question begs the answer, can we configure SharePoint roles provider with any of these groups to give this user administrative access on the SharePoint? and the answer is yes. To prove this we can do a quick test. We’ll modify SharePoint to use “Role#Schema Admins” instead of “Role#Domain Admins”. Since Administrator account is member of Schema Admins group, he will have administrative rights on the site.

During step 4 (step-step guide) Administrator configures site with couple new roles: “Role#DrugTrial1Admins” and “Role#DrugTrial1Auditors”. At the end of step 4 we’ll authenticate as user Contoso\Danielw and verify that he has appropriate rights. Same flow will happen as shown in Figure 2. Based on the configured rules the claim will have the following values:

Claim Type	Claim Value
Name	danielw@contoso.com
Role	Domain Users DrugTrial1Admins Developer
E-Mail Address	danielw@contoso.com

Because Daniels claim type ‘Role” has value matching SharePoint configured role, he is will be given appropriate rights on this site.

Key Learning's:

In basic mapping of the tokenGroup LDAP attribute and Outgoing Claim type, the Role value configured on the SharePoint site must match the name of the Active Directory group.
At this point we have one STS configured with single RP and we have a rule set corresponding to this RP.

Additional Research Items

When user tries to authenticate to SharePoint, does it provide back to the user a set of Claim Types it is asking for or is it simply redirecting user to the STS and relies on STS to provide whatever claims it is configured with? It would be very nice and intelligent for SharePoint to only ask for what it needs and for STS to provide only the type of claims that RP has asked from it.

In the next post we’ll continue examination of this configuration.

Re-Revoking Certificates with Different Reason Code

lezine — Sat, 18 Aug 2007 02:53:00 GMT

One of my customers is using 3rd party Card Management System (CMS) to manage their smart cards. One of many common management tasks that such systems perform is revocation of the smart card and in particular the certificates issued to the given smart card. Well, of course CMS only originates the revocation request - the actual revocation is performed on CA that issued certificates. Certificates can be revoked for different reasons and when you revoke it is good idea to specify the reason code for revocation. Some implementations require that the reason code is specified, and some implementations require that this reason code must be set to "key compromise". If you do not specify the reason code during revocation then it will be set to the default reason code which is "unspecified".

So this particular CMS does not specify the reason code when it sends revocation requests to CA. At the same time customer Security Policy dictates that all subscriber certificates will be revoked with "key compromise" reason code.

As I mention before the default revocation reason code for Windows 2003 CA is "unspecified". It is not possible to change the default setting to any other reason code.

Since CMS doesn't specify the reason code for revocation all revoked certificates by this CMS are revoked with the reason code "unspecified". This is a problem for them and we had to find some quick and easy solution to change the reason code on already revoked certificates from "unspecified" to "key compromise".

Fortunately it is possible to do in couple different ways. One of them is to use certutil.exe command to re-revoke already issued certificates and specify new required reason code.

Here is the command you need to run to revoke a certificate with Serial Number 18e877ea00000000000a and reason code "key compromise":

certutil -revoke "18e877ea00000000000a" 1

So far so good, but how do we know what Serial Number to put into this command? We need to know what certificates already have been revoked. Well, the same utility comes to our rescue. If you run the following command it will provide you with Serial Numbers of all revoked certificates after the specified date:

certutil –view –restrict "RevokedWhen>=08/15/2007" –out SerialNumber

OK, so we run this command, get all serial numbers of revoked certificates, populate this numbers to the first command and re-revoke all of them with new reason code. Cool, but what kind of output does this command provide to us? Can we easily grab serial numbers out from it?

The output from this command looks similar to this:

1/1/2006 12:00 AM

Schema:

Column Name Localized Name Type MaxLength

---------------------------- ---------------------------- ------ ---------

SerialNumber Serial Number String 128 -- Indexed

Row 1:

Serial Number: "61153ff1000000000006"

Row 2:

Serial Number: "18daada4000000000007"

Row 3:

Serial Number: "18e2c82a000000000008"

Row 4:

Serial Number: "18e3c5d4000000000009"

Row 5:

Serial Number: "18e877ea00000000000a"

Can we get actual numbers out of this output? To the rescue comes Visual Basic script that parse through this information and as it finds anything between "" it takes it, and then creates the revocation command and executes that command.

First we run this command and create the output file with serial numbers:

certutil –view –restrict "RevokedWhen>=08/15/2007" –out SerialNumber > sn-input.txt

Then we can run the following VBScript to re-revoke all certificates that have been revoked since 8/15/07. Here is the sample script to do it:

sInFile = "sn-input.txt"

sDelimiter = """"

const ForReading = 1, ForWriting = 2, ForAppending = 8

set oShell = wscript.createobject("wscript.shell")

set oFSO = wscript.createobject("scripting.filesystemobject")

if oFSO.FileExists(sInFile) then

set oInFile = oFSO.OpenTextFile(sInFile,ForReading)

else

wscript.echo "Input file " & sInFile & " does not exist."

wscript.quit(1)

end if

do while not oInFile.AtEndOfStream

sLine = oInFile.ReadLine

aValues = split(sLine,sDelimiter)

if ubound(aValues)>0 then

if ucase(trim(aValues(0))) = ucase("Serial Number:") then

iRetVal = oShell.Run("certutil -revoke " & """"& aValues(1) &"""" & " 1",TRUE)

end if

loop ' oFile

oInFile.Close

Now it should be easy to create a batch file that will first create an input file with serial numbers of all revoked certificates and then run vbscript that will parse through this file and re-revoke them with new reason code.

To truly really automate this solution we'll need to automatically inject the date into the command that creates the input file, otherwise it will re-revoke bunch more certificates that we really need. But I didn’t do any investigation yet on how easy it would be inject a certain date into that command. Maybe some other time.

By the way it would take me much longer to come up with this solution if not for some quick pointers from PG and help with writing vbscript from another MS Consultant. Mark you are da man!

TS Gateway #4

lezine — Mon, 02 Jul 2007 00:38:00 GMT

Server side configuration

In previous 3 postings I talked about why I liked TS gateway, the overall architecture for configuring TS Gateway in home lab environment and the client side configuration.

This time I'll show a few screen shots of the TS Gateway configuration. The configuration is very simple and one can figure it out by basically going through the wizard and consulting available help. But pictures sometime are nice to see too, especially of already configured server.

Anyway, in my lab I have TS Gateway server running the publically available beta of Windows Server 2008, it is running as virtual guest on Virtual PC hosted on Windows Vista. TS Gateway server has one network card assigned to it. It is important to know the IP address on this card and make sure your perimeter firewall (Linksys in my case) is configured to allow port 443 to this IP.

When you install TS Gateway the wizard will ask you to specify certificate, create new one or to choose one later. I didn't have one at the time of installation and decided to install certificate later. When TS Gateway is installed you can right-click on the server name and choose properties. For simple installations the "SSL Certificate" tab is of most importance as it will allow you to choose or replace certificates. Without certificate TS gateway cannot function. The following screenshot shows my certificate issued from my own CA. As I wrote before it is very important to make sure that certificate name (shown in Issued to: field) is the name you specify in the Remote Desktop connection client, if they don't match you won't be able to connect.

During installation wizard you'll be asked to configure 2 polices required for TS Gateway:

Connection Authorization Policies
Resource Authorization Policies

Connection Authorization Policy (TS CAP) allows you to specify the users who can connect to this TS Gateway server. The configuration is fairly simple and straightforward. You'd specify the groups or users who can connect to this TS Gateway server. Interesting granularity here is that you can specify the type of authentication will be supported by this TS CAP - Password and/or Smart Card. So if you have issued Smart Cards to your employees you can create policy that only allows Smart Card authentication into the TS Gateway server - very secure mechanism for remote authentication. Here is the shot of the TS CAP requirements.

Device Redirection tab can be useful in controlling who can redirect what from the TS server to their client PC.

The second policy that must be configured is the TS RAP which allows to specify the network resources that users can connect to remotely through this TS Gateway server. During configuration or later you can choose which computers you be able to access or just provide a blank policy that will allow connection to any target computer.

All in all , it is easy to configure a single server TS Gateway to allow access to your internal network.

Windows Server 2008 Terminal Services gateway #3

lezine — Thu, 28 Jun 2007 02:50:00 GMT

Client Side Configuration to access remote TS Server via TS Gateway

Windows Vista Remote Desktop Connection client has new option under Advanced Tab - "Connect from anywhere"

If you click on the Settings button it will allow to specify the TS Gateway server:

Server name that you type here must resolve to the Public IP address on your firewall and it must match the name on the certificate installed on the TS Gateway.

And finally what name are you going to specify for the target server that you are actually trying to access? It might be confusing at first but the IP must be the actual IP of the target server and it must be accessible from the TS Gateway server. You are not connecting to this IP directly, TS Gateway server connects to it. So we put the actual private IP of my Domain Controller, it will look like that:

OK, but what if I have Windows XP and not Vista? If you open Remote Desktop Connection and look under advanced tab you won't see Connect from anywhere configuration button. No problem, just go to the Windows Update site and under optional updates you'll find new version for Remote Desktop Connection client. Just install it and you are in business.

Windows Server 2008 Terminal Services Gateway #2

lezine — Wed, 27 Jun 2007 03:49:00 GMT

Configuration of the Terminal Services Gateway is fairly straightforward. The following diagram shows the simplified configuration of how I configured it to get access to my home lab.

Windows 2008 provides wizards for all of it different components and the configuration of Terminal Services Gateway is probably the easiest in the entire solution. The most difficulty most people will encounter will be with acquiring SSL certificate for TS Gateway. You have a few choices here:

1. Get this certificate from one of the commercial CAs.

2. Implement your own PKI (like in my lab)

3. TS Gateway can issue self signed certificate. This is usually used only for testing.

Another challenge is to provide name resolution to the public IP address assigned to your router by your Internet service provider. Usually this IP is assigned via DHCP and unless you pay extra money to have static IP it can change. In my experience, if you keep your router powered on 24/7 the IP address doesn’t change very frequently. So use one of the many Dynamic DNS free services to keep the DNS name up to date with current IP address or just update it manually if you find that the IP has changed.

The key point here is that the name on the certificate you install on the TS Gateway must match the FQDN assigned to Public IP address on your router

Next time we’ll talk about how to configure TS Gateway server.

Windows 2008 Terminal Services Gateway

lezine — Tue, 26 Jun 2007 02:42:00 GMT

One of the new exciting technologies that will be shipped with Windows 2008 Server is the Terminal Services Gateway. It is exciting not just because it will be used by many companies but because it can be used by many other technologists and make our life a little easier and more exciting.

I like to test new technologies and for my work sometimes I have to test or show different new and old products. I have 2 laptops, one is for my general day-day work with bunch of productivity applications and all required corporate tools, it runs Windows Vista. The second laptop is running Windows XP Pro with Windows Virtual Server 2005 R2 SP1. It acts as the host platform to run different virtual guest systems - DC, CA, ILM, SQL etc etc. I use to carry both laptops on my trips because I needed access to my virtual environment to test certain things or learn new product. As you imagine carrying 2 laptops is not fun, it is heavy, it is pain to go through the security checks at the airports, requires extra space at any table...

So I've been looking forward to a solution that will allow me to keep my virtual network back at my house and have full secure access to it from any network that I have to be - it is usually 90% of the time at my client, or on my BlackJack 3G Cingular network.

Of course I could always leave my virtual network back at my house and configure my Linksys router to path port 3389 to one of the systems. What is the problem with such solution? None of the corporate firewalls allow outbound port 3389. So I could not connect to my home based virtual network via normal TS session.

So thankfully now we have a solution for this type of problem - use Windows 2008 Terminal Services gateway. It works over SSL port 443. Is that port open on corporate firewalls? You betcha it is. Now you can connect to you home network from any location via normal SSL port.

Next time I’ll write how I configured Windows 2008 Server Terminal Services gateway to get into my home network virtually from any location.

Dmitrii

FBCA PKI cross-certification

lezine — Wed, 23 Aug 2006 17:26:00 GMT

For the last few months I've been helping large organization with their efforts to cross-certify their PKI infrastructure with Federal Bridge Certification Authority (FBCA). We had some technical challenges with interoperability between our systems which we were able to resolve fairly quickly with some help from product group guys and our own tireless testing. But at the end of the day the technical issues are really not that difficult comparing to the implementation of all required operational processes and ensuring that they are auditable by Audit Company. FBCA wants to know that cross-certifying agency is in full compliance with their Certificate Practice Statement (CPS). Auditors are the folks who actually provide report to FBCA about this compliance, and let me tell you, they do want to see working process (ie documentation, equipment, facilities, personnel etc) for every statement in your CPS. If you say in CPS that something is done certain way, well you better have actual process established, people trained etc on how to do that. Otherwise you'll fail the Audit and eventually might have problems with FBCA giving you a green light for issuing cross certificate keys.

In large organizations with multiple data centers, multiple departments, different contracting companies it can be fairly difficult to implement in short amount of time.

USB authentication tokens

lezine — Sat, 06 May 2006 19:45:00 GMT

I've been evaluating USB tokens for two factor authentication for one of my current projects, I've got 3 of them for evaluation: Cryptoken, Axalto e-gate token and Omnikey 6121 token. The basic requirement is to allow VPN authentication into POC solution over the Internet. We used middleware from Raak Technologies to manage the tokens. All three work as advertised and provide two-factor authentication. Each has its own little quirks that might make a difference if it will be chosen for the current solution.

Cryptoken looks like a little silver bullet, it is very small and very sturdy, I think it can survive on the key chain and not break for at least couple years. Axalto token probably was the least durable one, it is a little bigger than Cryptoken, easier to hold and pull out from the USB port. Omnikey 6121 is the longest token, but it appears to be more sturdy than Axalto token. Axalto token and Omnikey both have SIM cards that were taken off from the Smart Card and inserted into the token. You can replace the SIM card in the token - token basically acts as USB smart card reader.

Cryptoken and OmniKey 6121 require the same USB drivers and Axalto had its own set of drivers. All of them work with Raak middleware.

One of the challenges with Cryptoken is that the default driver doesn't allow reinsertion of the token. If you take the token out from USB port, insert it back and try to access it you'll get error message. To fix this problem you need to reboot PC or install a static driver that will allow reinsertion of the token.

Axalto token didn't have the above problem, it just works.

Cryptoken is probably about 2-3 times faster than Axalto token, it has build in chip that processes all operations in the token, while Axalto has to rely on the drivers and processing speed of OS. Of course the speed advantage comes with price, Cryptoken almost as twice as expensive as Axalto e-gate USB token.

Overall, they all work and my customer will have to evaluate them and decide which one to use after using them with our POC.