This video looks at Claim Based/Identity Based systems using Active Directory Federation Services as an example. An example of a claim based system is where the user logs into a system like a web page using another system, for example a Facebook login.
Download the PDF handout
In this fictional example, it shows the key points to a Federation Service. Federation Services work by a user wanting to access a system which belongs to a 3rd party. In order to do this, the first party needs to provide something the 3rd party can check to ensure the person is allowed access. It is still up to the 3rd party if they will allow them access or not. The point is that business B can check that the employee is a valid employee without having to contact business A to check.
In this example, an Active Directory Federation Services model would work the following way.
1) The user contacts the web server in business B in order to obtain access to a service.
2) The web server rejects the request as the web server does not know who they are. The web server refers them to Federation Server in business B in order to get a claim in order to access the web server.
3) The user then contacts the Federation Server in the business B network.
4) The Federation Server does not know who the user is, so it says to get authorization first.
5) The user contacts the Federation Server in its DMZ and requests to be authenticated.
6) The Federation Server will pass the username and password the user provided to a Domain Controller.
7) The Domain Controller will respond back to the Federation Server that they have been authenticated.
8) The Federation Server will give the user a claim. This claim contains information indicating the user has been authenticated.
9) This claim is presented to the Federation Server in business B.
10) The Federation Server will accept the claim. Although not shown in this video, the Federation Server will often create a new claim that would be given to the user to grant them access services.
11) The user will use the claim with the web server.
12) The web server will accept the claim and connect to a file server.
13) The file server will give the information to the web server.
14) The web server will then present the information to the user.
In order to have authentication occur between two businesses using Active Directory, a trust relationship needs to be created between the two businesses. In order for this to occur, firewall changes need to made. An Active Directory trust is also connection based, which means a direct connection between the two businesses must also be present. If you want to allow services like file transfers you also need to make additional changes to the firewall. Companies often do not want to make changes to their firewall and do not want to establish direct permanent connections between different businesses.
Advantages of Federation Services
Federation Services does not require a connection style trust in order to work. It only requires a certificate to be exported and imported on the other side before the trust can be configured. Federation Services also uses standard HTTP and HTTPS protocols and thus these ports are most likely already open on the companies file firewall. Companies are more likely to agree to open these ports than open less commonly used ports. Federation Services uses standard protocols and thus can work with other systems. For example, a Windows based Federation Server can also work with a Linux based Federation Server.
Example Of Online Services
In this example, a mobile user requires access to Exchange Services stored in the cloud using Microsoft Outlook as the client.
1) The user contacts the online Exchange Server in the cloud.
2) The server responds back that it needs a claim in order to access the service.
3) The user contacts that Federation Server.
4) The Federation Server responds back saying it will not issue a claim until they have been given a claim showing they are allow access.
5) The user contacts the Federation Service on their network with their username and password. Any authentication system could be used here. Even a system that only requires the user to present an e-mail address could be used.
6) The Federation Server contacts a Domain Controller to authenticate the user.
7) The Domain Controller responds back to the Federation Server that the user has been authenticated.
8) The Federation Server gives a claim to the user.
9) The user then gives the claim to a Federation Server.
10) The Federation Server accepts the claim and presents the user with another claim that the user can use with the online server to access the Exchange service.
11) The user then presents this claim to the online server and is now able to access the Exchange service in the cloud.
The point to remember with claim based systems is that authentication is provided by a system that is separate from the system that is providing access. This means that the first system can add and remove users as required and thus indirectly be responsible for who has access.
A Federation Service uses standard web protocols and does not require a connection style trust. For this reason these ports may already be open on the firewall and thus is generally easier to get management approval. Federation Services require many systems to work together and thus may not be that easy to get up and working. Microsoft cloud based systems are well documented. Other Federation Services solutions are not as well documented and thus may be harder to set up. Lastly a claim contains user information and what they would like access to. They use certificates to make sure the data is secure. In later videos claims will be covered in more detail.
“Active Directory Federation Services Overview” http://technet.microsoft.com/en-us/library/hh831502.aspx
“Federated identity” http://en.wikipedia.org/wiki/Federated_identity
This video from ITFreeTraining will look at claims that are used with Federation Services. By the end of the video you will understand what are claims and what protocols are used with claims.
Download the PDF handout
A claim essentially is a statement made by one party about another party. This is provided by an Identity Provider. Services like Facebook are able to create a claim about a user which holds some information about the user. For example, the user can then use their Facebook login to access other sites. Let’s consider an example of a shopping center that allows free parking for those people that have travelled a long distance to shop there. In order to get their free parking, all they need to do is show their driver’s license which has their address on it. The identity provider in this case would be the institution that issues driver’s licenses. The user would be the person wanting free parking. The service would be the shopping center who has made the decision to allow free parking for people outside the area.
Claims are generally packaged inside a security token. This allows the details of the claim to be checked to ensure they have not been changed. When working with Federation Services you may hear the term security token and claim used interchangeable. Essentially they are referring to the claim which may be packaged in a security token.
In this example, a person is given a voucher to a cinema in order to obtain a movie ticket. The movie ticket can then be used to enter a cinema to see a movie. Federation Services often work in a simple way.
In some cases you will hear wording to the effect that a server consumes claims. When Federation Services are setup like this, the following generally happens. The Federation Server will issue a claim to the user. The user will then give this claim to another Federation Server. Once this Federation Server is able to verify that claim is valid, the Federation Server will destroy the claim and create a new claim. The new claim is free to change the information in the old claim and add to it. For example, it may add which servers the user is allowed to access. This kind of information is subject to change and thus the original server creating this claim does not know this information when the first claim is created.
There are a lot of different protocols that make Federation Services work. Federation Services is also very customizable so even though there are some key protocols to make the system work, depending on how it is configured will determine which protocols will be used. For example, there are a number of different protocols that can be used to create a security token.
In order for Federation Services to exchange information between different Federation Services there needs to be a common protocol between the systems. The WS-Trust protocol is designed to allow the Federation Services to communicate with each other and exchange information like security tokens. There are a number of different versions of the protocol so it is a matter of making sure that both sides are using the same protocol.
SAML (Security Assertion Markup Language)
SAML is one of the protocols that can be used to create security tokens. It is an open standard for authentication but can be used to create tokens. Once the token is created, it is transported to the other server using WS-Trust. It is possible to use other protocols however this one is the most common. What the server will accept and not accept is referred to as an endpoint.
If you open AD FS Management on a server that has Active Directory Federation Services installed and configured, this will show all the different types of connections that server can accept. To access EndPoints, expand services and then open the container EndPoints. This container shows all the EndPoints this server will accept. For example, if you select one and it says the type is WS-Trust 2005 and authentication type is Certificate, this EndPoint will only accept WS-Trust 2005 connections that use certificates. In order to use this server with another Federation Server, both Federation Servers must have the same end point configured in order to allow communication to occur.
Configuration information about the server is also available under Metadata. If you need to access the configuration information for the server you only need to open this URL in a web browser. This information can be saved to a file and read on the other server if required. If this information is not available, it can be manually entered in on the other server.
There are a lot of protocols that make Federation Services. The Web Service Description Language (WSDL) and Universal Description Discovery and Integration (UDDI) are low level protocols that are used with Federation Services. For this reason you may not come across these protocols directly as they are used with other protocols.
“Web Services Description Language” http://en.wikipedia.org/wiki/Web_Services_Description_Language
This video will look at the different Terminology that is used with Federation Services. This will give you a good indication of what components make up a Federation Service in Active Directory Federation Services and other Federation services.
Download the PDF handout
This video will look at 17 different Federation Services terms. They have been placed in a logically order to make it easier to understand.
Account Partner Organization
This contains the user accounts that will access the Federation Service. In some cases this may be a domain in other cases it may be a database or simply an e-mail address. The important point to remember is that these are the users that will access Federation Services. This will contain information like their usernames, password and other details about the user.
Resource Partner Organization
A resource partner organization contains the resources that are accessed by the Federation Service Users. Normally this will be external to the company, but in some cases may be on a DMZ of the company. A resource partner could also be in a cloud based application. For example MS Office products located in the cloud.
A Federation Trust is a trust between different parts of Federation Services. An example is the trust between the Account Partner Organization and Resource Partner Organization. The trust is not a connection style trust and thus when created does not require communication to happen over the trust. The trust does not require a direct connection between the two Federation Servers, however it is often simpler to have a connection between the two so that the Federation Server can obtain information that it requires in order to create the trust.
A claim is essentially a statement about a user. When the claim is created, it will need to be created with information required by the other side. This may include information about what services they require. This may also contain information about groups they are in. The Federation Server creating the claim needs to ensure all this information is put into the claim. The claim is essentially a file that is then transferred to the other party. In a lot of cases, the user may request the claim from their Federation Server and then present this claim to the Federation Server that is providing the service.
Claims Provider Trust
Active Directory Federation Services has two types of trusts that are used. The first trust is a Claims Provider Trust. A Claims Provider Trust accepts claims. So essentially this trust defines who and how the trust can be used.
Relying Party Trust
A Relying Party Trust is used to create claims. Once a claim is created it is supplied to a Claims Provider Trust. A Relying Party Trust is required in the account partner organization to create claims that will be used in the Resource Partner Organization. A relying party trust is also used to access resources. For example, if the Active Directory Federation Services needs to access an application or Domain Services.
A claims provider is an organization that provides claims for users. These claims are normally used by Claims Aware applications that can be in the domain, external domain or in the cloud.
This is a server that is running Federation Services. In the case of Windows this will be Active Directory Federation Services.
Account Federation Server
An Account Federation Server provides security tokens that contains claims. These are given to the user. In order to do this the account Federation Server must get this information from somewhere.
An attribute store contains information about the user. This can be stored in Active Directory Domain Services, SQL Server or Active Directory Light Weight Directory Services. This does not provide authentication. For example a Domain Controller could be used to authenticate the user and then the attribute store could be used to get additional information about the user. For example the attribute store may contain a picture of the user.
This is the configuration information for the Federation Server. When creating a trust, data is required about the other server in order to create the trust. This data can be entered in manually however this is time consuming to do. When creating the trust, you have the option to use the Metadata. This Metadata can be obtained through a direct connection between the two servers. If this is not available, the data can be exported and any method can be used to get the data from one server to the other server.
AD FS Configuration Database
This stores the configuration that is used by Active Directory Federation Services. This can be on SQL server or Windows Internal Database.
Primary Federation Server
This is the first server that is setup in a farm. It holds a read/write copy of the database. All the other servers in the farm contain a read only copy of the database. These servers needs to replicate changes to the read/write copy of the database.
This is a user that has been given a claim. The claim can then be used on another server to gain access to a resource.
A relying party is the organization that receives a claim. In most cases this will be the resource partner organization.
Resource Federation Server
This is a Federation Server in the resource partner organization that accepts claims. When a claim is presented to the server, the server will create a new claim and give this to the user. This claim contains information like what resources they are allowed to access.
This is any application that can accept claims to provide access to an application. For example MS Office is capable of accepting claims.
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 888-896
“Understanding Key Concepts Before You Deploy AD FS 2.0” http://technet.microsoft.com/en-us/library/ee913566(WS.10).aspx
“Federation trusts” http://technet.microsoft.com/en-us/library/cc738707(v=ws.10).aspx
“Understanding Application Types for AD FS Federation” http://technet.microsoft.com/en-us/library/cc772483.aspx
This video will look the different versions of Active Directory Federation Services. This includes which features are available in each one and which operating system you need in order to use these features.
Download the PDF handout
AD FS 3.0
AD FS 3.0 is included in Windows Server 2012 R2. You will not be able to run AD FS 3.0 unless you install or upgrade to Windows Server 2012 R2. AD FS 3.0 comes with a few new features
Workplace Join: This allows a mobile device to join the domain. It is simpler than joining a computer to the domain; however, it does not include all the same features as joining a computer to the domain. For example, group policy is not supported. When you add a device to the domain using Workplace Join, the device is registered in Active Directory so administrators have control over which devices are added and also can remove a device later on if they wanted. Workplace Join could also be used with OS’s like Windows 8.1. This allows a computer to access some Active Directory functions. This is useful for external contractors who need access to certain files, but the administrator does not want to add them to domain functions like a standard user would have.
Enhanced access control risk management tools: This is a collection of features that help secure AD FS clients. For example, it makes it easier to disable remote devices. It also allows features like making sure the users enter in a username and password when accessing certain applications.
No longer requires IIS: AD FS 3.0 no longer requires IIS to be installed. It is now a separate role and does not require additional roles in order to be installed.
UI support for SQL Server: User interface has the ability to configure SQL server. If you are using SQL server with Active Directory Federation Services this makes it easier to configure SQL Server.
Group Managed Service Account Support: Managed services account were already present in Windows, however they were difficult to set up. AD FS 3.0 allows a managed service account to be created in the install wizard to be used with Active Directory Federation Services. A managed service account password is controlled by Active Directory. The password is very long and complex and automatically changed at periodic intervals. Group managed service accounts are different from the regular managed service accounts in that they can be used on multiple servers quite easily.
AD FS 3.0 difference from other version
The component Federation Service Proxy no longer exists. Its functionality has been replaced by a different component called “Web Application Proxy”. This component is found in the Remote Access Role rather than Federation Service role. This role is also used by other services as well as Active Directory Federation Services.
In AD FS 3.0 the web agents have been removed. These provided compatibility between AD FS and other systems. If you upgrade to this version you need to ensure that you do not require these web agents.
AD FS 2.1/AD FS 2.0
AD FS 2.1 is included with Windows Server 2012. There are only very minor changes between it and 2.0. The most significant change is that it is included in the operating system rather than being an optional download.
AD FS 2.0 is available as a free download from Microsoft. It can be installed on Windows Server 2008 and Windows Server 2008 R2.
AD FS 2.1/AD FS 2.0 New Features
Web support across domains: This feature allows Active Directory Federation Services to be used across domains. This feature allows a user in a child domain to access AD FS in a different domain. The user could also access Federation Services while mobile.
Improved federation trust support: Trust support has been improved. This means that Active Directory Federation has better support for working with other non-Microsoft Federation Services.
Improved management interface: The management interface has been improved making it easier to use and manage Federation Services.
AD FS 2.1/AD FS 2.0 Remove Features
AD LDS account store: In order for a user to use Active Directory Federation Services they need to be authenticated. Normally this will be done by a Domain Controller. Previously this could also have been done using an Active Directory Lightweight Directory Store. AD LDS can still be used as an attribute store, which means that it can be used to store data that Active Directory Federation Services will use, however it cannot be used for authentication.
Windows NT Token-based web agent: This is a web agent that allows the old Windows NT tokens to be used. This is no longer supported.
AD FS upgrade from 1.0: If you are using AD FS 1.0, an in-place upgrade is supported to AD FS 2.0. The upgrade is not supported to AD FS 2.0 and there is no upgrade path from AD FS 2.0 to AD FS 2.1
AD FS 1.1/AD FS 1.0
This is the first version of AD FS. It was available as a download for Windows Server 2003 R2 and included in Windows Server 2008 and Windows Server 2008 R2. It provides basic single sign on. It does have some compatibility problems with other non-Microsoft Federation Services which was fixed in later versions.
“Active Directory Federation Services 2.0 RTW” http://www.microsoft.com/en-us/download/details.aspx?id=10909
“Planning a Migration to AD FS 2.0” http://technet.microsoft.com/en-us/library/ff678044(v=ws.10).aspx
“Understanding Federation Design” http://technet.microsoft.com/en-us/library/cc753352.aspx
“Active Directory Federation Services Role” http://technet.microsoft.com/en-us/library/cc772313(v=ws.10).aspx
“First Impressions – AD FS and Windows Server 2012 R2 – Part I” http://blog.auth360.net/2013/09/13/first-impressions-ad-fs-and-windows-server-2012-r2-part-i/
“Samsung Knox enabled devices get Microsoft Workplace Join support” http://www.theinquirer.net/inquirer/news/2331546/samsung-knox-enabled-devices-get-microsoft-workplace-join-support
“Enhanced access control risk management tools” http://technet.microsoft.com/en-us/library/hh831502.aspx
“AD FS 2.0 and AD FS 1.x Interoperability” http://blogs.technet.com/b/askds/archive/2010/05/25/ad-fs-2-0-and-ad-fs-1-x-interoperability.aspx
“Features Removed or Deprecated in Windows Server 2012 R2” http://technet.microsoft.com/en-us/library/dn303411.aspx
“Overview of AD FS 2.0” http://technet.microsoft.com/en-us/library/gg274318.aspx
This video looks at the minimum requirements to install Active Directory Federation Services. Later videos will look at the process of installing Active Directory Federation Services.
Download the PDF handout
For Active Directory Federation Services 3.0 and below there are a number of common requirements. The server that you plan to install Active Directory Federation Services (AD FS) needs to be a member of the domain. If AD FS needs to be accessed from the internet, it is possible to put a proxy component in the DMZ and access AD FS indirectly that way.
AD FS also requires 3 certificates: an SSL certificate, a Token-Signing certificate and a Token decryption certificate. The SSL certificate needs to be created before the install. This will need to be trusted by the clients so it is recommend to use a trusted 3rd party or an internal CA hierarchy. It is possible to use a self-signed certificate, however self-signed certificates are generally only used in a test environment and there are a lot of additional steps in the install process in order to use a self-signed certificate. The Token-Signing and Token decryption certificates are created during the install and use self-signed certificates. It is possible for the administrator to create and use their own certificates if they want additional security.
Windows Server 2012/R2
If you are using Windows Server 2012 you will be running AD FS 2.1. Windows Server 2012 R2 runs AD FS 3.0. The install itself requires the Foundation, Essentials, Standard or Datacenter editions of Windows Server. On Windows Server 2012, IIS is required for AD FS. Version 3.0 that comes with Windows Server 2012 R2 does not require IIS to be installed. For the hardware, the minimum hardware requirements are quite low. RAM is listed as 1 Gigabyte, however for our use, Windows Server 2012 tends to run better with 2 Gigabytes or more RAM.
Windows Server 2008/R2
Windows Server 2008 and R2 both come with AD FS 1.1. Version 2.0 can be download and installed. In order to install AD FS, Windows Server needs to be running Enterprise or Datacenter. Also a number of additional components are required. These are IIS, ASP Net 2.0 and .NET Framework 2.0. The hardware requirements are quite low at a 133MHz CPU, 1 Gigabyte of RAM and 50 Gigabytes of drive space.
Windows Server 2003 R2
If you are using Windows Server 2003 R2 you will be running AD FS 1.0. AD FS requires the Enterprise or Datacenter editions in order to be installed. The following additional components are also required, IIS, ASP Net 2.0 and .NET Framework 2.0. The hardware requirements are quite low at a 133MHz CPU, 256 Megabytes of RAM and 10 Gigabytes of drive space.
“Appendix A: Reviewing AD FS Requirements” http://technet.microsoft.com/en-us/library/ff678034.aspx
“Window Server 2012 Products and Editions Comparison” http://www.microsoft.com/en-au/download/confirmation.aspx?id=38809
“ADFS requirements” http://technet.microsoft.com/en-us/library/cc727972(v=ws.10).aspx
This video will look at the different components that can be installed with Active Directory Federation Services. The components are mostly the same in each version, in most cases the main difference between the different components is that they have slightly different names.
Download the PDF handout
AD FS Components
The main role of Active Directory Federation Services remains much the same throughout the different versions. In Windows Server 2012 R2 Active Directory Federation Services is a role with no component. In all the other versions Federation Services is a component in the role.
AD FS has a proxy component that you can install in a DMZ to provide access to Federation Users from the internet. This component is called “Federation Service Proxy” except in Windows Server 2012 R2 where the component has been moved to the “Remote Access Role” and called “Web Application Proxy”. Even though the component has moved and the name has changed, the component provided the same basic functionality as the “Federation Service Proxy” component.
AD FS has a number of web agents. These are optional and allow AD FS to communicate with different systems. In different versions of AD FS the name of the component may have changed to include the version number of 1.1; however, the functionality of the component is still the same. In Windows Server 2012 R2 the web agents have been removed.
Web Application Proxy
In Windows Server 2012 R2 the Federation Service Proxy has change its name to “Web Application Proxy” and is found in the Remote Access Role. It provides the same functionality as the previous component but also has some additional functionality added. For this reason you may find that this component is used with other services, not just Active Directory Federation Services.
Web Application Proxy/Federation Service Proxy
This component is normally installed on a DMZ. If you consider that the user that is accessing the Active Directory Federation Service may not work for your company, you may not want them accessing your internal network directly. Since Active Directory Federation Services needs to be a member of the domain, accessing it directly does present some security issues. The application proxy does not need to be a member of the domain. The user would access the proxy server on the DMZ which would then pass on the request to the federation server. The Federation Server would then send the result back to the proxy server which would pass this on to the user. The user would most likely be receiving a claim. Once the user has a claim, they are able to use this claim to access a claim aware application. The claim aware application is most likely to be found on the DMZ.
AD FS Web Agents
Web agents are not available in Windows Server 2012 R2 as they have been removed. In the other version of AD FS the name may be slightly different, but they form the same function. A vendor is free to add their own agents however the two web agents provided by Microsoft are “Claims-aware Agent” or “AD FS 1.1 Claims-aware Agent” and “Windows Token-based Agent” or “AD FS 1.1 Windows Token-based Agent”.
AD FS Web Agents
Essentially a web agent converts a claim from one format to another. Given the example of the Windows Token-based Agent, this takes an AD FS claim and converts it into an NT Token. AD FS used to require IIS to operate, however it no longer requires it. Web agents were generally used with IIS. This may be the reason that Microsoft removed this feature in IIS as it is no longer required in Windows Server 2012 R2 for AD FS.
“Web Application Proxy” http://msdn.microsoft.com/en-us/library/windows/desktop/dn323740(v=vs.85).aspx
“Understanding the AD FS 2.0 Proxy” http://blogs.technet.com/b/askds/archive/2012/01/05/understanding-the-ad-fs-2-0-proxy.aspx
“ADFS Web Agent” http://technet.microsoft.com/en-us/library/cc783116(v=ws.10).aspx
This video will perform a basic Active Directory Certificate Service (ADCS) install to provide a certificate for use with Active Directory Federation Services (ADFS). The video looks at how to create a template for use with ADCS. If you have an existing certificate service on your network, you can use the procedure in this video to add a template to your existing certificate server.
Download the PDF handout
Demonstration installing the CA
1) To start the install, open Server Manager from the quick launch bar.
2) From Server Manager, select Roles from the left-hand side and then from the right-hand side select the option “Add Roles” to install the add roles wizard.
3) Once past the welcome screen select the role “Active Directory Certificate Services” and press next to start the Certificate Services part of the install.
4) The next screen is the information screen for the Certificates role. Press next to skip it.
5) The next screen displays all the different components that can be installed as part of the certificate role. In this case the only component that is required is “Certification Authority”. Tick this option and then press to move on to the next screen of the wizard.
6) On the next screen select the option of Enterprise CA. This is one of the two options to install. The Enterprise option requires the server to be a member of the domain. In later videos the standalone option is looked at to provide certificates for ADFS.
7) The next screen you need to decide is if the install is to be Root CA or Subordinate CA. In this case Root CA is selected because there are no other CA’s on the network. For better security a certificate hierarchy could be setup, but this video uses a simple install aimed at providing a working certificate for use with ADFS.
8) For the rest of the wizard all the defaults were accepted. In a production environment you may want to consider changing some of these options, for example changing the key size used for the certificate that is created for the Root CA.
Demonstration configuring the CA
1) To configure the certificate authority, select “Certification Authority” under “Administrative Tools” under the start menu.
2) Once open, expand down to Certificate Templates, right click it and select the option “Manage”. This will bring up a list of all the certificate templates that are currently configured on this server.
3) There is no default template for ADFS so the best option is to find a template that is simpler to the one required and then make changes to it. In this case, select the template “Web Server”, right click it and select the option “Duplicate Template”.
4) When duplicating the template you will be asked which version of Windows you want to use the certificate with. In this case the option “Windows Server 2008 Enterprise” was selected. When creating templates you need to work out which is the lowest operating system that the template will be used with. In this case, no ADFS server lower than Windows Server 2008 R2 will be used so it is safe to use the option “Windows Server 2008 Enterprise”.
5) Once the template has been duplicated, the properties for the certificate template will automatically be opened.
6) On the general tab, change the “Template display name” to something meaningful. This does not affect the operation of the template but does make it easier for other administrators to understand what the template is for.
7) Select the tab “Subject Name” and then select the option “Build from this Active Directory information”.
8) From the “Subject name format” pull down, select the option “Common name”.
9) There are 4 tick boxes at the bottom of the screen. The only tick box that needs to be ticked is “DNS name”.
10) These options essentially say, take the DNS Name from Active Directory and store it in the certificate using the format common name”.
11) The certificate needs to be configured so the ADFS server has permission to use it. To do this, select the security tab and then press add. Press the button “Object Types” and make sure the option “Computers” is ticked.
12) Next enter in the computer or computers that will use this certificate template. In this case the computer name entered was “ITADFS2008R2”.
13) Once the permission for the computer has been added, the default permission for read will be ticked, you will also need to tick the option for “Enroll” and then press o.k. to exit.
14) The template has been added and configured. Next it needs to be enabled in order to allow it to start issuing certificates. To do this, in Certificate Authority Management, right click “Certificate Template” and select the option “Certificate Template to Issue” under “New”.
15) This will bring up the “Enable Certificate Template” Window. Find the certificate template that was just created and configured, in this case “ADFS SSL Certificate 2008 R2”, select it and press o.k. This will allow the certificate server to start issuing new certificates using that template.
This video will look at how to install Active Directory Federation Services on Windows Server 2008 R2. Active Directory Federation Services requires a certificate in order for the install to be performed. In a previous video Active Directory Certificate Services was installed on a separate server on this network. This will be used during the install to create a certificate for use with Active Directory Federation Services to be used during the install of Active Directory Federation Services.
Download the PDF handout
The version of Active Directory Federation Services or AD FS that comes with Windows Server 2008 R2 is version 1.0. Version 2.0 is a free update from Microsoft and will be the version that is install in this demonstration.
1) To install version 2.0, it first needs to be downloaded and installed. The install can be found by googling “AD FS 2.0 RTW”. RTW stands for “release to web”. It is just a matter of downloading the 32bit or 64bit version depending on what operating system that you are running. Otherwise you can visit the following link. http://www.microsoft.com/en-au/download/details.aspx?id=10909
2) Once the download has completed, it is just a matter of running the executable.
3) Once past the welcome screen and license screen, the install will ask if you want to install the “Federation Server” or “Federation Server Proxy”. In this case the “Federation Server” was selected as the full product is required. If you wanted only the proxy service, the second option could be chosen.
4) The next screen of the install wizard will show you what perquisites are required by the install. The administrator does not need to install these, the install wizard will install these automatically if they are not already present on the system.
5) Once the wizard is completed, AD FS 2.0 will be added to the system and the next step is to configure it.
Once AD FS 2.0 has been installed, it next needs to be configured.
1) To configure, open “AD FS 2.0 Management” from Administrative Tools under the start menu.
2) On the home page, select the option “AD FS 2.0 Federation Server Configuration Wizard” to start the setup wizard.
3) On the first screen of the wizard you need to decide if you are creating a new federation service or adding this server to an existing farm. In this case, this is the Federation Server install on the network so the option “Create a new Federation Service” was selected.
4) The next screen of the wizard will ask if you want to create a new farm or if you want to install the server as a standalone server. Both options will give you the same set of features. The advantage of installing a new server farm is that additional servers can be added to the farm later on if required. The stand-alone option is generally recommend for testing, and the server farm option for production environments. In this case the option “New federation Server Farm” was selected.
5) The next screen of the wizard will ask for a certificate to be selected that will be used with Active Directory Federation Services. It is a matter of selecting an available certificate. If one is not available in the drop down list, you will need to request one following the procedure below.
6) If an existing AD FS database is found on the server, the install wizard will ask you if you want to remove this database from the server.
7) The next screen will ask for a service account that will be used to run Active Directory Federation Services. The user account can be a general domain user, however it will need to be added to the local administrator group on the server. To do this, open “Computer Management” from Administrative tools under the start menu. Once open, expand down to groups, right click the Administrators group and then select the option “Add to group”. It is just a matter then of adding the user name that you are planning to use as the service account.
8) The next screen of the wizard shows a summary of the configuration that was selected in the wizard, once next is pressed, the server will be configured. The process does take a few minutes to complete.
Creating a certificate
To create a certificate to be used with AD FS, a request for a certificate first needs to be created. In this case auto enrollment will be used to obtain a certificate and renew that certificate automatically.
1) To do this, run mmc from the start menu to access the certificate snap-in. There is no shortcut in the start menu to access this snap-in so it needs to be accessed this way.
2) To add the snap-in, select file and then select the option “Add/Remove Snap-in”. From the list of snap-ins, select certificates and then press the button add.
3) When the certificate snap-in is added, the administrator will be prompted for which certificate store that they want to manage. In this case, the certificates that Active Directory Federation Services will use is found in “Computer account” so this option will need to be selected and then next needs to be pressed to move on.
4) On the next screen, the wizard will ask which computer you want to manage certificates on. In this case this will be the local computer so the default option of “Local computer” will be left selected and then the wizard will be completed.
5) By default, the view of the certificate will be “Logical certificate stores”. To change it, select the view menu and then select options. From the option, change the view mode to “Certificate purpose”.
6) The certificate for AD FS needs to be used with “Server Authentication”, thus right click this container and select the option “Request New Certificate” which can be found under “All Tasks” to start the enrollment wizard.
7) Once past the welcome screen, the next screen will ask you to select an enrollment policy. In this case the default Active Directory enrollment policy will be selected.
8) The next screen will show the certificate templates that are available. In the previous video, a template for AD FS was created called “AD FS SSL Certificate 2008 R2”. For this video that template will be selected and then the enroll button will be pressed.
9) The enrollment should not take too long to complete. Once complete, the certificate will be obtained via enrollment and be added to the local certificate store.
“Active Directory Federation Services 2.0 RTW” http://www.microsoft.com/en-au/download/details.aspx?id=10909
This video will look at how to set up Active Directory Federation Services in the HighCost Training domain. In this example certificate services will also be installed on the server. This means the same server will issue certificates to AD FS. Normally in a production environment you would not install certificate services on the same server as AD FS, but in this case it is done to make the install simple.
Access the rest of the course
Download the PDF handout
Demonstration installing Active Directory Certificate Services
00:42 Open Server Manager by selecting the icon in the quick launch bar.
00:47 From Server Manager, select roles from the left hand side and then select “Add Roles” from the right hand side to start the add roles wizard.
00:58 Skip past the welcome screen and then select the role “Active Directory Certificate Services”. AD FS will not be installed at this time because version 1.0 ships with Windows. Version 2.0 is available as a free download and will be installed later in the video. Once the option is ticked, press next to move on to the next screen.
01:24 The next screen will be the welcome screen for certificate services. Once past the welcome screen, on the next screen the components for the certificate role will be displayed. Since the role is only required to issue certificates, the only component that is required to be select is the component “Certification Authority” and then press next.
01:41 The next screen will ask if the certificate authority will be Enterprise or Standalone. In this case the Standalone option will be selected. This option could be installed on any server and does not require the server to be part of the domain. Once the Standalone option has been selected press next to continue.
01:52 On the next screen there is the choice of Root CA and Subordinate CA. Root CA’s are able to issue certificates without requiring other CA’s. In this case this option is chosen so the CA can issue a certificate directly to AD FS. In a production environment for better security you would place the root CA on a standalone server and have a subordinate CA issue certificates. For the best level of security you would have the root CA only available when required.
02:33 For the private key screen, cryptography, CA Name, Validity period and certificate database screen, I will accept all the defaults. On a production environment you will want to go through these options and work out the best settings for your network.
02:40 Once you have verified that the settings are correct for the install, press install to start the install and then the wizard can be closed.
Demonstration requesting a certificate
The certificate snap-in needs to load in MMC and then a certificate request file created which will be imported by the stand alone CA on the server to generate the certificate.
02:55 Press the start button and then enter in the run box mmc.
03:10 From the file menu select the option “Add/remove Snap-in”.
03:19 From the list of snap-ins select “Certificates” and then press the add button.
03:20 The certificate is used by the server, so when prompted, select the option for “Computer Account” and press next.
03:30 The next screen asks which computer you want to manage certificates on. In this case the default option of the local computer will be used. Press the finish button to complete adding the snap-in followed by o.k. to return to MMC.
03:48 In certificates, expand down to personal container, right click the container and then under “All Tasks” select the option “Advanced Operations” followed by “Create Custom Request”.
04:10 The Certificate Enrollment wizard will create a request file that can be used to issue a certificate from the certificate authority. On the welcome screen press next.
04:16 On the Certificate Enrollment screen, select the option “Process without enrollment Policy” and press next. Since the CA is a standalone CA and not an Enterprise CA, the option “Active Directory Enrollment Policy” cannot be used.
04:28 For the template select the option “(No template) Legacy Key”. This option is required because Active Directory Federation Services requires access to the private key. Leave the option select “PKCS #10” and press next.
04:54 Additional information needs to be configured in the certificate request. If these options are not configured AD FS will not be able to use the certificate. To access these options press the downward arrow next to details and then press the properties button.
05:03 Enter in a friendly name and description for the certificate. This does not affect how AD FS will use the certificate, however it does make it easier for other administrators to work out what the certificate is being used for. In this case, the friendly name is configured to “HighCostTraining AD FS” and description as “High Cost Training Active Directory Federation Services”.
05:20 Select the subject tab. Two fields need to be added so AD FS can identify the certificate. Under subject name select common name. For the value, enter in the fully qualified domain name of the server. In this case “HIADFS2008R2.HighCost.Local. Once entered, press the add button.
05:46 To configure the alternative name, select DNS from the type menu. For the value enter in the fully qualified domain name of the server. In this case “HIADFS2008R2.HighCost.Local. Once entered, press the add button.
06:06 Select the extensions tab.
06:09 Expand the section “Extended Key Usage (application policies)”. In the available options select “Server Authentication” and press add and then select “Client Authentication” and press add. This allows the certificate to be used for these two tasks which are required by AD FS.
06:26 Select the private key tab.
06:30 Expand the section key options. For the key size select 2048. Microsoft recommends at least 2048. Larger key sizes can be used, but this may lead to incompatibility problems with older hardware and operating systems.
06:50 AD FS requires access to the private key, so tick the tick box “Make private key exportable” otherwise it will not be able to get access to it.
07:01 Press o.k. and then press next to move on to the next screen of the wizard.
07:08 Press the browse button and enter in a file and path to save the request file to. In this case the request will be saved to the desktop since the CA is on this server. If the CA was on a different server, the request file would be most likely saved to removable media or e-mailed. Once entered, leave the file format on “Base 64” and press finish.
07:35 To issue the certificate using the request file, open the start menu and under “Administrative Tools” select “Certification Authority”.
07:44 From Certification Authority, right click the server name and under “All Tasks” select the option “Submit new request”.
07:56 Browse the location of the request file and press open. In this case the request file is on the desktop.
08:07 To issue the certificate, open the container “Pending Requests”. The request should be in the container. Right click the request and select “Issue” under “All Tasks”.
08:21 The certificate needs to be exported and imported into the local certificate store to be used by AD FS. To do this, select the container “Issued Certificates”. Find the certificate and double click it to open it.
08:42 To export the certificate, select the details tab and then press the button “Copy to File” to launch the certificate export wizard.
08:54 In the certificate export wizard, press next to go past the welcome screen. On the next screen select the format to export the certificate in. The default format “DER encoded binary X.509 (.CER)” will work fine so press next to continue.
09:06 Enter in a filename for the exported certificate and press next. In this case the certificate will be exported to the desktop.
09:17 Press finish to complete the export of the certificate and then close all the Windows except MMC.
09:29 The next step is to import the exported certificate to the local certificate store so that it can be used by Active Directory Federation Services. To do this, expand down to the personal container, right click it and under “All Tasks” select the option “Import” to launch the import wizard.
09:46 Once past the welcome screen of the Certificate Import Wizard, press browse and browse to the location of the exported certificate and then press next.
10:03 The next screen will ask where to store the certificate. Since I right clicked on the personal certificate container this certificate store will automatically be selected. If it is not, press the browse button and select the personal certificate store and then press next and the press finish to complete the wizard.
10:25 Close all the open Windows.
Demonstration Installing and configuring AD FS
The version of AD FS shipped with Windows Server 2008 R2 is version 1.0. There is a newer version 2.0 that is a free download from Microsoft that will be installed and configured instead.
10:32 Open Internet Explorer from the start menu.
10:36 open http://www.google.com and perform a search for “ADFS 2.0 RTW”. RTW means released to web. Select the first result. If you cannot find it go to http://www.microsoft.com/en-au/download/details.aspx?id=10909
11:00 Select the language that you want to download and then press the continue button.
11:08 The next screen will ask if you want to register with Microsoft to receive updates. This is up to you, in this case the default option no will be selected and next pressed.
11:19 At the next screen, you need to select which version of AD FS to download. In this case the 64 bit version for Windows Server 2008 R2 was selected, however there is also options for the 32 and 64 bit version for Windows Server 2008. Once you have made the selection press next to start the download and save it to the desktop.
11:44 Run the setup saved to the desktop to launch the setup wizard.
11:50 Press next to go past the welcome screen and then tick the tick box “I accept the terms in the license Agreement” and press next.
11:59 On the Server Role screen choose either Federation Server or Federation Server Proxy. In this case Federation Server is chosen. The Federation server proxy is reverse proxy like service that is used by clients to access a federation server when it is behind a firewall. When you have made your selection press next.
12:20 The next screen will tell you what prerequisite software is required to be install for AD FS. If the software has not already been installed, setup will automatically install it for you. Press next to continue. The install will then start, which will take a few minutes to complete.
12:50 On the final screen of the wizard there is a tickbox “Start the AD FS 2.0 Management Snap-in when this wizard closes”. In this case the option was left ticked so when finish is press the Management tool will be automatically opened.
13:13 Additional post-configuration of AD FS is required. To perform this step, select the option in the middle of the screen “AD FS 2.0 Federation Server Configuration Wizard”.
13:28 On the first screen of the wizard, you can create a new federation service or add this server to an existing federation service or farm. In this case there is no existing Federation Services on the network so the first option “Create a new Federation Service” will be selected. Once selected press next to continue.
13:56 At the next screen, the administrator can choose to create a new farm or create a stand-alone install. There is no change to the functionality of the AD FS system regardless which option you choose. If you choose the stand-alone option you will not be able to add servers later on. For this reason, if you are not sure, you should choose the option “New federation server farm”. Once selected press next to continue.
14:29 On the next screen the certificate needs to be selected to use with Active Directory Federation Services. Since this server contains a CA the certificate for the CA will also appear. Make sure that if you have the CA installed on the same server that you choose the correct certificate and then press next to move on.
14:47 The next screen requires a service account. In this case I will browse to the service account that was created earlier and enter in its password. The service account can be a regular user account that has been added to the local administrators group. You could also use a domain administrator’s user account, but this is not considered to be best practice. Once the user account has been entered and the password entered, press next.
15:14 The next screen will show a summary of all the options that have been selected in the wizard. If you are happy with the options press next.
15:20 At the next screen the configuration of AD FS will occur. The results of the configuration will be shown. In this case, setup has indicated a warning stating that it could not configure the SPN on the service account. The SPN was created when the user account was created. Setup will not configure the SPN if it has already been configured. If the SPN is incorrect, you can change it by opening the properties of the user account.
“Active Directory Federation Services 2.0 RTW” http://www.microsoft.com/en-au/download/details.aspx?id=10909
In Active Directory Federation Services there are two types of trusts. This video will look at the relying party trust which is configured on the account side. It essentially determines what information will be placed inside the claim.
Download the PDF handout
Trusts in AD FS
In this example ITFreeTraining has an Active Directory Federation Server and so does HighCost Training. On the ITFreeTraining side a relying party trust is created. The relying party trust is the configuration that is used to create a claim. It may seem that the relying party trust should be on the HighCost training side, however this is not possible. The reason for this is that ITFreeTraining creates a claim. Once this claim is created it cannot be changed. If the relying party trust was on the HighCost Training side, it would not be able to decide what data is in the claim as the claim would have already been created.
Relying Party Trust
A relying party trust is the configuration that is used in the accounts partner organization that is used to create claims. Normally it is used between the accounts partner and the resource partner but can also be used with a claims based application. When a relying party trust is created there are 3 rules that can be configured. These are, issuance transform rules, issuance authorization rules, and delegation authorization rules.
Relying Party Trust Example
In this example, an AD FS server is required to authenticate from a domain controller and obtain information from a SQL data store. When a claim is created, the AD FS federation server needs to be able determine where to get this data and which Domain Controller to authenticate with and how to output the data. In order to do this, 3 different types of rules are used. The issuance authorization rule determines how authentication will occur. In this case a domain controller is being used, however authentication could be as simple as the user having an e-mail address. Issuance transform rules define the data that is obtained and also define how it can be changed. For example, if the data obtained from the SQL Data Store was an e-mail address that ended in local, the transform rule may be defined to change this address to one ending in .com. Delegation authorization allows different users to be defined to access data. For example, delegation could be used for one user to obtain data for another user.
Issuance Transform Rules
In this example the job title is being added to the claim. A rule is created which defines that the job title should be obtained from an attribute store, most likely an SQL database. Once this data is obtained the job title is added to the claim. The problem is that some users do not have a job title and the claim cannot be used without a job title. The application that accepts this claim does not use the job title information in any way, however something needs to be configured, otherwise the claim will be rejected. To get around this, a second transform rule is created that configures the job title to “ITFreeTraining Employee” when no data is configured. This means that there will always be a value configured for the job title. You can see how transform rules can obtain and change data. Multiple rules can be stacked together in order to obtain the required result.
Delegation Authorization Rules
This rule essentially allows a user to be impersonated, that is, they are pretending to be someone else. In this example, the user obtains a claim from an AD FS server. They then use this claim to access a web server. The web server will then access a claim aware application using a different user name. So essentially they are performing the access as a different user than what was originally used in the claim.
Delegation Authorization Rules Example
In this example, a library has purchased access to an online journal for their students. The online journal license agreement states that is can only be used by students who are members of that library. If the library was to give the users the username and password to access the online journal they would lose control. This is because a user could stop being a member of the library and still have access or they could give the username and password to other people to use. To keep control of the online journal, the users connect to the library using their username and password and are authenticated. This allows the library to confirm that they are members of the library and their access is still valid. The library then accesses the online journal using their username and password on behalf of the student. This is an example of delegation authorization rules where a different user is being used to access information rather than the original user that accesses the system.
Relying Party Trust Summary
A relying party trust is created on any Federation Server that is required to create claims. Since a claim cannot be changed after it is created, the relying party trust must be created on the server creating the claims although this may seem the opposite to the way it should be done. Any server that creates claims needs to have a relying party trust created. For example, if a federation server has a trust between it and another server that has a claims-aware application running on it, a relying party trust needs to be created on the federation server.
When a relying party trust is created, 3 different rules can be created in the relying party trust.
Issuance authorization rules: This determines who is allowed to have a claim created and also how the authentication of that person will work.
Issuance Transform Rules: This rule defines which data is put into the claim. The data that is put into the claim can also be changed as required.
Delegation Authorization Rules: This allows a user to be impersonated, or put another way, allows the Federation Server to masquerade as someone else.
“The Role of Claim Rules” http://technet.microsoft.com/en-us/library/ee913586.aspx
“Claims Transformation and Custom Attribute Stores in Active Directory Federation Services 2” http://www.syfuhs.net/post/2010/09/14/Claims-Transformation-and-Custom-Attribute-Stores-in-Active-Directory-Federation-Services-2.aspx
“When to Use Identity Delegation” http://technet.microsoft.com/en-us/library/dd807122.aspx
This video looks at how to create a relying party trust on Windows Server 2008 R2 using Active Directory Federation Services. The relying party trust is the configuration that is used to create a claim.
Download the PDF handout
In the previous videos, a basic install of Active Directory Federation Services has been performed. This video will look at configuring an existing Active Directory Federation Services install with a relying party trust.
1) To create the relying party trust, open AD FS 2.0 Management from under Administrative Tools under the start menu.
2) To start the wizard to create the trust, expand down through trust relationship until you reach the container “Relying Party Trusts”. Right click this container and then select the option “Add Relying Party Trust”.
3) When the welcome screen appears, press the start button.
4) The “select data source” screen of the wizard requests when to import the configuration data that will be used with the relying party trust. There are 3 different ways this data can be imported. The first option “Import data about the relying party published online or on a local network” will contact the other Active Directory Federation Server and transfer the data from that server. This option requires a direct network connection between the two servers. The second option “Import data about the relying party trust” requires that the data from the other Federation Server be exported in a file. Once this file has been exported, it needs to be transferred to the other server using a medium like e-mail or a flash drive. The last option “Enter data about the relying party manually” requires the administrator to enter in the data for the relying party trust manually.
5) In this case, the option “Import data about the relying party published online on a local network” will be used. In order to do this, a secure connection is required so the remote server requires the certificate from the local server. See below how to add the certificate.
6) On the next screen, enter in a friendly name for the relying party trust. This will assist other administrators working out what the trust is for. After entering the friendly name, move on to the next screen.
7) The next screen will ask what the default rule is for the Issuance Authorization. If the permit rule is used, by default users will be given access. If the deny rule is selected, a rule will have to be created before the user will be granted access. This provides better security but also means more work for the administrator. In this case the deny rule will be used.
8) The next screen will show all the information that was obtained and will be used to create the wizard. This is read only and cannot be changed.
9) Once the wizard is complete, the relying party trust has been created and is ready to be used.
Adding a certificate for SSL
In order for a direct connection to be made between the 2 Federation Servers, a certificate needs to be imported on the remote server and local server from the other server. This will allow a secure connection from the local server to the remote server to transfer the relying party trust configuration.
1) Run MMC from the start menu.
2) Select the option “Add/Remove snap-in” from under the file menu.
3) Add the snap-in certificates.
4) When prompted, select the option “Computer account” to access the certificates on the local server.
5) When asked each computer you want to manage, leave it on the default option of “Local computer” and press finish to complete the wizard.
6) Press o.k. to go back to the console.
7) Expand down to certificates located under “Trusted Root Certification Authority”. Select the certificate for Active Directory Federation Services and double click to open it.
8) To export the certificate, select the details tab and then press the button “Copy to File” to start the certificate export wizard.
9) Once past the welcome screen, leave it on the default option of “DER encoded binary X.509 (.CER)” and move on to the next screen.
10) The next screen saves the certificate to the location of your choice. This file will next need to be transferred to the remote server.
11) Complete the wizard to export the certificate to the location that was specified.
12) To import the certificate on the remote server, open MMC and add the certificate snap-in by running steps 1 to 6 on the remote server.
13) The certificate for this remote server needs to be export. Repeat steps 7 to 11 above.
14) To import the certificate from the other server, make sure the Certificates container under Trust Root Certification Authority is open. Right click the white space and select import under all tasks.
15) Browse to the location of the ITFreeTraining certificate.
16) Make sure the store is “Trusted Root Certification Authorities” and complete the wizard.
17) Repeat steps 14 to 16 on the other server to import the certificate.
This video looks at the theory of a claim provider trust. In order to have a trust in Federation Services a relying party trust and a claims provider trust need to be created.
Download the PDF handout
Trusts in AD FS
In the previous video, a relying party trust was created in the ITFreeTraining domain. The configuration in this trust is used to create claims. These claims are sent to the HighCostTraining domain’s Active Directory Federation Server. The claims provider trust is the configuration that is created on that server. This configuration determines what happens when a claim is presented to that server. It may seem that the claims provider trust should be on the ITFreeTraining side. However, when you consider that the claim has been created already, the next step is to create a set of rules that determine what to do when the claim arrives at the server. That is, the claims provider trust is, essentially, the configuration that is used when a claim is presented to that server. If you get confused where the claims provider trust needs to be created, work out which servers accept claims and the configuration needs to be created there.
Claim Provider Trust
The configuration for the claims provider trust is only one rule. In contrast to the relying party trust which is 3 rules. The rule decides what claims are accepted and also allows changes to the data in that claim to be made.
“Understanding Key AD FS Concepts” http://technet.microsoft.com/en-us/library/ee913566.aspx
In this video, the claims provider trust will be created in Active Directory Federation Services in the HighCostTraining domain on Windows Server 2008 R2. In the previous videos a relying party trust was created in the ITFreeTraining domain. Creating the claims provider trust completes the trust relationship between ITFreeTraining and HighCostTraining.
Download the PDF handout
1) To create the Claim Provider Trust, login to the server and run AD FS 2.0 Management under Administrative Tools under the start menu.
2) To start the “Add Claims Provider Trust Wizard”, expand down to “Claims Provider Trust”, right click it and select the option “Add Claims Provider Trust”.
3) Once past the welcome screen, on the next screen the source of the data to create the trust needs to be entered in. In this case the computer name ITADFS2008R2.ITFreeTraining.local was used. Conditional DNS forwarders were configured on the DNS server so the server can resolve the IP Address of the other server. In a previous video, a certificate was added to the local store on the server thus allowing a secure connection to be created between the two servers.
4) Once next is press on the “Select data source” screen, the other server will be contacted and the data obtained from it to create the trust. On the next screen a Display Name and Notes can be entered. Descriptive items should be entered in here so other administrators know what the trust relationship is used for.
5) On the “Ready to Add Trust” screen, this will show all the information that will be used to create the trust.
6) Once next is pressed, the trust will be created and the wizard will move on to the last screen of the wizard. By default, the tickbox “Open the edit Claim Rules dialog for this claims provider trust when the wizard closes” will be ticked. This will open the rules for the trust allowing changes to be made if it is left ticked. If you clear this tickbox, this can be opened later on.
7) Once the edit rules dialog has been opened, to add a new rule press the button at the bottom “Add Rule” to stat the “Add Transform Claim Wizard”. There is only the one rule tab “Acceptance Transform Rules” as the trust can only accept claims that are created by another server.
8) From the first screen of the wizard, a template needs to be selected from the pull down list. This will determine the options that will be displayed in the rest of the wizard. In this, the option “Pass Through or Filter an Incoming Claim”. This will essentially take a claim and pass it onto another server; however, it does allow changes to be made to the claim.
9) On the next screen of the wizard a number of fields of data need to be entered in. First a name for the rule needs to be entered in. The next option allows the type of claim that will be accept to be entered in. After this, a decision can be made about which values of the claim should be passed on. There is also the option for the administrator to make changes to the claim values. For example, the administrator is able to change the name of a group that may have been used in the claim. Multiple rules can be used if the administrator wants to make changes to a number of different values in the claim.