Archive

Archive for June, 2008

Adding an ADFS Proxy Server

June 10th, 2008 No comments

I’m going on an hour trying to get the screen shots formatted correctly.  Live Writer is making them too small.  I’ll just attach the word document to the end if you want to see the pictures better.  I’m done messing around with this for now!  If you know what I’m doing wrong – please send me a comment!


In this blog, I will discuss the steps needed to add an ADFS Proxy to your environment. I will also outline a couple of gotchas that I ran into along the way.


First, we will start with the certificates…We need an SSL certificate on the default web site that has a subject name which matches the Federation Server URL. Since I am adding a proxy on the Account side, I need a SSL certificate with adfsaccount.adatum.com


clip_image002


clip_image004


A good checkpoint would be to simply visit https://adfsaccount.adatum.com and make sure you can get to the Under Construction page without any certificate errors. In order to do this, we need to make sure that the name adfsaccount.adatum.com resolves to the IP address of the Proxy machine instead of the FS-A server. My DNS server currently resolves adfsaccount.adatum.com to the IP address of the FS-A. So, the easiest way to do this in a lab environment like this is by using a host file entry.


My Proxy Server has an IP of 192.168.0.119 – so I can use the host file to bypass DNS resolution for this name. It is easy to comment out the entry and put it back so you can simulate an external client and internal client quickly.


clip_image006


Now that we have SSL setup properly and our client machine resolves the name to the IP of the proxy server, we are ready to request and install a Client Authentication Certificate in the local computer store.


In my first attempt and putting this blog together, I ran into some issues with the client auth certificate, so it may be good information for you to read that blog before going any further.


The client authentication certificate will be used by the Proxy server to authenticate with the Federation Server. We will install it into the local computer personal store, then export the public key and add it to the Trust Policy on the Federation Server.


Unlike the SSL certificate, we don’t need to worry about any specific name. We only care that the EKU has client authentication.


Below is a shot of my certificate server web page after doing “advanced certificate request” then “Create and submit a request to this CA”


In the name field, I just put something useful to identify the certificate quickly when I view my local computer store.


If you have a plain Standalone CA, your screen should look like this:


clip_image008


You can check the box to store the certificate in your local store and give it a name like ADFS Proxy Certificate. This will save you some extra steps that I had to go through.


On my CA, I have had to issue some certificates to some Vista and WS08 machines. In order to do this from a 2003 CA, you need to update the web enrollment pages. Instructions and the hotfix needed to do this are outlined in this KB article. In the article it states the following about computer enrollement:


Computer certificate enrollment
Administrative rights are required to request a computer certificate. In Windows Vista, Microsoft Internet Explorer does not use administrative rights to run. Therefore, the option to store a computer certificate in the computer store was removed from the Windows Server 2008 certificate enrollment pages.


Note the lack of the ability to install the certificate directly into the computer store. So I had to install it in the user store, then export with the private key, then import to the computer store. I had to check the “mark keys as exportable” checkbox before placing the request.


clip_image009clip_image011


After approving the request on my CA, then going back to check on the status of a pending request, the only option is to “Install this certificate” and when you do this, it is placed in the user store.


clip_image013


From the user store, do an export with the private key


clip_image015


Then import to the local computer store and this will complete the Client Authentication Certificate request and your local computer store should look like this:


clip_image017


The next step is to install the ADFS Proxy component on this server.


clip_image019


Setup will prompt you to choose a Client Authentication Certificate.


clip_image021


After choosing Select – you will be displayed with a list of all certificates that have the Client EKU in the local computer store. In this setup, I only have one.


clip_image023


The next piece of information that setup will want is the FQDN of the Federation Server. We also should ensure that the Proxy Server resolves this name to the IP of the actual Federation Server. In most cases, this is accomplished with a host file entry. I will explain the name resolution portion of this more at the end of this blog.


clip_image025


The next item we need to do is export our Client Authentication Certificate (only the public key is needed) and copy it to the Federation Server.


clip_image027


clip_image029


clip_image031


Now we need to go to the Federation Server itself and launch ADFS.MSC. From the snap-in, go to properties of the Trust Policy and then go to the FSP Certificates tab. This is where we are going to add the exported client authentication certificate.


clip_image033


clip_image035


If you go back to the Proxy server and launch ADFS.MSC, you will notice there isn’t much to configure here and all the information needed should already be present.


clip_image037


Next, from the client machine that we have a host file entry on, we will enter the web application URL. Instead of being redirected to the FS-A when the client resolves adfsaccount.adatum.com it will go to the FS-A Proxy and we get a Forms Based Auth page like this:


clip_image039


This is the clientlogon.aspx page from the Proxy Server and the user is prompted for Username/Password each time they access an ADFS enabled application.


I’m going to try to cover a few items that often cause confusion with the Proxy component.


1. The server does not have to be domain joined. It can be and often is a standalone server in the perimeter network. A typical setup would be to have the Proxy in the DMZ and a firewall rule which allows communication over 443 between the Proxy and the Federation server only.


2. The matching certificate subject names on the Federation Server and the Federation Server Proxy also cause confusion. The reason for this is that the ADFS server can only have a single endpoint URL. The web servers and partner federation servers can only be configured with a single URL for federation services. In my example it is adfsaccount.adatum.com. My Federation Server has an IP address of 192.168.0.170 and my Federation Proxy Server has an IP address of 192.168.0.119 (normally this would be a public IP since it would be in the DMZ). My internal DNS server has an A record for adfsaccount.adatum.com à 192.168.0.170, but the internet DNS servers would have an A record for adfsaccount.adatum.com à 192.168.0.119


If we think about this – if the client is internal to the network, it will point to internal DNS for name resolution and will resolve the name to the .170 address and never visit the Proxy Server. This will result in a single sign on experience as the client has already entered username/password to authenticate with a DC on the internal network.


If the client is at home or at a public place on the internet, they will be pointed to some ISP DNS server for name resolution. This will resolve the name to the .119 address and the user will get a Forms Based Authentication experience because we assume they have not authenticated with a DC on the internal network.


Thru the use of a host file on the client machine, we can simulate resolving the name to different IP addresses quickly. The client is pointed to internal DNS so it resolves the name to .170, but a host file entry with the adfsaccount.adatum.com to the .119 address will bypass DNS and simulate a different DNS server with the .119 for that name.


I hope this is clear and I’m not over explaining. Please feel free to comment to this post if it isn’t clear or if you have a better way to explain.

Adding an ADFS Proxy Server

June 10th, 2008 No comments

I’m going on an hour trying to get the screen shots formatted correctly.  Live Writer is making them too small.  I’ll just attach the word document to the end if you want to see the pictures better.  I’m done messing around with this for now!  If you know what I’m doing wrong – please send me a comment!


In this blog, I will discuss the steps needed to add an ADFS Proxy to your environment. I will also outline a couple of gotchas that I ran into along the way.


First, we will start with the certificates…We need an SSL certificate on the default web site that has a subject name which matches the Federation Server URL. Since I am adding a proxy on the Account side, I need a SSL certificate with adfsaccount.adatum.com


clip_image002


clip_image004


A good checkpoint would be to simply visit https://adfsaccount.adatum.com and make sure you can get to the Under Construction page without any certificate errors. In order to do this, we need to make sure that the name adfsaccount.adatum.com resolves to the IP address of the Proxy machine instead of the FS-A server. My DNS server currently resolves adfsaccount.adatum.com to the IP address of the FS-A. So, the easiest way to do this in a lab environment like this is by using a host file entry.


My Proxy Server has an IP of 192.168.0.119 – so I can use the host file to bypass DNS resolution for this name. It is easy to comment out the entry and put it back so you can simulate an external client and internal client quickly.


clip_image006


Now that we have SSL setup properly and our client machine resolves the name to the IP of the proxy server, we are ready to request and install a Client Authentication Certificate in the local computer store.


In my first attempt and putting this blog together, I ran into some issues with the client auth certificate, so it may be good information for you to read that blog before going any further.


The client authentication certificate will be used by the Proxy server to authenticate with the Federation Server. We will install it into the local computer personal store, then export the public key and add it to the Trust Policy on the Federation Server.


Unlike the SSL certificate, we don’t need to worry about any specific name. We only care that the EKU has client authentication.


Below is a shot of my certificate server web page after doing “advanced certificate request” then “Create and submit a request to this CA”


In the name field, I just put something useful to identify the certificate quickly when I view my local computer store.


If you have a plain Standalone CA, your screen should look like this:


clip_image008


You can check the box to store the certificate in your local store and give it a name like ADFS Proxy Certificate. This will save you some extra steps that I had to go through.


On my CA, I have had to issue some certificates to some Vista and WS08 machines. In order to do this from a 2003 CA, you need to update the web enrollment pages. Instructions and the hotfix needed to do this are outlined in this KB article. In the article it states the following about computer enrollement:


Computer certificate enrollment
Administrative rights are required to request a computer certificate. In Windows Vista, Microsoft Internet Explorer does not use administrative rights to run. Therefore, the option to store a computer certificate in the computer store was removed from the Windows Server 2008 certificate enrollment pages.


Note the lack of the ability to install the certificate directly into the computer store. So I had to install it in the user store, then export with the private key, then import to the computer store. I had to check the “mark keys as exportable” checkbox before placing the request.


clip_image009clip_image011


After approving the request on my CA, then going back to check on the status of a pending request, the only option is to “Install this certificate” and when you do this, it is placed in the user store.


clip_image013


From the user store, do an export with the private key


clip_image015


Then import to the local computer store and this will complete the Client Authentication Certificate request and your local computer store should look like this:


clip_image017


The next step is to install the ADFS Proxy component on this server.


clip_image019


Setup will prompt you to choose a Client Authentication Certificate.


clip_image021


After choosing Select – you will be displayed with a list of all certificates that have the Client EKU in the local computer store. In this setup, I only have one.


clip_image023


The next piece of information that setup will want is the FQDN of the Federation Server. We also should ensure that the Proxy Server resolves this name to the IP of the actual Federation Server. In most cases, this is accomplished with a host file entry. I will explain the name resolution portion of this more at the end of this blog.


clip_image025


The next item we need to do is export our Client Authentication Certificate (only the public key is needed) and copy it to the Federation Server.


clip_image027


clip_image029


clip_image031


Now we need to go to the Federation Server itself and launch ADFS.MSC. From the snap-in, go to properties of the Trust Policy and then go to the FSP Certificates tab. This is where we are going to add the exported client authentication certificate.


clip_image033


clip_image035


If you go back to the Proxy server and launch ADFS.MSC, you will notice there isn’t much to configure here and all the information needed should already be present.


clip_image037


Next, from the client machine that we have a host file entry on, we will enter the web application URL. Instead of being redirected to the FS-A when the client resolves adfsaccount.adatum.com it will go to the FS-A Proxy and we get a Forms Based Auth page like this:


clip_image039


This is the clientlogon.aspx page from the Proxy Server and the user is prompted for Username/Password each time they access an ADFS enabled application.


I’m going to try to cover a few items that often cause confusion with the Proxy component.


1. The server does not have to be domain joined. It can be and often is a standalone server in the perimeter network. A typical setup would be to have the Proxy in the DMZ and a firewall rule which allows communication over 443 between the Proxy and the Federation server only.


2. The matching certificate subject names on the Federation Server and the Federation Server Proxy also cause confusion. The reason for this is that the ADFS server can only have a single endpoint URL. The web servers and partner federation servers can only be configured with a single URL for federation services. In my example it is adfsaccount.adatum.com. My Federation Server has an IP address of 192.168.0.170 and my Federation Proxy Server has an IP address of 192.168.0.119 (normally this would be a public IP since it would be in the DMZ). My internal DNS server has an A record for adfsaccount.adatum.com à 192.168.0.170, but the internet DNS servers would have an A record for adfsaccount.adatum.com à 192.168.0.119


If we think about this – if the client is internal to the network, it will point to internal DNS for name resolution and will resolve the name to the .170 address and never visit the Proxy Server. This will result in a single sign on experience as the client has already entered username/password to authenticate with a DC on the internal network.


If the client is at home or at a public place on the internet, they will be pointed to some ISP DNS server for name resolution. This will resolve the name to the .119 address and the user will get a Forms Based Authentication experience because we assume they have not authenticated with a DC on the internal network.


Thru the use of a host file on the client machine, we can simulate resolving the name to different IP addresses quickly. The client is pointed to internal DNS so it resolves the name to .170, but a host file entry with the adfsaccount.adatum.com to the .119 address will bypass DNS and simulate a different DNS server with the .119 for that name.


I hope this is clear and I’m not over explaining. Please feel free to comment to this post if it isn’t clear or if you have a better way to explain.

Adding an ADFS Proxy Server

June 10th, 2008 No comments

I’m going on an hour trying to get the screen shots formatted correctly.  Live Writer is making them too small.  I’ll just attach the word document to the end if you want to see the pictures better.  I’m done messing around with this for now!  If you know what I’m doing wrong – please send me a comment!


In this blog, I will discuss the steps needed to add an ADFS Proxy to your environment. I will also outline a couple of gotchas that I ran into along the way.


First, we will start with the certificates…We need an SSL certificate on the default web site that has a subject name which matches the Federation Server URL. Since I am adding a proxy on the Account side, I need a SSL certificate with adfsaccount.adatum.com


clip_image002


clip_image004


A good checkpoint would be to simply visit https://adfsaccount.adatum.com and make sure you can get to the Under Construction page without any certificate errors. In order to do this, we need to make sure that the name adfsaccount.adatum.com resolves to the IP address of the Proxy machine instead of the FS-A server. My DNS server currently resolves adfsaccount.adatum.com to the IP address of the FS-A. So, the easiest way to do this in a lab environment like this is by using a host file entry.


My Proxy Server has an IP of 192.168.0.119 – so I can use the host file to bypass DNS resolution for this name. It is easy to comment out the entry and put it back so you can simulate an external client and internal client quickly.


clip_image006


Now that we have SSL setup properly and our client machine resolves the name to the IP of the proxy server, we are ready to request and install a Client Authentication Certificate in the local computer store.


In my first attempt and putting this blog together, I ran into some issues with the client auth certificate, so it may be good information for you to read that blog before going any further.


The client authentication certificate will be used by the Proxy server to authenticate with the Federation Server. We will install it into the local computer personal store, then export the public key and add it to the Trust Policy on the Federation Server.


Unlike the SSL certificate, we don’t need to worry about any specific name. We only care that the EKU has client authentication.


Below is a shot of my certificate server web page after doing “advanced certificate request” then “Create and submit a request to this CA”


In the name field, I just put something useful to identify the certificate quickly when I view my local computer store.


If you have a plain Standalone CA, your screen should look like this:


clip_image008


You can check the box to store the certificate in your local store and give it a name like ADFS Proxy Certificate. This will save you some extra steps that I had to go through.


On my CA, I have had to issue some certificates to some Vista and WS08 machines. In order to do this from a 2003 CA, you need to update the web enrollment pages. Instructions and the hotfix needed to do this are outlined in this KB article. In the article it states the following about computer enrollement:


Computer certificate enrollment
Administrative rights are required to request a computer certificate. In Windows Vista, Microsoft Internet Explorer does not use administrative rights to run. Therefore, the option to store a computer certificate in the computer store was removed from the Windows Server 2008 certificate enrollment pages.


Note the lack of the ability to install the certificate directly into the computer store. So I had to install it in the user store, then export with the private key, then import to the computer store. I had to check the “mark keys as exportable” checkbox before placing the request.


clip_image009clip_image011


After approving the request on my CA, then going back to check on the status of a pending request, the only option is to “Install this certificate” and when you do this, it is placed in the user store.


clip_image013


From the user store, do an export with the private key


clip_image015


Then import to the local computer store and this will complete the Client Authentication Certificate request and your local computer store should look like this:


clip_image017


The next step is to install the ADFS Proxy component on this server.


clip_image019


Setup will prompt you to choose a Client Authentication Certificate.


clip_image021


After choosing Select – you will be displayed with a list of all certificates that have the Client EKU in the local computer store. In this setup, I only have one.


clip_image023


The next piece of information that setup will want is the FQDN of the Federation Server. We also should ensure that the Proxy Server resolves this name to the IP of the actual Federation Server. In most cases, this is accomplished with a host file entry. I will explain the name resolution portion of this more at the end of this blog.


clip_image025


The next item we need to do is export our Client Authentication Certificate (only the public key is needed) and copy it to the Federation Server.


clip_image027


clip_image029


clip_image031


Now we need to go to the Federation Server itself and launch ADFS.MSC. From the snap-in, go to properties of the Trust Policy and then go to the FSP Certificates tab. This is where we are going to add the exported client authentication certificate.


clip_image033


clip_image035


If you go back to the Proxy server and launch ADFS.MSC, you will notice there isn’t much to configure here and all the information needed should already be present.


clip_image037


Next, from the client machine that we have a host file entry on, we will enter the web application URL. Instead of being redirected to the FS-A when the client resolves adfsaccount.adatum.com it will go to the FS-A Proxy and we get a Forms Based Auth page like this:


clip_image039


This is the clientlogon.aspx page from the Proxy Server and the user is prompted for Username/Password each time they access an ADFS enabled application.


I’m going to try to cover a few items that often cause confusion with the Proxy component.


1. The server does not have to be domain joined. It can be and often is a standalone server in the perimeter network. A typical setup would be to have the Proxy in the DMZ and a firewall rule which allows communication over 443 between the Proxy and the Federation server only.


2. The matching certificate subject names on the Federation Server and the Federation Server Proxy also cause confusion. The reason for this is that the ADFS server can only have a single endpoint URL. The web servers and partner federation servers can only be configured with a single URL for federation services. In my example it is adfsaccount.adatum.com. My Federation Server has an IP address of 192.168.0.170 and my Federation Proxy Server has an IP address of 192.168.0.119 (normally this would be a public IP since it would be in the DMZ). My internal DNS server has an A record for adfsaccount.adatum.com à 192.168.0.170, but the internet DNS servers would have an A record for adfsaccount.adatum.com à 192.168.0.119


If we think about this – if the client is internal to the network, it will point to internal DNS for name resolution and will resolve the name to the .170 address and never visit the Proxy Server. This will result in a single sign on experience as the client has already entered username/password to authenticate with a DC on the internal network.


If the client is at home or at a public place on the internet, they will be pointed to some ISP DNS server for name resolution. This will resolve the name to the .119 address and the user will get a Forms Based Authentication experience because we assume they have not authenticated with a DC on the internal network.


Thru the use of a host file on the client machine, we can simulate resolving the name to different IP addresses quickly. The client is pointed to internal DNS so it resolves the name to .170, but a host file entry with the adfsaccount.adatum.com to the .119 address will bypass DNS and simulate a different DNS server with the .119 for that name.


I hope this is clear and I’m not over explaining. Please feel free to comment to this post if it isn’t clear or if you have a better way to explain.

Adding an ADFS Proxy Server

June 10th, 2008 No comments

I’m going on an hour trying to get the screen shots formatted correctly.  Live Writer is making them too small.  I’ll just attach the word document to the end if you want to see the pictures better.  I’m done messing around with this for now!  If you know what I’m doing wrong – please send me a comment!


In this blog, I will discuss the steps needed to add an ADFS Proxy to your environment. I will also outline a couple of gotchas that I ran into along the way.


First, we will start with the certificates…We need an SSL certificate on the default web site that has a subject name which matches the Federation Server URL. Since I am adding a proxy on the Account side, I need a SSL certificate with adfsaccount.adatum.com


clip_image002


clip_image004


A good checkpoint would be to simply visit https://adfsaccount.adatum.com and make sure you can get to the Under Construction page without any certificate errors. In order to do this, we need to make sure that the name adfsaccount.adatum.com resolves to the IP address of the Proxy machine instead of the FS-A server. My DNS server currently resolves adfsaccount.adatum.com to the IP address of the FS-A. So, the easiest way to do this in a lab environment like this is by using a host file entry.


My Proxy Server has an IP of 192.168.0.119 – so I can use the host file to bypass DNS resolution for this name. It is easy to comment out the entry and put it back so you can simulate an external client and internal client quickly.


clip_image006


Now that we have SSL setup properly and our client machine resolves the name to the IP of the proxy server, we are ready to request and install a Client Authentication Certificate in the local computer store.


In my first attempt and putting this blog together, I ran into some issues with the client auth certificate, so it may be good information for you to read that blog before going any further.


The client authentication certificate will be used by the Proxy server to authenticate with the Federation Server. We will install it into the local computer personal store, then export the public key and add it to the Trust Policy on the Federation Server.


Unlike the SSL certificate, we don’t need to worry about any specific name. We only care that the EKU has client authentication.


Below is a shot of my certificate server web page after doing “advanced certificate request” then “Create and submit a request to this CA”


In the name field, I just put something useful to identify the certificate quickly when I view my local computer store.


If you have a plain Standalone CA, your screen should look like this:


clip_image008


You can check the box to store the certificate in your local store and give it a name like ADFS Proxy Certificate. This will save you some extra steps that I had to go through.


On my CA, I have had to issue some certificates to some Vista and WS08 machines. In order to do this from a 2003 CA, you need to update the web enrollment pages. Instructions and the hotfix needed to do this are outlined in this KB article. In the article it states the following about computer enrollement:


Computer certificate enrollment
Administrative rights are required to request a computer certificate. In Windows Vista, Microsoft Internet Explorer does not use administrative rights to run. Therefore, the option to store a computer certificate in the computer store was removed from the Windows Server 2008 certificate enrollment pages.


Note the lack of the ability to install the certificate directly into the computer store. So I had to install it in the user store, then export with the private key, then import to the computer store. I had to check the “mark keys as exportable” checkbox before placing the request.


clip_image009clip_image011


After approving the request on my CA, then going back to check on the status of a pending request, the only option is to “Install this certificate” and when you do this, it is placed in the user store.


clip_image013


From the user store, do an export with the private key


clip_image015


Then import to the local computer store and this will complete the Client Authentication Certificate request and your local computer store should look like this:


clip_image017


The next step is to install the ADFS Proxy component on this server.


clip_image019


Setup will prompt you to choose a Client Authentication Certificate.


clip_image021


After choosing Select – you will be displayed with a list of all certificates that have the Client EKU in the local computer store. In this setup, I only have one.


clip_image023


The next piece of information that setup will want is the FQDN of the Federation Server. We also should ensure that the Proxy Server resolves this name to the IP of the actual Federation Server. In most cases, this is accomplished with a host file entry. I will explain the name resolution portion of this more at the end of this blog.


clip_image025


The next item we need to do is export our Client Authentication Certificate (only the public key is needed) and copy it to the Federation Server.


clip_image027


clip_image029


clip_image031


Now we need to go to the Federation Server itself and launch ADFS.MSC. From the snap-in, go to properties of the Trust Policy and then go to the FSP Certificates tab. This is where we are going to add the exported client authentication certificate.


clip_image033


clip_image035


If you go back to the Proxy server and launch ADFS.MSC, you will notice there isn’t much to configure here and all the information needed should already be present.


clip_image037


Next, from the client machine that we have a host file entry on, we will enter the web application URL. Instead of being redirected to the FS-A when the client resolves adfsaccount.adatum.com it will go to the FS-A Proxy and we get a Forms Based Auth page like this:


clip_image039


This is the clientlogon.aspx page from the Proxy Server and the user is prompted for Username/Password each time they access an ADFS enabled application.


I’m going to try to cover a few items that often cause confusion with the Proxy component.


1. The server does not have to be domain joined. It can be and often is a standalone server in the perimeter network. A typical setup would be to have the Proxy in the DMZ and a firewall rule which allows communication over 443 between the Proxy and the Federation server only.


2. The matching certificate subject names on the Federation Server and the Federation Server Proxy also cause confusion. The reason for this is that the ADFS server can only have a single endpoint URL. The web servers and partner federation servers can only be configured with a single URL for federation services. In my example it is adfsaccount.adatum.com. My Federation Server has an IP address of 192.168.0.170 and my Federation Proxy Server has an IP address of 192.168.0.119 (normally this would be a public IP since it would be in the DMZ). My internal DNS server has an A record for adfsaccount.adatum.com à 192.168.0.170, but the internet DNS servers would have an A record for adfsaccount.adatum.com à 192.168.0.119


If we think about this – if the client is internal to the network, it will point to internal DNS for name resolution and will resolve the name to the .170 address and never visit the Proxy Server. This will result in a single sign on experience as the client has already entered username/password to authenticate with a DC on the internal network.


If the client is at home or at a public place on the internet, they will be pointed to some ISP DNS server for name resolution. This will resolve the name to the .119 address and the user will get a Forms Based Authentication experience because we assume they have not authenticated with a DC on the internal network.


Thru the use of a host file on the client machine, we can simulate resolving the name to different IP addresses quickly. The client is pointed to internal DNS so it resolves the name to .170, but a host file entry with the adfsaccount.adatum.com to the .119 address will bypass DNS and simulate a different DNS server with the .119 for that name.


I hope this is clear and I’m not over explaining. Please feel free to comment to this post if it isn’t clear or if you have a better way to explain.

Adding an ADFS Proxy Server

June 10th, 2008 Comments off

I’m going on an hour trying to get the screen shots formatted correctly.  Live Writer is making them too small.  I’ll just attach the word document to the end if you want to see the pictures better.  I’m done messing around with this for now!  If you know what I’m doing wrong – please send me a comment!


In this blog, I will discuss the steps needed to add an ADFS Proxy to your environment. I will also outline a couple of gotchas that I ran into along the way.


First, we will start with the certificates…We need an SSL certificate on the default web site that has a subject name which matches the Federation Server URL. Since I am adding a proxy on the Account side, I need a SSL certificate with adfsaccount.adatum.com


clip_image002


clip_image004


A good checkpoint would be to simply visit https://adfsaccount.adatum.com and make sure you can get to the Under Construction page without any certificate errors. In order to do this, we need to make sure that the name adfsaccount.adatum.com resolves to the IP address of the Proxy machine instead of the FS-A server. My DNS server currently resolves adfsaccount.adatum.com to the IP address of the FS-A. So, the easiest way to do this in a lab environment like this is by using a host file entry.


My Proxy Server has an IP of 192.168.0.119 – so I can use the host file to bypass DNS resolution for this name. It is easy to comment out the entry and put it back so you can simulate an external client and internal client quickly.


clip_image006


Now that we have SSL setup properly and our client machine resolves the name to the IP of the proxy server, we are ready to request and install a Client Authentication Certificate in the local computer store.


In my first attempt and putting this blog together, I ran into some issues with the client auth certificate, so it may be good information for you to read that blog before going any further.


The client authentication certificate will be used by the Proxy server to authenticate with the Federation Server. We will install it into the local computer personal store, then export the public key and add it to the Trust Policy on the Federation Server.


Unlike the SSL certificate, we don’t need to worry about any specific name. We only care that the EKU has client authentication.


Below is a shot of my certificate server web page after doing “advanced certificate request” then “Create and submit a request to this CA”


In the name field, I just put something useful to identify the certificate quickly when I view my local computer store.


If you have a plain Standalone CA, your screen should look like this:


clip_image008


You can check the box to store the certificate in your local store and give it a name like ADFS Proxy Certificate. This will save you some extra steps that I had to go through.


On my CA, I have had to issue some certificates to some Vista and WS08 machines. In order to do this from a 2003 CA, you need to update the web enrollment pages. Instructions and the hotfix needed to do this are outlined in this KB article. In the article it states the following about computer enrollement:


Computer certificate enrollment
Administrative rights are required to request a computer certificate. In Windows Vista, Microsoft Internet Explorer does not use administrative rights to run. Therefore, the option to store a computer certificate in the computer store was removed from the Windows Server 2008 certificate enrollment pages.


Note the lack of the ability to install the certificate directly into the computer store. So I had to install it in the user store, then export with the private key, then import to the computer store. I had to check the “mark keys as exportable” checkbox before placing the request.


clip_image009clip_image011


After approving the request on my CA, then going back to check on the status of a pending request, the only option is to “Install this certificate” and when you do this, it is placed in the user store.


clip_image013


From the user store, do an export with the private key


clip_image015


Then import to the local computer store and this will complete the Client Authentication Certificate request and your local computer store should look like this:


clip_image017


The next step is to install the ADFS Proxy component on this server.


clip_image019


Setup will prompt you to choose a Client Authentication Certificate.


clip_image021


After choosing Select – you will be displayed with a list of all certificates that have the Client EKU in the local computer store. In this setup, I only have one.


clip_image023


The next piece of information that setup will want is the FQDN of the Federation Server. We also should ensure that the Proxy Server resolves this name to the IP of the actual Federation Server. In most cases, this is accomplished with a host file entry. I will explain the name resolution portion of this more at the end of this blog.


clip_image025


The next item we need to do is export our Client Authentication Certificate (only the public key is needed) and copy it to the Federation Server.


clip_image027


clip_image029


clip_image031


Now we need to go to the Federation Server itself and launch ADFS.MSC. From the snap-in, go to properties of the Trust Policy and then go to the FSP Certificates tab. This is where we are going to add the exported client authentication certificate.


clip_image033


clip_image035


If you go back to the Proxy server and launch ADFS.MSC, you will notice there isn’t much to configure here and all the information needed should already be present.


clip_image037


Next, from the client machine that we have a host file entry on, we will enter the web application URL. Instead of being redirected to the FS-A when the client resolves adfsaccount.adatum.com it will go to the FS-A Proxy and we get a Forms Based Auth page like this:


clip_image039


This is the clientlogon.aspx page from the Proxy Server and the user is prompted for Username/Password each time they access an ADFS enabled application.


I’m going to try to cover a few items that often cause confusion with the Proxy component.


1. The server does not have to be domain joined. It can be and often is a standalone server in the perimeter network. A typical setup would be to have the Proxy in the DMZ and a firewall rule which allows communication over 443 between the Proxy and the Federation server only.


2. The matching certificate subject names on the Federation Server and the Federation Server Proxy also cause confusion. The reason for this is that the ADFS server can only have a single endpoint URL. The web servers and partner federation servers can only be configured with a single URL for federation services. In my example it is adfsaccount.adatum.com. My Federation Server has an IP address of 192.168.0.170 and my Federation Proxy Server has an IP address of 192.168.0.119 (normally this would be a public IP since it would be in the DMZ). My internal DNS server has an A record for adfsaccount.adatum.com à 192.168.0.170, but the internet DNS servers would have an A record for adfsaccount.adatum.com à 192.168.0.119


If we think about this – if the client is internal to the network, it will point to internal DNS for name resolution and will resolve the name to the .170 address and never visit the Proxy Server. This will result in a single sign on experience as the client has already entered username/password to authenticate with a DC on the internal network.


If the client is at home or at a public place on the internet, they will be pointed to some ISP DNS server for name resolution. This will resolve the name to the .119 address and the user will get a Forms Based Authentication experience because we assume they have not authenticated with a DC on the internal network.


Thru the use of a host file on the client machine, we can simulate resolving the name to different IP addresses quickly. The client is pointed to internal DNS so it resolves the name to .170, but a host file entry with the adfsaccount.adatum.com to the .119 address will bypass DNS and simulate a different DNS server with the .119 for that name.


I hope this is clear and I’m not over explaining. Please feel free to comment to this post if it isn’t clear or if you have a better way to explain.

Adding an ADFS Proxy Server

June 10th, 2008 No comments

I’m going on an hour trying to get the screen shots formatted correctly.  Live Writer is making them too small.  I’ll just attach the word document to the end if you want to see the pictures better.  I’m done messing around with this for now!  If you know what I’m doing wrong – please send me a comment!


In this blog, I will discuss the steps needed to add an ADFS Proxy to your environment. I will also outline a couple of gotchas that I ran into along the way.


First, we will start with the certificates…We need an SSL certificate on the default web site that has a subject name which matches the Federation Server URL. Since I am adding a proxy on the Account side, I need a SSL certificate with adfsaccount.adatum.com


clip_image002


clip_image004


A good checkpoint would be to simply visit https://adfsaccount.adatum.com and make sure you can get to the Under Construction page without any certificate errors. In order to do this, we need to make sure that the name adfsaccount.adatum.com resolves to the IP address of the Proxy machine instead of the FS-A server. My DNS server currently resolves adfsaccount.adatum.com to the IP address of the FS-A. So, the easiest way to do this in a lab environment like this is by using a host file entry.


My Proxy Server has an IP of 192.168.0.119 – so I can use the host file to bypass DNS resolution for this name. It is easy to comment out the entry and put it back so you can simulate an external client and internal client quickly.


clip_image006


Now that we have SSL setup properly and our client machine resolves the name to the IP of the proxy server, we are ready to request and install a Client Authentication Certificate in the local computer store.


In my first attempt and putting this blog together, I ran into some issues with the client auth certificate, so it may be good information for you to read that blog before going any further.


The client authentication certificate will be used by the Proxy server to authenticate with the Federation Server. We will install it into the local computer personal store, then export the public key and add it to the Trust Policy on the Federation Server.


Unlike the SSL certificate, we don’t need to worry about any specific name. We only care that the EKU has client authentication.


Below is a shot of my certificate server web page after doing “advanced certificate request” then “Create and submit a request to this CA”


In the name field, I just put something useful to identify the certificate quickly when I view my local computer store.


If you have a plain Standalone CA, your screen should look like this:


clip_image008


You can check the box to store the certificate in your local store and give it a name like ADFS Proxy Certificate. This will save you some extra steps that I had to go through.


On my CA, I have had to issue some certificates to some Vista and WS08 machines. In order to do this from a 2003 CA, you need to update the web enrollment pages. Instructions and the hotfix needed to do this are outlined in this KB article. In the article it states the following about computer enrollement:


Computer certificate enrollment
Administrative rights are required to request a computer certificate. In Windows Vista, Microsoft Internet Explorer does not use administrative rights to run. Therefore, the option to store a computer certificate in the computer store was removed from the Windows Server 2008 certificate enrollment pages.


Note the lack of the ability to install the certificate directly into the computer store. So I had to install it in the user store, then export with the private key, then import to the computer store. I had to check the “mark keys as exportable” checkbox before placing the request.


clip_image009clip_image011


After approving the request on my CA, then going back to check on the status of a pending request, the only option is to “Install this certificate” and when you do this, it is placed in the user store.


clip_image013


From the user store, do an export with the private key


clip_image015


Then import to the local computer store and this will complete the Client Authentication Certificate request and your local computer store should look like this:


clip_image017


The next step is to install the ADFS Proxy component on this server.


clip_image019


Setup will prompt you to choose a Client Authentication Certificate.


clip_image021


After choosing Select – you will be displayed with a list of all certificates that have the Client EKU in the local computer store. In this setup, I only have one.


clip_image023


The next piece of information that setup will want is the FQDN of the Federation Server. We also should ensure that the Proxy Server resolves this name to the IP of the actual Federation Server. In most cases, this is accomplished with a host file entry. I will explain the name resolution portion of this more at the end of this blog.


clip_image025


The next item we need to do is export our Client Authentication Certificate (only the public key is needed) and copy it to the Federation Server.


clip_image027


clip_image029


clip_image031


Now we need to go to the Federation Server itself and launch ADFS.MSC. From the snap-in, go to properties of the Trust Policy and then go to the FSP Certificates tab. This is where we are going to add the exported client authentication certificate.


clip_image033


clip_image035


If you go back to the Proxy server and launch ADFS.MSC, you will notice there isn’t much to configure here and all the information needed should already be present.


clip_image037


Next, from the client machine that we have a host file entry on, we will enter the web application URL. Instead of being redirected to the FS-A when the client resolves adfsaccount.adatum.com it will go to the FS-A Proxy and we get a Forms Based Auth page like this:


clip_image039


This is the clientlogon.aspx page from the Proxy Server and the user is prompted for Username/Password each time they access an ADFS enabled application.


I’m going to try to cover a few items that often cause confusion with the Proxy component.


1. The server does not have to be domain joined. It can be and often is a standalone server in the perimeter network. A typical setup would be to have the Proxy in the DMZ and a firewall rule which allows communication over 443 between the Proxy and the Federation server only.


2. The matching certificate subject names on the Federation Server and the Federation Server Proxy also cause confusion. The reason for this is that the ADFS server can only have a single endpoint URL. The web servers and partner federation servers can only be configured with a single URL for federation services. In my example it is adfsaccount.adatum.com. My Federation Server has an IP address of 192.168.0.170 and my Federation Proxy Server has an IP address of 192.168.0.119 (normally this would be a public IP since it would be in the DMZ). My internal DNS server has an A record for adfsaccount.adatum.com à 192.168.0.170, but the internet DNS servers would have an A record for adfsaccount.adatum.com à 192.168.0.119


If we think about this – if the client is internal to the network, it will point to internal DNS for name resolution and will resolve the name to the .170 address and never visit the Proxy Server. This will result in a single sign on experience as the client has already entered username/password to authenticate with a DC on the internal network.


If the client is at home or at a public place on the internet, they will be pointed to some ISP DNS server for name resolution. This will resolve the name to the .119 address and the user will get a Forms Based Authentication experience because we assume they have not authenticated with a DC on the internal network.


Thru the use of a host file on the client machine, we can simulate resolving the name to different IP addresses quickly. The client is pointed to internal DNS so it resolves the name to .170, but a host file entry with the adfsaccount.adatum.com to the .119 address will bypass DNS and simulate a different DNS server with the .119 for that name.


I hope this is clear and I’m not over explaining. Please feel free to comment to this post if it isn’t clear or if you have a better way to explain.

blog-adding proxy.doc

Interesting problem when adding an ADFS Proxy

June 4th, 2008 No comments

I am working on a blog post (step-by-step) for the Proxy component and I ran into a problem yesterday that ran me around pretty good.  We have seen this issue or variations of it on some support cases recently, so I thought the actual problem itself would make a good post.


The problem is caused by permissions to the private key on the Client Authentication Certificate needed.  In my initial attempt to setup and document the Proxy component, I made a request to my Standalone CA for a client authentication certificate.  After approving the request, the only option from the certificate web page was to “install this certificate”.  Next, when I viewed the certificate snap-in on the proxy server, I noticed that the certificate was installed to the user store and not the computer store.  I simply did a copy paste operation from user to computer.  This appeared to work for me because when I double clicked the certificate, it looked fine.  I saw the “You have a private key” on the general tab and I assumed all was well.


When I went to test – I received a failure.  The first thing I did was run the ADFS Diagnostic tool.  I ran it on the FS-A, then copied the file to the FS-A Proxy.  I passed all tests and the tool was not finding the failure! 


Here are the Event Log and Debug Logs from my FS-A and FS-A Proxy when I attempted to access the application with the Proxy in place:


From the FS-A


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS Federation Service


Event Category:    None


Event ID:                664


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             ADFSACCOUNT


Description:


The Federation Service failed a privileged Web method call because Secure Sockets Layer (SSL) client authentication information was not available.


 


This event can occur if the client does not provide a client certificate or if Internet Information Services (IIS) rejects the client’s certificate because it does not chain to a trusted root certification authority in the Federation Service.


 


User Action


If this is a valid call from the Federation Service Proxy, ensure that the root of the Federation Service Proxy client certificate is trusted by the Federation Service.


 


Debug logs:


 


2008-06-03T22:13:09 [INFO] Processing HTTP POST: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


2008-06-03T22:13:09 [VERBOSE] Received message that is not SignIn Request or Response.


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Client cert is not present


2008-06-03T22:13:09 [EVENTLOG] Error ProxyWebMethodAccessDeniedNoCert ()


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Denying access


 


 


 


From the FS-A Proxy


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS


Event Category:    None


Event ID:                605


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             FSA-PROXY


Description:


The Federation Service Proxy encountered an exception when it called a Federation Service Web method.


Federation Server URL: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


Web method: GetProxyTrustConfiguration


Proxy certificate thumbprint: ECF1FE79E51231DF48098E1044233FCBDABF04CC


 


This may cause a user request to fail.


 


User Action


The exception details may give an indication of the precise problem.


Check network connectivity between the Federation Service Proxy and the Federation Service.


Ensure that the Federation Service is running.


Ensure that the Federation Service Proxy client authentication certificate has been added to the list of proxy authentication certificates in the Federation Service trust policy.


Ensure that the Federation Service Proxy client authentication certificate chains to a root that is trusted by the Federation Service.


Ensure that the Federation Service Internet Information Services (IIS) Secure Sockets Layer (SSL) server certificate chains to a root that is trusted by the Federation Service Proxy.


Ensure that the Federation Service Uniform Resource Locator (URL) that is configured in the Federation Service Proxy web.config uses the name that is the subject of the Federation Service IIS SSL server certificate.


 


Additional Data


Exception details:


System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


 




 


Debug logs:


 


2008-06-03T22:13:09 [VERBOSE] Processing HTTP GET: https://adfsaccount.adatum.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:treyresearch&wct=2008-06-03T22:13:09Z&wctx=https://adfsweb.treyresearch.net:8081/claimapp/https://adfsweb.treyresearch.net:8081/claimapp/default.aspx


2008-06-03T22:13:09 [VERBOSE] Received SignIn Request.


2008-06-03T22:13:09 [ERROR] Exception from GetProxyTrustConfiguration: System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


2008-06-03T22:13:09 [EVENTLOG] Error ExceptionFromFedServer (https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx, GetProxyTrustConfiguration, ECF1FE79E51231DF48098E1044233FCBDABF04CC, System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data))


 


As you can see, there is a problem with the client auth certificate somewhere.  I did a fair amount of double checking my steps – but everything looked correct and seemed to be checking out.  The doubt was starting to creep in – I started to wonder how much I knew about this stuff!  Then I remembered an issue that came up a few weeks ago. 


The diagnostic tool does check for the existence and proper permissions of the private key and will flag it – but it does so in the user context.  ADFS is operating under the machine context.  So when I look at the certificate or run some certutil commands against it – it all checks out because I’m in my user security context.  If I launch a CMD prompt with AT scheduler and run the same commands or run the Diagnostic tool – I find the error.  The local computer does not have permissions to the private key of the client authentication certificate.


I was able to re-issue the certificate and mark the private keys as exportable, then do an export/import operation from the user store to computer store and everything worked as expected.


Since Client Authentication certificates are commonly used for user operations vs. computer operations – it is easy to see how others could hit this very same problem.  Hopefully the errors and debug log entries will make this blog post discoverable for others hitting this.

Interesting problem when adding an ADFS Proxy

June 4th, 2008 No comments

I am working on a blog post (step-by-step) for the Proxy component and I ran into a problem yesterday that ran me around pretty good.  We have seen this issue or variations of it on some support cases recently, so I thought the actual problem itself would make a good post.


The problem is caused by permissions to the private key on the Client Authentication Certificate needed.  In my initial attempt to setup and document the Proxy component, I made a request to my Standalone CA for a client authentication certificate.  After approving the request, the only option from the certificate web page was to “install this certificate”.  Next, when I viewed the certificate snap-in on the proxy server, I noticed that the certificate was installed to the user store and not the computer store.  I simply did a copy paste operation from user to computer.  This appeared to work for me because when I double clicked the certificate, it looked fine.  I saw the “You have a private key” on the general tab and I assumed all was well.


When I went to test – I received a failure.  The first thing I did was run the ADFS Diagnostic tool.  I ran it on the FS-A, then copied the file to the FS-A Proxy.  I passed all tests and the tool was not finding the failure! 


Here are the Event Log and Debug Logs from my FS-A and FS-A Proxy when I attempted to access the application with the Proxy in place:


From the FS-A


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS Federation Service


Event Category:    None


Event ID:                664


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             ADFSACCOUNT


Description:


The Federation Service failed a privileged Web method call because Secure Sockets Layer (SSL) client authentication information was not available.


 


This event can occur if the client does not provide a client certificate or if Internet Information Services (IIS) rejects the client’s certificate because it does not chain to a trusted root certification authority in the Federation Service.


 


User Action


If this is a valid call from the Federation Service Proxy, ensure that the root of the Federation Service Proxy client certificate is trusted by the Federation Service.


 


Debug logs:


 


2008-06-03T22:13:09 [INFO] Processing HTTP POST: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


2008-06-03T22:13:09 [VERBOSE] Received message that is not SignIn Request or Response.


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Client cert is not present


2008-06-03T22:13:09 [EVENTLOG] Error ProxyWebMethodAccessDeniedNoCert ()


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Denying access


 


 


 


From the FS-A Proxy


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS


Event Category:    None


Event ID:                605


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             FSA-PROXY


Description:


The Federation Service Proxy encountered an exception when it called a Federation Service Web method.


Federation Server URL: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


Web method: GetProxyTrustConfiguration


Proxy certificate thumbprint: ECF1FE79E51231DF48098E1044233FCBDABF04CC


 


This may cause a user request to fail.


 


User Action


The exception details may give an indication of the precise problem.


Check network connectivity between the Federation Service Proxy and the Federation Service.


Ensure that the Federation Service is running.


Ensure that the Federation Service Proxy client authentication certificate has been added to the list of proxy authentication certificates in the Federation Service trust policy.


Ensure that the Federation Service Proxy client authentication certificate chains to a root that is trusted by the Federation Service.


Ensure that the Federation Service Internet Information Services (IIS) Secure Sockets Layer (SSL) server certificate chains to a root that is trusted by the Federation Service Proxy.


Ensure that the Federation Service Uniform Resource Locator (URL) that is configured in the Federation Service Proxy web.config uses the name that is the subject of the Federation Service IIS SSL server certificate.


 


Additional Data


Exception details:


System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


 




 


Debug logs:


 


2008-06-03T22:13:09 [VERBOSE] Processing HTTP GET: https://adfsaccount.adatum.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:treyresearch&wct=2008-06-03T22:13:09Z&wctx=https://adfsweb.treyresearch.net:8081/claimapp/\https://adfsweb.treyresearch.net:8081/claimapp/default.aspx


2008-06-03T22:13:09 [VERBOSE] Received SignIn Request.


2008-06-03T22:13:09 [ERROR] Exception from GetProxyTrustConfiguration: System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


2008-06-03T22:13:09 [EVENTLOG] Error ExceptionFromFedServer (https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx, GetProxyTrustConfiguration, ECF1FE79E51231DF48098E1044233FCBDABF04CC, System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data))


 


As you can see, there is a problem with the client auth certificate somewhere.  I did a fair amount of double checking my steps – but everything looked correct and seemed to be checking out.  The doubt was starting to creep in – I started to wonder how much I knew about this stuff!  Then I remembered an issue that came up a few weeks ago. 


The diagnostic tool does check for the existence and proper permissions of the private key and will flag it – but it does so in the user context.  ADFS is operating under the machine context.  So when I look at the certificate or run some certutil commands against it – it all checks out because I’m in my user security context.  If I launch a CMD prompt with AT scheduler and run the same commands or run the Diagnostic tool – I find the error.  The local computer does not have permissions to the private key of the client authentication certificate.


I was able to re-issue the certificate and mark the private keys as exportable, then do an export/import operation from the user store to computer store and everything worked as expected.


Since Client Authentication certificates are commonly used for user operations vs. computer operations – it is easy to see how others could hit this very same problem.  Hopefully the errors and debug log entries will make this blog post discoverable for others hitting this.

Interesting problem when adding an ADFS Proxy

June 4th, 2008 No comments

I am working on a blog post (step-by-step) for the Proxy component and I ran into a problem yesterday that ran me around pretty good.  We have seen this issue or variations of it on some support cases recently, so I thought the actual problem itself would make a good post.


The problem is caused by permissions to the private key on the Client Authentication Certificate needed.  In my initial attempt to setup and document the Proxy component, I made a request to my Standalone CA for a client authentication certificate.  After approving the request, the only option from the certificate web page was to “install this certificate”.  Next, when I viewed the certificate snap-in on the proxy server, I noticed that the certificate was installed to the user store and not the computer store.  I simply did a copy paste operation from user to computer.  This appeared to work for me because when I double clicked the certificate, it looked fine.  I saw the “You have a private key” on the general tab and I assumed all was well.


When I went to test – I received a failure.  The first thing I did was run the ADFS Diagnostic tool.  I ran it on the FS-A, then copied the file to the FS-A Proxy.  I passed all tests and the tool was not finding the failure! 


Here are the Event Log and Debug Logs from my FS-A and FS-A Proxy when I attempted to access the application with the Proxy in place:


From the FS-A


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS Federation Service


Event Category:    None


Event ID:                664


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             ADFSACCOUNT


Description:


The Federation Service failed a privileged Web method call because Secure Sockets Layer (SSL) client authentication information was not available.


 


This event can occur if the client does not provide a client certificate or if Internet Information Services (IIS) rejects the client’s certificate because it does not chain to a trusted root certification authority in the Federation Service.


 


User Action


If this is a valid call from the Federation Service Proxy, ensure that the root of the Federation Service Proxy client certificate is trusted by the Federation Service.


 


Debug logs:


 


2008-06-03T22:13:09 [INFO] Processing HTTP POST: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


2008-06-03T22:13:09 [VERBOSE] Received message that is not SignIn Request or Response.


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Client cert is not present


2008-06-03T22:13:09 [EVENTLOG] Error ProxyWebMethodAccessDeniedNoCert ()


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Denying access


 


 


 


From the FS-A Proxy


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS


Event Category:    None


Event ID:                605


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             FSA-PROXY


Description:


The Federation Service Proxy encountered an exception when it called a Federation Service Web method.


Federation Server URL: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


Web method: GetProxyTrustConfiguration


Proxy certificate thumbprint: ECF1FE79E51231DF48098E1044233FCBDABF04CC


 


This may cause a user request to fail.


 


User Action


The exception details may give an indication of the precise problem.


Check network connectivity between the Federation Service Proxy and the Federation Service.


Ensure that the Federation Service is running.


Ensure that the Federation Service Proxy client authentication certificate has been added to the list of proxy authentication certificates in the Federation Service trust policy.


Ensure that the Federation Service Proxy client authentication certificate chains to a root that is trusted by the Federation Service.


Ensure that the Federation Service Internet Information Services (IIS) Secure Sockets Layer (SSL) server certificate chains to a root that is trusted by the Federation Service Proxy.


Ensure that the Federation Service Uniform Resource Locator (URL) that is configured in the Federation Service Proxy web.config uses the name that is the subject of the Federation Service IIS SSL server certificate.


 


Additional Data


Exception details:


System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


 




 


Debug logs:


 


2008-06-03T22:13:09 [VERBOSE] Processing HTTP GET: https://adfsaccount.adatum.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:treyresearch&wct=2008-06-03T22:13:09Z&wctx=https://adfsweb.treyresearch.net:8081/claimapp/\https://adfsweb.treyresearch.net:8081/claimapp/default.aspx


2008-06-03T22:13:09 [VERBOSE] Received SignIn Request.


2008-06-03T22:13:09 [ERROR] Exception from GetProxyTrustConfiguration: System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


2008-06-03T22:13:09 [EVENTLOG] Error ExceptionFromFedServer (https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx, GetProxyTrustConfiguration, ECF1FE79E51231DF48098E1044233FCBDABF04CC, System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data))


 


As you can see, there is a problem with the client auth certificate somewhere.  I did a fair amount of double checking my steps – but everything looked correct and seemed to be checking out.  The doubt was starting to creep in – I started to wonder how much I knew about this stuff!  Then I remembered an issue that came up a few weeks ago. 


The diagnostic tool does check for the existence and proper permissions of the private key and will flag it – but it does so in the user context.  ADFS is operating under the machine context.  So when I look at the certificate or run some certutil commands against it – it all checks out because I’m in my user security context.  If I launch a CMD prompt with AT scheduler and run the same commands or run the Diagnostic tool – I find the error.  The local computer does not have permissions to the private key of the client authentication certificate.


I was able to re-issue the certificate and mark the private keys as exportable, then do an export/import operation from the user store to computer store and everything worked as expected.


Since Client Authentication certificates are commonly used for user operations vs. computer operations – it is easy to see how others could hit this very same problem.  Hopefully the errors and debug log entries will make this blog post discoverable for others hitting this.

Interesting problem when adding an ADFS Proxy

June 4th, 2008 No comments

I am working on a blog post (step-by-step) for the Proxy component and I ran into a problem yesterday that ran me around pretty good.  We have seen this issue or variations of it on some support cases recently, so I thought the actual problem itself would make a good post.


The problem is caused by permissions to the private key on the Client Authentication Certificate needed.  In my initial attempt to setup and document the Proxy component, I made a request to my Standalone CA for a client authentication certificate.  After approving the request, the only option from the certificate web page was to “install this certificate”.  Next, when I viewed the certificate snap-in on the proxy server, I noticed that the certificate was installed to the user store and not the computer store.  I simply did a copy paste operation from user to computer.  This appeared to work for me because when I double clicked the certificate, it looked fine.  I saw the “You have a private key” on the general tab and I assumed all was well.


When I went to test – I received a failure.  The first thing I did was run the ADFS Diagnostic tool.  I ran it on the FS-A, then copied the file to the FS-A Proxy.  I passed all tests and the tool was not finding the failure! 


Here are the Event Log and Debug Logs from my FS-A and FS-A Proxy when I attempted to access the application with the Proxy in place:


From the FS-A


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS Federation Service


Event Category:    None


Event ID:                664


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             ADFSACCOUNT


Description:


The Federation Service failed a privileged Web method call because Secure Sockets Layer (SSL) client authentication information was not available.


 


This event can occur if the client does not provide a client certificate or if Internet Information Services (IIS) rejects the client’s certificate because it does not chain to a trusted root certification authority in the Federation Service.


 


User Action


If this is a valid call from the Federation Service Proxy, ensure that the root of the Federation Service Proxy client certificate is trusted by the Federation Service.


 


Debug logs:


 


2008-06-03T22:13:09 [INFO] Processing HTTP POST: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


2008-06-03T22:13:09 [VERBOSE] Received message that is not SignIn Request or Response.


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Client cert is not present


2008-06-03T22:13:09 [EVENTLOG] Error ProxyWebMethodAccessDeniedNoCert ()


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Denying access


 


 


 


From the FS-A Proxy


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS


Event Category:    None


Event ID:                605


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             FSA-PROXY


Description:


The Federation Service Proxy encountered an exception when it called a Federation Service Web method.


Federation Server URL: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


Web method: GetProxyTrustConfiguration


Proxy certificate thumbprint: ECF1FE79E51231DF48098E1044233FCBDABF04CC


 


This may cause a user request to fail.


 


User Action


The exception details may give an indication of the precise problem.


Check network connectivity between the Federation Service Proxy and the Federation Service.


Ensure that the Federation Service is running.


Ensure that the Federation Service Proxy client authentication certificate has been added to the list of proxy authentication certificates in the Federation Service trust policy.


Ensure that the Federation Service Proxy client authentication certificate chains to a root that is trusted by the Federation Service.


Ensure that the Federation Service Internet Information Services (IIS) Secure Sockets Layer (SSL) server certificate chains to a root that is trusted by the Federation Service Proxy.


Ensure that the Federation Service Uniform Resource Locator (URL) that is configured in the Federation Service Proxy web.config uses the name that is the subject of the Federation Service IIS SSL server certificate.


 


Additional Data


Exception details:


System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


 




 


Debug logs:


 


2008-06-03T22:13:09 [VERBOSE] Processing HTTP GET: https://adfsaccount.adatum.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:treyresearch&wct=2008-06-03T22:13:09Z&wctx=https://adfsweb.treyresearch.net:8081/claimapp/\https://adfsweb.treyresearch.net:8081/claimapp/default.aspx


2008-06-03T22:13:09 [VERBOSE] Received SignIn Request.


2008-06-03T22:13:09 [ERROR] Exception from GetProxyTrustConfiguration: System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


2008-06-03T22:13:09 [EVENTLOG] Error ExceptionFromFedServer (https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx, GetProxyTrustConfiguration, ECF1FE79E51231DF48098E1044233FCBDABF04CC, System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data))


 


As you can see, there is a problem with the client auth certificate somewhere.  I did a fair amount of double checking my steps – but everything looked correct and seemed to be checking out.  The doubt was starting to creep in – I started to wonder how much I knew about this stuff!  Then I remembered an issue that came up a few weeks ago. 


The diagnostic tool does check for the existence and proper permissions of the private key and will flag it – but it does so in the user context.  ADFS is operating under the machine context.  So when I look at the certificate or run some certutil commands against it – it all checks out because I’m in my user security context.  If I launch a CMD prompt with AT scheduler and run the same commands or run the Diagnostic tool – I find the error.  The local computer does not have permissions to the private key of the client authentication certificate.


I was able to re-issue the certificate and mark the private keys as exportable, then do an export/import operation from the user store to computer store and everything worked as expected.


Since Client Authentication certificates are commonly used for user operations vs. computer operations – it is easy to see how others could hit this very same problem.  Hopefully the errors and debug log entries will make this blog post discoverable for others hitting this.

Interesting problem when adding an ADFS Proxy

June 4th, 2008 Comments off

I am working on a blog post (step-by-step) for the Proxy component and I ran into a problem yesterday that ran me around pretty good.  We have seen this issue or variations of it on some support cases recently, so I thought the actual problem itself would make a good post.


The problem is caused by permissions to the private key on the Client Authentication Certificate needed.  In my initial attempt to setup and document the Proxy component, I made a request to my Standalone CA for a client authentication certificate.  After approving the request, the only option from the certificate web page was to “install this certificate”.  Next, when I viewed the certificate snap-in on the proxy server, I noticed that the certificate was installed to the user store and not the computer store.  I simply did a copy paste operation from user to computer.  This appeared to work for me because when I double clicked the certificate, it looked fine.  I saw the “You have a private key” on the general tab and I assumed all was well.


When I went to test – I received a failure.  The first thing I did was run the ADFS Diagnostic tool.  I ran it on the FS-A, then copied the file to the FS-A Proxy.  I passed all tests and the tool was not finding the failure! 


Here are the Event Log and Debug Logs from my FS-A and FS-A Proxy when I attempted to access the application with the Proxy in place:


From the FS-A


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS Federation Service


Event Category:    None


Event ID:                664


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             ADFSACCOUNT


Description:


The Federation Service failed a privileged Web method call because Secure Sockets Layer (SSL) client authentication information was not available.


 


This event can occur if the client does not provide a client certificate or if Internet Information Services (IIS) rejects the client’s certificate because it does not chain to a trusted root certification authority in the Federation Service.


 


User Action


If this is a valid call from the Federation Service Proxy, ensure that the root of the Federation Service Proxy client certificate is trusted by the Federation Service.


 


Debug logs:


 


2008-06-03T22:13:09 [INFO] Processing HTTP POST: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


2008-06-03T22:13:09 [VERBOSE] Received message that is not SignIn Request or Response.


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Client cert is not present


2008-06-03T22:13:09 [EVENTLOG] Error ProxyWebMethodAccessDeniedNoCert ()


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Denying access


 


 


 


From the FS-A Proxy


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS


Event Category:    None


Event ID:                605


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             FSA-PROXY


Description:


The Federation Service Proxy encountered an exception when it called a Federation Service Web method.


Federation Server URL: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


Web method: GetProxyTrustConfiguration


Proxy certificate thumbprint: ECF1FE79E51231DF48098E1044233FCBDABF04CC


 


This may cause a user request to fail.


 


User Action


The exception details may give an indication of the precise problem.


Check network connectivity between the Federation Service Proxy and the Federation Service.


Ensure that the Federation Service is running.


Ensure that the Federation Service Proxy client authentication certificate has been added to the list of proxy authentication certificates in the Federation Service trust policy.


Ensure that the Federation Service Proxy client authentication certificate chains to a root that is trusted by the Federation Service.


Ensure that the Federation Service Internet Information Services (IIS) Secure Sockets Layer (SSL) server certificate chains to a root that is trusted by the Federation Service Proxy.


Ensure that the Federation Service Uniform Resource Locator (URL) that is configured in the Federation Service Proxy web.config uses the name that is the subject of the Federation Service IIS SSL server certificate.


 


Additional Data


Exception details:


System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


 




 


Debug logs:


 


2008-06-03T22:13:09 [VERBOSE] Processing HTTP GET: https://adfsaccount.adatum.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:treyresearch&wct=2008-06-03T22:13:09Z&wctx=https://adfsweb.treyresearch.net:8081/claimapp/\https://adfsweb.treyresearch.net:8081/claimapp/default.aspx


2008-06-03T22:13:09 [VERBOSE] Received SignIn Request.


2008-06-03T22:13:09 [ERROR] Exception from GetProxyTrustConfiguration: System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


2008-06-03T22:13:09 [EVENTLOG] Error ExceptionFromFedServer (https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx, GetProxyTrustConfiguration, ECF1FE79E51231DF48098E1044233FCBDABF04CC, System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data))


 


As you can see, there is a problem with the client auth certificate somewhere.  I did a fair amount of double checking my steps – but everything looked correct and seemed to be checking out.  The doubt was starting to creep in – I started to wonder how much I knew about this stuff!  Then I remembered an issue that came up a few weeks ago. 


The diagnostic tool does check for the existence and proper permissions of the private key and will flag it – but it does so in the user context.  ADFS is operating under the machine context.  So when I look at the certificate or run some certutil commands against it – it all checks out because I’m in my user security context.  If I launch a CMD prompt with AT scheduler and run the same commands or run the Diagnostic tool – I find the error.  The local computer does not have permissions to the private key of the client authentication certificate.


I was able to re-issue the certificate and mark the private keys as exportable, then do an export/import operation from the user store to computer store and everything worked as expected.


Since Client Authentication certificates are commonly used for user operations vs. computer operations – it is easy to see how others could hit this very same problem.  Hopefully the errors and debug log entries will make this blog post discoverable for others hitting this.

Interesting problem when adding an ADFS Proxy

June 4th, 2008 No comments

I am working on a blog post (step-by-step) for the Proxy component and I ran into a problem yesterday that ran me around pretty good.  We have seen this issue or variations of it on some support cases recently, so I thought the actual problem itself would make a good post.


The problem is caused by permissions to the private key on the Client Authentication Certificate needed.  In my initial attempt to setup and document the Proxy component, I made a request to my Standalone CA for a client authentication certificate.  After approving the request, the only option from the certificate web page was to “install this certificate”.  Next, when I viewed the certificate snap-in on the proxy server, I noticed that the certificate was installed to the user store and not the computer store.  I simply did a copy paste operation from user to computer.  This appeared to work for me because when I double clicked the certificate, it looked fine.  I saw the “You have a private key” on the general tab and I assumed all was well.


When I went to test – I received a failure.  The first thing I did was run the ADFS Diagnostic tool.  I ran it on the FS-A, then copied the file to the FS-A Proxy.  I passed all tests and the tool was not finding the failure! 


Here are the Event Log and Debug Logs from my FS-A and FS-A Proxy when I attempted to access the application with the Proxy in place:


From the FS-A


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS Federation Service


Event Category:    None


Event ID:                664


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             ADFSACCOUNT


Description:


The Federation Service failed a privileged Web method call because Secure Sockets Layer (SSL) client authentication information was not available.


 


This event can occur if the client does not provide a client certificate or if Internet Information Services (IIS) rejects the client’s certificate because it does not chain to a trusted root certification authority in the Federation Service.


 


User Action


If this is a valid call from the Federation Service Proxy, ensure that the root of the Federation Service Proxy client certificate is trusted by the Federation Service.


 


Debug logs:


 


2008-06-03T22:13:09 [INFO] Processing HTTP POST: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


2008-06-03T22:13:09 [VERBOSE] Received message that is not SignIn Request or Response.


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Client cert is not present


2008-06-03T22:13:09 [EVENTLOG] Error ProxyWebMethodAccessDeniedNoCert ()


2008-06-03T22:13:09 [ERROR] MethodInvocationCheck: Denying access


 


 


 


From the FS-A Proxy


 


Event Viewer:


 


Event Type:           Error


Event Source:       ADFS


Event Category:    None


Event ID:                605


Date:                      6/3/2008


Time:                      5:13:09 PM


User:                      N/A


Computer:             FSA-PROXY


Description:


The Federation Service Proxy encountered an exception when it called a Federation Service Web method.


Federation Server URL: https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx


Web method: GetProxyTrustConfiguration


Proxy certificate thumbprint: ECF1FE79E51231DF48098E1044233FCBDABF04CC


 


This may cause a user request to fail.


 


User Action


The exception details may give an indication of the precise problem.


Check network connectivity between the Federation Service Proxy and the Federation Service.


Ensure that the Federation Service is running.


Ensure that the Federation Service Proxy client authentication certificate has been added to the list of proxy authentication certificates in the Federation Service trust policy.


Ensure that the Federation Service Proxy client authentication certificate chains to a root that is trusted by the Federation Service.


Ensure that the Federation Service Internet Information Services (IIS) Secure Sockets Layer (SSL) server certificate chains to a root that is trusted by the Federation Service Proxy.


Ensure that the Federation Service Uniform Resource Locator (URL) that is configured in the Federation Service Proxy web.config uses the name that is the subject of the Federation Service IIS SSL server certificate.


 


Additional Data


Exception details:


System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


 




 


Debug logs:


 


2008-06-03T22:13:09 [VERBOSE] Processing HTTP GET: https://adfsaccount.adatum.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:treyresearch&wct=2008-06-03T22:13:09Z&wctx=https://adfsweb.treyresearch.net:8081/claimapp/https://adfsweb.treyresearch.net:8081/claimapp/default.aspx


2008-06-03T22:13:09 [VERBOSE] Received SignIn Request.


2008-06-03T22:13:09 [ERROR] Exception from GetProxyTrustConfiguration: System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data)


2008-06-03T22:13:09 [EVENTLOG] Error ExceptionFromFedServer (https://adfsaccount.adatum.com/adfs/fs/FederationServerService.asmx, GetProxyTrustConfiguration, ECF1FE79E51231DF48098E1044233FCBDABF04CC, System.Web.Services.Protocols.SoapException: Server was unable to process request. —> Attempted to perform an unauthorized operation.


   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)


   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


   at System.Web.Security.SingleSignOn.FederationServerSoapProxy.GetProxyTrustConfiguration(VersionInformation proxyVersion, VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& trustConfig)


   at System.Web.Security.SingleSignOn.LSPersistentState.GetPolicy(VersionInformation& fsVersion, ProxyInformation& proxyInformation, TrustConfigurationData[]& data))


 


As you can see, there is a problem with the client auth certificate somewhere.  I did a fair amount of double checking my steps – but everything looked correct and seemed to be checking out.  The doubt was starting to creep in – I started to wonder how much I knew about this stuff!  Then I remembered an issue that came up a few weeks ago. 


The diagnostic tool does check for the existence and proper permissions of the private key and will flag it – but it does so in the user context.  ADFS is operating under the machine context.  So when I look at the certificate or run some certutil commands against it – it all checks out because I’m in my user security context.  If I launch a CMD prompt with AT scheduler and run the same commands or run the Diagnostic tool – I find the error.  The local computer does not have permissions to the private key of the client authentication certificate.


I was able to re-issue the certificate and mark the private keys as exportable, then do an export/import operation from the user store to computer store and everything worked as expected.


Since Client Authentication certificates are commonly used for user operations vs. computer operations – it is easy to see how others could hit this very same problem.  Hopefully the errors and debug log entries will make this blog post discoverable for others hitting this.