Comment gérer Windows comme Linux / Unix: droits administratifs par appartenance à un groupe sans accident et sans partager le mot de passe administrateur?


8

J'apporte des modifications fondamentales à un environnement Windows Server 2003/2008. Côté Unix, mes contraintes de sécurité sont simples:

  1. Les utilisateurs qui devraient avoir des droits d'administrateur sont dans un groupe spécial ("roue" ou similaire).
  2. Lorsque ces utilisateurs se connectent à ces machines, ils n'ont toujours pas de droits d'administrateur, jusqu'à ce qu'ils exécutent explicitement une commande avec ces droits d'administrateur ("commande sudo" ou "su").
  3. Même lorsqu'ils exécutent la commande avec "su" (un peu comme "runas"), ils doivent toujours entrer un mot de passe: le leur.

Dans ce système, je peux contrôler qui a des privilèges d'administrateur (par appartenance à un groupe), les empêcher d'exécuter accidentellement quelque chose avec des privilèges d'administrateur par accident (en exigeant «su» ou «sudo»), et ne jamais révéler un «administrateur» de base (c.-à-d. "root"), car on leur demande le leur.

Comment faire l'équivalent sur Windows Server? Les options que je vois sont:

  1. Ajouter un utilisateur au compte d'administrateurs locaux: Mais tout ce qu'ils font est en tant qu'administrateur, ce qui risque une erreur.
  2. Les obliger à faire "runas Administrateur": Mais alors ils doivent connaître le mot de passe Administrateur, que je ne veux pas partager.

Y a-t-il une solution dans laquelle je peux simultanément: contrôler qui a accès en étant membre du groupe; les empêcher de faire accidentellement des choses dommageables en exigeant un mot de passe distinct; les empêcher de connaître le mot de passe administrateur?

Réponses:


8

Tout d'abord, seuls les administrateurs devraient avoir un accès administrateur, donc à moins qu'il y ait une énorme (je ne peux pas penser à une bonne) raison pour laquelle ils en ont besoin, cela devrait être laissé aux administrateurs; il y a de rares occasions où un utilisateur régulier obtient des privilèges d'administrateur, et même alors, je suis généralement sceptique quant à la raison pour laquelle il en a besoin.

Deuxièmement, vous pouvez accomplir ce que vous voulez faire en utilisant l'appartenance à un groupe dans Windows. Vous n'avez pas dit que vous utilisiez Active Directory, donc je ne sais pas si vous avez un domaine et le faites, mais vous pouvez créer des groupes de sécurité et leur ajouter des comptes d'utilisateurs individuels. Vois ici. Je n'ajouterais pas d'utilisateurs au groupe d'administrateurs locaux sur le serveur individuellement, car cela deviendra compliqué et difficile à suivre, et cela vous causera beaucoup de maux de tête et des problèmes de sécurité potentiels. Ce que je ferais, comme mentionné ci-dessus, est de créer un groupe de sécurité et d'ajouter les membres auxquels vous souhaitez avoir un accès administrateur à ce groupe. Vous créeriez deux comptes d'utilisateur pour vos utilisateurs; un pour la connexion régulière, puis un deuxième compte qui n'a été utilisé que pour des actions élevées. Vous devez ajouter le compte "supérieur / privilégié" des utilisateurs au groupe de sécurité, puis vous pouvez placer ce groupe dans une appartenance à un groupe local élevé sur le serveur réel, par exemple, les utilisateurs avec pouvoir. Cela leur permettra d'effectuer de nombreuses fonctions sans être administrateurs.

En ce qui concerne Run As Administrator, vous n'avez pas à le faire tout le temps. Le meilleur moyen pour que les gens exécutent des choses sans connaître l'administrateur ou un administrateur, le mot de passe consiste à utiliser Maj + clic droit, puis sélectionnez Exécuter en tant qu'utilisateur différent, ou Clic droit et exécuter en tant qu'administrateur. Vous voudriez d'abord créer un utilisateur distinct pour eux qui a des droits plus élevés ou des droits élevés comme mentionné ci-dessus (cet utilisateur élevé serait à nouveau ajouté au groupe de sécurité comme mentionné ci-dessus), car alors cet utilisateur pourrait être utilisé pour exécuter des choses qui nécessite une élévation tout en étant connecté avec un compte d'utilisateur normal / standard. Voir ma capture d'écran:

entrez la description de l'image ici

Cela devrait prendre soin de ce que vous voulez faire en ce qui concerne l'exécution des choses en tant qu'administrateur. Une dernière note que je pourrais ajouter est de garder l'UAC. Si vous procédez ainsi, les utilisateurs devront saisir leur mot de passe (élevé) et non un mot de passe administrateur pour les tâches qu'ils effectuent sur le serveur. C'est pénible quand on doit taper beaucoup, mais pour la sécurité ça vaut le coup.


c'est exactement ce que les 2 autres ont suggéré. Vous avez raison, nous exécutons AD et nous les ajouterons à un groupe d'administrateurs de serveurs, qui disposera de privilèges d'administrateur local.
deitch

RE:, Run as Administratortoutes les informations d'identification administratives feront l'affaire. Si le compte auquel vous êtes connecté ne dispose pas d'informations d'identification administratives, vous serez invité à entrer un nom d'utilisateur et un mot de passe, et vous pourrez y saisir un compte administratif. Votre message ne le précise pas vraiment.
HopelessN00b

Et dans ce cas, je suis parle sysadmins. Une bonne pratique de sécurité consiste à ce que les administrateurs système ne disposent pas d'un mot de passe de compte de production / système, mais uniquement à exécuter les choses comme leur propre compte. Je veux étendre cela aux administrateurs système.
deitch

1
@deitch Yup, c'est exactement ce que nous faisons à $ [dayjob]. Tous les informaticiens ont des comptes d'utilisateur et des comptes administratifs normaux. Connectez-vous à tout en tant qu'utilisateurs limités et exécutez l' Run as Administratoroption pour tout ce qui nécessite une élévation. les utilisateurs administrateurs locaux ne sont pas utilisés sauf s'ils doivent l'être (approbation de domaine rompue, etc.)
HopelessN00b

2
@ HopelessN00bGeniusofnetwork, donc RunAsAdministrator ne signifie pas "Exécuter en tant que compte administrateur", cela signifie "Exécuter en tant que tout compte disposant de privilèges d'administrateur, tant que vous pouvez fournir des informations d'identification pour un tel compte"?
deitch

5

Laissez leur compte standard comme «standard». Créez-leur un deuxième compte privilégié et ajoutez-le aux différents groupes d'administration. Utilisez 'runas' avec le compte privilégié. (Vous pouvez trouver utile de désactiver les ouvertures de session interactives avec le compte administrateur, mais là encore - cela deviendra probablement ennuyeux).


1
J'ai compris. Vous avez donc 2 comptes: Sobrique et SobriqueA. SobriqueA est bloqué de se connecter à tous les systèmes sur une console / télécommande, ne peut faire que des runas. SobriqueA est membre d'un groupe avec des privilèges d'administrateur. L'utilisateur se connecte en tant que Sobrique, puis exécute «runas SobriqueA» qui nécessite un mot de passe SobriqueA, et toutes ces commandes s'exécutent avec des privilèges d'administrateur complets. C'est un peu alambiqué, mais cela pourrait être pire.
deitch

2
C'est exact.
Brad Bouchard

1
+1 pour adresser désactiver les ouvertures de session interactives. Sinon, les utilisateurs se connecteraient simplement avec les informations d'identification de l'administrateur et seraient sujets à l'inquiétude d'OP pour chaque action en tant qu'administrateur.
Byron C.12

4

Dans Server 2003, vous devez utiliser l' Run As...option pour exécuter en tant que compte avec des privilèges administratifs.

Avec Server 2008+, vous utilisez l'UAC et / ou l' Run as Administratoroption que vous avez suggérée. Cela ne nécessite pas de connaître le mot de passe du compte administratif [local] - toutes les informations d'identification administratives feront l'affaire.

Vous ajouteriez donc leurs comptes aux groupes administratifs locaux, ou mieux, d'un point de vue de la sécurité, créeriez des comptes administratifs distincts et les ajouteriez aux groupes administratifs locaux. Ensuite, lorsqu'ils ont besoin d'exécuter quelque chose avec des privilèges administratifs, l'UAC demandera des informations d'identification administratives et / ou ils utiliseront l' option Run As.../ Run as Administrator.


Ceci est très similaire à la réponse de @ sobrique. Donc, Win considère les comptes comme ayant ou non des privilèges d'administrateur? Et il n'a pas de concept de "ce compte a le droit d'exécuter les choses en tant qu'administrateur s'il demande explicitement et se réauthentifie"?
deitch

1
En gros, non. Windows a un tas de droits de sécurité - généralement, ces droits sont accordés à un groupe (car chaque utilisateur est méchant). L'appartenance au groupe confère les droits. La pratique courante consiste simplement à se connecter à l'aide d'un compte administrateur, car c'est facile - mais cela ne signifie pas que c'est juste. Nous avons des comptes d'utilisateurs locaux et des comptes d'administrateur de domaine que nous utilisons pour nous connecter aux serveurs de gestion (sur lesquels divers outils de gestion Windows sont installés).
Sobrique

Vous pouvez jouer avec «secpol.msc» et configurer un profil de droits personnalisé - accorder l'accès à un groupe «pas exactement Administrateurs», et y ajouter les comptes d'utilisateurs de base. Mais de toute façon, vous devrez probablement trébucher sur la nécessité d'un compte administrateur «approprié».
Sobrique

1
@deitch Eh bien, c'est essentiellement ce que l'UAC est / permet. Il vous permet d'exécuter en tant que compte administratif, mais être invité à tout ce qui nécessite une «élévation». (Authentification à jetons fractionnés.) Techniquement, il ne s'agit pas de créer une dichotomie "Administrateur ou non administrateur", mais le fait d'exécuter quelque chose en tant qu'administrateur est une caractéristique tellement courante qu'on lui donne une option de menu spécifique. Dans la plupart des cas, cette option n'est pas strictement nécessaire (vous pouvez toujours simplement exécuter en tant qu'un autre utilisateur, qui se trouve être un administrateur), mais il est juste plus pratique d'y avoir cette option de menu.
HopelessN00b

1
Eh bien, John devra toujours connaître les informations d'identification d' un compte administratif pour exécuter quelque chose en tant qu'administrateur - il ne doit tout simplement pas être le compte administrateur.
HopelessN00b
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.