none
ADFS Sevices Name and Certificate Question

    Question

  • I am going through the ADFS v2 setup in my environment.  So far I have a standalone ADFS server on the internal network that was installed with a Self-Signed Cert and  I have a server ready to be installed with the ADFS proxy in the DMZ. 
    • I have an internal domain that differs from our external domain: the internal domain is company.local and the external DNS name for the ADFS proxy is adfs.sub.company.com.
    • I have an external DNS A record that points to the proxy using: adfs.sub.company.com
    • I do not have split DNS, so on the proxy I have a host file that points adfs.sub.company.com to the internal ADFS server. I can reach the internal server from the proxy using the host file. 
    • I have created an internal DNS zone for the sub.company.com domain and added an A records for adfs.sub.company.com that points to the internal ADFS server. When I ping adfs.sub.company.com from the internal network it hits the internal address.
    • For my internal server the actual server name is adfs-server.company.local

    With this configuration I am curious on how I should configure the environment for service name and certificates going forward being that I have different internal and external domains.

    Questions:

    Should I use the internal server name (adfs-server.company.local) OR the external DNS name (adfs.sub.company.com) for the ADFS services name?  It is currently installed using the internal server name.

    How many certificates should be used?  Can I use one cert for everything?  Meaning can the same cert be used for external to proxy and proxy>internal?

    Can the same cert be used for Token-signing/decrypting as well as the service communication?

    Being that I have different internal and external domains – what should the CN name be for the cert? Will I need a SAN for the internal server name?

    Thanks

    Wednesday, April 04, 2012 5:55 PM

Answers

  • Hi Mac1234,

    You've created an internal zone for the sub.company.com domain, so you do have split DNS.

    1. Use the external DNS name (adfs.sub.company.com) for the ADFS services name.

    2. You can use the same third-party (not self-signed) certificate on both the proxy and on the ADFS backend.

    3. ADFS can generate the token-signing/decrypting certificates for you. Use self-signed certificates for these. You can read more about token signing certs here (http://blog.auth360.net/2012/01/08/expiring-ad-fs-2-0-token-signing-certificates/)

    4. The federation service is registered for adfs.sub.company.com .. that's the common name on the cert. No you don't need a SAN .. you stated there is an A record registered pointing to the internal ADFS instance in the internal zone you created.

    Internal clients will do kerberized SSO to ADFS.. external clients will hit the (DMZ) proxy and do forms-logon.....

    Regards,

    Mylo

    • Marked as answer by mac1234 Wednesday, April 25, 2012 3:23 PM
    Friday, April 06, 2012 7:37 PM
  • Mylo,

    I disagree with your point #3 about the token signing certificate. See my post here: http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/0dc942cd-ced1-4d09-9f10-73e325c241a9

    Additionally, mac1234, you may need to add the example https://adfs.sub.company.com host to your Local Intranet zone in Internet Explorer. This will allow your clients to automatically pass user credentials to the ADFS server during passive federation requests.

    Thanks,
    Frank

    • Marked as answer by mac1234 Wednesday, April 25, 2012 3:23 PM
    Wednesday, April 11, 2012 4:18 PM

All replies

  • Hi Mac1234,

    You've created an internal zone for the sub.company.com domain, so you do have split DNS.

    1. Use the external DNS name (adfs.sub.company.com) for the ADFS services name.

    2. You can use the same third-party (not self-signed) certificate on both the proxy and on the ADFS backend.

    3. ADFS can generate the token-signing/decrypting certificates for you. Use self-signed certificates for these. You can read more about token signing certs here (http://blog.auth360.net/2012/01/08/expiring-ad-fs-2-0-token-signing-certificates/)

    4. The federation service is registered for adfs.sub.company.com .. that's the common name on the cert. No you don't need a SAN .. you stated there is an A record registered pointing to the internal ADFS instance in the internal zone you created.

    Internal clients will do kerberized SSO to ADFS.. external clients will hit the (DMZ) proxy and do forms-logon.....

    Regards,

    Mylo

    • Marked as answer by mac1234 Wednesday, April 25, 2012 3:23 PM
    Friday, April 06, 2012 7:37 PM
  • Mylo,

    I disagree with your point #3 about the token signing certificate. See my post here: http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/0dc942cd-ced1-4d09-9f10-73e325c241a9

    Additionally, mac1234, you may need to add the example https://adfs.sub.company.com host to your Local Intranet zone in Internet Explorer. This will allow your clients to automatically pass user credentials to the ADFS server during passive federation requests.

    Thanks,
    Frank

    • Marked as answer by mac1234 Wednesday, April 25, 2012 3:23 PM
    Wednesday, April 11, 2012 4:18 PM
  • THanks guys.  I think that answers it.  I will have additional questions regarding UPN names and what not; I will start new thread for those.
    Wednesday, April 25, 2012 3:26 PM
  • Hi Frank,

    That's a fair point, but I would add that large companies may publish the CRL in the manner you described via the Internet as it provides advantages for validating external access for other reasons than AD FS alone, for example in determining trustworthiness of certificates used for (managed) client access... 

    Sunday, May 06, 2012 9:17 PM
  • I really should proof read my mails before I send them :-)

    Frank.. if it's a self-signed cert (e.g. issued via the AD FS powershell function) then there is no revocation path to speak of as there are no CDPs defined in the certificate path. Only if you use an internal PKI (with CDP) to issue the token signing cert does this become an issue.. The token signing certificate itself is exchanged in the metadata exchange either manually (via file) or thru an online exchange....

    Regards,

    Mylo

    Sunday, May 06, 2012 9:40 PM