Dois-je exposer mon annuaire Active Directory au réseau Internet public pour les utilisateurs distants?

J'ai un client dont les effectifs sont entièrement composés d'employés distants utilisant un mélange de PC / ordinateurs portables Apple et Windows 7.

Les utilisateurs ne s'authentifient pas sur un domaine pour le moment, mais l'organisation souhaiterait aller dans cette direction pour plusieurs raisons. Il s’agit de machines appartenant à la société. La société cherche à contrôler la désactivation des comptes, la stratégie de groupe et la prévention des pertes de données (désactivation du support distant, de la clé USB, etc.). serait fastidieux, en particulier à l'intersection d'un employé licencié et des informations d'identification mises en cache sur un ordinateur distant.

La plupart des services de l'organisation étant basés sur Google (courrier, fichiers, discussion en ligne, etc.), les seuls services de domaine sont DNS et les autorisations associées à leur VPN Cisco ASA.

Le client souhaite comprendre pourquoi il n’est pas acceptable d’exposer ses contrôleurs de domaine au public. En outre, quelle est la structure de domaine la plus acceptable pour un effectif distant distribué?

Modifier:

Centrify est utilisé par une poignée de clients Mac.

Je publie cette réponse principalement parce que tout le monde a son propre "avis éclairé" basé sur l'expérience, les informations tierces, les ouï-dire et les connaissances tribales au sein de l'informatique, mais il s'agit davantage d'une liste de citations et de lectures "directement" de Microsoft. J'ai utilisé des guillemets parce que je suis sûr qu'ils ne filtrent pas correctement toutes les opinions de leurs employés, mais cela devrait néanmoins s'avérer utile si vous recherchez des authoritativeréférences directes de Microsoft.

BTW, je pense aussi qu'il est très facile de dire contrôleur de domaine == Active Directory, ce qui n'est pas tout à fait le cas. Les mandataires AD FS et autres moyens (autorisation basée sur les formulaires pour OWA, EAS, etc.) offrent un moyen de "s'exposer" au Web pour permettre aux clients de s'authentifier au moins via AD sans exposer les contrôleurs de domaine eux-mêmes. Allez sur le site OWA de quelqu'un et tenter de connexion et AD va obtenir la demande d'authentification sur un back - end DC, donc AD est techniquement « exposé » ... mais est sécurisé par SSL et via un serveur proxy Exchange.

Citation n ° 1

Instructions pour le déploiement de Windows Server Active Directory sur des machines virtuelles Windows Azure

Avant de partir "Azure n'est pas AD" ... vous POUVEZ déployer ADDS sur une machine virtuelle Azure.

Mais pour citer les bits pertinents:

N'exposez jamais les STS directement à Internet.

En tant que meilleure pratique de sécurité, placez les instances STS derrière un pare-feu et connectez-les au réseau de votre entreprise pour éviter toute exposition à Internet. Cela est important car le rôle STS émet des jetons de sécurité. Par conséquent, ils doivent être traités avec le même niveau de protection qu'un contrôleur de domaine. Si un STS est compromis, des utilisateurs malveillants peuvent émettre des jetons d'accès contenant potentiellement les revendications de leur choix à des applications tierces et d'autres STS dans des organisations de confiance.

ergo ... n'exposez pas les contrôleurs de domaine directement à Internet.

Citation n ° 2

Active Directory - Le mystère UnicodePwd de AD LDS

Exposer un contrôleur de domaine à Internet est généralement une mauvaise pratique, que cette exposition provienne directement de l'environnement de production ou d'un réseau de périmètre. L'alternative naturelle consiste à placer un serveur Windows Server 2008 avec le rôle AD LDS (Active Directory Lightweight Directory Services) s'exécutant dans le réseau de périmètre.

Citation n ° 3 - pas de la part de la SEP ... mais utile encore pour l'avenir

Active Directory en tant que service? Azure, Intune laisse entrevoir l'avenir de l'AD hébergé dans le nuage

En fin de compte, il n’ya pas de grande réponse "courte" qui réponde aux objectifs de débarrasser le bureau du serveur AD en échange d’une alternative Azure. Tandis que Microsoft s'abstient d'autoriser les clients à héberger des services de domaine Active Directory sur des zones Server 2012 et 2008 R2 dans Azure, leur utilité dépend uniquement de la connectivité VPN que vous pouvez rassembler pour votre personnel. DirectAccess, bien qu’une technologie très prometteuse, a les mains liées à cause de ses propres limitations malheureuses.

Citation n ° 4

Déployez AD DS ou AD FS et Office 365 avec la connexion unique et les machines virtuelles Windows Azure

Les contrôleurs de domaine et les serveurs AD FS ne doivent jamais être exposés directement à Internet et ne doivent être accessibles que via un réseau privé virtuel

Active Directory (AD) n'a pas été conçu pour ce type de déploiement.

Les modèles de menace utilisés dans la conception du produit supposent un déploiement "derrière le pare-feu" avec un certain nombre d'acteurs hostiles filtrés à la frontière du réseau. Bien que vous puissiez certainement empêcher Windows Server d'être exposé au réseau public, le bon fonctionnement d'Active Directory requiert une sécurité qui est nettement plus laxiste qu'un hôte renforcé pour les réseaux ouverts au public. De nombreux services doivent être exposés à partir d'un contrôleur de domaine (DC) pour que AD puisse fonctionner correctement.

La suggestion de Zoredache dans les commentaires, en particulier de faire référence à quelque chose comme OpenVPN qui s'exécute comme un service à l'échelle de la machine avec authentification par certificat, pourrait bien convenir. Comme d'autres l'ont déjà mentionné, DirectAccess est exactement ce dont vous avez besoin, à ceci près qu'il ne dispose pas du support multiplate-forme souhaité.

En passant: j'ai eu l'idée d'utiliser IPSEC en mode transport basé sur certificat pour exposer AD directement sur Internet, mais je n'ai jamais eu le temps de le faire. Microsoft a apporté des modifications dans le calendrier Windows Server 2008 / Vista qui auraient rendu cela possible, mais je ne les ai jamais exercées.

Ce que tout le monde a dit. Je suis particulièrement inquiet au sujet des tentatives de force brute mentionnées par Christopher Karel. Une présentation lors du dernier Def Con était sur le sujet:

Vous pensez donc que votre contrôleur de domaine est sécurisé?

JUSTIN HENDRICKS INGÉNIEUR DE LA SÉCURITÉ, MICROSOFT

Les contrôleurs de domaine sont les joyaux de la société. Une fois qu'ils tombent, tout dans le domaine tombe. Les organisations mettent tout en œuvre pour sécuriser leurs contrôleurs de domaine. Toutefois, elles ne parviennent souvent pas à sécuriser correctement les logiciels utilisés pour gérer ces serveurs.

Cette présentation portera sur les méthodes non conventionnelles permettant d’obtenir un administrateur de domaine en abusant des logiciels de gestion couramment utilisés que les organisations déploient et utilisent.

Justin Hendricks travaille au sein de l'équipe de sécurité d'Office 365, où il est impliqué dans le regroupement rouge, les tests d'intrusion, la recherche sur la sécurité, la révision de code et le développement d'outils.

Je suis sûr que vous pouvez trouver beaucoup d'autres exemples. Je cherchais des articles sur les contrôleurs de domaine et le piratage informatique dans l'espoir d'obtenir une description de la rapidité avec laquelle le contrôleur de domaine serait trouvé, etc., mais je pense que cela suffira pour le moment.

Si vous essayez de convaincre la direction, un bon début serait que:

It goes against Microsoft's Best Practices for Active Directory Deployment.

Mise à jour : voir cet article technique sur la sécurisation des contrôleurs de domaine contre les attaques, ainsi que la section intitulée Perimeter Firewall Restrictions:

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

Et la section intitulée Blocking Internet Access for Domain Controllersqui dit:

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

Je suis sûr que vous pouvez créer de la documentation Microsoft sur le sujet, alors c'est tout. En plus de cela, vous pouvez énoncer les risques d'un tel déménagement, comme suit:

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

Les informations d'identification mises en cache ne sont que cela - mis en cache. Ils travaillent pour la machine locale quand il ne peut pas se connecter au domaine , mais si ce compte était désactivé, ils ne fonctionneraient pour aucune ressource réseau (svn, vpn, smb, fbi, cia, etc.), ils n'auraient donc pas à s'inquiéter de cela. . N'oubliez pas non plus que les utilisateurs ont déjà des droits complets sur tous les fichiers de leur dossier de profil sur une machine locale (et probablement sur un support amovible), de sorte que les informations d'identification sont désactivées ou non, ils peuvent faire ce qu'ils veulent avec ces données. Ils ne fonctionneraient pas non plus pour la machine locale une fois que celle-ci serait reconnectée au réseau.

Faites-vous référence aux services fournis par Active Directory ou un contrôleur de domaine, tels que LDAP? Si tel est le cas, LDAP est souvent sécurisé de manière sécurisée à des fins d'authentification et d'interrogation d'annuaire, mais le simple fait de désactiver le pare-feu Windows (ou d'ouvrir tous les ports requis au public - comme dans cet exemple) risque de poser de graves problèmes.

AD ne gère pas vraiment les Macs, une solution distincte serait donc nécessaire (pensez à OS X Server). Vous pouvez associer un Mac à un domaine, mais cela ne leur laisse guère plus d'autoriser les informations d'identification réseau, de définir les administrateurs de domaine comme administrateurs locaux sur le Mac, etc. Aucune stratégie de groupe. MS tente de percer sur ce terrain avec les nouvelles versions de SCCM qui prétendent pouvoir déployer des applications sur des macs et des boîtes * nix, mais je ne l'ai pas encore vu dans un environnement de production. Je pense également que vous pourriez configurer les Mac pour qu'ils se connectent à OS X Server, ce qui permettrait de s'authentifier auprès de votre répertoire basé sur AD, mais je peux me tromper.

Ceci étant dit, certaines solutions créatives pourraient être imaginées, telles que la proposition d'Evan d'utiliser OpenVPN en tant que service et de désactiver le certificat d'ordinateur si / le moment venu de laisser cet employé partir.

On dirait que tout est basé sur Google, alors Google agit comme votre serveur LDAP? Je recommanderais à mon client de le garder de cette façon si possible. Je ne connais pas la nature de votre entreprise, mais pour les applications Web telles que les serveurs Git ou Redmine, même lorsqu'elles sont configurées en interne, elles peuvent s'authentifier auprès de OAuth, en tirant parti d'un compte Google.

Enfin, une configuration de type roadwarrior nécessiterait presque un VPN pour réussir. Une fois que les machines sont entrées dans le bureau et configurées (ou configurées à distance à l'aide d'un script), elles ont besoin d'un moyen de recevoir les modifications de configuration.

Les Mac nécessiteraient une approche de gestion distincte du VPN. Dommage qu’ils ne fabriquent plus de véritables serveurs Mac, mais ils avaient quelques implémentations de stratégies décentes dans OS X Server la dernière fois que j’ai vérifié (il y a quelques années). )

Il est regrettable que DirectAccess ne soit disponible que sur Win7 + Enterprise Edition, car il est conçu sur mesure pour votre demande. Mais si vous ne connaissez pas votre édition et que vous avez MacOS, cela ne fonctionnera pas.

/ Edit - on dirait que certaines tierces parties affirment avoir des clients DA pour Unices: http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

Il existe des solutions MDM disponibles qui peuvent répondre à vos besoins. nous en diffusons l’un (MAAS360) à un client qui se trouve dans une position similaire.

Ce serait évidemment un risque de sécurité important. En outre, cela ne fonctionnerait probablement pas aussi bien que vous le souhaiteriez. Si des personnes aléatoires sur Internet sont en mesure de tenter de se connecter à votre environnement AD, il y a de fortes chances que tous vos utilisateurs soient verrouillés. Pour toujours. Et supprimer les exigences de verrouillage signifie qu'il est assez facile de vérifier la force brute avec des mots de passe simples.

Plus important encore, vous ne devriez avoir aucun problème à mettre en œuvre votre objectif (utilisateurs finaux se connectant à un ordinateur portable avec des informations d'identification de domaine) sans rendre les serveurs AD directement accessibles. À savoir, les machines Windows peuvent mettre en cache les dernières connexions X réussies, de sorte que ces mêmes informations d'identification fonctionnent lorsqu'elles sont déconnectées. Cela signifie que les utilisateurs finaux peuvent se connecter et effectuer un travail utile sans avoir besoin de toucher vos serveurs AD. Ils devront évidemment utiliser un réseau privé virtuel (VPN) pour se connecter aux autres ressources majeures de l'entreprise et actualiser leurs paramètres AD / GPO en même temps.

Ewwhite,

Votre question est extrêmement valable et mérite un examen attentif.

Tous les professionnels de la sécurité recommandent des couches de sécurité devant toute ressource réseau, y compris les pare-feu SPI, IDS, pare-feu basés sur hôte, etc. Vous devez toujours utiliser un pare-feu de passerelle de périmètre proxy tel que ISA (désormais TMG).

Cela dit, Microsoft Active Directory 2003+ n'a pas divulgué publiquement de vulnérabilités majeures. La technologie LDAP et ses algorithmes de hachage sont généralement très sécurisés. Il est sans doute plus sûr que le VPN SSL si ce VPN SSL exécute OpenSSL et est vulnérable à la réconciliation.

Je mettrais en garde 5 choses:

1. Soyez préoccupé par les autres services auxquels le réseau est confronté, tels que Terminal Server, les services DNS, CIFS et, en particulier, IIS avec son terrible enregistrement de sécurité.

2. Utilisez LDAPS avec un certificat de sécurité pour éviter de transmettre des informations d'identification de domaine en texte clair sur le réseau. Cela se produit automatiquement après l'installation des services de certificats (utilisez un ordinateur séparé pour l'infrastructure à clé publique).

3. Placez un renifleur de paquets sur l'interface et surveillez votre trafic, corrigez tous les mots de passe en texte clair, pare-feu ou non, si vous n'utilisez pas de réseau privé virtuel (VPN) ou LDAPS, certains systèmes hérités envoient des mots de passe en texte clair.

4. Sachez que les attaques MITM peuvent forcer les mécanismes d'authentification natifs à rétrograder et à exposer les mots de passe à une authentification NTLM plus faible.

5. Soyez conscient de certaines vulnérabilités d'énumération d'utilisateurs qui peuvent encore exister.

Cela dit, Active Directory a fait ses preuves en matière de sécurité. En outre, MS Active Directory ne stocke pas les mots de passe, mais uniquement les hachages pouvant également atténuer la gravité d'une compromission.

Vous pouvez bénéficier d'une infrastructure de sécurité plus transparente, vous n'avez pas besoin de configurer des serveurs DNS spéciaux ni d'utiliser domain.local et vous pouvez utiliser votre domaine réel sur Internet, tel que domain.com.

Selon mon opinion professionnelle, le déploiement public de technologies de sécurité telles qu'Active Directory, où d'autres technologies telles qu'Exchange et DNS et les serveurs Web, ne présente aucun avantage ni risque.

Remarque: si vous déployez Active Directory, il inclura un serveur DNS. Soyez CERTAIN de désactiver la récursion sur vos serveurs DNS (activé par défaut) ou vous participerez sans aucun doute à des attaques par déni de service.

À votre santé,

-Brian

Dell (via l’achat de Quest (via l’achat de Vintela)) dispose d’une solution multiplate-forme fréquemment déployée dans les entreprises F500 à cette fin .

Choses à considérer...

1. Vos utilisateurs sont-ils toujours connectés? Dans ce cas, vous serez mieux servi avec un environnement d'hébergement flexible basé sur une machine virtuelle, capable de s'adapter lorsque de nombreux utilisateurs actifs martèlent LDAP.
2. Etes-vous en cours d'exécution dans plus d'un centre de données physique? Envisagez un équilibrage géographique de la charge devant les services AD pour réduire le nombre de sauts entre les utilisateurs et vos systèmes.
3. De plus, si la réponse à la question 2 est oui, assurez-vous de configurer des ressources réseau dédiées pour répliquer votre forêt, comme illustré ici.

Et assurez-vous que votre solution de pare-feu est capable de gérer des taux de retransmission extrêmement élevés si vous avez des utilisateurs sur des liaisons montantes étranglées, une connexion à partir de centres wifi bruyants, etc.