Pourquoi utiliseriez-vous un compte de service géré plutôt qu'un compte virtuel dans SQL Server 2012?

Dans SQL Server 2012, les comptes de service sont créés en tant que comptes virtuels (VA), comme décrit ici , par opposition aux comptes de service gérés (MSA).

Les différences importantes que je peux voir pour celles-ci, basées sur les descriptions:

Les MSA sont des comptes de domaine, les VA sont des comptes locaux
Les MSA utilisent la gestion de mot de passe automagique gérée par AD, les VA n'ont pas de mot de passe
dans un contexte Kerberos, les MSA enregistrent automatiquement les SPN, les VA ne

Y-a-t'il d'autres différences? Si Kerberos n'est pas utilisé, pourquoi un DBA préfèrerait-il un MSA?

MISE À JOUR : Un autre utilisateur a noté une contradiction possible dans les documents MS concernant les VA :

Le compte virtuel est autogéré et le compte virtuel peut accéder au réseau dans un environnement de domaine.

contre

Les comptes virtuels ne peuvent pas être authentifiés sur un emplacement distant. Tous les comptes virtuels utilisent l'autorisation du compte d'ordinateur. Provisionnez le compte d'ordinateur au format <domain_name>\<computer_name>$.

Qu'est-ce que le "compte machine"? Comment / quand / pourquoi est-il «provisionné»? Quelle est la différence entre "accéder au réseau dans un environnement de domaine" et "s'authentifier auprès d'un emplacement distant [dans un environnement de domaine]"?

— jordanpg
source

Votre dernier paragraphe a ajouté 4 autres questions. Les règles S / O recommandent une question par demande. Je peux répondre à l'une de ces questions: Un "compte d'ordinateur" est un compte de service local (NT). Chaque machine en a un. Lorsque vous exécutez un service NT en tant que «système», il s'exécute sous ce compte local spécial. Comme il n'est pas géré par un domaine, il ne peut pas vraiment (intrinsèquement) être approuvé par les autres machines d'un domaine. Le compte est créé automatiquement lors de l'installation du système d'exploitation. C'est un retour aux jours des réseaux peer-to-peer.

— TimG

Donc, si "tous les comptes virtuels utilisent l'autorisation du compte d'ordinateur", selon cette définition, il ne pourrait pas "accéder au réseau dans un environnement de domaine".

— jordanpg

(dans mon message précédent, j'ai omis quelque chose). Lorsqu'un serveur rejoint un domaine, le compte "Système" local est mappé sur un compte de domaine <nom_domaine> \ <nom_ordinateur> $. Ce compte est un compte de domaine réel.

— TimG

Je dirais qu'il n'est pas typique d'utiliser un compte d'ordinateur pour "accéder au réseau dans un environnement de domaine". Comme vous pouvez l'imaginer, il est assez générique et présente donc une généreuse porte dérobée. Vous pouvez accorder des autorisations pour ce compte, comme tout autre compte, mais il est déconseillé.

— TimG

Ça ne peut pas être si atypique. Les VA, qui "utilisent l'autorisation du compte d'ordinateur", sont le type de compte par défaut pour presque tous les comptes de service MSSQL12. Soit MS a omis une phrase comme "cependant, il n'est pas recommandé d'utiliser des VA pour accéder au réseau dans un domaine" ou c'est précisément ce qui est prévu. C'est pourquoi j'ai posé la question.

— jordanpg

Voici la façon dont je le vois.

Lorsque vous utilisez un VA, vous empruntez l'identité du compte d'ordinateur.

Le problème est qu'il est facile de faire un VA ou d'utiliser un existant (ex. NT Authority \ NETWORKSERVICE). Si vous accordez au compte d'ordinateur l'accès à une instance, une application qui s'exécute en tant qu'appareil virtuel pourra se connecter à cette instance et effectuer des actions.

Avec un compte géré, vous devrez fournir les informations d'identification de ce compte à l'application qui souhaite les utiliser, ce qui vous donnera plus de granularité avec les autorisations.

— Nabil Becker
source