Limit Access to Office 365 Based on the Location of Client

0 Likes
over 6 years ago

Introduction


 
There are some requirements for enterprises such as policy restriction of client location to access Office 365 services. For example STS token has to be sent only for activesync client. Or allow only internal client IPAddress.

Solution


 
Office 365 sends information about application name, client IP, useragent, proxy information to STS as part of HTTP request. Solution to restrict user access to STS can be implemented via ServletFilter. Filter will look for following header names:

x-ms-client-application
x-ms-forwarded-client-ip
x-ms-client-user-agent

Implementation steps



  1. Download servlet filter attached to this cool solution.

  • Copy the jar file to IDP /opt/novell/nam/idp/webapps/nidp/WEB-INF/lib

  • Modify the web.xml to add the servlet filter, as below:
     
    <filter>
    <filter-name>o365stsfilter</filter-name>
    <display-name>NIDP O365 STS Filter</display-name>
    <description> ACL implementation for O365 NIDP STS</description>
    <filter-class>com.netiq.custom.filter.O365STSFilter</filter-class>
    <init-param>
    <param-name>ALLOWED_APPS</param-name>
    <param-value>Microsoft.Exchange.Autodiscover,Microsoft.Exchange.ActiveSync</param-value>
    </init-param>
    <init-param>
    <param-name>ALLOWED_CLIENT_IPS</param-name>
    <param-value>\b137\.65\.231\.141\b</param-value>
    </init-param>
    <init-param>
    <param-name>ALLOWED_CLIENT_USER_AGENTS</param-name>
    <param-value>iPhone</param-value>
    </init-param>

    <init-param>
    <param-name>DEBUG</param-name>
    <param-value>true</param-value>
    </init-param>
    </filter>
    <filter-mapping>
    <filter-name>o365stsfilter</filter-name>
    <url-pattern>/wstrust/sts/active12</url-pattern>
    </filter-mapping>

     

  • Restart IDP /etc/init.d/novell-idp restart

  • Test your applicable use case.



Servlet Filter parameters




  1. ALLOWED_APPS – list of applications allowed to access STS, application names has to be entered as comma separated values. E.g., Microsoft.Exchange.Autodiscover,Microsoft.Exchange.ActiveSync
     
    <init-param>
    <param-name>ALLOWED_APPS</param-name>
    <param-value>Microsoft.Exchange.Autodiscover,Microsoft.Exchange.ActiveSync</param-value>
    </init-param>

     

  • ALLOWED_CLIENT_IPS – list of IPAddress in regex format, multiple regex format can be used, values to be comma separated. E.g.,
     
    <init-param>
    <param-name>ALLOWED_CLIENT_IPS</param-name>
    <param-value>\b137\.65\.31\.41\b,\b174\.54\.13\.40\b</param-value>
    </init-param>

     
    Further information how to prepare regex please do visit this url https://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx#build


  • ALLOWED_CLIENT_USER_AGENTS – allowed list of user agents like iphone, android E.g.,
     
    <init-param>
    <param-name>ALLOWED_CLIENT_USER_AGENTS</param-name>
    <param-value>iPhone</param-value>
    </init-param>

     

  • DEBUG – enables log, which prints to catalina.out, value is true or false. E.g.,
     
    <init-param>
    <param-name>DEBUG</param-name>
    <param-value>true</param-value>
    </init-param>

     



Additional parameters


 
DEFAULT_ALLOW – value is true or false. If this parameter is not configured, above parameters like ALLOWED_CLIENT_USER_AGENTS not configured, considered restriction not to be enforced. If value is set to false, all request will be denied.

NEGATE_ALLOWED_APPS_RESULT – value is true result of ALLOWED_APPS rule will be negated, this is useful where one want to allow other than listed apps.

NEGATE_ALLOWED_IPS_RESULT – value is true result of ALLOWED_CLIENT_IPS rule will be negated, this is useful where IPAddress not in the list is allowed

NEGATE_ALLOWED_CLIENT_USER_AGENTS_RESULT – value is true result of ALLOWED_CLIENT_USER_AGENTS rule will be negated, this is useful where useragent not in the list are allowed.


UseCase: Allow ActiveSync application only to NAM STS from anywhere.

Solution: Add ALLOWED_APPS init parameter of filter with following values

“Microsoft.Exchange.Autodiscover,Microsoft.Exchange.ActiveSync”

Microsoft.Exchange.Autodiscover is queried first for registration of ActiveSync application, and next Microsoft.Exchange.ActiveSync is sent as next, as part of registration and accessing exchange.

Remaining parameters are not required, DEBUG parameter can be added to enable logs.

Sample logs: where activesync application and client IPs are 137.65.31.41 or 174.54.13.40 and user agent Iphone are allowed.

Before finalize the result for x-ms-client-application- true
Result is not negated !! - true
clientIP: 174.52.31.20
Iterate IP_REGEX value: \b137\.65\.31\.41\b
Iterate IP_REGEX value: \b174\.54\.13\.40\b
Before finalize the result for x-ms-forwarded-client-ip - false
Result is not negated !! - false
requested path denied - https://www.idp.com/nidp/wstrust/sts/active12
Before finalize the result for x-ms-client-application- true
Result is not negated !! – true



Additional Notes

  1. x-ms-endpoint-absolute-path - header will give information request is passive or active, passive means browser based request, active means application client request. STS is called by active authentication hence this header is not checked but in future, clients will have passive authentication so utilizing this header and applying ACL for ws-fed request will be useful. In this case servlet filter should be applicable to the following path /nidp/wsfed/ep

  • x-ms-proxy - header will give information about when ADFS federation proxy is involved in request process

  • Regex - filter source has to be modified to accommodate regex for any x-ms-* header value search to apply ACL



Resources
https://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx

Labels:

How To-Best Practice
Comment List
Anonymous
Related Discussions
Recommended