Hello!
I'm using an ADFS environment for Office 365. I've two ADFS v3 and also two WAP for external accesses. My goal is to forbid external accesses without MFA.
After some lecture, I understood that some PowerShell accesses cannot be made with MFA. So I created a dedicated account for remote PowerShell to Office 365 only.
I restricted connections with the following authorization rule:
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-client-application", Value == "Microsoft.Exchange.Autodiscover"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\b185\.11\.188"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
It's working great. The remote PowerShell is working for Exchange because of the x-ms-forwarded-client-ip exclusion.
But I've a problem with Lync Online and the New-CsOnlineSession command. It does not seems to work like Exchange. The connection is refused. After looking the logs for the ADFS server, I see the incoming claims:
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path
/adfs/services/trust/2005/usernamemixed
http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork
false
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip
172.XX.XX.XX
And I see an "external access" but with a private IP address... How is this possible? As far as I know, the x-ms-forwarded-client-ip header is populated by Office 365. I should be the public IP no? I'm also wondering why this is an external
access. I'm inside my corporate network with a direct access to the ADFS. I think this is because the request is coming from Office 365 to the ADFS proxy. Can someone confirm this? But why a private address?
The obvious solution for me is to add my private network to the authorization rule but that mean that my rule is now useless because the access is granted from anywhere with someone with the same private IP address scope than me ...
Thanks!