Configurations non prises en charge DirectAccess
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016
Passez en revue la liste suivante des configurations DirectAccess non prises en charge avant de commencer votre déploiement pour éviter d’avoir à recommencer votre déploiement.
Distribution d’objets de stratégie de groupe (réplications SYSVOL) par le service de réplication de fichiers (FRS)
Ne déployez pas DirectAccess dans des environnements où vos contrôleurs de domaine exécutent le service de réplication de fichiers (FRS) pour la distribution d’objets de stratégie de groupe (réplications SYSVOL). Le déploiement de DirectAccess n’est pas pris en charge lorsque vous utilisez FRS.
Vous utilisez FRS si vos contrôleurs de domaine exécutent Windows Server 2003 ou Windows Server 2003 R2. En outre, vous pouvez utiliser FRS si vous utilisiez auparavant des contrôleurs de domaine Windows 2000 Server ou Windows Server 2003 et que vous n’avez jamais migré la réplication SYSVOL de FRS vers la réplication du système de fichiers distribués (DFS-R).
Si vous déployez DirectAccess avec la réplication SYSVOL FRS, vous risquez de supprimer involontairement les objets de stratégie de groupe DirectAccess qui contiennent les informations de configuration du serveur et du client DirectAccess. Si ces objets sont supprimés, votre déploiement DirectAccess subira une panne et les ordinateurs clients qui utilisent DirectAccess ne pourront pas se connecter à votre réseau.
Si vous envisagez de déployer DirectAccess, vous devez utiliser des contrôleurs de domaine qui exécutent des systèmes d’exploitation ultérieurs à Windows Server 2003 R2, et vous devez utiliser DFS-R.
Pour plus d’informations sur la migration de FRS vers DFS-R, consultez le Guide de migration de la réplication SYSVOL : réplication FRS vers DFS.
Protection de l’accès réseau pour les clients DirectAccess
La protection d’accès réseau (NAP) est utilisée pour déterminer si les ordinateurs clients distants respectent les stratégies informatiques avant de leur accorder l’accès au réseau d’entreprise. La protection d’accès réseau (NAP) a été déconseillée dans Windows Server 2012 R2 et n’est pas incluse dans Windows Server 2016. Pour cette raison, le démarrage d’un nouveau déploiement de DirectAccess avec NAP n’est pas recommandé. Une autre méthode de contrôle de point de terminaison pour la sécurité des clients DirectAccess est recommandée.
Prise en charge multisite pour les clients Windows 7
Lorsque DirectAccess est configuré dans un déploiement multisite, les clients Windows 10®, Windows® 8.1 et Windows® 8 peuvent se connecter au site le plus proche. Les ordinateurs clients Windows 7® n’ont pas la même fonctionnalité. La sélection du site pour les clients Windows 7 est définie sur un site particulier au moment de la configuration de la stratégie, et ces clients se connectent toujours à ce site désigné, quel que soit leur emplacement.
Contrôle d’accès basé sur l’utilisateur
Les stratégies DirectAccess sont basées sur l’ordinateur, et non sur l’utilisateur. La spécification de stratégies utilisateur DirectAccess pour contrôler l’accès au réseau d’entreprise n’est pas prise en charge.
Personnalisation de la stratégie DirectAccess
DirectAccess peut être configuré à l’aide de l’Assistant Installation de DirectAccess, de la console de gestion de l’accès à distance ou des applets de commande Windows PowerShell pour l’accès à distance. L’utilisation de tout autre moyen que l’Assistant Installation de DirectAccess pour configurer DirectAccess, comme la modification directe des objets de stratégie de groupe DirectAccess ou la modification manuelle des paramètres de stratégie par défaut sur le serveur ou le client, n’est pas prise en charge. Ces modifications peuvent entraîner une configuration inutilisable.
Authentification KerbProxy
Lorsque vous configurez un serveur DirectAccess avec l’Assistant Mise en route, le serveur DirectAccess est automatiquement configuré pour utiliser l’authentification KerbProxy pour l’authentification de l’ordinateur et de l’utilisateur. Pour cette raison, vous devez utiliser l’Assistant Mise en route uniquement pour les déploiements sur un site unique où seuls les clients Windows 10®, Windows 8.1 ou Windows 8 sont déployés.
En outre, les fonctionnalités suivantes ne doivent pas être utilisées avec l’authentification KerbProxy :
Équilibrage de charge à l’aide d’un équilibreur de charge externe ou de l’équilibreur de charge Windows
Authentification à deux facteurs où des cartes à puce ou un mot de passe à usage unique (OTP) sont nécessaires
Les plans de déploiement suivants ne sont pas pris en charge si vous activez l’authentification KerbProxy :
Multisite.
Prise en charge de DirectAccess pour les clients Windows 7.
Tunneling forcé. Pour vous assurer que l’authentification KerbProxy n’est pas activée lorsque vous utilisez le tunneling forcé, configurez les éléments suivants lors de l’exécution de l’assistant :
Activer Forcer le mode tunneling
Activer DirectAccess pour les clients Windows 7
Notes
Pour les déploiements précédents, vous devez utiliser l’Assistant Configuration avancée, qui utilise une configuration à deux tunnels avec un ordinateur basé sur un certificat et l’authentification utilisateur. Pour plus d’informations, consultez Déployer un serveur DirectAccess avec des paramètres avancés.
Utilisation d’ISATAP
ISATAP est une technologie de transition qui fournit une connectivité IPv6 dans les réseaux d’entreprise uniquement IPv4. Elle est limitée aux petites et moyennes organisations qui ne déploient qu’un seul serveur DirectAccess et permet la gestion à distance des clients DirectAccess. Si ISATAP est déployé dans un environnement multisite, d’équilibrage de charge ou multidomaine, vous devez le supprimer ou le déplacer vers un déploiement IPv6 natif avant de configurer DirectAccess.
Configuration des points de terminaison IPHTTPS et à mot de passe à usage unique (OTP)
Lorsque vous utilisez IPHTTPS, la connexion IPHTTPS doit se terminer sur le serveur DirectAccess, et non sur un autre appareil, tel qu’un équilibreur de charge. De même, la connexion SSL (Secure Sockets Layer) hors bande créée lors de l’authentification par mot de passe à usage unique (OTP) doit se terminer sur le serveur DirectAccess. Tous les appareils entre les points de terminaison de ces connexions doivent être configurés en mode pass-through.
Tunnel forcé avec authentification par mot de passe à usage unique (OTP)
Ne déployez pas de serveur DirectAccess avec l’authentification à deux facteurs avec OTP et tunneling forcé, ou l’authentification par mot de passe à usage unique échouera. Une connexion SSL (Secure Sockets Layer) hors bande est requise entre le serveur DirectAccess et le client DirectAccess. Cette connexion nécessite une exemption pour envoyer le trafic en dehors du tunnel DirectAccess. Dans une configuration Tunnel forcé, tout le trafic doit transiter par un tunnel DirectAccess, et aucune exemption n’est autorisée une fois le tunnel établi. Pour cette raison, l’authentification par mot de passe à usage unique (OTP) n’est pas prise en charge dans une configuration Tunnel forcé.
Déploiement de DirectAccess avec un contrôleur de domaine en lecture seule
Les serveurs DirectAccess doivent avoir accès à un contrôleur de domaine en lecture-écriture et ne fonctionnent pas correctement avec un contrôleur de domaine en lecture seule (RODC).
Un contrôleur de domaine en lecture-écriture est nécessaire pour de nombreuses raisons, notamment les suivantes :
Sur le serveur DirectAccess, un contrôleur de domaine en lecture-écriture est nécessaire pour ouvrir la console MMC (Microsoft Management Console) d’accès à distance.
Le serveur DirectAccess doit lire et écrire dans les objets de stratégie de groupe (GPO) du client DirectAccess et du serveur DirectAccess.
Le serveur DirectAccess lit et écrit dans l’objet de stratégie de groupe du client spécifiquement à partir de l’émulateur de contrôleur de domaine principal (PDC).
En raison de ces exigences, ne déployez pas DirectAccess avec un contrôleur de domaine en lecture seule (RODC).