Newsgroup: it.comp.sicurezza.windows
Titolo: SQL Server su DC

Ciao a tutti,
anticipandovi che sono totamente contrario, per tutta un serie di motivi
(performance+sicurezza), voi installeste SQL Sever su un Domain Controller?
Perchč?
Ciao
thanks
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Perchè?
L'unico motivo, o quasi, che posso immaginare, e' che ci sia solo un
server. Nel senso di un unico cassone hardware dove mettere le cose.
Tipicamente qualcuno in alto domanda: "Si puo' metterlo sulla stessa
macchina?" "Si', ma..." "SI PUO'?" "Potere si puo', ma..." "Bene, lo
faccia."
Poi magari viene anche acquistato un secondo server, ma poche cose a
questo mondo sono piu' definitive di una "sistemazione temporanea".
Leonardo
-- 
In nessun caso Microsoft, o i suoi fornitori, saranno responsabili per
[...] omissione di rispetto di obblighi, incluso quello di comportarsi
in buona fede o ragionevole diligenza
                                     -- Contratto di Licenza Microsoft

 Chiediti perche' no, invece: un domain controller non deve offrire
scusa la domanda brutale, quanti DC hai installato/utilizzato nella tua
carriera?
Mi sembra tu abbia le idee un po' confuse.
Un domain controller autentica gli utenti e fa un mucchio di altre cose,
specie se ha i ruoli FSMO.
La situazione DC+SQL Server è semplicemente *sconsigliata*, a meno di non
trovarsi in un piccolissimo contesto e casomai puo' essere accettabile se il
DC è solo un member DC.

 browser pronto.
mi sa che ci eravamo capiti molto male : stavo sostenendo la stessa cosa !
ho riletto la tua risposta e mi sono reso conto di aver frainteso....
Nota che anch'io ho scritto che è sconsigliata e "casomai accettabile" solo
in un piccolo contesto nel quale non si abbiano $$ per separare i servizi.

 Perchč?
Si, perchč mi sono (anzi, ci siamo) talmente triturato i coglioni per 
convincere che al domain controller serviva un backup che non mi passa 
manco nell'anticamera del cervello di andare a chiedere un'altro server.

 ho riletto la tua risposta e mi sono reso conto di aver frainteso....
Mica tanto. Alla tua prima domanda aveva risposto:
"Chiediti perche' no, invece: un domain controller non deve offrire 
servizi (un po' come per un firewall, in fondo): deve _solo_ 
autenticare gli utenti e basta. Non mi sembra ci sia molto da stare a
pensarci sopra."
-- 
IBM: I Built Mine
News 2000 [v 2.06] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 manco nell'anticamera del cervello di andare a chiedere un'altro server.
ROTFLASTC

 Domain Controller? Perchè?
Dipende da quanti server hai :-)

 (P) Pubblicita' Progresso
Sono perfettamente daccordo con te, Due di Nano...
Comunque sia, ecco una spiegazione scientifica al perche' non si deve fare 
una cosa del genere:
FONTE: 
http://www.winnetmag.com/Windows/Article/ArticleID/4536/4536.html
Q: Does installing SQL Server on a domain controller affect security and 
performance?
To avoid performance and security problems, we encourage you to install SQL 
Server on a member server in a domain, rather than a Primary Domain 
Controller (PDC) or Backup Domain Controller (BDC). Performance is affected 
because the domain controller consumes memory, CPU, and other resources that 
a member server would delegate to SQL Server. Performance degradation is not 
noticeably great, unless you don't have enough domain controllers to handle 
the network load.
Many people are familiar with these performance problems, but not everyone 
realizes the potential security risks associated with SQL Server installed 
on a domain controller. SQL Server is a Windows NT service called 
MSSQLServer. Like any NT service, MSSQLServer must run within the security 
context of an NT account. This configuration lets users assign permissions 
and rights to a service by assigning those permissions and rights to the 
underlying NT account. You have two account choices: You can run a service 
as LocalSystem, which is an administrator account with powerful rights and 
privileges, or you can run a service as normal, which is an account with the 
rights of an ordinary system user. By default, the setup program installs 
MSSQLServer to run as a LocalSystem account, giving users powerful rights 
and privileges.
This default setting can lead to security problems. For example, xp_cmdshell 
is an extended stored procedure that lets SQL Server users issue a Transact 
SQL (T-SQL) command as if they were typing in a command prompt window. If a 
user types the command
xp_cmdshell "dir c:\"
from a T-SQL session, the system returns the output "dir c:\" as the query's 
result set. This result is benign, but xp_cmdshell executes in the same user 
security context of the NT account running the MSSQLServer service. Thus, 
users who have the right to execute xp_cmdshell also have the right to 
perform
xp_cmdshell "erase c:\*.* -F -S -Q"
This command is a full recursive deletion of the root directory. For even 
more fun, a SQL Server system administrator (sa) can type
xp_cmdshell "net" **inc
This command lets sas turn their personal NT accounts (i.e., with ordinary 
user privileges) into a domain administrator account.
You can avoid these security holes (even if you install SQL Server on a 
domain controller) by running MSSQLServer under an account other than 
LocalSystem and without domain administrator privileges. However, to contain 
potential security problems and not degrade performance, your best option is 
to put SQL Server on a member server rather than a domain controller.
FONTE: 
http://www.winnetmag.com/Windows/Article/ArticleID/4536/4536.html