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

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?

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:

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.

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).

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.