For the complete documentation index, see llms.txt. This page is also available as Markdown.

Utilisation du serveur de contrôle DVLS_Owner

La permission Control Server sur le compte DVLS_Owner peut sembler excessive à première vue. Cet article explique précisément pourquoi elle est requise, quand elle est utilisée et comment éviter de l'accorder.

Accorder View Server State à DVLS_Scheduler

Devolutions Server requiert que le compte DVLS_Scheduler détienne la permission View server state server level. Le service Scheduler utilise cette permission pour interroger les vues de gestion dynamique (DMV) de SQL Server afin de surveiller la charge actuelle sur l'instance SQL et de réguler son propre travail en conséquence, garantissant ainsi que le Scheduler ne surcharge jamais votre SQL Server lors des opérations en arrière-plan.

SQL Server applique une règle : pour accorder une permission de niveau serveur à un autre compte, le concédant doit lui-même détenir Control Server (ou être membre du rôle sysadmin). Il n'existe pas d'alternative à privilèges réduits pour accorder des permissions de niveau serveur dans SQL Server.

Cela signifie que DVLS_Owner a besoin de Control Server non pas pour l'utiliser directement, mais uniquement pour pouvoir émettre l'instruction d'octroi suivante à DVLS_Scheduler : GRANT VIEW SERVER STATE TO [DVLS_Scheduler];.

Message d'erreur

Le message d'erreur suivant apparaît lorsqu'un utilisateur clique sur le bouton Appliquer les autorisations minimales dans la console Devolutions Server sans avoir la permission GRANT, ou lors d'une mise à jour de Devolutions Server :

Msg 4613, Level 16, State 1, Line 1 Grantor does not have GRANT permission

Quand Control Server est-il réellement utilisé ?

Control Server n'est pas une permission d'exécution. Devolutions Server ne l'utilise jamais lors d'un fonctionnement normal. Elle n'est exercée qu'aux moments administratifs spécifiques suivants :

  • Installation initiale : lorsque la base de données et les comptes sont provisionnés pour la première fois.

  • Mises à jour du produit : lorsque le modèle de permissions est réappliqué après une mise à niveau.

  • Réapplication manuelle : lorsqu'un administrateur clique explicitement sur Appliquer les autorisations minimales dans la section Informations d'identification avancées de la console Devolutions Server.

  • Fenêtre des informations d'identification (généralement nécessaire uniquement lors d'un changement de compte de service).

En dehors de ces moments, DVLS_Owner ne se connecte pas à SQL Server lors d'un fonctionnement normal et n'est pas le compte d'exécution.

Solutions de contournement pour éviter d'utiliser Control Server sur DVLS_Owner

Si votre politique de sécurité ne permet pas d'accorder Control Server à DVLS_Owner, deux alternatives sont prises en charge. Les deux permettent d'obtenir le même résultat : DVLS_Scheduler détient View Server State sans que DVLS_Owner ait besoin de détenir Control Server.

Option 1 : Générer et exécuter le script manuellement

Devolutions Server peut générer le script SQL qu'il exécuterait autrement lui-même. Un administrateur SQL Server disposant des privilèges appropriés, par exemple un compte sysadmin, peut ensuite examiner et exécuter le script manuellement.

Option 2 : Accorder la permission manuellement

Un administrateur SQL Server peut accorder la permission directement à DVLS_Scheduler sans impliquer DVLS_Owner du tout.

Mis à jour

Ce contenu vous a-t-il été utile ?