Est-ce que les bonnes pratiques consistent à avoir une connexion séparée pour un domaine pour les administrateurs de domaine?


33

En général, j'aime bien configurer des identifiants distincts pour moi, l'un avec des autorisations utilisateur normales et un autre pour les tâches administratives. Par exemple, si le domaine était XXXX, je mettrais en place un compte XXXX \ bpeikes et un compte XXXX \ adminbp. Je l'ai toujours fait parce que, franchement, je ne me fais pas confiance pour être connecté en tant qu'administrateur, mais à chaque endroit où j'ai travaillé, les administrateurs système semblent simplement ajouter leurs comptes habituels au groupe Administrateurs de domaine.

Existe-t-il des meilleures pratiques? J'ai vu un article de MS qui semble indiquer que vous devez utiliser Exécuter en tant que, et ne pas vous connecter en tant qu'administrateur, mais ils ne donnent pas d'exemple d'implémentation et je n'ai jamais vu quelqu'un d'autre le faire.


1
En tant que spécialiste des systèmes d'exploitation Linux / Unix et de Windows, N'est-ce pas précisément ce que l'UAC est censé résoudre? Par ce que je veux dire, pour que l'on puisse utiliser un compte mais que seuls les processus autorisés reçoivent des privilèges d'administrateur.
Dolda2000

@ Dolda2000 UAC était davantage destiné aux utilisateurs finaux habitués à s'exécuter en tant qu'administrateur sur leur ordinateur local. Lorsque vous vous adressez à un administrateur de domaine sur votre ordinateur local, vous rencontrez des problèmes supplémentaires: vos informations d'identification et votre accès peuvent être bien pire qu'installer un virus sur votre ordinateur, car vous disposez de droits élevés pour la plupart des tâches. l'ensemble du domaine.
HopelessN00b

1
@ HopelessN00b: Et vous dites que le contrôle de compte d'utilisateur ne s'applique pas à ces choses? Pourquoi pas? Existe-t-il des raisons techniques ou la mise en œuvre fait-elle tout simplement défaut?
Dolda2000

2
@ Dolda2000 Eh bien, le contrôle de compte d'utilisateur était censé résoudre le problème, car les logiciels malveillants pouvaient utiliser le contexte utilisateur de l'utilisateur administratif connecté pour s'installer sur les ordinateurs des utilisateurs finaux et des utilisateurs. Et ça le fait. Cela empêcherait également ce vecteur spécifique d'utiliser le contexte utilisateur d'un administrateur de domaine pour installer les logiciels malveillants localement. Toutefois, ce n'est pas l'étendue des problèmes de sécurité liés à l'exécution en tant qu'administrateur de domaine plutôt qu'en tant qu'utilisateur limité.
HopelessN00b

1
@ Dolda2000 UAC empêche les processus d'exécuter des fonctions privilégiées sur la machine locale. Si vous êtes connecté en tant qu'administrateur de domaine, vous pouvez exécuter des commandes privilégiées à distance sur d'autres ordinateurs. Ces derniers s'exécuteront en mode élevé sur les ordinateurs distants sans invite UAC. Ainsi, les logiciels malveillants spécifiquement conçus pour exploiter ceci peuvent infecter votre domaine entier (puis votre ordinateur local à l'aide d'un autre ordinateur distant) sans que vous ne voyiez jamais une invite UAC.
Monstieur

Réponses:


25

"Meilleure pratique" dicte généralement LPU (utilisateur le moins privilégié) ... mais vous avez raison (comme ETL et Joe so +1), les gens suivent rarement ce modèle.

La plupart des recommandations consistent à faire ce que vous dites ... Créez 2 comptes et ne les partagez pas avec d'autres. Un compte ne devrait pas avoir de droits d'administrateur sur le poste de travail local que vous utilisez en théorie, mais encore une fois qui respecte cette règle, en particulier avec le contrôle de compte d'utilisateur ces jours-ci (qui devrait en théorie être activé).

Cependant, il existe de nombreux facteurs qui expliquent pourquoi vous souhaitez suivre cette voie. Vous devez prendre en compte la sécurité, la commodité, la politique d'entreprise, les restrictions réglementaires (le cas échéant), les risques, etc.

Garder les groupes de niveau Domain Adminset Administratorsdomaine bien et propres avec des comptes minimaux est toujours une bonne idée. Mais ne partagez pas simplement les comptes d’administrateur de domaine commun si vous pouvez les éviter. Sinon, il y a un risque que quelqu'un fasse quelque chose, puis pointe du doigt un administrateur système "ce n'est pas moi qui ai utilisé ce compte". Mieux vaut avoir des comptes individuels ou utiliser quelque chose comme CyberArk EPA pour l’auditer correctement.

De plus, sur ces lignes, votre Schema Adminsgroupe devrait toujours être VIDE, sauf si vous modifiez le schéma, puis insérez le compte, effectuez la modification et supprimez le compte. La même chose pourrait être dite en Enterprise Adminsparticulier dans un modèle à domaine unique.

Vous ne devez PAS non plus autoriser les comptes privilégiés à accéder à un réseau privé virtuel sur le réseau. Utilisez un compte normal puis élevez-vous selon vos besoins une fois à l'intérieur.

Enfin, vous devez utiliser SCOM ou Netwrix ou une autre méthode d’audit de tout groupe privilégié et avertir le groupe approprié dans le système d’information chaque fois que l’un des membres de ce groupe a changé. Cela vous donnera une tête à dire "attendez une minute, pourquoi est-ce si soudain un administrateur de domaine?" etc.

À la fin de la journée, il existe une raison pour que cela s'appelle "Meilleure pratique" et non pas "Seulement pratique" ... Il y a des choix acceptables faits par les groupes informatiques en fonction de leurs propres besoins et philosophies à cet égard. Certains (comme Joe l'a dit) sont tout simplement paresseux ... tandis que d'autres ne s'en soucient tout simplement pas, car ils ne sont pas intéressés à combler le trou de sécurité lorsqu'il y en a déjà des centaines et qu'il faut combattre quotidiennement. Cependant, maintenant que vous avez lu tout cela, considérez-vous comme l'un de ceux qui lutteront contre le bon combat et feront tout ce qui est en votre pouvoir pour assurer la sécurité des événements. :)

Les références:

http://www.microsoft.com/en-us/download/details.aspx?id=4868

http://technet.microsoft.com/en-us/library/cc700846.aspx

http://technet.microsoft.com/en-us/library/bb456992.aspx


Le moindre privilège s'applique principalement aux comptes non-administrateurs. La séparation des informations d'identification n'aide pas du point de vue du moins privé si le cred est utilisé sur un système sale compromis par le plus bas credle.
Jim B

Certes, mais je considère "LPU" comme signifiant également ne donner que l'accès à des groupes privilégiés, selon les besoins. Beaucoup de services informatiques. donner un accès DA simplement parce que c'est plus facile que de traiter la myriade de demandes d'accès.
TheCleaner

28

D'après les informations dont je dispose, il est recommandé aux administrateurs de domaine / réseau de disposer d'un compte utilisateur standard permettant de se connecter à leur poste de travail afin d'effectuer des tâches "utilisateur" de routine (courrier électronique, documentation, etc.) et de disposer d'un compte administratif nommé disposant des informations appropriées. l'appartenance à un groupe pour leur permettre d'effectuer des tâches administratives.

C’est le modèle que j’essaie de suivre, bien qu’il soit difficile à mettre en œuvre si le personnel informatique en place n’est pas habitué à le faire de cette façon.

Personnellement, si je trouve un personnel informatique réticent à aller dans cette direction, j’estime qu’il est soit paresseux, inexpérimenté, soit ne comprend pas la pratique de l’administration système.


12

Ceci est une pratique recommandée pour des raisons de sécurité. Comme d'autres l'ont mentionné, cela vous empêche de faire quelque chose par accident ou de compromettre votre navigation sur le réseau. Cela limite également les dommages que votre navigation personnelle peut causer - idéalement, votre travail quotidien ne devrait même pas avoir les privilèges d'administrateur local, encore moins d'administrateur de domaine.

Il est également extrêmement utile de contrer les détournements de jetons d’authentification Hash ou Windows. ( Exemple ) Un test de pénétration approprié le prouvera facilement. À savoir, une fois qu'un attaquant obtient l'accès à un compte administrateur local, il utilisera ce pouvoir pour migrer vers un processus utilisant un jeton d'administrateur de domaine. Ensuite, ils ont effectivement ces pouvoirs.

Pour ce qui est des exemples de personnes qui utilisent cela, mon entreprise le fait! (200 personnes, équipe de 6 personnes) En fait, nos administrateurs de domaine ont trois comptes. Un pour l’utilisation quotidienne, un pour l’administration du PC / l’installation de logiciels sur place. Le troisième est les comptes d'administrateur de domaine, utilisés uniquement pour administrer les serveurs et le domaine. Si nous voulions être plus paranoïaques / en sécurité, un quatrième serait probablement en ordre.


Trois récits ... intéressants ... Je dois tenir compte du changement de domaine imminent dans mon entreprise ...
pepoluan

1
Même en ma compagnie. Compte de bureau normal, compte administrateur pour un accès administrateur local sur les ordinateurs clients ET un compte administrateur de serveur distinct. Les deux comptes d’administrateur ne reçoivent ni courrier électronique ni accès à Internet. Le seul problème est que le compte serveur-admin a besoin de droits d'administrateur local sur le poste de travail, sinon UAC interfère avec l'exécution de MMC en local avec RunAs en tant que compte serveur-admin. (Peut utiliser RDP sur un serveur et tout exécuter à partir de là, mais cela gêne parfois si vous devez copier / coller ou comparer des données stockées sur le compte du poste de travail.)
Tonny

Nous avons très bien réussi à faire en sorte que nos administrateurs de domaine RDP de domaine soient sur un serveur pour leur travail de gestion. Copier-coller se déplace incroyablement bien à travers RDP. Et tous nos utilitaires de gestion sont déjà installés sur ce serveur unique. Mais cela étant dit ... Je pense que le groupe Domain Admins a les droits d’administrateur local par défaut. Je préfère simplement que ces informations d'identification ne touchent jamais les ordinateurs de bureau, afin d'éviter le vol de jetons, etc.
Christopher Karel

8

Dans mon ancienne entreprise, j'ai insisté pour que tous les administrateurs système aient 2 comptes, à savoir:

  • DOMAINE \ st19085
  • DOMAINE \ st19085a ("a" pour l'administrateur)

Les collègues étaient réticents au début, mais cela est devenu une règle de base, après que la question typique sur la menace virale "nous avons eu un antivirus" a été démystifiée par une base de données de virus obsolète ...

  • Comme vous l'avez mentionné, la commande RUNAS peut être utilisée (j'avais l'habitude d'avoir un script batch, présentant un menu personnalisé, lançant des tâches spécifiques avec la commande RUNAS).

  • Une autre chose est l'utilisation de la console de gestion Microsoft , vous pouvez enregistrer les outils dont vous avez besoin et les lancer avec un clic droit , Exécuter en tant que ... et votre compte d'administrateur de domaine.

  • Le dernier mais non le moindre, je lançais un shell PowerShell en tant qu'administrateur de domaine et lançais les tâches dont j'avais besoin à partir de là.

6
C’est essentiellement la mise en œuvre que j’ai utilisée (et imposée à tous les autres) partout où j’ai eu mon mot à dire. Vous vous connectez à votre ordinateur et effectuez vos tâches quotidiennes en tant qu'utilisateur normal, comme tout le monde. Lorsque vous avez besoin de droits d’administrateur, vous Run As/ Run as Administratoret utilisez le compte d’utilisateur administratif. Utiliser un seul compte pour tout est une mauvaise pratique de sécurité, et d'après mon expérience, les personnes qui s'y opposent sont les personnes qui ont le plus besoin d'être isolées pour pouvoir tout gérer en tant qu'administrateur.
HopelessN00b

+1 grande observation de @ HopelessN00b: "les personnes qui s'opposent sont celles qui ont le plus besoin d'être isolées pour tout gérer en tant qu'administrateur de toute façon"
mr.b

En fait, vous devriez utiliser un poste de travail séparé qui a été verrouillé pour exécuter uniquement l'administrateur
Jim B

4

J'ai travaillé dans des endroits qui fonctionnent dans les deux sens et je préfère généralement avoir un compte séparé. C'est en fait beaucoup plus facile, contrairement à ce que semblent penser les utilisateurs / clients réticents de joeqwerty:

Avantages d'utiliser votre compte quotidien quotidien pour les activités d'administration de domaine: tous les outils d'administration fonctionnent sur mon poste de travail sans runas! W00t!

Inconvénients de l’utilisation de votre compte quotidien quotidien pour les activités d’administrateur de domaine: Peur. ;) Desktop tech vous demande de regarder une machine car il ne comprend pas ce qui ne va pas, vous vous connectez, il y a un virus. Débranchez le câble réseau, changez le mot de passe (ailleurs). Lorsque les responsables vous demandent pourquoi vous ne recevez pas votre courrier électronique professionnel sur votre BlackBerry personnel via votre fournisseur de téléphonie mobile, vous leur expliquez qu'ils stockent votre mot de passe DOMAIN ADMIN sur leurs serveurs lorsque vous le faites. Etc., etc. Votre mot de passe hautement privilégié est utilisé pour des éléments tels que ... Webmail, VPN, connectez-vous sur cette page Web. (Ew.) (Pour être juste, mon compte a été bloqué de la page Web "changer votre mot de passe", donc c'était au moins le cas. Si je voulais changer mon ancien mot de passe LDAP, que la page Web synchronisait, je devais aller au bureau d'un collègue.)

Avantages d'utiliser un compte différent pour les activités d'administration de domaine: Intention. Ce compte est destiné aux outils administratifs, etc., et non aux courriels, webmail, vpn, connexions aux pages Web, etc. Ainsi, moins de craintes que mes activités "d'utilisateur" normales exposent l'ensemble du domaine à des risques.

Inconvénients de l’utilisation d’un compte différent pour les activités d’administration de domaine: je dois utiliser des runas pour les outils d’administration. Ce n'est tout simplement pas si douloureux.

La version TL; DR: Avoir un compte séparé est tout simplement plus facile. C'est également une pratique exemplaire, car c'est le privilège le moins nécessaire .


2

Least Priv devrait constituer une raison suffisante, mais dans le cas contraire, considérez également que si vous utilisez un compte disposant des mêmes autorisations que vos utilisateurs, vous risquez davantage de rencontrer des problèmes qu'ils rencontrent - et vous pouvez les déboguer sur votre propre compte. aussi - souvent avant même de les avoir vus!

Rien de pire qu'un administrateur qui dit "ça marche pour moi" et ferme le ticket :)


+1 pour reconnaître que l'utilisation quotidienne d'un compte utilisateur améliore l'efficacité du dépannage.
Je dis: réintégrez Monica le

1

En théorie, il est préférable que vous n'utilisiez pas la connexion supérieure de l'administrateur pour vos activités quotidiennes. Il existe de nombreuses raisons, telles que les virus: si vous êtes infecté par un virus et que vous exécutez une ouverture de session administrateur de domaine, le virus offre un moyen simple de se connecter à votre réseau grâce à un accès complet! Les erreurs possibles sont certes plus faciles à commettre, mais je ne vois pas cela comme le plus gros défi. Si vous visitez votre campus et que vous vous connectez avec votre administrateur principal, il est possible que quelqu'un recherche votre mot de passe par-dessus votre épaule. Toutes sortes de choses comme ça.

Mais est-ce pratique? J'ai du mal à suivre cette règle, mais j'aimerais bien la suivre.


0

en ajoutant mes 2 centimes basés sur l'expérience réelle ..

Sachant que vous utilisez un compte administrateur pour votre travail quotidien, sachez que vous êtes très prudent, peu importe ce que vous faites. vous ne devez donc pas simplement cliquer sur un courrier électronique / un lien ou exécuter toutes les applications sans triple vérification. Je pense que cela vous garde sur vos gardes.

utiliser un compte le moins privilégié pour votre travail quotidien vous rend imprudent.


C'est une théorie intéressante, mais d'après mon expérience, cela ne fonctionne pas (du moins pas pour tout le monde). J'ai vu des collègues effacer des quantités énormes de données des systèmes de production par erreur (un blanc au mauvais endroit dans une ligne de commande suffit).
Gerald Schneider

Ce n'est pas une théorie, nous le pratiquons ici ;-) D'après mon expérience, vous contrôlez les personnes auxquelles vous allez accorder de tels privilèges et ne les donnez pas simplement pour le demander.
Badbanana
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.