locked
Need ADFS 3.0 Claim Rule to whitelist testconnectivity.microsoft.com RRS feed

 > 

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hey PNutts,

    I assume you have a rule that blocks authentications coming via the proxy.

    If the test you use relies on legacy auth then the TestConnectivity IPs should exist in x-ms-forwarded-client-ip

    • 13.67.59.89/32
    • 40.85.91.8/32
    • 104.208.36.70/32

    Got these from here

    x-ms-forwarded-client-ip typically contains the source IP of the authentication request, so I suspect you've got the wrong authentication.

    Anyway assuming you have a rule like this already - you'd add some bits for these IPs

    exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) &&
NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"\bYourPublicIP\b|\b13.67.59.89\b|\b40.85.91.8\b|104.208.36.70\b"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

    Good Luck!

    Shane

    Monday, January 23, 2017 2:40 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you for the response. I'll end up with an allow rule for each test based on the specific characteristics of that test. I'm hoping someone has already done the legwork to put them together but I'm preparing to run each test to see what the claim looks like and see if I can find anything that distinguishes it every time.

    I already have an unconditional allow for Autodiscover so I don't have to worry about that one. :) And also allow for ActiveSync and Outlook tests when we currently don't allow ActiveSync and Outlook connectivity when the request originates outside the corporate network (temporary until we finish setting up conditional access).

    In my sample above there's nothing that indicates it's not me trying to connect via Outlook from my home PC other than these that I don't normally see (but I don't think are unique enough to key off of):

    http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant
    2017-01-01T18:37:33.928Z
    http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
    http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password
    http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime
    2017-01-07T17:00:39.944Z

    Tuesday, January 24, 2017 1:02 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Is this question answered?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, February 3, 2017 12:38 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Nosir.
    Saturday, February 4, 2017 4:46 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hey PNutts,

    The issue is that an authentication from test-connectivity is naturally exactly the same as your authentication from your workstation - otherwise it wouldn't be a valid test.

    The only way to differentiate the two is using the source IP of the authentication attempt. This value always appears in the following claim

    http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip 

    The fact that you state this claim only contains your ADFS IP address indicates that either you are mistaken or your environment is configured incorrectly.

    In every environment I have seen, this claim contains one of the following possible entries:

    • The Public IP of the workstation/server that connected to your Web Application Proxy
    • The public IP of the workstation/server that connected to the Office 365 mailbox server that is proxying a legacy authentication
    • The IP address of any SSL terminating load balancer/SSL inspection device that also adds the x-ms-forwarded-client-IP http header.

    So, most likely you have a configuration problem that is preventing you from creating this rule. I suggest you describe your environment in more detail and provide any claim rules that might be manipulating x-ms-forwarded-client-IP

    Good luck!

    Shane

    Tuesday, February 7, 2017 8:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi PNutts,

    I just realised that you might have a Source Nat in front of your ADFS service and when you say 

    xxx.xxx.xx.xx <our ADFS IP> 

    You mean the internal IP of your Source NAT. In this case there is nothing you can do without modifying your reverse proxy to open the SSL session and inject a HTTP header for x-ms-forwarded-client-ip or changing your architecture to not use a Source NAT.

    Good Luck!

    Shane


    Tuesday, February 7, 2017 8:17 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Shane:

    Your point is well taken and I'll follow up with the server and F5 guys to see if they have any knobs they can turn. When I originally asked they thought their systems were configured to do what I want, and when the systems were first set up I occasionally saw multiple values for x-ms-forwarded-client-ip (probably before we set up modern authentication). I haven't seen anything but our own IP addresses for a long time.

    Thank you for the thoughtful reply.

    Paul

    Thursday, February 23, 2017 4:42 AM