Délégation et quotas

Bonjour,
Lorsqu'on délègue, on accepte les risques que cela peut induire.
Une délégation obligera toujours, d'une manière ou d'une autre, à donner des droits supplémentaires à des utilisateurs  (même extérieurs dans le cas d'un prestataire) sur le domaine ou sur des serveurs particuliers. Et il est rare de pouvoir ajouter un rôle précis sans que celui-ci ajoute également d'autres droits qui ne sont pas voulus, à moins de modifier en profondeur les droits par défaut, ce qui provoquera probablement d'autres soucis.

D'ordinaire, on part du principe ou la personne qui gérera les comptes utilisateurs est de confiance, a suffisamment de connaissances de base, de bon sens et de prudence pour exploiter de tels droits sur un domaine AD.





 

Bonjour,
Je suis conscient de ce qu'implique la délégation mais nous ne sommes pas en mesure d'avoir un serveur de fichier dissocié du serveur de domaine uniquement pour gérer les quotas disques.... D'ailleurs, d'autres rôles sont installés sur ce serveur : NPS, DHCP, DNS...
Le délégation avec des droits administrateurs impliquerait ainsi la possibilité d'actions sur ces autres rôles, et ce même si la confiance ne fait pas parti de l'équation.
La délégation ne doit concerné que la gestion des utilisateurs et c'est ce que fait très bien KoXo.
Simplement, je pense qu'implémenter un "runas" pour élever les droits lors de certaines fonctions qui le nécessite (uniquement lorsque la délégation est mise en place) me parait quand même moins à risque que d'attribuer les droits administrateur local à une personne pour "simplement" gérer des quotas.
J'aurais aimer que cette possibilité soit étudiée ...
C'est dommage de devoir se passer des quotas à cause de la délégation ou de devoir donner des droits administrateurs local à une personne juste pour gérer ces quotas avec la délégation...

Egalement, si cela n'est pas envisager de gérer les quotas avec la délégation, il faudrait peut-être le préciser lorsque l'on veut mettre en place celle-ci, soit ne pas autoriser la délégation si les quotas sont actifs soit mettre un avertissement dans la page de configuration de la délégation...
 

Bonjour,
Le seul moyen sécurisé de gérer un serveur de fichiers avec les droits nécessaires pour créer des dossiers, partages et quotas est d'être administrateur de ce fichiers. Un compte qui n'est pas administrateur peut créer les fichiers et dossiers si les droits sont configurés correctement. Pour les partages l'utilisateur doit faire partie des opérateurs de sauvegarde en plus. Un simple utilisateur ne peut pas créer de partages sur un ordinateur, il n'y a pas de droit spécifique pour ça. Cette possibilité est implémentée directement via le service LanmanServer et n'est bien sûr pas documentée, et la modification des réglages n'est pas supportée par Microsoft. Pour les quotas, les paramètres sont inscrits à bas niveau et impose donc d'être administrateur de l'ordinateur.
Le "runas" est très dangereux car il est facile d'intercepter le mot de passe en quelques minutes. Il peut être utilisé sur un poste ordinaire pour lancer une application "mal écrité", au pire le poste peut être endommagé, mais le réseau non.
Le fait d'avoir un serveur de fichiers avec un utilisateur du domaine qui en est administrateur limite les actions aux fichiers et la santé de ce serveur , cet utilisateur a aussi des droits sur une OU de l'annuaire et le dossier des scripts, il pourra donc créer des utilisateur avec stockages et quotas. Il ne peut donc en aucun cas planter l'annuaire et les services DNS, DHCP etc.
Rien ne vous empêche de lancer directement KoXo Administrator via un "runas", mais la sécurité du domaine ne sera plus assurée.
Cdt
Le support

Le fait d'avoir un serveur de fichiers avec un utilisateur du domaine qui en est administrateur limite les actions aux fichiers et la santé de ce serveur , cet utilisateur a aussi des droits sur une OU de l'annuaire et le dossier des scripts, il pourra donc créer des utilisateur avec stockages et quotas. Il ne peut donc en aucun cas planter l'annuaire et les services DNS, DHCP etc.

Lorsqu'un utilisateur du domaine possède les droits administrateurs local du serveur, il n'a pas de possibilité d'actions sur les autres rôles installés ? Comment le limiter alors pour qu'il ne puisse pas accéder à l'AD ? Je suis d'accord avec vous concernant la sécurité d'un "runas". Si on peut s'assurer qu'un utilisateur du domaine avec droits administrateurs local ne peut pas planter les autres rôles alors ca sera sans doute suffisant.

Bonjour,

Au niveau sécurité, le serveur de fichiers se comporte comme est un poste lié au domaine.
L'utilisateur "délégué" est membre du domaine et des administrateurs locaux du serveur de fichiers et à ce titre il peut accéder à AD avec les droits qui sont configurés. (OU=Utilisateurs par exemple). Au niveau des droits fichiers vis à vis des DC il a juste besoin de pouvoir écrire les scripts.
L'onglet de délégation dans la fiche de configuration permet de réaliser ces différentes actions à l'exception de l'admin local.

Cdt
Le support

Sans être sûr, à confirmer ou non, il me semble que :
-La délégation intégrée à koxo permet à un utilisateur de gérer uniquement l' UO "koxoadm" de l'AD, et de modifier les dossiers/fichiers que koxo génère (scripts de connexions, dossiers des utilisateurs...). Donc ni l'ensemble du domaine, ni l'ensemble des dossiers partagés.

-le groupe local administrateurs d'un serveur (même si c'est un DC) n'a aucun accès sur le domaine, à moins de lui donner. Je ne crois même pas qu'il puisse arrêter un service qui concerne le domaine ou le réseau (à confirmer ou non).

Donc le fait de donner les droits d'admin local uniquement sur un serveur n'est pas catastrophique. Seule précaution à prendre éventuellement, une sauvegarde des données du serveur concerné pour pouvoir les restaurer au cas où.