Perché dovresti utilizzare un account del servizio gestito anziché un account virtuale in SQL Server 2012?

In SQL Server 2012, gli account di servizio vengono creati come account virtuali (VA), come descritto qui , anziché account di servizio gestiti (MSA).

Le differenze importanti che posso vedere per questi, in base alle descrizioni:

Gli MSA sono account di dominio, i VA sono account locali
Gli MSA usano la gestione automatica delle password gestita da AD, i VA non hanno password
in un contesto Kerberos, gli MSA registrano automaticamente gli SPN, i VA non lo fanno

Ci sono altre differenze? Se Kerberos non è in uso, perché un DBA preferirebbe mai un MSA?

AGGIORNAMENTO : Un altro utente ha notato una possibile contraddizione nei documenti MS riguardanti VA :

L'account virtuale è gestito automaticamente e l'account virtuale può accedere alla rete in un ambiente di dominio.

contro

Gli account virtuali non possono essere autenticati in una posizione remota. Tutti gli account virtuali utilizzano l'autorizzazione dell'account macchina. Effettuare il provisioning dell'account macchina nel formato <domain_name>\<computer_name>$.

Cos'è l '"account macchina"? Come / quando / perché viene "fornito"? Qual è la differenza tra "accesso alla rete in un ambiente di dominio" e "autenticazione in una posizione remota [in un ambiente di dominio]"?

— jordanpg
fonte

Il tuo ultimo paragrafo ha aggiunto altre 4 domande. Le regole di S / O raccomandano una domanda per richiesta. Posso rispondere a una di queste domande: Un "Account macchina" è un account di servizio locale (NT). Ogni macchina ne ha una. Quando si esegue un servizio NT come "Sistema", viene eseguito con questo account locale speciale. Poiché non è gestito da un dominio, non può realmente (intrinsecamente) essere considerato attendibile da altre macchine in un dominio. L'account viene creato automaticamente quando viene installato il sistema operativo. È un ritorno ai giorni delle reti peer-to-peer.

— TimG

Pertanto, se "tutti gli account virtuali utilizzano l'autorizzazione dell'account macchina", in base a questa definizione, non è possibile "accedere alla rete in un ambiente di dominio".

— jordanpg,

(nel mio messaggio precedente, ho lasciato fuori qualcosa). Quando un server si unisce a un dominio, l'account "Sistema" locale viene associato a un account di dominio <nome_dominio> \ <nome_computer> $. Quell'account è un vero account di dominio.

— TimG

Direi che non è tipico usare un account macchina per "accedere alla rete in un ambiente di dominio". Come puoi immaginare, è piuttosto generico e quindi presenta una generosa back-door. Puoi concedere le autorizzazioni per quell'account, proprio come qualsiasi altro account, ma è sconsigliato.

— TimG

Non può essere così atipico. I VA, che "utilizzano l'autorizzazione dell'account macchina", sono il tipo di account predefinito per quasi tutti gli account del servizio MSSQL12. O MS ha escluso una frase del tipo "tuttavia, non è consigliabile utilizzare VA per accedere alla rete in un dominio" o questo è esattamente ciò che si intende. Ecco perché ho posto la domanda.

— jordanpg,

Ecco come la vedo io.

Quando si utilizza un VA, si rappresenta l'account del computer.

Il problema è che è facile creare un VA o usarne uno esistente (es. NT Authority \ NETWORKSERVICE). Se si concede all'account del computer l'accesso a un'istanza, un'applicazione in esecuzione come VA sarà in grado di connettersi a tale istanza ed eseguire azioni.

Con un account gestito, dovrai fornire le credenziali per quell'account a qualunque applicazione voglia usarli, consentendoti una maggiore granularità con le autorizzazioni.

— Nabil Becker
fonte