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.
Le proxy d'authentification O365 garantit que les utilisateurs de votre organisation sont protégés par Netskope Security Cloud Platform. Il redirige toutes les sessions de navigation des utilisateurs qui ne se trouvent pas dans la plage d'adresses IP source Netskope (Netskope Client installée et activée) vers le proxy inverse Netskope. Cela permet de gérer l'accès à O365. Des exceptions peuvent être faites par un administrateur pour permettre à certaines adresses IP sources et à certaines plages d'adresses de contourner la redirection par proxy inverse. Et pour les flux qui ne concernent pas les navigateurs, l'accès à l'application n'est autorisé qu'à partir d'un périphérique géré.
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.
Pour regarder une vidéo sur Netskope Auth Proxy for O365 with Okta, cliquez sur 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 : utilisée par les applications natives, comme Outlook sur Windows.
- MEX Flow : utilisé par les applications natives, comme OneDrive sous Windows.
Le tableau suivant décrit les configurations générales des flux d'authentification possibles :
| Type d'application | Netskope Client Installed | Netskope Client Désinstallé | Flux d'authentification |
|---|---|---|---|
| Native apps | Autoriser l'accès en tant que trafic de passage | Block traffic (except for Outlook) | Actif |
| Applications basées sur le web | Autoriser l'accès en tant que trafic de passage | Redirection vers le proxy inverse de Netskope | Passive |
Configuration Best Practices
| Meilleures pratiques | Description |
|---|---|
| Add your auth server domains as a custom app definition | Cela facilite l'identification du mappage de l'application et permet à Netskope de suivre les événements de connexion. Définissez votre définition d'application personnalisée en allant à Settings > Security Cloud Platform > App Definition. |
| Paramètre Bypass + Tunnel pour diriger le trafic des applications spéciales | Si vous avez installé le site Netskope Client, mais que vous souhaitez toujours diriger le trafic du point de terminaison vers le proxy Netskope Auth, sélectionnez Bypass + Tunnel for Certificate-Pinned apps (Contournement + tunnel pour les applications à certificat fixe). Par exemple, si vous configurez Lync/Skype for Business, allez sur Settings > Security Cloud Platform > Steering Configuration et sélectionnez cette configuration de pilotage. Cliquez sur Exceptions, puis sur Add Exception > Certificate-Pinned Apps. Cliquez sur Advanced Options, puis sélectionnez l'action de contournement + le mode tunnel pour les plates-formes appropriées. En outre, vous devez ajouter les domaines appropriés (comme Lync.com, login.microsoftonline.com), aproxy.inskope.com, etc.) |