Se stai cercando di convincere il management, un buon inizio sarebbe che:
It goes against Microsoft's Best Practices for Active Directory Deployment.
Aggiornamento : vedi questo articolo tecnico sulla protezione dei controller di dominio dagli attacchi e la sezione intitolata Perimeter Firewall Restrictions
che afferma:
Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet.
E la sezione intitolata Blocking Internet Access for Domain Controllers
che afferma:
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
Sono sicuro che puoi raccogliere un po 'di documentazione Microsoft sull'argomento, quindi è così. Oltre a ciò, potresti dichiarare i rischi di una tale mossa, qualcosa sulla falsariga di:
A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.
Le credenziali memorizzate nella cache sono proprio questo: memorizzate nella cache. Funzionano per il computer locale quando non è in grado di connettersi al dominio , ma se tale account fosse disabilitato non funzionerebbero per nessuna risorsa di rete (svn, vpn, smb, fbi, cia, ecc.), Quindi non devono preoccuparsene . Ricorda inoltre che gli utenti hanno già diritti completi su qualsiasi file nella loro cartella del profilo su un computer locale (e probabilmente su supporti rimovibili) in modo che le credenziali disabilitate o meno possano fare quello che vogliono con quei dati. Inoltre, non funzionerebbero per il computer locale una volta che si riconnette alla rete.
Ti riferisci ai servizi forniti da Active Directory o da un controller di dominio, come LDAP? In tal caso, LDAP viene spesso suddiviso in modo sicuro ai fini dell'autenticazione e dell'interrogazione delle directory, ma la disattivazione di Windows Firewall (o l'apertura di tutte le porte richieste al pubblico - La stessa cosa in questo esempio) potrebbe causare gravi problemi.
AD non gestisce veramente i Mac, quindi sarebbe necessaria una soluzione separata (pensa OS X Server). Puoi unire un Mac a un dominio ma ciò non fa altro che autorizzarli con le credenziali di rete, impostare amministratori di dominio come amministratori locali sul Mac, ecc. Nessuna politica di gruppo. MS sta cercando di violare il terreno con le versioni più recenti di SCCM che affermano di essere in grado di distribuire applicazioni su mac e * nix box, ma devo ancora vederlo in un ambiente di produzione. Credo anche che potresti configurare i mac per connettersi al server OS X che si autenticherà nella tua directory basata su AD, ma potrei sbagliarmi.
Detto questo, alcune soluzioni creative potrebbero essere escogitate, come il suggerimento di Evan per l'utilizzo di OpenVPN come servizio e la disabilitazione del certificato macchina se / quando arriva il momento di lasciar andare quel dipendente.
Sembra che tutto sia basato su Google, quindi Google agisce come il tuo server LDAP? Consiglierei al mio cliente di mantenerlo tale, se possibile. Non conosco la natura della tua attività, ma per le app basate sul Web come un server git o redmine, anche quando l'installazione in casa può eseguire l'autenticazione con OAuth, sfruttando un account Google.
Infine, una configurazione di un guerriero stradale come questa richiederebbe quasi una VPN per avere successo. Una volta che le macchine vengono portate in ufficio e configurate (o configurate in remoto tramite script), hanno bisogno di un modo per ricevere eventuali modifiche alla configurazione.
I mac avrebbero bisogno di un approccio di gestione separato oltre alla VPN, peccato che non realizzino più veri server mac, ma avevano alcune decenti implementazioni dei criteri in OS X Server l'ultima volta che ho controllato (un paio di anni fa ).