¿Por qué usaría una cuenta de servicio administrado en lugar de una cuenta virtual en SQL Server 2012?

En SQL Server 2012, las cuentas de servicio se crean como cuentas virtuales (VA), como se describe aquí , a diferencia de las cuentas de servicio administradas (MSA).

Las diferencias importantes que puedo ver para estos, en base a las descripciones:

Los MSA son cuentas de dominio, los VA son cuentas locales
Los MSA usan la administración automática de contraseñas manejada por AD, los VA no tienen contraseñas
en un contexto Kerberos, los MSA registran SPN automáticamente, los VA no

¿Hay otras diferencias? Si Kerberos no está en uso, ¿por qué un DBA alguna vez preferiría un MSA?

ACTUALIZACIÓN : Otro usuario ha notado una posible contradicción en los documentos de MS sobre VA :

La cuenta virtual se administra automáticamente y la cuenta virtual puede acceder a la red en un entorno de dominio.

versus

Las cuentas virtuales no se pueden autenticar en una ubicación remota. Todas las cuentas virtuales usan el permiso de la cuenta de la máquina. Aprovisione la cuenta de la máquina en el formato <domain_name>\<computer_name>$.

¿Qué es la "cuenta de máquina"? ¿Cómo / cuándo / por qué se "aprovisiona"? ¿Cuál es la diferencia entre "acceder a la red en un entorno de dominio" y "autenticar en una ubicación remota [en un entorno de dominio]"?

— jordanpg
fuente

Su último párrafo agregó 4 preguntas más. Las reglas de S / O recomiendan una pregunta por solicitud. Puedo responder una de estas preguntas: Una "cuenta de máquina" es una cuenta de servicio local (NT). Cada máquina tiene uno. Cuando ejecuta un servicio NT como "Sistema", se ejecuta bajo esta cuenta local especial. Dado que no es administrado por un dominio, otras máquinas de un dominio no pueden confiar en él (inherentemente). La cuenta se crea automáticamente cuando se instala el sistema operativo. Es un retroceso a los días de las redes punto a punto.

— TimG

Entonces, si "todas las cuentas virtuales usan el permiso de la cuenta de la máquina", entonces, según esta definición, no podría "acceder a la red en un entorno de dominio".

— jordanpg

(en mi mensaje anterior, omití algo). Cuando un servidor se une a un dominio, la cuenta "Sistema" local se asigna a una cuenta de dominio <nombre_dominio> \ <nombre_de_computadora> $. Esa cuenta es una cuenta de dominio real.

— TimG

Yo diría que no es típico usar una cuenta de máquina para "acceder a la red en un entorno de dominio". Como puede imaginar, es bastante genérico y, por lo tanto, presenta una puerta trasera generosa. Puede otorgar permisos para esa cuenta, como cualquier otra cuenta, pero se desaconseja.

— TimG

No puede ser tan atípico. Los VA, que "usan el permiso de la cuenta de la máquina", son el tipo de cuenta predeterminado para casi todas las cuentas de servicio MSSQL12. O MS omitió una oración como "sin embargo, no se recomienda usar VA para acceder a la red en un dominio" o esto es precisamente lo que se pretende. Por eso hice la pregunta.

— jordanpg

Así es como lo veo.

Cuando usa un VA, se hace pasar por la cuenta de la máquina.

El problema es que es fácil crear un VA o usar uno existente (por ejemplo, NT Authority \ NETWORKSERVICE). Si concede acceso a la cuenta de la máquina a una instancia, una aplicación que se ejecuta como VA podrá conectarse a esa instancia y realizar acciones.

Con una cuenta administrada, tendrá que proporcionar las credenciales para esa cuenta a la aplicación que quiera usar, lo que le permitirá una mayor granularidad con los permisos.

— Nabil Becker
fuente