Si vous essayez de convaincre la direction, vous pouvez commencer par cela :
It goes against Microsoft's Best Practices for Active Directory Deployment.
Mise à jour : Voir cet article de technet sur la sécurisation des contrôleurs de domaine contre les attaques, et la section intitulée Perimeter Firewall Restrictions qui stipule que
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 Controllers qui stipule que
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 trouver de la documentation Microsoft à ce sujet, et c'est tout. En outre, vous pourriez exposer les risques d'une telle démarche, en disant quelque chose du genre :
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 sont justement mises en cache. Elles fonctionnent pour la machine locale lorsqu'elle ne peut pas se connecter au domaine Mais si ce compte était désactivé, ils ne pourraient travailler pour aucune ressource du réseau (svn, vpn, smb, fbi, cia, etc.), ils n'ont donc pas à s'en préoccuper. N'oubliez pas non plus que les utilisateurs ont déjà tous les droits sur les fichiers contenus dans leur dossier de profil sur une machine locale (et probablement sur les supports amovibles), de sorte qu'ils peuvent faire ce qu'ils veulent avec ces données. Elles ne fonctionneraient pas non plus pour la machine locale une fois qu'elle se reconnecte au réseau.
Faites-vous référence aux services fournis par Active Directory ou un contrôleur de domaine, tels que LDAP ? Si c'est le cas, LDAP est souvent déconnecté de manière sécurisée à des fins d'authentification et d'interrogation de l'annuaire, mais le simple fait de désactiver le pare-feu Windows (ou d'ouvrir tous les ports requis au public - même chose dans cet exemple) peut entraîner de graves problèmes.
L'AD n'est pas vraiment gérer Macs, une solution séparée serait donc nécessaire (pensez à OS X Server). Vous pouvez joindre un Mac à un domaine, mais cela ne fait guère plus que lui permettre de s'authentifier à l'aide d'informations d'identification du réseau, de définir les administrateurs du domaine comme administrateurs locaux sur le Mac, etc. Pas de politique de groupe. MS tente d'ouvrir une brèche dans ce domaine avec des versions plus récentes 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 crois aussi que vous pourriez configurer les Macs pour qu'ils se connectent à OS X Server qui s'authentifierait à votre répertoire basé sur AD, mais je peux me tromper.
Cela dit, des solutions créatives pourraient être élaborées, comme la suggestion d'Evan d'utiliser OpenVPN en tant que service, et de désactiver la machine cert si/quand le moment est venu de licencier cet employé.
Il semble que tout soit basé sur Google, donc Google agit en tant que serveur LDAP ? Je recommanderais à mon client de faire en sorte qu'il en soit ainsi dans la mesure du possible. Je ne connais pas la nature de votre activité, mais pour les applications web telles qu'un serveur git ou redmine, même lorsqu'elles sont configurées en interne, il est possible de s'authentifier avec OAuth, en tirant parti d'un compte Google.
Enfin, une installation de type "roadwarrior" comme celle-ci serait presque exiger un VPN pour réussir. Une fois que les machines sont amenées au bureau et configurées (ou configurées à distance au moyen d'un script), elles ont besoin d'un moyen de recevoir tout changement de configuration.
Les Macs nécessiteraient une approche de gestion séparée en plus du VPN, c'est dommage qu'ils ne fabriquent plus de vrais serveurs Mac, mais ils avaient quelques implémentations de politiques décentes dans OS X Server la dernière fois que j'ai vérifié (il y a quelques années).
