Asked by:
Need ADFS 3.0 Claim Rule to whitelist testconnectivity.microsoft.com

Question
-
We whitelist access to Office 365 and I want to determine a way to identify requests from testconnectivity.microsoft.com. Per the claim below (from that site) I don't have a lot to work with so I'm hoping there is an additional claim type I'm not seeing. I suppose I could request an account that's allowed to unconditionally pass, but less paperwork and more fun if I can find something that identifies the request as a test from that site. Thank you!
Caller identity:
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
FOO\x123456
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
FOO\x123456
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
x123456@foo.com
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip
xxx.xxx.xx.xx <our ADFS IP>
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy
xxxxxxxxxx <our ADFS host name>
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path
/adfs/services/trust/2005/usernamemixed
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
http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork
falseFriday, January 20, 2017 7:41 PM
All replies
-
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 -
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 -
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 -
Nosir.Saturday, February 4, 2017 4:46 AM
-
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 -
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
- Edited by Shane Wright Tuesday, February 7, 2017 8:20 PM
Tuesday, February 7, 2017 8:17 PM -
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