This document describes how to configure the Office 365 (O365) sign in authentication (auth) flow to go through your Auth/Federation server. The Auth Proxy will act as the pass-through proxy for all auth flows. Use this document if you are using an on-premises Auth/Federation server. The Auth Proxy enhances the O365 auth flow to ensure access to your enterprise instance of O365 is protected by Netskope Security Cloud Platform.
O365 Auth Proxy intermediates the auth flow between enterprise users and your organization’s on-premises Auth/Federation server. The Auth Proxy operates transparently. The user experience is unchanged, as the federation service itself is unchanged. The trust relationship between your organization’s Auth/Federation server with O365 also remains intact.
The O365 Auth Proxy ensures that enterprise users from your organization are protected by Netskope Security Cloud Platform. It redirects all user browser sessions, which are not within the Netskope Source IP Address Ranges (Netskope Client installed and enabled), to the Netskope reverse proxy. This ensures O365 access is managed. Exceptions can be made by an admin to allow certain source IP addresses and ranges to bypass the reverse proxy redirection. And for non-browser flows, app access is only allowed from managed devices.
If an O365 app is configured for idle-timeout, then the Netskope proxy can redirect the user session to IDP logout URL (configured by the admin) upon the idle timeout expiration. This will force the user to re-authenticate even if same user tries to log back into O365 after idle-timeout. Currently this functionality is available only for forward proxy.
To watch a video about Netskope Auth Proxy for O365 with Okta, click play.
The following diagram illustrates a deployment scenario where Auth Proxy is in your DMZ and accessible from the Internet.
 |
O365 uses multiple auth flows, namely:
- Passive Auth: Used by web-based apps, browsers, etc.
- Active Auth: Used by native apps, like Outlook on Windows.
- MEX Flow: Used by native apps, like OneDrive on Windows.
The following table describes general configurations for possible auth flows:
| App Type | Netskope Client Installed | Netskope Client Uninstalled | Auth Flow |
|---|---|---|---|
| Native apps | Allow access as pass-through traffic | Block traffic (except for Outlook) | Active |
| Web-based apps | Allow access as pass-through traffic | Redirect to the Netskope reverse proxy | Passive |
Configuration Best Practices
| Best Practice | Description |
|---|---|
| Add your auth server domains as a custom app definition | This makes it easier to identify the app mapping and allows Netskope to track log in events. Define your custom app definition by going to Settings > Security Cloud Platform > App Definition. |
| Bypass + Tunnel setting for directing special app traffic | If you have the Netskope Client installed, but you still want to steer traffic from the endpoint to the Netskope Auth Proxy, select Bypass + Tunnel for Certificate-Pinned apps. For example, if you configure Lync/Skype for Business, go to Settings > Security Cloud Platform > Steering Configuration and select that steering configuration. Click on Exceptions, and then click Add Exception > Certificate-Pinned Apps. Click Advanced Options, and then select the Bypass action + Tunnel mode for the appropriate platforms. In addition, you should add the appropriate domains (like Lync.com, login.microsoftonline.com, aproxy.inskope.com, and so on). |