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 exactement pourquoi elle est requise, quand elle est utilisée et comment éviter de l'accorder.

Octroyer la permission de visualiser l'état du serveur à DVLS_Scheduler

Devolutions Server exige 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 (DMVs) du serveur SQL afin de surveiller la charge actuelle sur l'instance SQL et d'adapter sa propre activité en conséquence, garantissant ainsi que le Scheduler ne surcharge jamais le serveur SQL lors des opérations en arrière-plan.

SQL Server applique une règle : pour octroyer une permission au niveau du serveur à un autre compte, le donnant doit lui-même détenir Control Server (ou être membre du rôle sysadmin). Il n'existe pas d'alternative avec des privilèges inférieurs pour l'octroi des permissions au niveau du 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 la subvention 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 moindres permissions dans la Console Devolutions Server sans avoir la permission GRANT, ou lors de la mise à jour de Devolutions Server :

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

Quand le contrôle du serveur est-il réellement utilisé

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

  • Première installation : 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 permission est réappliqué après une mise à niveau.

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

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

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

Solutions de contournement pour éviter d'utiliser le contrôle du serveur sur DVLS_Owner

Si votre politique de sécurité n’autorise pas d’accorder Control Server à DVLS_Owner, il existe deux alternatives prises en charge. Les deux atteignent 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 avec les privilèges appropriés (par exemple, un compte sysadmin) peut alors examiner et exécuter le script manuellement.

Option 2 : Octroyer la permission manuellement

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

Devolutions Forum logo Partagez vos commentaires