Nella preistoria i web e i servizi giravano come localsystem. Localsystem è più potente di Administrator sul pc locale nel senso che molti dei privilegi sono già attivati mentre l'Administrator li ha ma non sono attivati di default.
Perciò far girare un processo come Localsystem è come usare una pistola carica senza sicura. Oggi lo fanno solo i suicidi perché quel livello di privilegi è altamente improbabile che serva e i rischi che si corrono con quell'account sono altissimi.
Ed è così che nacquero gli account di localservice e networkservice, utenti builtin nel sistema operativo ma privi di tutta quella lunga serie di privilegi.
Ma qual'è il vantaggio di usare questi account? Semplice, la loro logon session viene creata da Windows e di conseguenza sono account privi di password. Questo aspetto semplifica enormemente il deploy di servizi e web application ma apre un ovvio problema.
Essendo due account di numero, tutti i servizi e i web devono convivere sotto le stesse credenziali. Ne consegue che due web che girano come networkservice possono accedere alle stesse risorse con conseguenti problemi di security.
Ecco quindi comparire i "Managed Account", anch'essi privi di password ma distinti per ogni Application Pool creato in IIS7:
Selezionando "ApplicationPoolIdentity" nelle opzioni avanzate di un Application Pool, si ottiene la creazione di un "Managed Account".
Il suo nome completo sarà "IIS AppPool\AppPoolName" dove AppPoolName è il nome dell'Application Pool.
Questo account non lo vedremo dentro la console di amministrazione degli utenti di Windows ma sarà disponibile a tutti gli effetti per qualsiasi impostazione sulla security del file system e di un database. Ma qui nasce il problema …
Il problema è che la User Interface di Windows e di SQL Server non mostra questi utenti e quindi non è possibile assegnare i diritti nel modo classico.
La soluzione è banale: creare un gruppo locale che contiene uno o più Managed Account.
Fase 1: creazione di un gruppo che contiene un Managed Account:
- Creare un gruppo da 'Computer Management' oppure da command prompt (admin):
net localgroup DBReadersWriters /add - Aggiungere l'utente al gruppo:
net localgroup DBReadersWriters "IIS AppPool\AppPoolName" /add
A questo punto da Computer Management avremo il gruppo con dentro l'utente relativo all'Application Pool e gli si potrà assegnare i diritti di accesso a file e cartelle.
Fase 2: Anche su SQL server funziona tutto come al solito. Per assegnare i diritti, ad esempio, di datareader/datawriter in Sql Server:
- In Sql Server Management Studio (sotto Security – Logins) creare una nuova Login
- Sotto General specificare Login Name: MyServer\DBReadersWriters (il gruppo) e naturalmente il DB di default
- Sotto User Mapping, selezionare il DB a cui dare l'accesso e i permessi (ad esempio datareader e datawriter)