Bonjour à tous,
Je dois pour la première fois, désactiver le compte SA sur toutes nos instances.
J'ai des réponses ici : https://www.developpez.net/forums/d1...vation-compte/ : mais j'ai besoin de précisions et désolé si je me répète sur la précédente discussion.
Mais je vais en profiter pour revoir tous les owners et les modifier si nécessaire sur 50 instances (Prod et NonProd)
Je commence par l'environnement DEV bien sûr.
Sur 82 DB, il y en a :
34 avec le compte SA
18 sans owner, le champ est vide
25 avec comme owner un compte AD
5 avec un compte SQL
Pour les jobs, il y en a 20 :
3 avec le compte SA
7 sans owner, le champ est vide
6 avec comme owner un compte AD
4 avec un compte SQL
Pour les jobs, dans le post, Nicolas dit :
Si je comprends bien donc, si je mets SA comme owner des jobs et que je le désactive ensuite, cela veut dire que seul un membre du rôle de sysadmin pourra exécuter le job manuellement. Mais s'il y a un schedule, ça ça ne change rien, il sera exécuté normalement?
Code : Sélectionner tout - Visualiser dans une fenêtre à part Ceci est du au fait que le propriétaire d'un job indique seulement qui peut l'exécuter, Un job peut ne pas avoir de propriétaire, et dans ce cas, seul un utilisateur membre du rôle de serveur sysadmin peut l'exécuter.
Et si je mets un compte AD, seul ce compte ou un sysadmin pourra exécuter ce job?
Pour les DB, Nicolas dit :
Donc idéalement, je devrais mettre SA comme owner de toutes les DB même si après je le désactive pour éviter le problème avec un groupe ou user AD qu'on désactiverait, cela n'a pas de conséquences?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 Dans le cas des bases de données non-contenues, le fait que le login sa soit désactivé empêche simplement de se connecter à l'instance sous ce nom de login. Cela n'empêche pas un membre du rôle se serveur sysadmin de l'utiliser une fois qu'il est authentifié et qu'il a été établi qu'il est bien membre de ce rôle de serveur. L'avantage d'utiliser ce nom de login, bien qu'il soit désactivé, est qu'il est présent sur toute instance SQL Server. Dès lors, un déplacement de base de données ou une copie de job se fait sans encombre. Par ailleurs, si le propriétaire de la base de données est un groupe AD, ou pire, un utilisateur AD, le jour où l'on modifie le groupe ou désactive le compte d'utilisateur AD ... patatra !
Mais alors pourquoi c'est différent si on met un compte ou groupe AD et qu'on le désactive dans l'AD, par rapport à SA qu'on désactive?
Donc si je résume, si je désactive SA:
Pour les jobs : Mettre SA comme owner sauf si un compte "extérieur" doit l'exécuter manuellement?
Et quelle est la conséquence si je ne mets pas d'owner à un job? Que je laisse le champ vide?
Pour les DB : Mettre SA comme owner n'a pas de conséquences sur les applications qui se connectent à ces DB (mais qui n'utilisent pas le compte SA bien sûr!), et donc pour éviter le problème avec un groupe/compte AD, c'est mieux de mettre SA?
Et quelle est la conséquence si je ne mets pas d'owner à une DB? Que je laisse le champ vide?
Si j'ai oublié des problèmes à la désactivation du compte SA, je suis à votre écoute.
Partager