locked
ADFS 3.0 client certificate authentication display with no result on WAP RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have the setup as ADFS 3.0 client authentication method enabled. When I open browser to logon, the ADFS 3.0 page displays a message as "Select a certificate that you want to use for authentication. If you cancel the operation, please close your browser and try again." the certificats are displayed from internal when browsers access directly to ADFS 3.0 Server but the certificates are displayed for selection when I use external acces througt Web Application Proxy (WAP) with TCP port 49443 enabled inbound on the firewall between the clients and the Web Application Proxy (netstats show Etablished state on 49443 of the WAP with no resluts

    It smells it's the only requirement is :

    if client user certificate authentication (clientTLS authentication using X509 user certificates) is required, AD FS in Windows Server 2012 R2 requires that TCP port 49443 be enabled inbound on the firewall between the clients and the Web Application Proxy. This is not required on the firewall between the Web Application Proxy and the federation servers).

    source : https://technet.microsoft.com/en-us/library/dn554247.aspx#BKMK_7

    All sources tell that 49443 is the only requirement

    https://technet.microsoft.com/en-us/library/dn486819.aspx

    Anyone can help me to solve this issue ?

    https://technet.microsoft.com/en-us/library/dn283415.aspx

    thank you for your help




    Thursday, March 17, 2016 8:48 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    When the certificate selection dialog popup, if we select one of them, what happens?

    If the dialog box is frozen, please check if the CRL of the certificate is available. I've seen a similar case which is caused by the revocation check failure.

    Best Regards,

    Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, March 21, 2016 2:22 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hey,

    ok maybe it is a CRL problem -- but if I checkt it with the cerutil certutil -f –urlfetch -verify all seams fine on the WAP.

    Now I made a workaround with the following guide:

    https://blogs.msdn.microsoft.com/kaushal/2012/10/15/disable-client-certificate-revocation-crl-check-on-iis/

    1. netsh http add sslcert hostnameport= adfs.xyz.de:49443 certhash=<the old value> appid={<the old value>} certstorename=My verifyclientcertrevocation=disable clientcertnegotiation=enable

    Use the IIS 8 settings ...

    Now it works without a CRL checking - not nice but it works. I start to debug the pki ... maybe something is wrong here.


    • Edited by sbidys Tuesday, May 24, 2016 2:31 PM
    • Proposed as answer by sbidys Tuesday, May 24, 2016 2:32 PM
    • Marked as answer by Stéphane Mendez Monday, July 11, 2016 2:40 PM
    Tuesday, May 24, 2016 10:07 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    It was an issue with CRL

    The main problem was the fact that the WAP was not able to verify the revocation status of the client certificate (presence of error 30 and / or 53 at the CPAI newspaper on WAP server).
     In fact the latter had only a single LDAP path in the CDP extension, while the LDAP traffic between the web server (located in DMZ) and domain controllers was not allowed.
     Configuration of the issuing CA client certificates was then changed so that in the CDP extension of newly issued certificates there is an additional way of http.
     After obtaining (enrollment) a new client certificate with dual path (CRL at the CDP extension), it was nevertheless necessary to do the following to the WAP server to properly validate the revocation status of the client certificate (in the scenario where the revocation check of the client certificate in the SSL binding of the 49443 port was again "ENABLE"):
     The publication of an updated CRL was performed from the administration of the intermediate CA mmc.
     Purge CRL "caching" in the context "local system" in the WAP server (via the use of the tool "psexec / s / i cmd"):
     certutil -urlcache CRL delete
     certutil -setreg chain \ ChainCacheResyncFiletime @Now
     Restart the service "Cryptographic Service"
     Once ADFS authentication via WAP on the basis of a client certificate were then possible.

    Monday, July 11, 2016 2:39 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    When the certificate selection dialog popup, if we select one of them, what happens?

    If the dialog box is frozen, please check if the CRL of the certificate is available. I've seen a similar case which is caused by the revocation check failure.

    Best Regards,

    Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, March 21, 2016 2:22 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    hello Steven,

    When I select the good certificate nothing happens, the dialog box isn't frozen, I don't think that the CRL need to be published although it was a private certificate it's that because when I use the internal acces through the ADFS server it works so the revocation check need to be use only after 7days.

    In this case I then tries external access via WAP which request appears not achieve while connection on the TCP port 49443 is well established, so if the revocation list has already been verified that audit does not seem yet necessary since there was no expiration which leads to consult again

    Monday, April 4, 2016 12:50 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hey,

    same here - we have the exact same behavior with the WAP and a client certificate authentication.

    I checked the external and internal CDP and AIA of the user certificate - it is accessible and valid (checked with certutil -url).

    If i tried to connect to the https://adfs.urls.com:49443/adfs/ls/idpinitiatedsignon.aspx --> I select a valid user certificate --> the Borwser accept his and tries to connect to the WAP. I saw some TCP keepalive packages at my client to the WPA system.

    and the trace to the URL

    Tuesday, May 24, 2016 7:44 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hey,

    ok maybe it is a CRL problem -- but if I checkt it with the cerutil certutil -f –urlfetch -verify all seams fine on the WAP.

    Now I made a workaround with the following guide:

    https://blogs.msdn.microsoft.com/kaushal/2012/10/15/disable-client-certificate-revocation-crl-check-on-iis/

    1. netsh http add sslcert hostnameport= adfs.xyz.de:49443 certhash=<the old value> appid={<the old value>} certstorename=My verifyclientcertrevocation=disable clientcertnegotiation=enable

    Use the IIS 8 settings ...

    Now it works without a CRL checking - not nice but it works. I start to debug the pki ... maybe something is wrong here.


    • Edited by sbidys Tuesday, May 24, 2016 2:31 PM
    • Proposed as answer by sbidys Tuesday, May 24, 2016 2:32 PM
    • Marked as answer by Stéphane Mendez Monday, July 11, 2016 2:40 PM
    Tuesday, May 24, 2016 10:07 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    It was an issue with CRL

    The main problem was the fact that the WAP was not able to verify the revocation status of the client certificate (presence of error 30 and / or 53 at the CPAI newspaper on WAP server).
     In fact the latter had only a single LDAP path in the CDP extension, while the LDAP traffic between the web server (located in DMZ) and domain controllers was not allowed.
     Configuration of the issuing CA client certificates was then changed so that in the CDP extension of newly issued certificates there is an additional way of http.
     After obtaining (enrollment) a new client certificate with dual path (CRL at the CDP extension), it was nevertheless necessary to do the following to the WAP server to properly validate the revocation status of the client certificate (in the scenario where the revocation check of the client certificate in the SSL binding of the 49443 port was again "ENABLE"):
     The publication of an updated CRL was performed from the administration of the intermediate CA mmc.
     Purge CRL "caching" in the context "local system" in the WAP server (via the use of the tool "psexec / s / i cmd"):
     certutil -urlcache CRL delete
     certutil -setreg chain \ ChainCacheResyncFiletime @Now
     Restart the service "Cryptographic Service"
     Once ADFS authentication via WAP on the basis of a client certificate were then possible.

    Monday, July 11, 2016 2:39 PM