Cet article explique comment configurer les applications Netskope Private Access (NPA) pour les services de domaine Microsoft Active Directory, tels que DNS, Kerberos et WINS.
Souvent, les clients recherchent la même expérience pour l'utilisateur final en utilisant Windows Active Directory Domain Services pour la main-d'œuvre mobile que pour la main-d'œuvre sur site. Par exemple, si des utilisateurs travaillant à distance sur un domaine Active Directory géré par l'entreprise et joint au périphérique souhaitent se connecter à une application sur site qui utilise l'authentification intégrée de Windows, ils ne doivent pas être invités à entrer un mot de passe.
Netskope Private Access permet aux administrateurs d'étendre l'expérience des services de domaine aux utilisateurs distants de manière pratique et sécurisée.
 |
Configurer les applications privées pour le DNS avec la fonctionnalité DNS éditeur activée
La première étape pour permettre aux utilisateurs finaux d'utiliser les services de domaine Active Directory et les partages de fichiers à distance consiste à configurer la résolution DNS native et pass-through pour le domaine Active Directory interne. Dans le déploiement par défaut de Netskope Private Access, chaque application privée est représentée au client par une adresse IP artificielle non routable qui a été renvoyée à l'utilisateur dans la réponse à la requête DNS.
Par exemple, si une application privée sur site possède une adresse IP 10.0.0.10, le publicateur NPA y accèdera via cette adresse IP, tandis que les utilisateurs finaux recevront une adresse IP artificielle comme 191.1.1.5 lors de l’exécution d’une requête DNS depuis leur périphérique géré. Pour utiliser les services de domaine Windows, les utilisateurs doivent utiliser les vraies adresses IP des contrôleurs de domaine Windows. Pour cela, vous devez configurer une application privée pour le DNS avec la fonction DNS du publicateur activée. Cette application DNS privée permet aux utilisateurs de rejoindre des domaines Active Directory, d’interroger les politiques des groupes Active Directory et les rôles FSMO depuis leur périphérique distant.
Considérations sur l'architecture
- Déployez un éditeur par centre de données/cloud colocalisé avec les serveurs Active Directory.
- Pour chaque domaine Active Directory (comme
example.com,apac.example.com,europe.example.com) dans la forêt, il faudra une définition d'application privée <Active Directory DNS> et une définition d'application privée <Active Directory Domain> (selon l'exemple de définition d'application privée dans la procédure suivante) mappée sur le bon éditeur en fonction de leur emplacement.
Pour créer une définition d'application privée, connectez-vous à l'interface utilisateur de Netskope et allez sur Settings > Security Cloud Platform > App Definition > Private Apps. Créez deux définitions New Private App, une pour Active Directory DNS et une pour Active Directory Domain.
- Créez une application privée pour donner accès au DNS de l'annuaire. Dans ce cas, domain.local est votre domaine local. Cliquez sur New Private App et entrez ces paramètres :
- Nom de l'application : Entrez un nom, comme Active Directory DNS. (ou ce que vous préférez).
- Hôte : Saisissez ces hôtes :
*._http.domain.local*._https.domain.local*._kkdcp.domain.local*._msdcs.domain.local*._tcp.domain.local*._udp.domain.local*._sites.domain.local
- TCP: Enter
53. - UDP: Enter
53. - Editeur : Select le(s) éditeur(s) qui peuvent accéder aux ressources de votre serveur DNS interne local.
- Utiliser le DNS de l'éditeur : Activez cette option.
- Cliquez sur Save.
- Créez une définition d'application privée qui permet aux utilisateurs d'accéder aux contrôleurs de domaine Windows à partir de leur périphérique géré.
Étant donné que l'application précédente que vous avez configurée renvoie à l'adresse IP interne de l'utilisateur final du contrôleur de domaine, vous devez configurer une application privée qui englobe les adresses IP de tous les contrôleurs de domaine afin qu'ils deviennent accessibles via Netskope Private Access. Cliquez sur New Private App et entrez ces paramètres :
- Nom de l'application : Saisissez un nom comme Active Directory Domain (ou tout autre nom que vous préférez).
- Hôte : Saisissez le FQDN et l'IP de chaque serveur Active Directory situé sur le même site que l'éditeur.
- TCP: Enter
53,88,135,137,139,389,445,464,636,1512,3268,3269,5357,49152-65535. - UDP: Enter
53,88,123,135,137,138,389,464,1512,5357,49152-65535 - Éditeur : Select l'éditeur hébergé sur le serveur AD.
- Utiliser le DNS de l'éditeur : Activez cette option.
- Cliquez sur Save.
- Créez New stratégie d'accès aux applications privées en utilisant les critères spécifiques à votre environnement. Allez à Policies > Real-time Protection, modifiez une politique existante, ou cliquez sur New Policy et sélectionnez Private App Access.
- Saisissez les paramètres en utilisant les critères propres à votre environnement.
- Source : Select, tout ce qui est approprié.
- Destination : Select Private App, puis sélectionnez les définitions d'applications privées que vous avez créées (dans cet exemple, Active Directory DNS et Active Directory Domain).
- Profil et action : Select Allow.
- Définir la politique : Saisissez un nom pour la politique (celui que vous préférez).
- Statut : Activez cette option.
- Cliquez sur Save.
- Cliquez sur Apply Changes.
Définitions des ports Active Directory
| Numéro de port | Protocole(s) | Description du service |
|---|---|---|
| 53 | TCP/UDP | DNS |
| 88 | TCP/UDP | Kerberos |
| 123 | UDP | NTP / Heure |
| 135 | TCP | Mappage de points d'extrémité RPC |
| 389 | TCP/UDP | LDAP / CLDAP |
| 445 | TCP | CIFS / SMB |
| 464 | TCP/UDP | Modification du mot de passe Kerberos |
| 636 | TCP | LDAPS |
| 3268 | TCP | Global Catalog LDAP |
| 3269 | TCP | Global Catalog LDAPS |
| 9389 | TCP | ADWS (utilisé par Powershell) |
| 49152-65535 | TCP | Ports élevés pour RPC |
Dans la configuration ci-dessus :
- L'hôte distant périphérique accèdera aux contrôleurs de domaine à l'aide des enregistrements SRV de domaine
_gc._tcp.<yourwindowsdomain.com>et_ldap._tcp._sites.DomainDnsZones. yourwindowsdomain.com, nous définissons donc les zones windows underscore et les zones DNS de forêt et de domaine avec un FQDN de caractère générique pour couvrir toutes les requêtes DNS pour les services de domaine Windows, comme indiqué dans les captures d'écran précédentes. - Port : Le port 53 doit être utilisé pour le trafic DNS.
Activation de SCCM avec Netskope Private Access
Si vous avez déjà déployé des serveurs de publication aux emplacements idéaux pour accéder aux ressources SCCM, votre première étape consiste à vous assurer que vous avez suivi les meilleures pratiques pour le déploiement des services Active Directory via Netskope Private Access. Cela garantit que des services tels que Kerberos, la résolution SRV et d'autres services sont disponibles pour une authentification et une sélection SCCM correctes.
Si Active Directory est correctement configuré, vous pouvez configurer SCCM sur NPA en suivant la procédure ci-dessous :
- Définissez des groupes de délimitation basés sur les sites Active Directory en utilisant les IP de l'éditeur ou les sous-réseaux RFC 1918.
- Définir les définitions d'application pour les ressources SCCM.
- Créez des stratégies de protection en temps réel pour permettre l'accès aux ressources SCCM.
Pour en savoir plus, consultez : SCCM et produits : Netskope Private Access.