none
How to properly setup LB probe for ADFS 3.0 servers

    Question

  • We are facing a problem during ADFS 3.0 (Windows Server 2012 R2), because we do not find a suitable URL for hardware Load Balancer probe to test ADFS nodes.

    When tried with IE browser, the URL https://sts.adfs1.ad/adfs/ls/IdpInitiatedSignon.aspx properly results in ADFS login page but, when tried the same URL with HW LB probe, the probe gets no answer from ADFS server at all.

    We compared incoming traffic with network monitor in that ADFS server node (https temporary changed to http to see the traffic), a somewhat similar HTTP GET query did exist:

    GET /adfs/ls/IdpInitiatedSignon.aspx HTTP/1.1..Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*..Accept-Language: fi-FI..User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)..Accept-Encoding: gzip, deflate..Host: sts.adfs1.ad

    .PV??ìà_¹«.ç..E..ð'@.ÿ.%Ƭ..ü¬..Lî¢.PL?Ëf\Mæ?...?Ä.......f;[.4..GET /adfs/ls/IdpInitiatedSignon.aspx HTTP/1.1..Connection: Close..Host: sts.adfs1.ad

    How to properly monitor the ADFS 3.0 server nodes?

    Br, Kari Oikkonen
    MCITP/2008
    Fujitsu Finland

    Thursday, February 06, 2014 1:59 PM

All replies

  • You might see better results probing /FederationMetadata/2007-06/FederationMetadata.xml.

    With that being said the IdpInit page should load. I'm wondering if your load balancer is having issues with the SSL connection. Can you enable tracing on the ADFS server to see if anything funny is getting logged when the LB does its thing? Also, is it just the probe, or are you seeing this issue when the LB is routing traffic to ADFS (assuming you fake the probe endpoint)?


    Developer Security MVP | www.syfuhs.net

    Thursday, February 06, 2014 5:14 PM
  • We tried also that, but it actually leads us to one key problem that we faced. As the LB probe rule has to contain the server IP, and we wondered why it cannot get it working, we forked the problem down with IE browser with two URL's:
    https://sts.adfs1.ad/FederationMetadata/2007-06/FederationMetadata.xml
    opens the XML file OK. Here, the sts.adfs1.ad DNS address matches to the https cert installed in the ADFS server.
    https://123.123.123.123/FederationMetadata/2007-06/FederationMetadata.xml
    results in Internet Explorer cannot display the webpage
    So, does the ADFS 3 behave differently to that in ADFS 2, and how should we probe the ADFS 3?

    Friday, February 07, 2014 7:29 AM
  • I recommended using the federation metadata file to a client recently as well. Evidently the F5 documentation for monitors is stale. It currently suggests pointing at the root of https://sts.mydomain.com, which is not a path that the new version of AD FS provisions. Your NLB vendor may be out of date as well.

    I'd guess that your issue with requiring the IP address rather than the DNS name is down to the move from IIS to HTTP.SYS. If you run netsh http show sslcert you will see the bindings that are configured. In one of my environments, this is the URLs in the SSL certificate on port 443, plus the AD FS URL on 49443 (for certificate authentication) plus localhost:443. There may be a way that you could add the IP address as another binding in here but I'm not entirely sure about that (still learning about HTTP.SYS). I suspect this is a binding thing, because if you run netsh http show urlacl you'll see things like https://+:443/FederationMetadata/2007-06/, which are unconcerned with the host name.


    http://twitter.com/tristanwatkins http://tristanwatkins.com

    Friday, February 07, 2014 2:48 PM
  • Please note that using dns name in the url opens the metadata OK, but using IP address fails, not opposite as you mentioned.

    The netsh http show sslcert lists the following:

    SSL Certificate bindings:
    -------------------------

        Hostname:port                : sts.mydomain.com:443
        Certificate Hash             : 12b510eead093f8d29db950a42ecf4940c933533
        Application ID               : {5d89a20c-beab-4389-9447-324788eb944a}
        Certificate Store Name       : MY
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : AdfsTrustedDevices
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled

        Hostname:port                : localhost:443
        Certificate Hash             : 12b510eead093f8d29db950a42ecf4940c933533
        Application ID               : {5d89a20c-beab-4389-9447-324788eb944a}
        Certificate Store Name       : MY
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : AdfsTrustedDevices
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled

        Hostname:port                : sts.mydomain.com:49443
        Certificate Hash             : 12b510eead093f8d29db950a42ecf4940c933533
        Application ID               : {5d89a20c-beab-4389-9447-324788eb944a}
        Certificate Store Name       : MY
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Enabled

    The netsh http show urlacl shows the following:

    URL Reservations:
    -----------------

        Reserved URL            : http://+:80/Temporary_Listen_Addresses/
            User: \Everyone
                Listen: Yes
                Delegate: No
                SDDL: D:(A;;GX;;;WD)

        Reserved URL            : https://+:5986/wsman/
            User: NT SERVICE\WinRM
                Listen: Yes
                Delegate: No
            User: NT SERVICE\Wecsvc
                Listen: Yes
                Delegate: No
                SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

        Reserved URL            : http://+:5985/wsman/
            User: NT SERVICE\WinRM
                Listen: Yes
                Delegate: No
            User: NT SERVICE\Wecsvc
                Listen: Yes
                Delegate: No
                SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

        Reserved URL            : http://+:47001/wsman/
            User: NT SERVICE\WinRM
                Listen: Yes
                Delegate: No
            User: NT SERVICE\Wecsvc
                Listen: Yes
                Delegate: No
                SDDL: D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

        Reserved URL            : http://*:2869/
            User: NT AUTHORITY\LOCAL SERVICE
                Listen: Yes
                Delegate: No
                SDDL: D:(A;;GX;;;LS)

        Reserved URL            : http://*:5357/
            User: BUILTIN\Users
                Listen: Yes
                Delegate: No
            User: NT AUTHORITY\LOCAL SERVICE
                Listen: Yes
                Delegate: No
                SDDL: D:(A;;GX;;;BU)(A;;GX;;;LS)

        Reserved URL            : https://*:5358/
            User: BUILTIN\Users
                Listen: Yes
                Delegate: No
            User: NT AUTHORITY\LOCAL SERVICE
                Listen: Yes
                Delegate: No
                SDDL: D:(A;;GX;;;BU)(A;;GX;;;LS)

        Reserved URL            : https://+:443/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/
            User: NT SERVICE\SstpSvc
                Listen: Yes
                Delegate: Yes
            User: BUILTIN\Administrators
                Listen: No
                Delegate: No
            User: NT AUTHORITY\SYSTEM
                Listen: Yes
                Delegate: Yes
                SDDL: D:(A;;GA;;;S-1-5-80-3435701886-799518250-3791383489-3228296122-2938884314)(A;;GR;;;BA)(A;;GA;;;SY)

        Reserved URL            : http://+:80/adfs/
            User: NT SERVICE\adfssrv
                Listen: Yes
                Delegate: Yes
                SDDL: D:(A;;GA;;;S-1-5-80-2246541699-21809830-3603976364-117610243-975697593)

        Reserved URL            : https://+:443/adfs/
            User: NT SERVICE\adfssrv
                Listen: Yes
                Delegate: Yes
                SDDL: D:(A;;GA;;;S-1-5-80-2246541699-21809830-3603976364-117610243-975697593)

        Reserved URL            : https://+:49443/adfs/
            User: NT SERVICE\adfssrv
                Listen: Yes
                Delegate: Yes
                SDDL: D:(A;;GA;;;S-1-5-80-2246541699-21809830-3603976364-117610243-975697593)

        Reserved URL            : https://+:443/FederationMetadata/2007-06/
            User: NT SERVICE\adfssrv
                Listen: Yes
                Delegate: Yes
                SDDL: D:(A;;GA;;;S-1-5-80-2246541699-21809830-3603976364-117610243-975697593)

    Any idea of how to build a probe rule with IP address?

    Friday, February 07, 2014 6:55 PM
  • Hi Kari,

    Sorry, I think we've crossed wires. I understand that your load balancer works with IP addresses but your AD FS is only responding on the DNS name. My lab environment is also only responding on the DNS name. What I'm suggesting is that you're focused on constructing the monitor when you should be focusing on getting AD FS to respond to requests on the IP address (assuming there will never be a way to get your monitor to work with DNS).

    The two NETSH commands hopefully show you that HTTP.SYS is listening for all requests to on port 443 (https://+:443/FederationMetadata/2007-06/) but there is no SSL binding for the IP address. I'm not certain about this, but I'm speculating that this is the cause of the behaviour we're seeing. HTTP.SYS does not work in the same way that IIS used to. If I had more time to look in to this right now, I'd be starting my search by reviewing the HTTP.SYS documentation or the NETSH HTTP commands. I would start with this MSDN article and see what I could get working in a lab http://msdn.microsoft.com/en-us/library/windows/desktop/cc307220(v=vs.85).aspx. Sorry I can't be more helpful with this right now. Hopefully this at least clarifies my original response, and hopefully someone who's actually done this comes along here. :)

    Cheers,

    Tristan


    http://twitter.com/tristanwatkins http://tristanwatkins.com

    Friday, February 07, 2014 9:22 PM
  • Use http://httpsysmanager.codeplex.com/ and add the SSL Binding for the IP address on each host.  We used /adfs/ls/IdpInitiatedSignon.aspx for the lb probe along with a  username and password.  Hope that helps.
    Wednesday, March 05, 2014 2:38 PM
  • As was brought up in another thread here, ADFS 2012 R2 uses SNI, so we can expect requests to the bare IP address to fail.

    Steve Kradel, Zetetic LLC

    Wednesday, March 05, 2014 11:26 PM
  • Hi Steve,

    Does this mean that NETSH HTTP ADD SSLCERT IPPORT is in fact controlling SNI in HTTP.SYS?

    Cheers,

    Tristan


    http://twitter.com/tristanwatkins http://tristanwatkins.com

    Friday, March 07, 2014 2:42 PM
  • Use https://123.123.123.123/federationmetadata/2007-06/federationmetadata.xml, but then use a host header with your load balancer.  So the host header would be sts.adfs1.ad.  AD FS will not respond to the IP any longer.  The older AD FS proxy server was the same way. 

     
    Thursday, March 13, 2014 7:39 PM
  • Hi Tristan,

    I think that's a case of the tail wagging the dog. Given that the default configuration demands SNI, the question is how to support non-SNI clients (in this case the load balancer probe which doesn't support it). In that situation, NETSH can be used to add an additional listener to bind to 0.0.0.0:443 to support non SLI clients. The downside of that is that the certificate concerned needs to include the published URLs.. not so much of a problem on the backend farm, but more problematic on the WAP because it embraces other functionality such as reverse proxy (and the load balancer in front of it if we're doing L7 load balancing/cookie injection).


    http://blog.auth360.net

    Thursday, March 13, 2014 11:46 PM
  • I think I follow. So you're saying that we can disable SNI by binding all IP addresses in HTTP.SYS, but then we're back to the world of loads of SANs in the reverse proxy's certificate, right? And is there a reason you're adding the binding for 0.0.0.0 rather than the specific IP address/addresses in question, as recommended by NOCAdmin above?


    http://twitter.com/tristanwatkins http://tristanwatkins.com

    Friday, March 14, 2014 10:28 AM
  • From what I've seen from testing, the clients that are SNI capable normally should send the FQDN of the server in the DNS field of the TLS extension as part of an extended client hello when setting up a TLS connection with the web server. The alternate listener mentioned (0.0.0.0:443) is there to provide support for clients that don't support (read: send) the TLS extensions such as SLI during the hello phase.

    As you mentioned if the server in question is (reverse) proxying multiple URLs, then those addresses need to be available in the certificate (i.e. SAN) of the listener that is to be available for non-SNI capable clients. If we're using strict names (sts.mydomain.com, webserver.domain1.com etc) then this shouldn't be a problem, but I would imagine that wildcard certificates (e.g. *.mydomain1.com and *.mydomain2.com) pose an issue as we cannot service these via a SAN entry in a single cert. I've not tested bind the listener to an IP address, but I would imagine that this is fine, if you want to service multiple listeners for non-SNI use.  

    In other words, we're not disabling SNI. Rather, we're accommodating non-SNI capable clients through setting up the additional listener, as the default configuration in HTTP.SYS in R2 assumes the use of the TLS extensions (and SNI).


    http://blog.auth360.net


    • Edited by Mylo Saturday, March 15, 2014 9:23 PM
    Saturday, March 15, 2014 9:22 PM
  • This works for us using F5 Big-IP. Ran on each ADFS server and bare IP is good now.

    netsh http add sslcert ipport=IPAddress:443 certhash=certificatethumbprint certstorename=MY sslctlstorename=AdfsTrustedDevices
    • Edited by NOCAdmin Wednesday, March 26, 2014 2:33 PM
    Wednesday, March 26, 2014 2:24 PM
  • Right, although as part of the broader conversation, this means using a non-SLI listener. Surprising if the F5 doesn't have native support for SLI

    http://blog.auth360.net

    Wednesday, March 26, 2014 10:11 PM
  • Hi, Please have a look at https://devcentral.f5.com/articles/big-ip-and-adfs-part-5-working-with-adfs-30-and-sni#.U4zzLokazCQ
    • Proposed as answer by chisinev Monday, June 02, 2014 9:59 PM
    Monday, June 02, 2014 9:58 PM