Dmitrii blog

Claim Based Authentication IV

2009-10-05T05:14:56Z

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

2009-10-03T17:06:46Z

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

2009-10-02T19:07:57Z

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

2009-10-02T15:39:19Z

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.

Deleting old keys on Smart Card

2009-03-07T18:19:05Z

If you use your smart card a lot and issue many certificates to your Smart Card there will be a moment when the storage on the card will get too small to accommodate new certificates. In most cases your IT department might ask you to send your card back for replacement or they will tell you to issue replacement certificates while reusing the same private key – too keep the size of new certificates on the card to a minimum.

But it is fairly easy to delete old certificates from your card and free up space on it.

Do delete certificate on Smart Card use the following command:

certutil –delkey –csp "Microsoft Base Smart Card Crypto Provider" KeyContainerName

Of course you need to know KeyContainerName before you can run above command.

To find the right container name on the card you can run the following command:

certutil –key –csp "Microsoft Base Smart Card Crypto Provider"

This command will show container names, but it will not show associated certificates with containers.

To list all certificates on the card use the following command:

certutil –scinfo

Make sure to find container corresponding to expired certificate that you want to remove from Smart Card. If you specify wrong container it will delete valid certificate and your card will become useless and then you’ll definitively have to contact help desk.

Here is an example of the “certutil –key –csp "Microsoft Base Smart Card Crypto Provider"” output:

C:\>certutil -key -csp "Microsoft base Smart Card Crypto Provider"

Microsoft base Smart Card Crypto Provider:

484fdef3-4106-40aa-b060-73c36f70db7b

AT_KEYEXCHANGE

c364101a-df8f-49f1-b71d-13c67ec6032f

AT_KEYEXCHANGE

da73e850-19f7-454f-a4e9-7ceb15aa4b0d

AT_KEYEXCHANGE

le-S/MIMESignatureSmartcard-5-05811

AT_SIGNATURE

le-MSSmartcardUser-02c869ab-c62d--61905 [Default Container]

AT_KEYEXCHANGE

CertUtil: -key command completed successfully.

Provisioning Computers with ILM ‘2’

2009-02-16T02:13:51Z

In previous post I talked about different ways to provide Registration Authority (RA) functionality for device certificates. The 4th method was using ILM ‘2’ workflow functionality to control group membership. A few days ago I decided to setup a demonstration on how it actually can be done. I used ILM ‘2’ RC0 software which at the moment of this writing can be downloaded from this location http://technet.microsoft.com/en-us/evalcenter/cc872861.aspx. I used preinstalled VHD image to speed up my testing. Keep in mind that ILM ‘2’ only comes as 64 bit application and available VHD image is build for Hyper-V server.

There is good walkthrough on how to create computer object in ILM ‘2’ and how to join this object to the security group, check Bobby and Nima's ILM Blog blog for more information http://blogs.technet.com/doittoit/archive/2008/06/25/extending-ilm-2-to-manage-and-provision-computer-objects.aspx

So if you follow instructions in this blog it will walk you through all major steps required to configure ILM schema, modify ILMMA and ADMA, and create all required rules in ILM ‘2’ for object creation and workflow approval.

After going through all configuration steps I was able to provision computer object to AD, it was shown in my target OU with the name I specified in ILM. I was happy. Then I came to the point of joining actual computer to the provisioned computer object. It didn’t work, while joining computer to AD it would create another object and it would not join it to already existing computer object. So I started troubleshooting it and trying to figure out what was going on.

Obviously the first thing I did is opened computer object to see what is looks like. First discovery was that “Computer name pre-windows 2000” was some long pre-generated string, that looked like this - $C41000-7T6LLPIABSAP. “Computer name pre-windows 2000” is actually samAccountName attribute on the computer object. So ILM was creating computer object in AD with right DN name, but it was not populating samAccountName with the same name and let AD to auto-generate it for us. As you know that would be a problem. While my actual computer name was named “TestPC1” and it was showing in OU as TestPC1 (CN name), its samAccountName didn’t match the computer name. While joining it to AD it didn’t find the object with samAccountName matching computer name and created a new computer object. OK, I asked around and got suggestion that we need to flow samAccountName from ILM to AD. No problem, I added the following attribute flow:

After adding this attribute flow I created new computer in ILM, it showed up in AD, and its samAccountName was matching computer name. Great. Till I tried to join computer with that name to AD. Same problem, I was getting new computer object in AD and it was not joining to my object.

OK, this started to frustrate me. I tried to Reset computer object, it complained to me about password not being strong enough for the password policy. This was odd.

So I decided to compare computer object created via ADUC and computer object created with ILM. It is easy to do via ADSIEdit. I discovered that object type created by ILM was actually recognized by AD as User object, its userAccountControl attribute matched user object userAccountControl, not computer object. Very good. userAccountControl for computer object is 4128.

Back to ILM attribute flow, created another one that looked like this:

Created another computer account in ILM, it showed up in AD, I tried to Reset this object – no complains, looked at it in ADSIEdit, all attributes were computer object related. Last test, join computer to AD – it worked. Life is good.

So if you are trying to create computer object in AD via ILM ‘2’ I found that the following attribute flow will create the right computer object:

Registration Authority and Device Certificates

2009-01-26T03:24:09Z

Registration Authority (RA) in PKI implementations is used to authorize issuance of certificates to the certificate subscriber. Usually it is used with user certificates, especially if they are issued on the Smart Cards. In some implementations it is necessary to provide RA functionality for device certificates. Usually it is done with PKI implementations that are covered by the Certificate Policy (CP) that require a “human sponsor” for every device certificate issued in the organization. One such CP is U.S. Common Policy CP, specifically check out section 4.1.1.3.

Most organizations implement Microsoft CA and take advantage of the auto-enrollment functionality provided by MS CA and Windows platform. Windows XP and Vista, Windows Server 2003 and 2008 all can easily auto-enroll with certificates from Windows 2003 or 2008 Certificate Authority. While it is easily configured and target Windows devices just auto-enroll behind the scene with required certificates it does not satisfy the ‘human sponsor’ requirement specified by U.S. Common Policy CP.

There are a few ways to keep auto-enrollment functionality and provide Registration Authority for device certificates. Here I’ll list a few way to do it with Microsoft products, from simple RA to full featured Identity Management solutions. As time goes, I’ll provide details on how to implement each of these solutions in your customer environment.

One of the key questions to decide about auto-enrollment and approval workflow is where the “human sponsor” comes into play with any number of approvers and where or how it is triggered in the system to allow specific computer to auto-enroll with new certificate.

The “human sponsor” usually should be the system administrator who owns the desktop or server. This person can be the initiator of the process, approver and the final executioner. Some companies might want to separate those roles between more than one person and maybe automate some of them.

The technical part can be achieved in couple different ways as well. It might be decided to require approval of each certificate on the CA itself or we can handle approval by managing security group membership that have been granted auto-enroll permission. Adding computer object to a group will trigger auto-enrollment on that computer.

Now it is really up to the customer to decide how they want to execute it and what components they want to automate, how much audit and historical data they want to have etc.

Here are a few approaches to solve the “human sponsor” requirement with auto-enrollment functionality still intact.

1. Enrollment with manual approval workflow.

With this configuration server administrator would fill in form(s) asking to issue certificate to the installed system. The form(s) will go to the approving manager, get approved or denied. Approved form can be routed to the AD group manager who would find the computer object in AD and add it to the appropriate security group.

In this approach the “human sponsor” is the system administrator. His request is approved by another manager and the execution is done by another administrator. It provides good separation of powers and in my opinion satisfy the requirements of the US Common Policy CP.

On other hand this process can be very slow. It can take days, sometimes weeks. Things can get lost. Not the best way to accomplish desired result.

2. Automated enrollment with Computer Admin Acting as RA.

With this configuration server administrator will add the computer object to the desired security group. There is no forms to fill. Quick and easy.

In this approach the “human sponsor” is the system administrator, he also acts as approver and executioner of the final step. While it might be acceptable and satisfy the US Common Policy CP it might not satisfy some other requirements as it puts little checks on certificate issuance to devices.

3. Automated enrollment with MS CA Certificate Manager as RA.

With this configuration certificate template will be configured to require manager approval before certificate issuance. Server administrator will be required to add computer object to security group that is authorized for auto-enrollment.

In this approach the “human sponsor” is the system administrator. Computer will try to auto-enroll for certificate and its request will go into the Pending Requests folder. Certificate Manager will be required to approve or deny the request. After request is approved the subject computer will finish enrollment process and get the certificate.

One of the potential issues in this design is figure out how Certificate Manager would know if the request is legit or not.

4. Automated enrollment with ILM 2 Workflow, ISO Manager act as RA.

With this configuration server administrator would logon to ILM 2 and create a request to add computer object to the desired security group. The workflow will route request to the manager who approves the request (or denies). The approval will trigger ILM to add computer object to the desired group and eventually target computer will auto-enroll with certificate.

In this approach the ‘human sponsor” is the system administrator. manager is approver and ILM 2 is the executioner of the workflow tasks. ILM 2 can enforce group memberships and provide historical data on who and when request certificates and approved it. Of course you’ll need to implement ILM 2.

I’ll set this up later in the lab and provide more details on how it works.

5. Automated enrollment with CLM Workflow, ISO Manager act as RA.

With this approach use Certificate Lifecycle Manager (CLM) product. More on it later.

Old Certificates Identification and Removal

2009-01-16T17:35:00Z

Certificate renewal on Web sites can be a big nightmare, especially if you have hundreds of them and if you don’t know when they are going to expire. Also, sometime you have change the Issuing CA from one to another and finding out the certificate chain on multiple sites can be a time consuming process. Of course you can open each site with IE or some other browser and look at each cert and document it that way. There are couple approaches that can help with automation of this task.

The first one would be running a script on each web server. This script can collect information about all certificates installed and provide some intelligent reporting. The problems with this approach are multiple: web servers can be running different platforms, so the script that can easily run on Windows might not run on other web servers. Another problem would be to actually be able to find the actual servers to run the script and then the issue with rights to run the script on the target server.

Another approach we can take is to run script on central workstation and target each web site from it. Open the site that is protected with SSL certificate, read information from the certificate and log it into the output report. This way we really don’t care about web server platform, its physical location and other potential issues. Sounds like a much better approach.

So here is a little PowerShell script that can help you with identifying certificate expiration and certificate chain on the target web servers.

First, you need to get a list of all web sites that have been protected with SSL certificates. Put URLs for these sites into input file (in this example, I call it sslinput.txt) that our script will read:

Websites

securesite.domain1.com

securesite.domain2.com

securesite.domainX.com

Second, save the following script to the DiscoverSSL.PS1 file and run it from PowerShell command. The script will produce an output file (ssloutput.txt) with information about each certificate.

$webinputpath = "C:\sslinput.txt"

$outputpath = "C:\ssloutput.txt"

function Get-RemoteCertificate ($serverName,$port)

{

$client = New-Object System.Net.Sockets.tcpclient($serverName, $port)

$sslStream = New-Object System.Net.Security.SslStream($client.GetStream(),$false, $null,$null)

$sslStream.AuthenticateAsClient($serverName)

$remoteCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($sslstream.remoteCertificate)

Add-Content $outputpath "Certificate for $servername on port $port"

Add-Content $outputpath "Subject: $remoteCert.Subject"

if ($remoteCert.Verify() -eq $true) {Add-Content $outputpath "Revocation status: OK"} else { Add-Content $outputpath "Revocation status: REVOKED"}

Add-Content $outputpath ""

Add-Content $outputpath "---------------------------------------------------------------------------"

Add-Content $outputpath ""

$client.close()

}

import-csv $webinputpath | foreach-object {get-remoteCertificate -servername $_.websites -port 443}

Limitations

1. This script will not provide information on certificates if the computer running this script does not trust the Root CA chaining from the issued SSL certificate.

2. This script will not provide information on self issued certificates. See #1.

3. This script will not provide information on certificates if their common name does not match the input URL. It will not work if the input file provides IP addresses or DNS names that do not match the target certificate.

4. In all 3 cases the output file will be logged with error message indicating that script could not authenticate to the target SSL certificate.

Re-Revoking Certificates with Different Reason Code

2007-08-18T02:53:00Z

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!

Cool Windows 2008 posters

2007-07-19T16:27:00Z

cool posters for download, check it out:

http://www.microsoft.com/downloads/details.aspx?FamilyID=c2b9e44e-0bbd-47cb-bc09-b3d48be7f867&displaylang=en

TS Gateway #4

2007-07-02T00:38:00Z

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

2007-06-28T02:50:00Z

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

2007-06-27T03:49:00Z

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

2007-06-26T02:42:00Z

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

Dmitrii blog

Claim Based Authentication IV

Claims Based Authentication – Part III

Claims based Authentication – Part II

Claims based Authentication - Part I

Deleting old keys on Smart Card

Provisioning Computers with ILM ‘2’

Registration Authority and Device Certificates

1. Enrollment with manual approval workflow.

2. Automated enrollment with Computer Admin Acting as RA.

3. Automated enrollment with MS CA Certificate Manager as RA.

4. Automated enrollment with ILM 2 Workflow, ISO Manager act as RA.

5. Automated enrollment with CLM Workflow, ISO Manager act as RA.

Old Certificates Identification and Removal

More options with Re-Revocation solution

Re-Revoking Certificates with Different Reason Code

Cool Windows 2008 posters

TS Gateway #4

Windows Server 2008 Terminal Services gateway #3

Windows Server 2008 Terminal Services Gateway #2

Windows 2008 Terminal Services Gateway