“The execution of scripts is disabled on this system” … How to run your own PowerShell scripts

So you’re picking up PowerShell scripting, are you?
As a first test, you create a little, never fail “hello world” script and launch it from within a PowerShell, but instead of seeing “Hello World” you see this:
File C:\scripts\test.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-
help about_signing" for more details.
At line:1 char:19
+ c:\scripts\test.ps1 <<<<

What the hell?? Yep, that’s right: by default only digitally signed scripts can be run from within PowerShell. Luckily, this can be remedied fairly easily.

If you launch the command Get-ExecutionPolicy you will see that the default policy is set to Restricted, basically creating your problem.

Now we can change that value to 5 different settings:
1. Restricted: no scripts will be executed
2. Unrestricted: all scripts will be executed
3. RemoteSigned: all scripts you created yourself will be run, all scripts downloaded from the internet will need to be signed by a trusted publisher
4. AllSigned: all scripts, including your own, will need to be signed by a trusted publisher
5. Default: = Restricted (unless you change the default value to something else)

OK, so now that we know that we can change the policy by simply typing Set-ExecutionPolicy RemoteSigned.

And that’s it! Your scripts can be run. I’ll be posting soon about how to set up your own “trusted publisher” so that we can secure our PowerShell environment as much as possible.

Have fun!

Infrastructure Planning & Design (IPD)

This weekend I've found a collection of documents on the Microsoft download pages: IPD.zip

It holds a whole list of documents, defided per technology, in which they go over the design processes:
- Windows Server 2008 File Services
- Selecting the Right NAP Architecture
- Windows Server 2008 Active Directory Domain Services
- ...

The series is a collection of documents that leads the reader through a sequence of core decision points to design an infrastructure for Microsoft products. It also provides a means to validate design decisions with the business to ensure that the solution meets the requirements for both business and infrastructure stakeholders..

Very interesting reading, for whoever is interested ...

Configuring IPsec NAP (Network Address Protection) - Part 4: Testing with a NAP client

Now that our NAP has been configured, we can start playing around with a NAP client.
In the following post I’ve logged on with an administrator account on a Vista client that is part of the domain krva.local.

Test 1: Log on to the Vista client with an administrator account and open a command screen. In the cmd box, type netsh nap client show grouppolicy. You should check for the following:

Test 2: Open a command screen and in the cmd box, type netsh nap client show state. You should see something like this:

Test 3: Verify that you have the required certificate, via MMC  Certificates  Local computer. You should see something like this:

Test 4: Verify that the Network Address Protection Agent has been started as a service

Test 5: Turn off your firewall. You should quickly see a message saying that your machine is not compliant after which the client will be auto-remedied and the firewall enabled. If you missed it, you can always request the status via the command napstat.

That’s pretty much it for now.
Of course, there are LOTS more things about NAP and possible errors you might encounter during the installation and configuration of it. Two tools you will definitely need during the troubleshooting of NAP are the NAP server events and the NAP client events.
They can be found in the event viewer under \Custom Views\Server Roles\Network Policy and Access Services (for the server) and \Applications and Services Logs\Microsoft\Windows\Network Access Protection\Operational (for the client).

Everything is correctly configured, but still your NAP clients are not being enforced? Check this first: are all systems involved activated?

NAP WILL ONLY FUNCTION IF YOUR SERVERS & CLIENTS ARE ACTIVATED!!

Enjoy!

Network Address Protection (NAP) posts:
IPsec NAP: Network Address Protection in Server 2008

Configuring IPsec NAP (Network Address Protection) - Part 1: Certificates

Configuring IPsec NAP (Network Address Protection) - Part 2: Installation of the NPS (Network Policy Server)

Configuring IPsec NAP (Network Address Protection) - Part 3: Configuring the NPS as NAP HRA (Health Registration Authority)

Configuring IPsec NAP (Network Address Protection) - Part 3: Configuring the NPS as NAP HRA (Health Registration Authority)

The bulk of the work is done by now. Now all that is left to do is configure our newly configured NPS and a NAP Health Policy Server.

The components of the NPS to configure are: System Health Validators, Health Policies, Network Policies, Connection Request Policies, RADIUS Clients and Servers and Remediation Server Groups, as indicated in the screen shot.

To configure these components I'm just going to take the easy way and use the configuration wizard.

Step 1: NAP wizard: launch the wizard by clicking on Configure NAP in the details pane of the NPS.

Now in the wizard, choose the following uptions:
a) select IPsec with Health Registration Authority (HRA) and give it a name
b) no Radius clients are being added, since the HRA is installed on the NAP Health Policy Server
c) we are going to apply to policy to all users, so we don't need to add any machine groups
d) make sure the Windows Security Health Validator and Enable auto-remediation of client computers are selected
e) Finish the wizard

Step 2: Configure the SHV (System Health Validators): By default, the WSHV is configured to require firewall, virus protection, spyware protection, and automatic updating. You can easily change this in the Properties of the SHV.

Step 3: Configure a GPO for the NAP client settings: now we can start enforcing specific client computers to apply to our NAP. To do this, create a new GPO and define the following settings:
a) Computer Configuration/Policies/Windows Settings/Security Settings/System Services/Network Access Protection Agent --> Define the policy: Automatic
b) Computer Configuration/Policies/Windows Settings/Security Settings/Network Access Protection/NAP Client Configuration/Enforcement Clients --> Enable IPsec Relying Party
c) Computer Configuration/Policies/Windows Settings/Security Settings/Network Access Protection/NAP Client Configuration/Health Registration Settings/Trusted Server Groups --> New "Trusted HRA Servers" --> Add URL "Https://NPS.Test.local/domainhra/hcsrvext.dll" --> Finish
d) Computer Configuration/Policies/Windows Settings/Security Settings/Network Access Protection/NAP Client Configuration --> right click and choose Apply

e) Computer Configuration\Policies\Administrative Templates\Windows Components\Security Center --> Enable Turn on Security Center (Domain PCs only)
f) close the GPO editor
g) go to the Security Filtering of the GPO and Remove the Authenticated Users and Add the security group created earlier. In my case, that would be GS_NAP_ClientPCs.

And there you have it, IPsec NAP is installed, configured and ready to be used. In my last post about IPsec NAP I'll be using a Vista client to try and connect to the secure network section as an example.

Network Address Protection (NAP) posts:
IPsec NAP: Network Address Protection in Server 2008

Configuring IPsec NAP (Network Address Protection) - Part 1: Certificates

Configuring IPsec NAP (Network Address Protection) - Part 2: Installation of the NPS (Network Policy Server)

Configuring IPsec NAP (Network Address Protection) - Part 4: Testing with a NAP client

Configuring IPsec NAP (Network Address Protection) - Part 2: Installation of the NPS (Network Policy Server)

Now that we have our CA installed in the domain, we can configure a member server to act as a Network Protection Server. To do so, several steps will have to be followed again.

Step 1: Install and configure the NPS: In my case, that would mean the “NPS.test.local” machine: Install WS08, configure the TCP/IP properties, join to the domain: I don’t suppose this will cause too many problems

Step 2: Exemption group: since the NPS needs to be able to communicate immediately with all computers on the network, it needs to have a health certificate (without any questions asked :)), so we need to add the computer account to the exemption group created earlier. In my case that would be NPS.test.local --> GS_NAP_ClientPCs_Exemption. Then restart the NPS server

Step 3: Computer certificate: to be able to install the NAP server roles, the computer already needs to have a personal computer certificate. In a MMC add the certificates of the local computer, request and enroll a new certificate (computer check box only!).

Step 4: Install NPS, HRA and CA: now we can install the NAP server roles
4a CS: in the server roles section, select Active Directory Certificate Services and Network Policy and Access Services, then choose Health Registration Authority, and in the next screen select Install a local CA.

OK, now this is important, select in the wizard still, select No, allow anonymous requests for health certificates. This way, computers in a workgroup will be auto-enroleld with health certificates, otherwise they can't be given the certificate automatically! After that, choose to use the existing certificate to close of the NPS section of the wizard.

Next, we get to the CS part, here select a Standalone CA, then Subordinate CA, then Create a new private key, and Configure the private key and give a clear common name to your CA.

Since this is a subCA, we will have to send the certificate request to the root CA.

No other settings have to be configured in the wizard, so proceed to the Install section and verify that the installation was successful.
NOTE: the failure of the HRA section is normal, it will be configured with the correct CA settings in the next steps.

4b: GPMC: Install the Group Policy Management Console via the server Features.

4c: Configure the subCA: now that the Certificate Services are installed we can configure them. Open the CA console and open the Properties of the subCA. On the tab Policy Module, open the Properties and select Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate. As indicated by the server, stop and restart the CA service.

4d: Configure the CA on Health Registration Authority
Open the CA in the HRA console of the server manager, select to Add Certification Authority and browse to the subCA.

Next, open the Properties of the Certification Authority and verify that the settings are as indicated in the screenshot.

That's it for the installation of the NPS itself. In the next post, we'll be configuring the NPS as a NAP Health Policy Server. But the biggest part of the job is done now. As you can see, no rocket science.

Network Address Protection (NAP) posts:
IPsec NAP: Network Address Protection in Server 2008

Configuring IPsec NAP (Network Address Protection) - Part 1: Certificates

Configuring IPsec NAP (Network Address Protection) - Part 3: Configuring the NPS as NAP HRA (Health Registration Authority)

Configuring IPsec NAP (Network Address Protection) - Part 4: Testing with a NAP client

Configuring IPsec NAP (Network Address Protection) - Part 1: Certificates

OK, so in my last post I’ve posted a brief summary of the IPSec NAP basics and the involved processes.
Now I’ll be doing the same for the actual installation of the Network Address Protection infrastructure. I’m not including to many actions paths with a huge number of print screens, because it’s pretty self-explanatory when you know what steps to follow. It benefits the clearity of the post which make the configuration easier.
Although it seems complicated, and yes, you do need to do quite a bit of stuff, it actually isn’t all that hard to do.

So let’s do this again step by step. But first I’ll show you my setup.

Step 1: Install and configure the DC: in my case, that would mean the “DC.test.local” machine: Install WS08, configure the TCP/IP properties, promote to DC and configure DNS: I don’t suppose this will cause too many problems

Step 2: Install the CA: also this is still pretty straightforward

Step 3: Create the required security groups: see above

Step 4: Installation and configuration of the CA
4a: Create a certificate template by copying an existing certificate template, making the changes as indicated in the print screen and publish it in AD (Tabs: Extension & Security)


4b: Publish the created certificate: via “Certificate Template to Issue”

Step 5: Enable the Auto-enroll policy in the Default Domain GPO: see print screen

In my next post, we'll go over the installation of the NPS.

Network Address Protection (NAP) posts:
IPsec NAP: Network Address Protection in Server 2008

Configuring IPsec NAP (Network Address Protection) - Part 2: Installation of the NPS (Network Policy Server)

Configuring IPsec NAP (Network Address Protection) - Part 3: Configuring the NPS as NAP HRA (Health Registration Authority)

Configuring IPsec NAP (Network Address Protection) - Part 4: Testing with a NAP client

IPsec NAP: Network Address Protection in Server 2008

Let’s do some napping. Although (unfortunately) not the kind of napping you do in your seat in front of the TV.

I guess this is one of the coolest new features that comes with Server 2008. Before, no matter how secure you made your network from the outside, if a computer brought in, by a consultant for example, had a virus and connected it to the network, the whole thing could get infected.
Now with Network Address Protection (NAP) it is possible to elimate, or at least seriously reduce this threat.

I think that by now we’ve all seen lots of examples of DHCP NAP Enforcements. Instead I’d like to take a look at the most interesting kind of Network Address Protection: IPsec NAP.

A short summary of theorie of IPsec NAP:
1. by implementing IPsec NAP you divide your physical network into 3 logical networks: secure, boundary and restricted network.
2. A computer can be member of only one network at any time, depending on the health certificate it has
3. Non-compliant computers remain isolated until they are remedied.

Types of logical networks:
1. Secure: computers that have health certificates and require them as well on incoming communication attempts
2. Boundary: computers that have health certificates but DO NOT require them on incming communication attemps
3. Restricted: computers that do not have a health certificate


The involved NAP processes:
1. Policy validation: System Health Validators (SHV’s) analyze the health status of a computer
2. NAP enforcement and network restriction: limit network access of noncompliant computers
3. Remediation: noncompliant computers on the restricted network can access a remediation server to meet the current health requirements.
4. Ongoing monitoring to ensure compliance: enforce health compliance on computers that already have connection to the secure network

Unfortunately, IPsec NAP can only be implemented on NAP-capable computers: Windows Server 2008, Vista & XP SP3 clients. This is because the Windows Security Health Validator (WSHV) and Windows Security Health Agent (WSHA) are used to enforce the IPsec NAP.
Of course, you can choose to allow non NAP-capable computers access to the secure part of the network.

Also, and this is very important for test setups:

NAP WILL ONLY FUNCTION IF YOUR SERVERS AND CLIENTS ARE ACTIVATED!!

In my next post, I’ll install a IPsec NAP policy in my test environment and include a step-by-step guide here.

Network Address Protection (NAP) posts:
Configuring IPsec NAP (Network Address Protection) - Part 1: Certificates

Configuring IPsec NAP (Network Address Protection) - Part 2: Installation of the NPS (Network Policy Server)

Configuring IPsec NAP (Network Address Protection) - Part 3: Configuring the NPS as NAP HRA (Health Registration Authority)

Configuring IPsec NAP (Network Address Protection) - Part 4: Testing with a NAP client

Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 6: Creating the federation trust on both sides

OK, last step. Everything has been configured in both domains. All that is left to do is "trusting" the partners by exporting and importing the created policies.

STEP 6: FS - Creating both sides of the federation trust
To do this, we have to perform 5 simple steps: export the policy from the account domain, import the policy in the resource domain, create the claim mapping in the resource domain, export the partner policy in the resource domain and import that policy in the account domain.

A) Export the Trust policy (Account domain)
1. Open Active Directory Federation Services and right-click the Trust Policy to Export Basic Partner Policy and safe it to any location.

2. E-mail the XML file to the administrator of the Resource domain

B) Import the Trust policy (Resource domain)
1. Open Active Directory Federation Services and browse to Trust Policy --> Partner Organizations and right click Account Partners to add a new Account Partner.

2. In the wizard, browse to the XML file you received from the partner and check if the details displayed are correct.

3. Then, select to Use the verification certificate in the import policy file before continuing.
4. If you are setting up FS between 2 forests that do not have a trust configured between them, select Federated Web SSO and click Next.
5. In the Identity claims option, select UPN claim and E-mail claim, after which you provide DNS suffixes and Enable this account partner.

C) Create the claim mapping (Resource domain)
1. Open Active Directory Federation Services and browse to Trust Policy --> Partner Organizations --> Account Partners and right-click the partner to add a new Incoming Group Claim Mapping.

2. Enter a name and make sure you select the correct organization group chain (in this case, there is only one)

D) Export the Partner policy (Resource domain)
1. Open Active Directory Federation Services and browse to Trust Policy --> Partner Organizations --> Account Partners and right-click the partner to Export Partner Policy and safe it to any location.
2. E-mail the XML file to the administrator of the Resource domain

E) Import the Partner policy (Account domain)
1. Open Active Directory Federation Services and browse to Trust Policy --> Partner Organizations and right click Resource Partners to add a new Resource Partner.

2. In the wizard, browse to the XML file you received from the partner and check if the details displayed are correct.

3. If you are setting up FS between 2 forests that do not have a trust configured between them, select Federated Web SSO and click Next.
4. In the Identity claims option, select UPN claim and E-mail claim, and verify that the DNS suffixes are adding the DNS suffix of the Account Domain.

5. On the Map Claim Transformations page, under Mapping select the ClaimApp Claim (TEST in my case), then click Next and select to Enable this resource partner.


There, that’s it. As promised, it was quite a long way. But now that it's working, it feels pretty good doing stuff that not too many other people do, am I right? :)

If you are having problems, to troubleshoot check that:
1. the client PC has the DNS IP-adresses of the DNS servers in both domains configured
2. the FS servers have been added to the trusted sites of the local intranet in your internet explorer
3. if you are setting this up in a test environment, make sure the routing between both domains is working.


Federation Services setup posts:
1. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 1: Overview and installation
2. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 2: Configure IIS to use SSL on the FS servers
3. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 3: Configure the FS certificates
4. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 4: Configuring the FS server in the Account domain
5. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 5: Configuring the FS server in the Resource domain

Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 5: Configuring the FS server in the Resource domain

In my last post, we configured the FS for the account domain. Now let's complete the FS setup by configuring the FS in the resource domain.

STEP 5: FS - Configuring the Federation Servers (Resource domain)
To set up the Federarion Services in a resource domain, you need to perform four steps: trust policy, group claim, the infamous account store configuration & configuring the claims-aware application.

A) Trust policy configuration
1. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 4: Configuring the FS server in the Account domain

B) Creating the group claim for the claims-aware application
1. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 4: Configuring the FS server in the Account domain

C) Creating the AD DS account store
1. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 4: Configuring the FS server in the Account domain

D) Configuring a claims-aware application
Here it starts getting different. Since we don't have the security group in this domain, we can't simply add it here. Instead, we add a claims-aware application:
1. Open Active Directory Federation Services and browse to Trust Policy --> My Organization and right click Applications to add a new Application.

2. In the Wizard, choose Claims-aware application, then enter a name and in the URL point to the application you created earlier.

3. Select User principal name (UPN) as a Accepted Identity Claim and Enable the application.


Federation Services setup posts:
1. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 1: Overview and installation
2. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 2: Configure IIS to use SSL on the FS servers
3. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 3: Configure the FS certificates
4. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 4: Configuring the FS server in the Account domain
6. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 6: Creating the federation trust on both sides

Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 4: Configuring the FS server in the Account domain

In my last post, we created and imported our necessary certificates. Quite a bit of work, but when you think about it, pretty straightforward.

Now that we have our domains in order, our FS installed and our certificates out of the way, let's configure the Federation Services.

STEP 4: FS - Configuring the Federation Servers (Account domain)
To set up the Federarion Services in a domain, you need to perform three steps: trust policy, group claim & infamous account store configuration.

A) Trust policy configuration
1. Open the Active Directory Federation Services and open the Properties of the Trust Policy
2. In the Federation Service URI, type urn:federation: (case sensitive)
3. In the Federation Service URL, type https://.FQDN/adfs/ls

4. Then add a name in the Display Name tab

B) Creating the group claim for the claims-aware application
1. Open the Active Directory Federation Services and browse to Trust Policy --> My Organization --> Organization Claims and create a new Organization Claim.

2. Enter a name and make sure the Group Claim is selected.

C) Creating the AD DS account store
1. Open the Active Directory Federation Services and browse to Trust Policy --> My Organization --> Account Stores and create a new Account Store.

2. In the wizard, choose for Active Directory Domain Services and make sure the account store is enabled
3. Now the Active Directory object has appeared, which we right click and choose to add a new Group Claim Extraction

4. Enter the name of the security group to which you want to map the account store.


That's it, now we are going do the same for the resource domain. See my next (and last) post on this topic.


Federation Services setup posts:
1. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 1: Overview and installation
2. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 2: Configure IIS to use SSL on the FS servers
3. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 3: Configure the FS certificates
5. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 5: Configuring the FS server in the Resource domain
6. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 6: Creating the federation trust on both sides

Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 3: Configure the FS certificates

In my last post, I explained how to configure your IIS to require SSL and how to install the needed FS Claims-aware agent.
Now, we need to configure our certificates.

STEP 3: FS - Creating, Exporting & Importing Certificates (Resource domain)
A) Creating the certificate (self-signed)
1. Open the IIS Manager and open the Server certificates on the server properties center panel
2. Here, under Actions click Create Self-signed certificate and give it a recognizable name.

B) Export the server authentication certificate to a file (Resource domain)
So that successful communication between the FS server and web server can occur, the web server must first trust the root of the FS server.
1. Open the IIS manager and double click on the Server Certificates
2. There select the FS server of the domain (here server3.test.local) and click Export.
3. Specify a certificate name and password, then click OK.

C) Import the certicate on the web server (Resource domain)
Now, the file that we created by exporting the certificate on the FS server can be imported on the web server.
1. Open a MMC window and add Certificates
2. Choose for Computer account -> Local computer and click Finish.
3. Go to the Trusted Root Certificate Authorities, right click and select Import under "All Tasks"

4. Browse to the certificate pfx file, created above and provide the password
5. On the Certificate Store page, click Place all certificates in the following store, and then click Next.

6. You should get a message: The import was successful after which you can see the certificate added in the mmc.

D) Export the token-signing certificate (Account domain)
The token-signing certificate will be used later to set up to Account Partner. For that, it will be imported to the Resource domain later on.
1. Open the Active Directory Federation Services and choose Properties on the Federation Service.
2. On the Details tab, click Copy to File.

3. In the wizard, on the Export Private Key choose No, do not export the private key
4. Then in the wizard, on the Export File Format, choose DER encoded binary X.509 (.CER)
5. Lastly, choose a file to export to and finish the wizard

There, that's it for this post. OK, it's quite a lot, but at least it very straightforward. It's the configuration of the FS were the magic is. That's for my next posts ...


Federation Services setup posts:
1. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 1: Overview and installation
2. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 2: Configure IIS to use SSL on the FS servers
4. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 4: Configuring the FS server in the Account domain
5. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 5: Configuring the FS server in the Resource domain
6. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 6: Creating the federation trust on both sides

Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 2: Configure IIS to use SSL on the FS servers

In my previous post, I explained my Federation Services setup and installed the FS roles on the servers in both domains.
Now, we'll configure IIS to use SSL on the FS servers.

STEP 2: FS - Configuring IIS on the webser (Resource domain)
A) Require SSL on both FS servers
1. on the web server open the IIS console
2. go to the Default Web Site and located the SSL settings.
3. choose Require SSL and for the client certificates choose Accept.

B) Certificate configuration of the IIS
1. open the IIS manager and browse to the Default Web Site.
2. Add a site binding in the Site Bingings action pane
3. Choose HTTPS as type and browse the certicate you created earlier for the FS

C) FS Web Agent
Next, we need to install the FS Web Agent, which makes you web server "claims aware"
1. open the Server Manager and add go to the Active Directory Federation Services role,
2. here click Add role Services and add the Claims-aware Agent. (if you have a seperate webserver (and for production I hope you do) you do the same but of course you go in via Add roles)

D) Creating a claims-aware application
Last in this post, we'll create a small default application as an example.
1. open the IIS manager and browse to the Default Web Site, right click it and choose Add Application.

2. choose an application name and select Classic .NET AppPool in the drop-down menu
3. point to the C:\Inetpub\wwwroot folder and create a seperate folder (do not use capitals for creating this folder)
4. Create the three files that make up the sample claims-aware application by using the procedures in Creating the Sample Claims-Aware Application.

That's it for this post, in the next post, we'll handle our certificates (creating, exporting and importing).


Federation Services setup posts:
1. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 1: Overview and installation
3. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 3: Configure the FS certificates
4. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 4: Configuring the FS server in the Account domain
5. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 5: Configuring the FS server in the Resource domain
6. Setting up Federation Services (FS) in a Windows 2008 (WS08) environment: Part 6: Creating the federation trust on both sides