Archive

Archive for the ‘Installation-How to’ Category

ADFS Certificates – SSL, Token Signing, and Client Authentication Certs

July 24th, 2007 Comments off

 


We are seeing quite a few support calls relating to certificate problems. Many of these are due to a misunderstanding of how the various certificates are used.

ADFS/PKI issues are often very difficult to diagnose for the following reason – a lack of logging telling you what the problem is.

For example – if the SSL certificate on your Web Server is incorrect or has a problem like missing a private key. The user experience will be a page can’t be displayed error and absolutely nothing will be logged in the event viewer, security log, or adfs debug logs.

There are several variations of this – but if you aren’t getting *anything* in the logs – start looking at your certificates! More times than not – it is the SSL certificate and you aren’t even getting to ADFS which is why there aren’t any error messages to work with.

Other sub-items that come to mind on this topic are:

1. Using Certutil to verify the certificates in question

2. What type of certificate should I use? 3rd Party, an internal CA, or a combination of the two.

In addition to this blog, you should also review the TechNet documentation on Understanding Certificates starting here. Between the two, I hope it makes it clear what goes where.

Also, it may be helpful to revisit my blog on the PKI portion of setting up a lab.  That is located here.


ADFS Certificates for Federation Servers

SSL Certificate

The SSL certificates must be trusted by the client machine which accesses the web sites. Since the client machine (in a Federated WebSSO scenario) will visit the WS, then the FS-R, then the FS-A, the client must trust all three SSL certificates. For this reason, it may make sense to use a 3rd party certificate for the SSL certificate.

A SSL certificate is in place to encrypt the session between client and the server. These certificates are not specific to ADFS, but rather specific to IIS.

The Subject Name of the SSL certificate must match the names used in the ADFS configuration. For example, if you specify a federation server endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – then the subject name on the SSL certificate for that server must be “adfsresource.treyresearch.net” This is a very important item and a common misconfiguration. The name can be anything – it just needs to match. If you choose to setup ADFS for use on the intranet only and you want to use only the host name, then the endpoint URL would be https://adfsresource/adfs/ls/ and the Subject Name on the certificate should be “adfsresource”

The same Subject Name rules also apply to the web sites protected by ADFS. The name on the certificate should match the name clients will use to access the ADFS protected web site.

Token Signing Certificate

On the Federation Servers – you also need a token signing certificate. This certificate can be any X.509 certificate, the intended purpose or EKU doesn’t matter. The “issued to” name doesn’t matter. Any X.509 certificate will do. When you install the Federation Server role – setup will prompt you to pick a token signing certificate OR let setup create a self signed certificate for you.

Self Signed Certificates are OK for a lab – but should not be used in production deployments.

If you choose to select a token signing certificate in the setup portion, you will be presented with a list of all certificates present in the local machine personal certificate store. Whichever option you choose, the setup program will place an export of the token signing certificate in the list of verification certificates for the same machine. A verification certificate is simply an export (less the private key) of the token signing certificate. Each Federation Server must have a verification certificate for its own token signing certificate. If you change the token signing certificate later – the adfs.msc program will display a message telling you that the new verification certificate will be added to the list of verification certificates.

It seems a little strange that a Federation Server needs to verify its own token signing certificate, but that is the way it works…

A token signing certificate is used to “sign the ADFS authentication token” – this is the token that contains a users claims and is used to make authorization decisions at the website. The verification token is used to “verify” the token was sent by the federated partner and that it has not been tampered with.

In a Federated WebSSO scenario where you have an Account Partner and a Resource Partner, the Account Partner’s verification certificate must be present on the Resource Partners trust policy file. This certificate (by default) must be trusted, must be able to chain to the root, and must be able to access the certificate revocation list.

IMPORTANT NOTE:

Using the SSL certificate for the token signing certificate will work – but this should not be the configuration you use in production. This is considered bad key hygiene. The SSL certificate for the web site serves one purpose – the token signing certificate serves an entirely different purpose. This is the most misunderstood item we see.

Here is a screenshot from my Federation Server – notice how the SSL certificate is “issued to” adfsresource.treyresearch.net and the Token Signing certificate I use has a friendly name in the Issued To


ADFS Certificates for Federation Server Proxies

SSL Certificate

As with the other Federation Server roles, the FS-P web site will need a SSL certificate. The Subject Name must match the Federation Server endpoint URL specified on the Federation Server. If you have your endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – the SSL certificate for the federation server itself should have a Subject Name of adfsresource.treyresearch.net and the Federation Server Proxy SSL certificate should also have a Subject Name of adfsresource.treyresearch.net. Even if the machine name is adfsproxy.treyresearch.net – the URL the client will hit is adfsresource.treyresearch.net. Whether or not the client is redirected to the IP address of adfsresource or adfsproxy depends on how the client resolves that name via DNS.

A typical name resolution setup for a Proxy scenario would be to have client machines on the internal LAN resolve adfsresource to the actual IP address of adfsresource.

Client machines on the internet (or outside of your internal LAN) resolve the name adfsresource.treyresearch.net to the IP address of adfsproxy.treyresearch.net. It is important to remember that you won’t specify the name adfsproxy.treyresearch.net anywhere in your setup. The website on this server should have a certificate issued to the name adfsresource.treyresearch.net.

The adfsproxy.treresearch.net server should be configured to resolve the name adfsresource.treyresearch.net to the actual IP address of adfsresource.treyresearch.net (this machine should be the only server in the DMZ/Internet) that knows adfsresource by its real IP. This is commonly accomplished by using a host file on adfsproxy.

With the scenario setup like this – the internal LAN clients will enjoy a single sign on experience when visiting an ADFS resource (not be prompted for credentials). Users external to the LAN will be presented with a forms based authentication page asking for username/password.

This is typically a desired configuration because the internet user probably hasn’t authenticated with his or her home domain.

Client Authentication Certificate

I like to explain the client authenticate certificate as “It is sort of like the token signing certificate, but for ADFS proxy servers” – while this isn’t really the case, it is a different certificate than what is used for SSL on the website. This certificate must have “client authentication” as an intended purpose. When you install the Federation Proxy component, when you choose your client authentication certificate, you will be presented with a list of certificates that have an EKU of “Client Authentication.” If you don’t have any in the local machine personal store, the list will be empty.

The client authentication certificate and its private key reside on the ADFS Proxy Server, but a copy of this certificate with only the public key resides on the Federation Server. This is why I try to explain it as “think of it like the proxies TS certificate” – it is different in many ways. Most importantly, it isn’t used to sign any tokens. But again – this is a completely different certificate than the one used for SSL on the server.

ADFS Certificates – SSL, Token Signing, and Client Authentication Certs

July 24th, 2007 No comments

 


We are seeing quite a few support calls relating to certificate problems. Many of these are due to a misunderstanding of how the various certificates are used.

ADFS/PKI issues are often very difficult to diagnose for the following reason – a lack of logging telling you what the problem is.

For example – if the SSL certificate on your Web Server is incorrect or has a problem like missing a private key. The user experience will be a page can’t be displayed error and absolutely nothing will be logged in the event viewer, security log, or adfs debug logs.

There are several variations of this – but if you aren’t getting *anything* in the logs – start looking at your certificates! More times than not – it is the SSL certificate and you aren’t even getting to ADFS which is why there aren’t any error messages to work with.

Other sub-items that come to mind on this topic are:

1. Using Certutil to verify the certificates in question

2. What type of certificate should I use? 3rd Party, an internal CA, or a combination of the two.

In addition to this blog, you should also review the TechNet documentation on Understanding Certificates starting here. Between the two, I hope it makes it clear what goes where.

Also, it may be helpful to revisit my blog on the PKI portion of setting up a lab.  That is located here.


ADFS Certificates for Federation Servers

SSL Certificate

The SSL certificates must be trusted by the client machine which accesses the web sites. Since the client machine (in a Federated WebSSO scenario) will visit the WS, then the FS-R, then the FS-A, the client must trust all three SSL certificates. For this reason, it may make sense to use a 3rd party certificate for the SSL certificate.

A SSL certificate is in place to encrypt the session between client and the server. These certificates are not specific to ADFS, but rather specific to IIS.

The Subject Name of the SSL certificate must match the names used in the ADFS configuration. For example, if you specify a federation server endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – then the subject name on the SSL certificate for that server must be “adfsresource.treyresearch.net” This is a very important item and a common misconfiguration. The name can be anything – it just needs to match. If you choose to setup ADFS for use on the intranet only and you want to use only the host name, then the endpoint URL would be https://adfsresource/adfs/ls/ and the Subject Name on the certificate should be “adfsresource”

The same Subject Name rules also apply to the web sites protected by ADFS. The name on the certificate should match the name clients will use to access the ADFS protected web site.

Token Signing Certificate

On the Federation Servers – you also need a token signing certificate. This certificate can be any X.509 certificate, the intended purpose or EKU doesn’t matter. The “issued to” name doesn’t matter. Any X.509 certificate will do. When you install the Federation Server role – setup will prompt you to pick a token signing certificate OR let setup create a self signed certificate for you.

Self Signed Certificates are OK for a lab – but should not be used in production deployments.

If you choose to select a token signing certificate in the setup portion, you will be presented with a list of all certificates present in the local machine personal certificate store. Whichever option you choose, the setup program will place an export of the token signing certificate in the list of verification certificates for the same machine. A verification certificate is simply an export (less the private key) of the token signing certificate. Each Federation Server must have a verification certificate for its own token signing certificate. If you change the token signing certificate later – the adfs.msc program will display a message telling you that the new verification certificate will be added to the list of verification certificates.

It seems a little strange that a Federation Server needs to verify its own token signing certificate, but that is the way it works…

A token signing certificate is used to “sign the ADFS authentication token” – this is the token that contains a users claims and is used to make authorization decisions at the website. The verification token is used to “verify” the token was sent by the federated partner and that it has not been tampered with.

In a Federated WebSSO scenario where you have an Account Partner and a Resource Partner, the Account Partner’s verification certificate must be present on the Resource Partners trust policy file. This certificate (by default) must be trusted, must be able to chain to the root, and must be able to access the certificate revocation list.

IMPORTANT NOTE:

Using the SSL certificate for the token signing certificate will work – but this should not be the configuration you use in production. This is considered bad key hygiene. The SSL certificate for the web site serves one purpose – the token signing certificate serves an entirely different purpose. This is the most misunderstood item we see.

Here is a screenshot from my Federation Server – notice how the SSL certificate is “issued to” adfsresource.treyresearch.net and the Token Signing certificate I use has a friendly name in the Issued To


ADFS Certificates for Federation Server Proxies

SSL Certificate

As with the other Federation Server roles, the FS-P web site will need a SSL certificate. The Subject Name must match the Federation Server endpoint URL specified on the Federation Server. If you have your endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – the SSL certificate for the federation server itself should have a Subject Name of adfsresource.treyresearch.net and the Federation Server Proxy SSL certificate should also have a Subject Name of adfsresource.treyresearch.net. Even if the machine name is adfsproxy.treyresearch.net – the URL the client will hit is adfsresource.treyresearch.net. Whether or not the client is redirected to the IP address of adfsresource or adfsproxy depends on how the client resolves that name via DNS.

A typical name resolution setup for a Proxy scenario would be to have client machines on the internal LAN resolve adfsresource to the actual IP address of adfsresource.

Client machines on the internet (or outside of your internal LAN) resolve the name adfsresource.treyresearch.net to the IP address of adfsproxy.treyresearch.net. It is important to remember that you won’t specify the name adfsproxy.treyresearch.net anywhere in your setup. The website on this server should have a certificate issued to the name adfsresource.treyresearch.net.

The adfsproxy.treresearch.net server should be configured to resolve the name adfsresource.treyresearch.net to the actual IP address of adfsresource.treyresearch.net (this machine should be the only server in the DMZ/Internet) that knows adfsresource by its real IP. This is commonly accomplished by using a host file on adfsproxy.

With the scenario setup like this – the internal LAN clients will enjoy a single sign on experience when visiting an ADFS resource (not be prompted for credentials). Users external to the LAN will be presented with a forms based authentication page asking for username/password.

This is typically a desired configuration because the internet user probably hasn’t authenticated with his or her home domain.

Client Authentication Certificate

I like to explain the client authenticate certificate as “It is sort of like the token signing certificate, but for ADFS proxy servers” – while this isn’t really the case, it is a different certificate than what is used for SSL on the website. This certificate must have “client authentication” as an intended purpose. When you install the Federation Proxy component, when you choose your client authentication certificate, you will be presented with a list of certificates that have an EKU of “Client Authentication.” If you don’t have any in the local machine personal store, the list will be empty.

The client authentication certificate and its private key reside on the ADFS Proxy Server, but a copy of this certificate with only the public key resides on the Federation Server. This is why I try to explain it as “think of it like the proxies TS certificate” – it is different in many ways. Most importantly, it isn’t used to sign any tokens. But again – this is a completely different certificate than the one used for SSL on the server.

ADFS Certificates – SSL, Token Signing, and Client Authentication Certs

July 24th, 2007 No comments

 


We are seeing quite a few support calls relating to certificate problems. Many of these are due to a misunderstanding of how the various certificates are used.

ADFS/PKI issues are often very difficult to diagnose for the following reason – a lack of logging telling you what the problem is.

For example – if the SSL certificate on your Web Server is incorrect or has a problem like missing a private key. The user experience will be a page can’t be displayed error and absolutely nothing will be logged in the event viewer, security log, or adfs debug logs.

There are several variations of this – but if you aren’t getting *anything* in the logs – start looking at your certificates! More times than not – it is the SSL certificate and you aren’t even getting to ADFS which is why there aren’t any error messages to work with.

Other sub-items that come to mind on this topic are:

1. Using Certutil to verify the certificates in question

2. What type of certificate should I use? 3rd Party, an internal CA, or a combination of the two.

In addition to this blog, you should also review the TechNet documentation on Understanding Certificates starting here. Between the two, I hope it makes it clear what goes where.

Also, it may be helpful to revisit my blog on the PKI portion of setting up a lab.  That is located here.


ADFS Certificates for Federation Servers

SSL Certificate

The SSL certificates must be trusted by the client machine which accesses the web sites. Since the client machine (in a Federated WebSSO scenario) will visit the WS, then the FS-R, then the FS-A, the client must trust all three SSL certificates. For this reason, it may make sense to use a 3rd party certificate for the SSL certificate.

A SSL certificate is in place to encrypt the session between client and the server. These certificates are not specific to ADFS, but rather specific to IIS.

The Subject Name of the SSL certificate must match the names used in the ADFS configuration. For example, if you specify a federation server endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – then the subject name on the SSL certificate for that server must be “adfsresource.treyresearch.net” This is a very important item and a common misconfiguration. The name can be anything – it just needs to match. If you choose to setup ADFS for use on the intranet only and you want to use only the host name, then the endpoint URL would be https://adfsresource/adfs/ls/ and the Subject Name on the certificate should be “adfsresource”

The same Subject Name rules also apply to the web sites protected by ADFS. The name on the certificate should match the name clients will use to access the ADFS protected web site.

Token Signing Certificate

On the Federation Servers – you also need a token signing certificate. This certificate can be any X.509 certificate, the intended purpose or EKU doesn’t matter. The “issued to” name doesn’t matter. Any X.509 certificate will do. When you install the Federation Server role – setup will prompt you to pick a token signing certificate OR let setup create a self signed certificate for you.

Self Signed Certificates are OK for a lab – but should not be used in production deployments.

If you choose to select a token signing certificate in the setup portion, you will be presented with a list of all certificates present in the local machine personal certificate store. Whichever option you choose, the setup program will place an export of the token signing certificate in the list of verification certificates for the same machine. A verification certificate is simply an export (less the private key) of the token signing certificate. Each Federation Server must have a verification certificate for its own token signing certificate. If you change the token signing certificate later – the adfs.msc program will display a message telling you that the new verification certificate will be added to the list of verification certificates.

It seems a little strange that a Federation Server needs to verify its own token signing certificate, but that is the way it works…

A token signing certificate is used to “sign the ADFS authentication token” – this is the token that contains a users claims and is used to make authorization decisions at the website. The verification token is used to “verify” the token was sent by the federated partner and that it has not been tampered with.

In a Federated WebSSO scenario where you have an Account Partner and a Resource Partner, the Account Partner’s verification certificate must be present on the Resource Partners trust policy file. This certificate (by default) must be trusted, must be able to chain to the root, and must be able to access the certificate revocation list.

IMPORTANT NOTE:

Using the SSL certificate for the token signing certificate will work – but this should not be the configuration you use in production. This is considered bad key hygiene. The SSL certificate for the web site serves one purpose – the token signing certificate serves an entirely different purpose. This is the most misunderstood item we see.

Here is a screenshot from my Federation Server – notice how the SSL certificate is “issued to” adfsresource.treyresearch.net and the Token Signing certificate I use has a friendly name in the Issued To


ADFS Certificates for Federation Server Proxies

SSL Certificate

As with the other Federation Server roles, the FS-P web site will need a SSL certificate. The Subject Name must match the Federation Server endpoint URL specified on the Federation Server. If you have your endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – the SSL certificate for the federation server itself should have a Subject Name of adfsresource.treyresearch.net and the Federation Server Proxy SSL certificate should also have a Subject Name of adfsresource.treyresearch.net. Even if the machine name is adfsproxy.treyresearch.net – the URL the client will hit is adfsresource.treyresearch.net. Whether or not the client is redirected to the IP address of adfsresource or adfsproxy depends on how the client resolves that name via DNS.

A typical name resolution setup for a Proxy scenario would be to have client machines on the internal LAN resolve adfsresource to the actual IP address of adfsresource.

Client machines on the internet (or outside of your internal LAN) resolve the name adfsresource.treyresearch.net to the IP address of adfsproxy.treyresearch.net. It is important to remember that you won’t specify the name adfsproxy.treyresearch.net anywhere in your setup. The website on this server should have a certificate issued to the name adfsresource.treyresearch.net.

The adfsproxy.treresearch.net server should be configured to resolve the name adfsresource.treyresearch.net to the actual IP address of adfsresource.treyresearch.net (this machine should be the only server in the DMZ/Internet) that knows adfsresource by its real IP. This is commonly accomplished by using a host file on adfsproxy.

With the scenario setup like this – the internal LAN clients will enjoy a single sign on experience when visiting an ADFS resource (not be prompted for credentials). Users external to the LAN will be presented with a forms based authentication page asking for username/password.

This is typically a desired configuration because the internet user probably hasn’t authenticated with his or her home domain.

Client Authentication Certificate

I like to explain the client authenticate certificate as “It is sort of like the token signing certificate, but for ADFS proxy servers” – while this isn’t really the case, it is a different certificate than what is used for SSL on the website. This certificate must have “client authentication” as an intended purpose. When you install the Federation Proxy component, when you choose your client authentication certificate, you will be presented with a list of certificates that have an EKU of “Client Authentication.” If you don’t have any in the local machine personal store, the list will be empty.

The client authentication certificate and its private key reside on the ADFS Proxy Server, but a copy of this certificate with only the public key resides on the Federation Server. This is why I try to explain it as “think of it like the proxies TS certificate” – it is different in many ways. Most importantly, it isn’t used to sign any tokens. But again – this is a completely different certificate than the one used for SSL on the server.

ADFS Certificates – SSL, Token Signing, and Client Authentication Certs

July 24th, 2007 No comments

 


We are seeing quite a few support calls relating to certificate problems. Many of these are due to a misunderstanding of how the various certificates are used.

ADFS/PKI issues are often very difficult to diagnose for the following reason – a lack of logging telling you what the problem is.

For example – if the SSL certificate on your Web Server is incorrect or has a problem like missing a private key. The user experience will be a page can’t be displayed error and absolutely nothing will be logged in the event viewer, security log, or adfs debug logs.

There are several variations of this – but if you aren’t getting *anything* in the logs – start looking at your certificates! More times than not – it is the SSL certificate and you aren’t even getting to ADFS which is why there aren’t any error messages to work with.

Other sub-items that come to mind on this topic are:

1. Using Certutil to verify the certificates in question

2. What type of certificate should I use? 3rd Party, an internal CA, or a combination of the two.

In addition to this blog, you should also review the TechNet documentation on Understanding Certificates starting here. Between the two, I hope it makes it clear what goes where.

Also, it may be helpful to revisit my blog on the PKI portion of setting up a lab.  That is located here.


ADFS Certificates for Federation Servers

SSL Certificate

The SSL certificates must be trusted by the client machine which accesses the web sites. Since the client machine (in a Federated WebSSO scenario) will visit the WS, then the FS-R, then the FS-A, the client must trust all three SSL certificates. For this reason, it may make sense to use a 3rd party certificate for the SSL certificate.

A SSL certificate is in place to encrypt the session between client and the server. These certificates are not specific to ADFS, but rather specific to IIS.

The Subject Name of the SSL certificate must match the names used in the ADFS configuration. For example, if you specify a federation server endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – then the subject name on the SSL certificate for that server must be “adfsresource.treyresearch.net” This is a very important item and a common misconfiguration. The name can be anything – it just needs to match. If you choose to setup ADFS for use on the intranet only and you want to use only the host name, then the endpoint URL would be https://adfsresource/adfs/ls/ and the Subject Name on the certificate should be “adfsresource”

The same Subject Name rules also apply to the web sites protected by ADFS. The name on the certificate should match the name clients will use to access the ADFS protected web site.

Token Signing Certificate

On the Federation Servers – you also need a token signing certificate. This certificate can be any X.509 certificate, the intended purpose or EKU doesn’t matter. The “issued to” name doesn’t matter. Any X.509 certificate will do. When you install the Federation Server role – setup will prompt you to pick a token signing certificate OR let setup create a self signed certificate for you.

Self Signed Certificates are OK for a lab – but should not be used in production deployments.

If you choose to select a token signing certificate in the setup portion, you will be presented with a list of all certificates present in the local machine personal certificate store. Whichever option you choose, the setup program will place an export of the token signing certificate in the list of verification certificates for the same machine. A verification certificate is simply an export (less the private key) of the token signing certificate. Each Federation Server must have a verification certificate for its own token signing certificate. If you change the token signing certificate later – the adfs.msc program will display a message telling you that the new verification certificate will be added to the list of verification certificates.

It seems a little strange that a Federation Server needs to verify its own token signing certificate, but that is the way it works…

A token signing certificate is used to “sign the ADFS authentication token” – this is the token that contains a users claims and is used to make authorization decisions at the website. The verification token is used to “verify” the token was sent by the federated partner and that it has not been tampered with.

In a Federated WebSSO scenario where you have an Account Partner and a Resource Partner, the Account Partner’s verification certificate must be present on the Resource Partners trust policy file. This certificate (by default) must be trusted, must be able to chain to the root, and must be able to access the certificate revocation list.

IMPORTANT NOTE:

Using the SSL certificate for the token signing certificate will work – but this should not be the configuration you use in production. This is considered bad key hygiene. The SSL certificate for the web site serves one purpose – the token signing certificate serves an entirely different purpose. This is the most misunderstood item we see.

Here is a screenshot from my Federation Server – notice how the SSL certificate is “issued to” adfsresource.treyresearch.net and the Token Signing certificate I use has a friendly name in the Issued To


ADFS Certificates for Federation Server Proxies

SSL Certificate

As with the other Federation Server roles, the FS-P web site will need a SSL certificate. The Subject Name must match the Federation Server endpoint URL specified on the Federation Server. If you have your endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – the SSL certificate for the federation server itself should have a Subject Name of adfsresource.treyresearch.net and the Federation Server Proxy SSL certificate should also have a Subject Name of adfsresource.treyresearch.net. Even if the machine name is adfsproxy.treyresearch.net – the URL the client will hit is adfsresource.treyresearch.net. Whether or not the client is redirected to the IP address of adfsresource or adfsproxy depends on how the client resolves that name via DNS.

A typical name resolution setup for a Proxy scenario would be to have client machines on the internal LAN resolve adfsresource to the actual IP address of adfsresource.

Client machines on the internet (or outside of your internal LAN) resolve the name adfsresource.treyresearch.net to the IP address of adfsproxy.treyresearch.net. It is important to remember that you won’t specify the name adfsproxy.treyresearch.net anywhere in your setup. The website on this server should have a certificate issued to the name adfsresource.treyresearch.net.

The adfsproxy.treresearch.net server should be configured to resolve the name adfsresource.treyresearch.net to the actual IP address of adfsresource.treyresearch.net (this machine should be the only server in the DMZ/Internet) that knows adfsresource by its real IP. This is commonly accomplished by using a host file on adfsproxy.

With the scenario setup like this – the internal LAN clients will enjoy a single sign on experience when visiting an ADFS resource (not be prompted for credentials). Users external to the LAN will be presented with a forms based authentication page asking for username/password.

This is typically a desired configuration because the internet user probably hasn’t authenticated with his or her home domain.

Client Authentication Certificate

I like to explain the client authenticate certificate as “It is sort of like the token signing certificate, but for ADFS proxy servers” – while this isn’t really the case, it is a different certificate than what is used for SSL on the website. This certificate must have “client authentication” as an intended purpose. When you install the Federation Proxy component, when you choose your client authentication certificate, you will be presented with a list of certificates that have an EKU of “Client Authentication.” If you don’t have any in the local machine personal store, the list will be empty.

The client authentication certificate and its private key reside on the ADFS Proxy Server, but a copy of this certificate with only the public key resides on the Federation Server. This is why I try to explain it as “think of it like the proxies TS certificate” – it is different in many ways. Most importantly, it isn’t used to sign any tokens. But again – this is a completely different certificate than the one used for SSL on the server.

ADFS Certificates – SSL, Token Signing, and Client Authentication Certs

July 24th, 2007 No comments

 


We are seeing quite a few support calls relating to certificate problems. Many of these are due to a misunderstanding of how the various certificates are used.

ADFS/PKI issues are often very difficult to diagnose for the following reason – a lack of logging telling you what the problem is.

For example – if the SSL certificate on your Web Server is incorrect or has a problem like missing a private key. The user experience will be a page can’t be displayed error and absolutely nothing will be logged in the event viewer, security log, or adfs debug logs.

There are several variations of this – but if you aren’t getting *anything* in the logs – start looking at your certificates! More times than not – it is the SSL certificate and you aren’t even getting to ADFS which is why there aren’t any error messages to work with.

Other sub-items that come to mind on this topic are:

1. Using Certutil to verify the certificates in question

2. What type of certificate should I use? 3rd Party, an internal CA, or a combination of the two.

In addition to this blog, you should also review the TechNet documentation on Understanding Certificates starting here. Between the two, I hope it makes it clear what goes where.

Also, it may be helpful to revisit my blog on the PKI portion of setting up a lab.  That is located here.


ADFS Certificates for Federation Servers

SSL Certificate

The SSL certificates must be trusted by the client machine which accesses the web sites. Since the client machine (in a Federated WebSSO scenario) will visit the WS, then the FS-R, then the FS-A, the client must trust all three SSL certificates. For this reason, it may make sense to use a 3rd party certificate for the SSL certificate.

A SSL certificate is in place to encrypt the session between client and the server. These certificates are not specific to ADFS, but rather specific to IIS.

The Subject Name of the SSL certificate must match the names used in the ADFS configuration. For example, if you specify a federation server endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – then the subject name on the SSL certificate for that server must be “adfsresource.treyresearch.net” This is a very important item and a common misconfiguration. The name can be anything – it just needs to match. If you choose to setup ADFS for use on the intranet only and you want to use only the host name, then the endpoint URL would be https://adfsresource/adfs/ls/ and the Subject Name on the certificate should be “adfsresource”

The same Subject Name rules also apply to the web sites protected by ADFS. The name on the certificate should match the name clients will use to access the ADFS protected web site.

Token Signing Certificate

On the Federation Servers – you also need a token signing certificate. This certificate can be any X.509 certificate, the intended purpose or EKU doesn’t matter. The “issued to” name doesn’t matter. Any X.509 certificate will do. When you install the Federation Server role – setup will prompt you to pick a token signing certificate OR let setup create a self signed certificate for you.

Self Signed Certificates are OK for a lab – but should not be used in production deployments.

If you choose to select a token signing certificate in the setup portion, you will be presented with a list of all certificates present in the local machine personal certificate store. Whichever option you choose, the setup program will place an export of the token signing certificate in the list of verification certificates for the same machine. A verification certificate is simply an export (less the private key) of the token signing certificate. Each Federation Server must have a verification certificate for its own token signing certificate. If you change the token signing certificate later – the adfs.msc program will display a message telling you that the new verification certificate will be added to the list of verification certificates.

It seems a little strange that a Federation Server needs to verify its own token signing certificate, but that is the way it works…

A token signing certificate is used to “sign the ADFS authentication token” – this is the token that contains a users claims and is used to make authorization decisions at the website. The verification token is used to “verify” the token was sent by the federated partner and that it has not been tampered with.

In a Federated WebSSO scenario where you have an Account Partner and a Resource Partner, the Account Partner’s verification certificate must be present on the Resource Partners trust policy file. This certificate (by default) must be trusted, must be able to chain to the root, and must be able to access the certificate revocation list.

IMPORTANT NOTE:

Using the SSL certificate for the token signing certificate will work – but this should not be the configuration you use in production. This is considered bad key hygiene. The SSL certificate for the web site serves one purpose – the token signing certificate serves an entirely different purpose. This is the most misunderstood item we see.

Here is a screenshot from my Federation Server – notice how the SSL certificate is “issued to” adfsresource.treyresearch.net and the Token Signing certificate I use has a friendly name in the Issued To


ADFS Certificates for Federation Server Proxies

SSL Certificate

As with the other Federation Server roles, the FS-P web site will need a SSL certificate. The Subject Name must match the Federation Server endpoint URL specified on the Federation Server. If you have your endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – the SSL certificate for the federation server itself should have a Subject Name of adfsresource.treyresearch.net and the Federation Server Proxy SSL certificate should also have a Subject Name of adfsresource.treyresearch.net. Even if the machine name is adfsproxy.treyresearch.net – the URL the client will hit is adfsresource.treyresearch.net. Whether or not the client is redirected to the IP address of adfsresource or adfsproxy depends on how the client resolves that name via DNS.

A typical name resolution setup for a Proxy scenario would be to have client machines on the internal LAN resolve adfsresource to the actual IP address of adfsresource.

Client machines on the internet (or outside of your internal LAN) resolve the name adfsresource.treyresearch.net to the IP address of adfsproxy.treyresearch.net. It is important to remember that you won’t specify the name adfsproxy.treyresearch.net anywhere in your setup. The website on this server should have a certificate issued to the name adfsresource.treyresearch.net.

The adfsproxy.treresearch.net server should be configured to resolve the name adfsresource.treyresearch.net to the actual IP address of adfsresource.treyresearch.net (this machine should be the only server in the DMZ/Internet) that knows adfsresource by its real IP. This is commonly accomplished by using a host file on adfsproxy.

With the scenario setup like this – the internal LAN clients will enjoy a single sign on experience when visiting an ADFS resource (not be prompted for credentials). Users external to the LAN will be presented with a forms based authentication page asking for username/password.

This is typically a desired configuration because the internet user probably hasn’t authenticated with his or her home domain.

Client Authentication Certificate

I like to explain the client authenticate certificate as “It is sort of like the token signing certificate, but for ADFS proxy servers” – while this isn’t really the case, it is a different certificate than what is used for SSL on the website. This certificate must have “client authentication” as an intended purpose. When you install the Federation Proxy component, when you choose your client authentication certificate, you will be presented with a list of certificates that have an EKU of “Client Authentication.” If you don’t have any in the local machine personal store, the list will be empty.

The client authentication certificate and its private key reside on the ADFS Proxy Server, but a copy of this certificate with only the public key resides on the Federation Server. This is why I try to explain it as “think of it like the proxies TS certificate” – it is different in many ways. Most importantly, it isn’t used to sign any tokens. But again – this is a completely different certificate than the one used for SSL on the server.

ADFS Certificates – SSL, Token Signing, and Client Authentication Certs

July 23rd, 2007 No comments

 


We are seeing quite a few support calls relating to certificate problems. Many of these are due to a misunderstanding of how the various certificates are used.

ADFS/PKI issues are often very difficult to diagnose for the following reason – a lack of logging telling you what the problem is.

For example – if the SSL certificate on your Web Server is incorrect or has a problem like missing a private key. The user experience will be a page can’t be displayed error and absolutely nothing will be logged in the event viewer, security log, or adfs debug logs.

There are several variations of this – but if you aren’t getting *anything* in the logs – start looking at your certificates! More times than not – it is the SSL certificate and you aren’t even getting to ADFS which is why there aren’t any error messages to work with.

Other sub-items that come to mind on this topic are:

1. Using Certutil to verify the certificates in question

2. What type of certificate should I use? 3rd Party, an internal CA, or a combination of the two.

In addition to this blog, you should also review the TechNet documentation on Understanding Certificates starting here. Between the two, I hope it makes it clear what goes where.

Also, it may be helpful to revisit my blog on the PKI portion of setting up a lab.  That is located here.


ADFS Certificates for Federation Servers

SSL Certificate

The SSL certificates must be trusted by the client machine which accesses the web sites. Since the client machine (in a Federated WebSSO scenario) will visit the WS, then the FS-R, then the FS-A, the client must trust all three SSL certificates. For this reason, it may make sense to use a 3rd party certificate for the SSL certificate.

A SSL certificate is in place to encrypt the session between client and the server. These certificates are not specific to ADFS, but rather specific to IIS.

The Subject Name of the SSL certificate must match the names used in the ADFS configuration. For example, if you specify a federation server endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – then the subject name on the SSL certificate for that server must be “adfsresource.treyresearch.net” This is a very important item and a common misconfiguration. The name can be anything – it just needs to match. If you choose to setup ADFS for use on the intranet only and you want to use only the host name, then the endpoint URL would be https://adfsresource/adfs/ls/ and the Subject Name on the certificate should be “adfsresource”

The same Subject Name rules also apply to the web sites protected by ADFS. The name on the certificate should match the name clients will use to access the ADFS protected web site.

Token Signing Certificate

On the Federation Servers – you also need a token signing certificate. This certificate can be any X.509 certificate, the intended purpose or EKU doesn’t matter. The “issued to” name doesn’t matter. Any X.509 certificate will do. When you install the Federation Server role – setup will prompt you to pick a token signing certificate OR let setup create a self signed certificate for you.

Self Signed Certificates are OK for a lab – but should not be used in production deployments.

If you choose to select a token signing certificate in the setup portion, you will be presented with a list of all certificates present in the local machine personal certificate store. Whichever option you choose, the setup program will place an export of the token signing certificate in the list of verification certificates for the same machine. A verification certificate is simply an export (less the private key) of the token signing certificate. Each Federation Server must have a verification certificate for its own token signing certificate. If you change the token signing certificate later – the adfs.msc program will display a message telling you that the new verification certificate will be added to the list of verification certificates.

It seems a little strange that a Federation Server needs to verify its own token signing certificate, but that is the way it works…

A token signing certificate is used to “sign the ADFS authentication token” – this is the token that contains a users claims and is used to make authorization decisions at the website. The verification token is used to “verify” the token was sent by the federated partner and that it has not been tampered with.

In a Federated WebSSO scenario where you have an Account Partner and a Resource Partner, the Account Partner’s verification certificate must be present on the Resource Partners trust policy file. This certificate (by default) must be trusted, must be able to chain to the root, and must be able to access the certificate revocation list.

IMPORTANT NOTE:

Using the SSL certificate for the token signing certificate will work – but this should not be the configuration you use in production. This is considered bad key hygiene. The SSL certificate for the web site serves one purpose – the token signing certificate serves an entirely different purpose. This is the most misunderstood item we see.

Here is a screenshot from my Federation Server – notice how the SSL certificate is “issued to” adfsresource.treyresearch.net and the Token Signing certificate I use has a friendly name in the Issued To


ADFS Certificates for Federation Server Proxies

SSL Certificate

As with the other Federation Server roles, the FS-P web site will need a SSL certificate. The Subject Name must match the Federation Server endpoint URL specified on the Federation Server. If you have your endpoint URL as https://adfsresource.treyresearch.net/adfs/ls/ – the SSL certificate for the federation server itself should have a Subject Name of adfsresource.treyresearch.net and the Federation Server Proxy SSL certificate should also have a Subject Name of adfsresource.treyresearch.net. Even if the machine name is adfsproxy.treyresearch.net – the URL the client will hit is adfsresource.treyresearch.net. Whether or not the client is redirected to the IP address of adfsresource or adfsproxy depends on how the client resolves that name via DNS.

A typical name resolution setup for a Proxy scenario would be to have client machines on the internal LAN resolve adfsresource to the actual IP address of adfsresource.

Client machines on the internet (or outside of your internal LAN) resolve the name adfsresource.treyresearch.net to the IP address of adfsproxy.treyresearch.net. It is important to remember that you won’t specify the name adfsproxy.treyresearch.net anywhere in your setup. The website on this server should have a certificate issued to the name adfsresource.treyresearch.net.

The adfsproxy.treresearch.net server should be configured to resolve the name adfsresource.treyresearch.net to the actual IP address of adfsresource.treyresearch.net (this machine should be the only server in the DMZ/Internet) that knows adfsresource by its real IP. This is commonly accomplished by using a host file on adfsproxy.

With the scenario setup like this – the internal LAN clients will enjoy a single sign on experience when visiting an ADFS resource (not be prompted for credentials). Users external to the LAN will be presented with a forms based authentication page asking for username/password.

This is typically a desired configuration because the internet user probably hasn’t authenticated with his or her home domain.

Client Authentication Certificate

I like to explain the client authenticate certificate as “It is sort of like the token signing certificate, but for ADFS proxy servers” – while this isn’t really the case, it is a different certificate than what is used for SSL on the website. This certificate must have “client authentication” as an intended purpose. When you install the Federation Proxy component, when you choose your client authentication certificate, you will be presented with a list of certificates that have an EKU of “Client Authentication.” If you don’t have any in the local machine personal store, the list will be empty.

The client authentication certificate and its private key reside on the ADFS Proxy Server, but a copy of this certificate with only the public key resides on the Federation Server. This is why I try to explain it as “think of it like the proxies TS certificate” – it is different in many ways. Most importantly, it isn’t used to sign any tokens. But again – this is a completely different certificate than the one used for SSL on the server.

Setting up an ADFS environment – Part 2

April 26th, 2007 No comments

 


This blog will build on my previous blog and walk you through the steps to getting your lab up and running.

Let’s start on the Account side and install the Federation Server Service. Select add/remove programs, windows components, details of Active Directory Federated Services, then check the Federation Server checkbox


Setup does a check to make sure SSL has been enabled on the web site, then it will prompt you to select a token signing certificate and select an Trust Policy or create a new one.


Instead of having setup create a self-signed token signing certificate (the default) – Choose “Select token-signing certificate” and hit the Select button


The select certificate dialog appears and displays the local computer personal certificate store. The Token signing certificate you downloaded and installed previously will be listed along with your SSL certificate for IIS. Choose the token signing certificate and complete the installation.

Repeat these steps on ADFSRESOURCE (the FS-R) and get it to same place.

Launch the ADFS snap-in (start/run/adfs.msc – or find it in the administrative tools folder). On both servers, we should now have the Federation Service installed and ready to begin the process of creating a Federation trust between the organizations.

I will start the configuration on the FS-A again and configure the information to reflect Adatum.

Right click on the Trust Policy node and choose properties. The general tab has two items of information which we will fill in to reflect “My Organization”

I recommend that you make all entries in lower case and keep the URI something short and meaningful.

Change the Federation Service URI to urn:federation:adatum

Change the Federation Service URL to https://adfsaccount.adatum.com/adfs/ls/


The display name tab can be changed if you wish. If you review the Verification Certificate tab, you will notice the same Token Signing Certificate you selected at setup is present. Each Federation Server will have a Token Signing certificate and this certificate will automatically be added to the list of verification certificates on the Trust Policy level.

Switch to the Resource side and perform the same steps on the FS-R. Populate it with the following information:

Change the Federation Service URI to urn:federation:treyresearch

Change the Federation Service URL to https://adfsresource.treyresearch.net/adfs/ls/

The next step is to configure an Account Store on the FS-A

On your FS-A, right click on the Account Stores node under My Organization and choose New – Account Store. This will launch the Add Account Store Wizard. This lab example will use an Active Directory Account Store (ADAM as an account store is worthy of a different blog)


There isn’t any configuration left to do here so just hit next and complete the wizard.

We are now ready to complete the federation trust by using the import/export feature. I recommend you use this feature as it will eliminate any typo’s or mismatches that are common to initial installations of ADFS.

Start on the FS-A and right click the Trust Policy Node – choose Export Policy from the menu. I’m going to put it in my c:certs folder (I know it’s not a certificate – just trying to keep things organized) and name it something descriptive.


Notice the description of the Export Generic Partner Policy dialog – it tells you the following information is contained in the file:

Display Name, URL, URI, and Verification Certificate

It’s not a ton of information and it won’t help you import any claims you may configure (we will have to wait for the next version to get more options on import/export). But this does ensure the correct certificate is brought over and also URI and URL are usual suspects when initial setup doesn’t work. It really is a better way to go.

Repeat the export process on the FS-R and then copy each export file to the partner machine. The FS-A should have the “Treyresearch-FS-R export file.xml” and the FS-R should have the “Adatum-FS-A export file.xml” locally

On the account side (FS-A) , expand and right click and choose new – resource partner. The Add Resource Partners wizard appears. The first page gives the option to import a Parnter interoperability policy file


On the next page – choose Federated Web SSO


Notice how you have two options – Federated Web SSO and Federated Web SSO with Forest Trust. There are three scenarios you can setup ADFS in. Federated Web SSO, Federated Web SSO, and Web SSO. The WebSSO scenario would only involve a single company – therefore, you would never add a partner in this scenario.

Next – select UPN as the identity claim you wish to send (these can be changed later – for now, just choose UPN)


Let’s pass all UPN suffixes unchanged to the partner (again, we can change this later)


Keep the default to enable this partner and finish the wizard. Your account side ADFS snap-in should look like this:


Now – we will visit the Resource side (FS-R) and import the account partner with the file we copied over earlier.

Right click the Account Partner node under Partner Organizations and choose New – this will launch the Add Account Partner Wizard. Browse to the export file on when prompted.


Again – choose Federated Web SSO as the scenario



On the Accepted UPN suffix tab – we will enter adatum.com and choose add


Choose next, enable the application, and complete the wizard. Your ADFS snap-in on the Resource side should look like this:


At this stage we have the Federation Trust established between the two organizations. Our next task is to configure an application on the resource side and “federate it” to users on the account side.

I know I said that I would do this in two steps – but this document has been just sitting here for quite some time – Part 3 (later) will wrap it up with the application installation/configuration.

The federation trust between partners is now established – the rest is fairly easy.

The reason I’m stopping here and posting this – is mainly to clear the way for a new project (which is almost fully understood!)

I will get the steps needed to setup/configure SQL Reporting Services and use ADFS on the SSRS site. We have been heads down on this for a while now – and today we finally made some real progress!

Since my lab environment is already setup – I can get some screen shots and show you all the places to go to install/configure this.

Setting up an ADFS environment – Part 2

April 26th, 2007 Comments off

 


This blog will build on my previous blog and walk you through the steps to getting your lab up and running.

Let’s start on the Account side and install the Federation Server Service. Select add/remove programs, windows components, details of Active Directory Federated Services, then check the Federation Server checkbox


Setup does a check to make sure SSL has been enabled on the web site, then it will prompt you to select a token signing certificate and select an Trust Policy or create a new one.


Instead of having setup create a self-signed token signing certificate (the default) – Choose “Select token-signing certificate” and hit the Select button


The select certificate dialog appears and displays the local computer personal certificate store. The Token signing certificate you downloaded and installed previously will be listed along with your SSL certificate for IIS. Choose the token signing certificate and complete the installation.

Repeat these steps on ADFSRESOURCE (the FS-R) and get it to same place.

Launch the ADFS snap-in (start/run/adfs.msc – or find it in the administrative tools folder). On both servers, we should now have the Federation Service installed and ready to begin the process of creating a Federation trust between the organizations.

I will start the configuration on the FS-A again and configure the information to reflect Adatum.

Right click on the Trust Policy node and choose properties. The general tab has two items of information which we will fill in to reflect “My Organization”

I recommend that you make all entries in lower case and keep the URI something short and meaningful.

Change the Federation Service URI to urn:federation:adatum

Change the Federation Service URL to https://adfsaccount.adatum.com/adfs/ls/


The display name tab can be changed if you wish. If you review the Verification Certificate tab, you will notice the same Token Signing Certificate you selected at setup is present. Each Federation Server will have a Token Signing certificate and this certificate will automatically be added to the list of verification certificates on the Trust Policy level.

Switch to the Resource side and perform the same steps on the FS-R. Populate it with the following information:

Change the Federation Service URI to urn:federation:treyresearch

Change the Federation Service URL to https://adfsresource.treyresearch.net/adfs/ls/

The next step is to configure an Account Store on the FS-A

On your FS-A, right click on the Account Stores node under My Organization and choose New – Account Store. This will launch the Add Account Store Wizard. This lab example will use an Active Directory Account Store (ADAM as an account store is worthy of a different blog)


There isn’t any configuration left to do here so just hit next and complete the wizard.

We are now ready to complete the federation trust by using the import/export feature. I recommend you use this feature as it will eliminate any typo’s or mismatches that are common to initial installations of ADFS.

Start on the FS-A and right click the Trust Policy Node – choose Export Policy from the menu. I’m going to put it in my c:\certs folder (I know it’s not a certificate – just trying to keep things organized) and name it something descriptive.


Notice the description of the Export Generic Partner Policy dialog – it tells you the following information is contained in the file:

Display Name, URL, URI, and Verification Certificate

It’s not a ton of information and it won’t help you import any claims you may configure (we will have to wait for the next version to get more options on import/export). But this does ensure the correct certificate is brought over and also URI and URL are usual suspects when initial setup doesn’t work. It really is a better way to go.

Repeat the export process on the FS-R and then copy each export file to the partner machine. The FS-A should have the “Treyresearch-FS-R export file.xml” and the FS-R should have the “Adatum-FS-A export file.xml” locally

On the account side (FS-A) , expand and right click and choose new – resource partner. The Add Resource Partners wizard appears. The first page gives the option to import a Parnter interoperability policy file


On the next page – choose Federated Web SSO


Notice how you have two options – Federated Web SSO and Federated Web SSO with Forest Trust. There are three scenarios you can setup ADFS in. Federated Web SSO, Federated Web SSO, and Web SSO. The WebSSO scenario would only involve a single company – therefore, you would never add a partner in this scenario.

Next – select UPN as the identity claim you wish to send (these can be changed later – for now, just choose UPN)


Let’s pass all UPN suffixes unchanged to the partner (again, we can change this later)


Keep the default to enable this partner and finish the wizard. Your account side ADFS snap-in should look like this:


Now – we will visit the Resource side (FS-R) and import the account partner with the file we copied over earlier.

Right click the Account Partner node under Partner Organizations and choose New – this will launch the Add Account Partner Wizard. Browse to the export file on when prompted.


Again – choose Federated Web SSO as the scenario



On the Accepted UPN suffix tab – we will enter adatum.com and choose add


Choose next, enable the application, and complete the wizard. Your ADFS snap-in on the Resource side should look like this:


At this stage we have the Federation Trust established between the two organizations. Our next task is to configure an application on the resource side and “federate it” to users on the account side.

I know I said that I would do this in two steps – but this document has been just sitting here for quite some time – Part 3 (later) will wrap it up with the application installation/configuration.

The federation trust between partners is now established – the rest is fairly easy.

The reason I’m stopping here and posting this – is mainly to clear the way for a new project (which is almost fully understood!)

I will get the steps needed to setup/configure SQL Reporting Services and use ADFS on the SSRS site. We have been heads down on this for a while now – and today we finally made some real progress!

Since my lab environment is already setup – I can get some screen shots and show you all the places to go to install/configure this.

Setting up an ADFS environment – Part 2

April 26th, 2007 No comments

 


This blog will build on my previous blog and walk you through the steps to getting your lab up and running.

Let’s start on the Account side and install the Federation Server Service. Select add/remove programs, windows components, details of Active Directory Federated Services, then check the Federation Server checkbox


Setup does a check to make sure SSL has been enabled on the web site, then it will prompt you to select a token signing certificate and select an Trust Policy or create a new one.


Instead of having setup create a self-signed token signing certificate (the default) – Choose “Select token-signing certificate” and hit the Select button


The select certificate dialog appears and displays the local computer personal certificate store. The Token signing certificate you downloaded and installed previously will be listed along with your SSL certificate for IIS. Choose the token signing certificate and complete the installation.

Repeat these steps on ADFSRESOURCE (the FS-R) and get it to same place.

Launch the ADFS snap-in (start/run/adfs.msc – or find it in the administrative tools folder). On both servers, we should now have the Federation Service installed and ready to begin the process of creating a Federation trust between the organizations.

I will start the configuration on the FS-A again and configure the information to reflect Adatum.

Right click on the Trust Policy node and choose properties. The general tab has two items of information which we will fill in to reflect “My Organization”

I recommend that you make all entries in lower case and keep the URI something short and meaningful.

Change the Federation Service URI to urn:federation:adatum

Change the Federation Service URL to https://adfsaccount.adatum.com/adfs/ls/


The display name tab can be changed if you wish. If you review the Verification Certificate tab, you will notice the same Token Signing Certificate you selected at setup is present. Each Federation Server will have a Token Signing certificate and this certificate will automatically be added to the list of verification certificates on the Trust Policy level.

Switch to the Resource side and perform the same steps on the FS-R. Populate it with the following information:

Change the Federation Service URI to urn:federation:treyresearch

Change the Federation Service URL to https://adfsresource.treyresearch.net/adfs/ls/

The next step is to configure an Account Store on the FS-A

On your FS-A, right click on the Account Stores node under My Organization and choose New – Account Store. This will launch the Add Account Store Wizard. This lab example will use an Active Directory Account Store (ADAM as an account store is worthy of a different blog)


There isn’t any configuration left to do here so just hit next and complete the wizard.

We are now ready to complete the federation trust by using the import/export feature. I recommend you use this feature as it will eliminate any typo’s or mismatches that are common to initial installations of ADFS.

Start on the FS-A and right click the Trust Policy Node – choose Export Policy from the menu. I’m going to put it in my c:\certs folder (I know it’s not a certificate – just trying to keep things organized) and name it something descriptive.


Notice the description of the Export Generic Partner Policy dialog – it tells you the following information is contained in the file:

Display Name, URL, URI, and Verification Certificate

It’s not a ton of information and it won’t help you import any claims you may configure (we will have to wait for the next version to get more options on import/export). But this does ensure the correct certificate is brought over and also URI and URL are usual suspects when initial setup doesn’t work. It really is a better way to go.

Repeat the export process on the FS-R and then copy each export file to the partner machine. The FS-A should have the “Treyresearch-FS-R export file.xml” and the FS-R should have the “Adatum-FS-A export file.xml” locally

On the account side (FS-A) , expand and right click and choose new – resource partner. The Add Resource Partners wizard appears. The first page gives the option to import a Parnter interoperability policy file


On the next page – choose Federated Web SSO


Notice how you have two options – Federated Web SSO and Federated Web SSO with Forest Trust. There are three scenarios you can setup ADFS in. Federated Web SSO, Federated Web SSO, and Web SSO. The WebSSO scenario would only involve a single company – therefore, you would never add a partner in this scenario.

Next – select UPN as the identity claim you wish to send (these can be changed later – for now, just choose UPN)


Let’s pass all UPN suffixes unchanged to the partner (again, we can change this later)


Keep the default to enable this partner and finish the wizard. Your account side ADFS snap-in should look like this:


Now – we will visit the Resource side (FS-R) and import the account partner with the file we copied over earlier.

Right click the Account Partner node under Partner Organizations and choose New – this will launch the Add Account Partner Wizard. Browse to the export file on when prompted.


Again – choose Federated Web SSO as the scenario



On the Accepted UPN suffix tab – we will enter adatum.com and choose add


Choose next, enable the application, and complete the wizard. Your ADFS snap-in on the Resource side should look like this:


At this stage we have the Federation Trust established between the two organizations. Our next task is to configure an application on the resource side and “federate it” to users on the account side.

I know I said that I would do this in two steps – but this document has been just sitting here for quite some time – Part 3 (later) will wrap it up with the application installation/configuration.

The federation trust between partners is now established – the rest is fairly easy.

The reason I’m stopping here and posting this – is mainly to clear the way for a new project (which is almost fully understood!)

I will get the steps needed to setup/configure SQL Reporting Services and use ADFS on the SSRS site. We have been heads down on this for a while now – and today we finally made some real progress!

Since my lab environment is already setup – I can get some screen shots and show you all the places to go to install/configure this.

Setting up an ADFS environment – Part 2

April 26th, 2007 No comments

 


This blog will build on my previous blog and walk you through the steps to getting your lab up and running.

Let’s start on the Account side and install the Federation Server Service. Select add/remove programs, windows components, details of Active Directory Federated Services, then check the Federation Server checkbox


Setup does a check to make sure SSL has been enabled on the web site, then it will prompt you to select a token signing certificate and select an Trust Policy or create a new one.


Instead of having setup create a self-signed token signing certificate (the default) – Choose “Select token-signing certificate” and hit the Select button


The select certificate dialog appears and displays the local computer personal certificate store. The Token signing certificate you downloaded and installed previously will be listed along with your SSL certificate for IIS. Choose the token signing certificate and complete the installation.

Repeat these steps on ADFSRESOURCE (the FS-R) and get it to same place.

Launch the ADFS snap-in (start/run/adfs.msc – or find it in the administrative tools folder). On both servers, we should now have the Federation Service installed and ready to begin the process of creating a Federation trust between the organizations.

I will start the configuration on the FS-A again and configure the information to reflect Adatum.

Right click on the Trust Policy node and choose properties. The general tab has two items of information which we will fill in to reflect “My Organization”

I recommend that you make all entries in lower case and keep the URI something short and meaningful.

Change the Federation Service URI to urn:federation:adatum

Change the Federation Service URL to https://adfsaccount.adatum.com/adfs/ls/


The display name tab can be changed if you wish. If you review the Verification Certificate tab, you will notice the same Token Signing Certificate you selected at setup is present. Each Federation Server will have a Token Signing certificate and this certificate will automatically be added to the list of verification certificates on the Trust Policy level.

Switch to the Resource side and perform the same steps on the FS-R. Populate it with the following information:

Change the Federation Service URI to urn:federation:treyresearch

Change the Federation Service URL to https://adfsresource.treyresearch.net/adfs/ls/

The next step is to configure an Account Store on the FS-A

On your FS-A, right click on the Account Stores node under My Organization and choose New – Account Store. This will launch the Add Account Store Wizard. This lab example will use an Active Directory Account Store (ADAM as an account store is worthy of a different blog)


There isn’t any configuration left to do here so just hit next and complete the wizard.

We are now ready to complete the federation trust by using the import/export feature. I recommend you use this feature as it will eliminate any typo’s or mismatches that are common to initial installations of ADFS.

Start on the FS-A and right click the Trust Policy Node – choose Export Policy from the menu. I’m going to put it in my c:\certs folder (I know it’s not a certificate – just trying to keep things organized) and name it something descriptive.


Notice the description of the Export Generic Partner Policy dialog – it tells you the following information is contained in the file:

Display Name, URL, URI, and Verification Certificate

It’s not a ton of information and it won’t help you import any claims you may configure (we will have to wait for the next version to get more options on import/export). But this does ensure the correct certificate is brought over and also URI and URL are usual suspects when initial setup doesn’t work. It really is a better way to go.

Repeat the export process on the FS-R and then copy each export file to the partner machine. The FS-A should have the “Treyresearch-FS-R export file.xml” and the FS-R should have the “Adatum-FS-A export file.xml” locally

On the account side (FS-A) , expand and right click and choose new – resource partner. The Add Resource Partners wizard appears. The first page gives the option to import a Parnter interoperability policy file


On the next page – choose Federated Web SSO


Notice how you have two options – Federated Web SSO and Federated Web SSO with Forest Trust. There are three scenarios you can setup ADFS in. Federated Web SSO, Federated Web SSO, and Web SSO. The WebSSO scenario would only involve a single company – therefore, you would never add a partner in this scenario.

Next – select UPN as the identity claim you wish to send (these can be changed later – for now, just choose UPN)


Let’s pass all UPN suffixes unchanged to the partner (again, we can change this later)


Keep the default to enable this partner and finish the wizard. Your account side ADFS snap-in should look like this:


Now – we will visit the Resource side (FS-R) and import the account partner with the file we copied over earlier.

Right click the Account Partner node under Partner Organizations and choose New – this will launch the Add Account Partner Wizard. Browse to the export file on when prompted.


Again – choose Federated Web SSO as the scenario



On the Accepted UPN suffix tab – we will enter adatum.com and choose add


Choose next, enable the application, and complete the wizard. Your ADFS snap-in on the Resource side should look like this:


At this stage we have the Federation Trust established between the two organizations. Our next task is to configure an application on the resource side and “federate it” to users on the account side.

I know I said that I would do this in two steps – but this document has been just sitting here for quite some time – Part 3 (later) will wrap it up with the application installation/configuration.

The federation trust between partners is now established – the rest is fairly easy.

The reason I’m stopping here and posting this – is mainly to clear the way for a new project (which is almost fully understood!)

I will get the steps needed to setup/configure SQL Reporting Services and use ADFS on the SSRS site. We have been heads down on this for a while now – and today we finally made some real progress!

Since my lab environment is already setup – I can get some screen shots and show you all the places to go to install/configure this.

Setting up an ADFS lab environment – Part 1

February 26th, 2007 Comments off

In this blog, I’ll go though the PKI portion of setting up Trey Research and Adatum. While you can do this a number of different ways – I always setup and use a Standalone CA instead of generating self-signed certificates.


In my opinion, setting up a new CA (or making an existing lab box a CA) is faster in the long run than using self signed certificates. Also, it offers a better user experience for testing. Self signed certificates should NEVER be used for production systems.


Often, people will start with self signed, then change to CA issued certs and then generate a huge mess in the ADFS snap-in and in the certificate stores. When you get into this mess, you will find yourself looking through the thumbprint of different certificates to find the right one.   If you lab setup will eventually be turned into your production environment, then do yourself a favor and setup the certificates the right way from the start.

I’ll start with the initial lab setup and end this blog at the completion of the certificate portion of the setup. Then do a part 2 blog that completes the FS setup with a sample application (the blog application) and a couple claims.

I know Nick’s step by step get’s you to the same place, but I think the PKI differences along with the order of steps I take you through are worthy enough to blog about and will help people get a good test environment up and running in short order.  Performing the steps in my order makes the setup more logical to me – guess that’s why it’s “my order”

One last note on this…I’ve worked with a number of customers who had trouble setting up the step by step and getting it to work.  In almost all cases – the problem was that they deviated from the guide.  Sometimes – not doing something as it says in the step-by-step guide (or changing it around) matters, sometimes not. 

I will try to stop at certain checkpoints and explain what we have done and why we did it. 

Here’s my method (using Virtual Machines):

1. Build a R2 Enterprise Virtual Machine and install IIS, ASP, .NET 2.0 Framework.  Put the support tools and resource kit on it… BGINFO that puts the IP / Machine name info on your wallpaper is handy as well. Another suggestion would be to install TextPad or some other file editor that can look at .xml files and display debug log files better than notepad.  Get that server just how you like it – then run sysprep on it and copy the .vhd file off to use as the base image for the rest of your setup.

2. Create two single dc forests – name them what you like, but as I’ve said in the past, my lab walkthoughs will always use Adatum and TreyResearch.  You may choose to set things up with Account.com and Resource.com – whatever works for you. Here are full machine names for the machines we will be installing certificates – if you have different names – you can map them to mine for the rest of the guide.

   a.  Adfsaccount.adatum.com – Domain controller and Federation Server for Adatum.com  (FS-A)

   b.  Adfsresource.treyresearch.net – Domain controller and Federation Server for Treyresearch.net  (FS-R)

   c.  Adfsweb.treyresearch.net – Web server in the Treyresearch forest.  (WS)

   d.  Adfsclient.adatum.com – XP client in Adatum – used to test the user experience

3.  Install and join an XP client to the Adatum forest

4.  Install (or add the service to an existing machine) a stand-alone certificate authority.  You can name it something creative like “StandaloneCA” – doesn’t really matter

5.  Configure DNS forwarders so both all machines can resolve adatum.com and treyresearch.net machine names

6.  Install SSL certificates on the default web site of the FS-A, FS-R, and WS

7.  Install the Certificate Authority CA chain in the Trusted Root store of FS-A, FS-R, WS, and the XP client

8.  Install a Token Signing certificate on the FS-A and FS-R in the local computer store of your FS/DC machines

Let’s get started…

At this point, you should have the forests established, name resolution configured, and the domain controllers/federation servers and the Web Server should already have IIS/Framework 2.0 installed.  

The first order of business is to install a SSL certificate on the default web site of all of the servers. I like to create a directory called c:\certs on each machine while setting things up.  There will be certificate request files, certificate files, then export of certificates copied to other machines, etc.  by the time we are all done.

It’s easier/cleaner than tossing random cert files on your desktop or the root of the c: drive.


SSL Certificates


Start by adding an SSL certificate to the default web site of each machine.   Launch the IIS Certificate wizard by going to Properties of Default Web Site – Directory Security tab – Server Certificate

When going through the IIS Certificate wizard  – pay attention to the Common Name page. It defaults to just your computer name and we need to change this to the FQDN of the computer.


Change it to reflect the FQDN


When you have finished the wizard, save the request file in the c:\certs folder


Next step is to launch a browser from this machine and go to http://certicate-authority-name/certsrv to access the certificate services web page. Choose Request a Certificate, then Advanced Certificate Request


Choose “Submit a request by using a base-64…”


Next – paste the contents of the certreq.txt file you created when running though the Server Certificate Wizard in IIS.


Once completed, go to your CA machine and issue the pending request from the Certificate Authority snap-in tool


Back at server where you are installing the SSL certificate – from the main page on the certsrv website, you can choose “View the status of a pending certificate request”

Download the certnew.cer file and save it to your c:\certs folder as certnew-ssl.cer so you can keep track of what this certificate is for.


We are now ready to go back to IIS and install the certificate.  If you go to properties – directory security tab – server certificate – you will get this dialog


Complete the wizard by selecting the certnew-ssl.cer file you obtained in the previous step.

Install the CA Certificate Chain

After installing a SSL certificate on the Default Web Site, the next step will be to install the CA certificate in the Trusted Root Store of the local machine.

From the main certsrv page, choose “Download a CA certificate, certificate chain, or CRL”

Select “Download CA certificate chain” towards the bottom and save the file to your c:\certs folder.


NOTE: If you choose “Install this CA certificate chain” link at the top of this page – it will install to the local users trusted root store which isn’t what we want – we need this in the local computer trusted root store.

Launch a MMC and add the certificates snap-in – choose local computer.

Right click certificates folder under Trusted Root – all tasks – import. Then browse to the chain file you downloaded in the previous step. After doing this, you should see your CA listed in this folder.


At this point, we have installed a SSL Server Authentication Certificate on the default web site and installed the CA chain in the local computer Trusted Root store. These steps should be repeated on the other Federation Server, the Web Server, and your XP client


Install the Token Signing Certificate

The next step will be installing a certificate to the local computer store which will be used for the ADFS Token Signing certificate. The token signing certificate can be any type (there is no EKU requirement for the TS certificate) and we don’t have to worry about the “issued to” name like we did with the SSL certificate.

From the main certsrv web page choose Request a certificate – advanced certificate request – create and submit a request to this CA

I change the type of certificate needed to Code Signing Certificate (but the type doesn’t really matter). Select the checkbox to “store in the local computer store” to save a step later.  Everything else can be left at the default.

Also – give this certificate a descriptive name in the friendly name field – we will want to differentiate this cert from our SSL cert at a glance.


Complete the request, then issue the pending request from the from the CA the same way we did for the SSL certificate, then take the browser back to “check the status of a pending request”

Now you can install this certificate to your local machine store by selecting “Install this certificate”


The FS-A and FS-R local computer computer store should look something like this


Remember – you will need 5 certificates in this setup example – 3 SSL certificates (adfsweb, adfsaccount, and adfsresource) and 2 token signing certificates (adfsaccount and adfsresource) installed in the local computer store.  The Certificate CA Chain should be installed on every machine (client, FS, and WS) in the lab environment.

If you give some attention to detail on these steps – the rest of the setup will be much easier and you will get things working much faster at initial setup.

This completes the PKI portion and we are now ready to start the ADFS installation and configure the federation servers.  I’ll finish the part 2 blog that covers the remainder of the setup soon.

Setting up an ADFS lab environment – Part 1

February 26th, 2007 No comments

In this blog, I’ll go though the PKI portion of setting up Trey Research and Adatum. While you can do this a number of different ways – I always setup and use a Standalone CA instead of generating self-signed certificates.


In my opinion, setting up a new CA (or making an existing lab box a CA) is faster in the long run than using self signed certificates. Also, it offers a better user experience for testing. Self signed certificates should NEVER be used for production systems.


Often, people will start with self signed, then change to CA issued certs and then generate a huge mess in the ADFS snap-in and in the certificate stores. When you get into this mess, you will find yourself looking through the thumbprint of different certificates to find the right one.   If you lab setup will eventually be turned into your production environment, then do yourself a favor and setup the certificates the right way from the start.

I’ll start with the initial lab setup and end this blog at the completion of the certificate portion of the setup. Then do a part 2 blog that completes the FS setup with a sample application (the blog application) and a couple claims.

I know Nick’s step by step get’s you to the same place, but I think the PKI differences along with the order of steps I take you through are worthy enough to blog about and will help people get a good test environment up and running in short order.  Performing the steps in my order makes the setup more logical to me – guess that’s why it’s “my order”

One last note on this…I’ve worked with a number of customers who had trouble setting up the step by step and getting it to work.  In almost all cases – the problem was that they deviated from the guide.  Sometimes – not doing something as it says in the step-by-step guide (or changing it around) matters, sometimes not. 

I will try to stop at certain checkpoints and explain what we have done and why we did it. 

Here’s my method (using Virtual Machines):

1. Build a R2 Enterprise Virtual Machine and install IIS, ASP, .NET 2.0 Framework.  Put the support tools and resource kit on it… BGINFO that puts the IP / Machine name info on your wallpaper is handy as well. Another suggestion would be to install TextPad or some other file editor that can look at .xml files and display debug log files better than notepad.  Get that server just how you like it – then run sysprep on it and copy the .vhd file off to use as the base image for the rest of your setup.

2. Create two single dc forests – name them what you like, but as I’ve said in the past, my lab walkthoughs will always use Adatum and TreyResearch.  You may choose to set things up with Account.com and Resource.com – whatever works for you. Here are full machine names for the machines we will be installing certificates – if you have different names – you can map them to mine for the rest of the guide.

   a.  Adfsaccount.adatum.com – Domain controller and Federation Server for Adatum.com  (FS-A)

   b.  Adfsresource.treyresearch.net – Domain controller and Federation Server for Treyresearch.net  (FS-R)

   c.  Adfsweb.treyresearch.net – Web server in the Treyresearch forest.  (WS)

   d.  Adfsclient.adatum.com – XP client in Adatum – used to test the user experience

3.  Install and join an XP client to the Adatum forest

4.  Install (or add the service to an existing machine) a stand-alone certificate authority.  You can name it something creative like “StandaloneCA” – doesn’t really matter

5.  Configure DNS forwarders so both all machines can resolve adatum.com and treyresearch.net machine names

6.  Install SSL certificates on the default web site of the FS-A, FS-R, and WS

7.  Install the Certificate Authority CA chain in the Trusted Root store of FS-A, FS-R, WS, and the XP client

8.  Install a Token Signing certificate on the FS-A and FS-R in the local computer store of your FS/DC machines

Let’s get started…

At this point, you should have the forests established, name resolution configured, and the domain controllers/federation servers and the Web Server should already have IIS/Framework 2.0 installed.  

The first order of business is to install a SSL certificate on the default web site of all of the servers. I like to create a directory called c:\certs on each machine while setting things up.  There will be certificate request files, certificate files, then export of certificates copied to other machines, etc.  by the time we are all done.

It’s easier/cleaner than tossing random cert files on your desktop or the root of the c: drive.


SSL Certificates


Start by adding an SSL certificate to the default web site of each machine.   Launch the IIS Certificate wizard by going to Properties of Default Web Site – Directory Security tab – Server Certificate

When going through the IIS Certificate wizard  – pay attention to the Common Name page. It defaults to just your computer name and we need to change this to the FQDN of the computer.


Change it to reflect the FQDN


When you have finished the wizard, save the request file in the c:\certs folder


Next step is to launch a browser from this machine and go to http://certicate-authority-name/certsrv to access the certificate services web page. Choose Request a Certificate, then Advanced Certificate Request


Choose “Submit a request by using a base-64…”


Next – paste the contents of the certreq.txt file you created when running though the Server Certificate Wizard in IIS.


Once completed, go to your CA machine and issue the pending request from the Certificate Authority snap-in tool


Back at server where you are installing the SSL certificate – from the main page on the certsrv website, you can choose “View the status of a pending certificate request”

Download the certnew.cer file and save it to your c:\certs folder as certnew-ssl.cer so you can keep track of what this certificate is for.


We are now ready to go back to IIS and install the certificate.  If you go to properties – directory security tab – server certificate – you will get this dialog


Complete the wizard by selecting the certnew-ssl.cer file you obtained in the previous step.

Install the CA Certificate Chain

After installing a SSL certificate on the Default Web Site, the next step will be to install the CA certificate in the Trusted Root Store of the local machine.

From the main certsrv page, choose “Download a CA certificate, certificate chain, or CRL”

Select “Download CA certificate chain” towards the bottom and save the file to your c:\certs folder.


NOTE: If you choose “Install this CA certificate chain” link at the top of this page – it will install to the local users trusted root store which isn’t what we want – we need this in the local computer trusted root store.

Launch a MMC and add the certificates snap-in – choose local computer.

Right click certificates folder under Trusted Root – all tasks – import. Then browse to the chain file you downloaded in the previous step. After doing this, you should see your CA listed in this folder.


At this point, we have installed a SSL Server Authentication Certificate on the default web site and installed the CA chain in the local computer Trusted Root store. These steps should be repeated on the other Federation Server, the Web Server, and your XP client


Install the Token Signing Certificate

The next step will be installing a certificate to the local computer store which will be used for the ADFS Token Signing certificate. The token signing certificate can be any type (there is no EKU requirement for the TS certificate) and we don’t have to worry about the “issued to” name like we did with the SSL certificate.

From the main certsrv web page choose Request a certificate – advanced certificate request – create and submit a request to this CA

I change the type of certificate needed to Code Signing Certificate (but the type doesn’t really matter). Select the checkbox to “store in the local computer store” to save a step later.  Everything else can be left at the default.

Also – give this certificate a descriptive name in the friendly name field – we will want to differentiate this cert from our SSL cert at a glance.


Complete the request, then issue the pending request from the from the CA the same way we did for the SSL certificate, then take the browser back to “check the status of a pending request”

Now you can install this certificate to your local machine store by selecting “Install this certificate”


The FS-A and FS-R local computer computer store should look something like this


Remember – you will need 5 certificates in this setup example – 3 SSL certificates (adfsweb, adfsaccount, and adfsresource) and 2 token signing certificates (adfsaccount and adfsresource) installed in the local computer store.  The Certificate CA Chain should be installed on every machine (client, FS, and WS) in the lab environment.

If you give some attention to detail on these steps – the rest of the setup will be much easier and you will get things working much faster at initial setup.

This completes the PKI portion and we are now ready to start the ADFS installation and configure the federation servers.  I’ll finish the part 2 blog that covers the remainder of the setup soon.

Setting up an ADFS lab environment – Part 1

February 26th, 2007 No comments

In this blog, I’ll go though the PKI portion of setting up Trey Research and Adatum. While you can do this a number of different ways – I always setup and use a Standalone CA instead of generating self-signed certificates.


In my opinion, setting up a new CA (or making an existing lab box a CA) is faster in the long run than using self signed certificates. Also, it offers a better user experience for testing. Self signed certificates should NEVER be used for production systems.


Often, people will start with self signed, then change to CA issued certs and then generate a huge mess in the ADFS snap-in and in the certificate stores. When you get into this mess, you will find yourself looking through the thumbprint of different certificates to find the right one.   If you lab setup will eventually be turned into your production environment, then do yourself a favor and setup the certificates the right way from the start.

I’ll start with the initial lab setup and end this blog at the completion of the certificate portion of the setup. Then do a part 2 blog that completes the FS setup with a sample application (the blog application) and a couple claims.

I know Nick’s step by step get’s you to the same place, but I think the PKI differences along with the order of steps I take you through are worthy enough to blog about and will help people get a good test environment up and running in short order.  Performing the steps in my order makes the setup more logical to me – guess that’s why it’s “my order”

One last note on this…I’ve worked with a number of customers who had trouble setting up the step by step and getting it to work.  In almost all cases – the problem was that they deviated from the guide.  Sometimes – not doing something as it says in the step-by-step guide (or changing it around) matters, sometimes not. 

I will try to stop at certain checkpoints and explain what we have done and why we did it. 

Here’s my method (using Virtual Machines):

1. Build a R2 Enterprise Virtual Machine and install IIS, ASP, .NET 2.0 Framework.  Put the support tools and resource kit on it… BGINFO that puts the IP / Machine name info on your wallpaper is handy as well. Another suggestion would be to install TextPad or some other file editor that can look at .xml files and display debug log files better than notepad.  Get that server just how you like it – then run sysprep on it and copy the .vhd file off to use as the base image for the rest of your setup.

2. Create two single dc forests – name them what you like, but as I’ve said in the past, my lab walkthoughs will always use Adatum and TreyResearch.  You may choose to set things up with Account.com and Resource.com – whatever works for you. Here are full machine names for the machines we will be installing certificates – if you have different names – you can map them to mine for the rest of the guide.

   a.  Adfsaccount.adatum.com – Domain controller and Federation Server for Adatum.com  (FS-A)

   b.  Adfsresource.treyresearch.net – Domain controller and Federation Server for Treyresearch.net  (FS-R)

   c.  Adfsweb.treyresearch.net – Web server in the Treyresearch forest.  (WS)

   d.  Adfsclient.adatum.com – XP client in Adatum – used to test the user experience

3.  Install and join an XP client to the Adatum forest

4.  Install (or add the service to an existing machine) a stand-alone certificate authority.  You can name it something creative like “StandaloneCA” – doesn’t really matter

5.  Configure DNS forwarders so both all machines can resolve adatum.com and treyresearch.net machine names

6.  Install SSL certificates on the default web site of the FS-A, FS-R, and WS

7.  Install the Certificate Authority CA chain in the Trusted Root store of FS-A, FS-R, WS, and the XP client

8.  Install a Token Signing certificate on the FS-A and FS-R in the local computer store of your FS/DC machines

Let’s get started…

At this point, you should have the forests established, name resolution configured, and the domain controllers/federation servers and the Web Server should already have IIS/Framework 2.0 installed.  

The first order of business is to install a SSL certificate on the default web site of all of the servers. I like to create a directory called c:certs on each machine while setting things up.  There will be certificate request files, certificate files, then export of certificates copied to other machines, etc.  by the time we are all done.

It’s easier/cleaner than tossing random cert files on your desktop or the root of the c: drive.


SSL Certificates


Start by adding an SSL certificate to the default web site of each machine.   Launch the IIS Certificate wizard by going to Properties of Default Web Site – Directory Security tab – Server Certificate

When going through the IIS Certificate wizard  – pay attention to the Common Name page. It defaults to just your computer name and we need to change this to the FQDN of the computer.


Change it to reflect the FQDN


When you have finished the wizard, save the request file in the c:certs folder


Next step is to launch a browser from this machine and go to http://certicate-authority-name/certsrv to access the certificate services web page. Choose Request a Certificate, then Advanced Certificate Request


Choose “Submit a request by using a base-64…”


Next – paste the contents of the certreq.txt file you created when running though the Server Certificate Wizard in IIS.


Once completed, go to your CA machine and issue the pending request from the Certificate Authority snap-in tool


Back at server where you are installing the SSL certificate – from the main page on the certsrv website, you can choose “View the status of a pending certificate request”

Download the certnew.cer file and save it to your c:certs folder as certnew-ssl.cer so you can keep track of what this certificate is for.


We are now ready to go back to IIS and install the certificate.  If you go to properties – directory security tab – server certificate – you will get this dialog


Complete the wizard by selecting the certnew-ssl.cer file you obtained in the previous step.

Install the CA Certificate Chain

After installing a SSL certificate on the Default Web Site, the next step will be to install the CA certificate in the Trusted Root Store of the local machine.

From the main certsrv page, choose “Download a CA certificate, certificate chain, or CRL”

Select “Download CA certificate chain” towards the bottom and save the file to your c:certs folder.


NOTE: If you choose “Install this CA certificate chain” link at the top of this page – it will install to the local users trusted root store which isn’t what we want – we need this in the local computer trusted root store.

Launch a MMC and add the certificates snap-in – choose local computer.

Right click certificates folder under Trusted Root – all tasks – import. Then browse to the chain file you downloaded in the previous step. After doing this, you should see your CA listed in this folder.


At this point, we have installed a SSL Server Authentication Certificate on the default web site and installed the CA chain in the local computer Trusted Root store. These steps should be repeated on the other Federation Server, the Web Server, and your XP client


Install the Token Signing Certificate

The next step will be installing a certificate to the local computer store which will be used for the ADFS Token Signing certificate. The token signing certificate can be any type (there is no EKU requirement for the TS certificate) and we don’t have to worry about the “issued to” name like we did with the SSL certificate.

From the main certsrv web page choose Request a certificate – advanced certificate request – create and submit a request to this CA

I change the type of certificate needed to Code Signing Certificate (but the type doesn’t really matter). Select the checkbox to “store in the local computer store” to save a step later.  Everything else can be left at the default.

Also – give this certificate a descriptive name in the friendly name field – we will want to differentiate this cert from our SSL cert at a glance.


Complete the request, then issue the pending request from the from the CA the same way we did for the SSL certificate, then take the browser back to “check the status of a pending request”

Now you can install this certificate to your local machine store by selecting “Install this certificate”


The FS-A and FS-R local computer computer store should look something like this


Remember – you will need 5 certificates in this setup example – 3 SSL certificates (adfsweb, adfsaccount, and adfsresource) and 2 token signing certificates (adfsaccount and adfsresource) installed in the local computer store.  The Certificate CA Chain should be installed on every machine (client, FS, and WS) in the lab environment.

If you give some attention to detail on these steps – the rest of the setup will be much easier and you will get things working much faster at initial setup.

This completes the PKI portion and we are now ready to start the ADFS installation and configure the federation servers.  I’ll finish the part 2 blog that covers the remainder of the setup soon.

Setting up an ADFS lab environment – Part 1

February 26th, 2007 No comments

In this blog, I’ll go though the PKI portion of setting up Trey Research and Adatum. While you can do this a number of different ways – I always setup and use a Standalone CA instead of generating self-signed certificates.


In my opinion, setting up a new CA (or making an existing lab box a CA) is faster in the long run than using self signed certificates. Also, it offers a better user experience for testing. Self signed certificates should NEVER be used for production systems.


Often, people will start with self signed, then change to CA issued certs and then generate a huge mess in the ADFS snap-in and in the certificate stores. When you get into this mess, you will find yourself looking through the thumbprint of different certificates to find the right one.   If you lab setup will eventually be turned into your production environment, then do yourself a favor and setup the certificates the right way from the start.

I’ll start with the initial lab setup and end this blog at the completion of the certificate portion of the setup. Then do a part 2 blog that completes the FS setup with a sample application (the blog application) and a couple claims.

I know Nick’s step by step get’s you to the same place, but I think the PKI differences along with the order of steps I take you through are worthy enough to blog about and will help people get a good test environment up and running in short order.  Performing the steps in my order makes the setup more logical to me – guess that’s why it’s “my order”

One last note on this…I’ve worked with a number of customers who had trouble setting up the step by step and getting it to work.  In almost all cases – the problem was that they deviated from the guide.  Sometimes – not doing something as it says in the step-by-step guide (or changing it around) matters, sometimes not. 

I will try to stop at certain checkpoints and explain what we have done and why we did it. 

Here’s my method (using Virtual Machines):

1. Build a R2 Enterprise Virtual Machine and install IIS, ASP, .NET 2.0 Framework.  Put the support tools and resource kit on it… BGINFO that puts the IP / Machine name info on your wallpaper is handy as well. Another suggestion would be to install TextPad or some other file editor that can look at .xml files and display debug log files better than notepad.  Get that server just how you like it – then run sysprep on it and copy the .vhd file off to use as the base image for the rest of your setup.

2. Create two single dc forests – name them what you like, but as I’ve said in the past, my lab walkthoughs will always use Adatum and TreyResearch.  You may choose to set things up with Account.com and Resource.com – whatever works for you. Here are full machine names for the machines we will be installing certificates – if you have different names – you can map them to mine for the rest of the guide.

   a.  Adfsaccount.adatum.com – Domain controller and Federation Server for Adatum.com  (FS-A)

   b.  Adfsresource.treyresearch.net – Domain controller and Federation Server for Treyresearch.net  (FS-R)

   c.  Adfsweb.treyresearch.net – Web server in the Treyresearch forest.  (WS)

   d.  Adfsclient.adatum.com – XP client in Adatum – used to test the user experience

3.  Install and join an XP client to the Adatum forest

4.  Install (or add the service to an existing machine) a stand-alone certificate authority.  You can name it something creative like “StandaloneCA” – doesn’t really matter

5.  Configure DNS forwarders so both all machines can resolve adatum.com and treyresearch.net machine names

6.  Install SSL certificates on the default web site of the FS-A, FS-R, and WS

7.  Install the Certificate Authority CA chain in the Trusted Root store of FS-A, FS-R, WS, and the XP client

8.  Install a Token Signing certificate on the FS-A and FS-R in the local computer store of your FS/DC machines

Let’s get started…

At this point, you should have the forests established, name resolution configured, and the domain controllers/federation servers and the Web Server should already have IIS/Framework 2.0 installed.  

The first order of business is to install a SSL certificate on the default web site of all of the servers. I like to create a directory called c:\certs on each machine while setting things up.  There will be certificate request files, certificate files, then export of certificates copied to other machines, etc.  by the time we are all done.

It’s easier/cleaner than tossing random cert files on your desktop or the root of the c: drive.


SSL Certificates


Start by adding an SSL certificate to the default web site of each machine.   Launch the IIS Certificate wizard by going to Properties of Default Web Site – Directory Security tab – Server Certificate

When going through the IIS Certificate wizard  – pay attention to the Common Name page. It defaults to just your computer name and we need to change this to the FQDN of the computer.


Change it to reflect the FQDN


When you have finished the wizard, save the request file in the c:\certs folder


Next step is to launch a browser from this machine and go to http://certicate-authority-name/certsrv to access the certificate services web page. Choose Request a Certificate, then Advanced Certificate Request


Choose “Submit a request by using a base-64…”


Next – paste the contents of the certreq.txt file you created when running though the Server Certificate Wizard in IIS.


Once completed, go to your CA machine and issue the pending request from the Certificate Authority snap-in tool


Back at server where you are installing the SSL certificate – from the main page on the certsrv website, you can choose “View the status of a pending certificate request”

Download the certnew.cer file and save it to your c:\certs folder as certnew-ssl.cer so you can keep track of what this certificate is for.


We are now ready to go back to IIS and install the certificate.  If you go to properties – directory security tab – server certificate – you will get this dialog


Complete the wizard by selecting the certnew-ssl.cer file you obtained in the previous step.

Install the CA Certificate Chain

After installing a SSL certificate on the Default Web Site, the next step will be to install the CA certificate in the Trusted Root Store of the local machine.

From the main certsrv page, choose “Download a CA certificate, certificate chain, or CRL”

Select “Download CA certificate chain” towards the bottom and save the file to your c:\certs folder.


NOTE: If you choose “Install this CA certificate chain” link at the top of this page – it will install to the local users trusted root store which isn’t what we want – we need this in the local computer trusted root store.

Launch a MMC and add the certificates snap-in – choose local computer.

Right click certificates folder under Trusted Root – all tasks – import. Then browse to the chain file you downloaded in the previous step. After doing this, you should see your CA listed in this folder.


At this point, we have installed a SSL Server Authentication Certificate on the default web site and installed the CA chain in the local computer Trusted Root store. These steps should be repeated on the other Federation Server, the Web Server, and your XP client


Install the Token Signing Certificate

The next step will be installing a certificate to the local computer store which will be used for the ADFS Token Signing certificate. The token signing certificate can be any type (there is no EKU requirement for the TS certificate) and we don’t have to worry about the “issued to” name like we did with the SSL certificate.

From the main certsrv web page choose Request a certificate – advanced certificate request – create and submit a request to this CA

I change the type of certificate needed to Code Signing Certificate (but the type doesn’t really matter). Select the checkbox to “store in the local computer store” to save a step later.  Everything else can be left at the default.

Also – give this certificate a descriptive name in the friendly name field – we will want to differentiate this cert from our SSL cert at a glance.


Complete the request, then issue the pending request from the from the CA the same way we did for the SSL certificate, then take the browser back to “check the status of a pending request”

Now you can install this certificate to your local machine store by selecting “Install this certificate”


The FS-A and FS-R local computer computer store should look something like this


Remember – you will need 5 certificates in this setup example – 3 SSL certificates (adfsweb, adfsaccount, and adfsresource) and 2 token signing certificates (adfsaccount and adfsresource) installed in the local computer store.  The Certificate CA Chain should be installed on every machine (client, FS, and WS) in the lab environment.

If you give some attention to detail on these steps – the rest of the setup will be much easier and you will get things working much faster at initial setup.

This completes the PKI portion and we are now ready to start the ADFS installation and configure the federation servers.  I’ll finish the part 2 blog that covers the remainder of the setup soon.