Os servidores Web de produção do Windows (IIS & SQL) devem estar em um domínio?

Question

Temos alguns servidores da Web e alguns servidores de banco de dados. Até o momento, eles são máquinas independentes que não fazem parte de um domínio. Os servidores da web não se comunicam entre si e os servidores da web conversam com os servidores de banco de dados por meio do Auth do SQL.

Minha preocupação em colocar as máquinas em um domínio foi

1. adicionou complexidade - é mais uma "coisa" em execução e "coisas" que podem dar errado.
2. risco - se um controlador de domínio falhar, estou colocando em risco outras máquinas?

No entanto, em determinados cenários, parece conveniente que eles estejam em um domínio, compartilhando credenciais. Por exemplo, se eu quiser dar aos "serviços" controle em uma máquina o acesso a outra máquina (porque a área de trabalho remota craps ) Eu preciso entrar e atribuir privilégios em várias máquinas - algo que acredito que o Active Directory e as Contas de Domínio configuram para simplificar.

Minha pergunta: tenho certeza de que há coisas que não estou considerando aqui. Existe uma prática recomendada?

    

Answer 1

Os Powers That Be podem esclarecer as coisas, é claro, mas toda a StackOverflow Network é executada em servidores IIS com um back end SQL em um domínio do Active Directory. Eu diria que funciona bem.

• added complexity - it's one more "thing" running, and doing "things" that could go wrong.

Às vezes, adicionar complexidade permite que você remova alguns. Especialmente se você está preocupado em escalar, ter um domínio pode facilitar muito o trabalho de adicionar servidores, alterar configurações e muitas outras coisas. Diretivas de grupo e scripts administrados centralmente podem fazer coisas incríveis para facilitar sua vida.

• risk - if a domain controller fails, am I now putting other machines at risk?

É por isso que você tem dois controladores de domínio e não os torna acessíveis pela Internet. Se alguém penetra no seu site, você é praticamente mesmo assim. É por isso que é uma boa ideia ter o seu Domínio do AD apenas para o ambiente da sua aplicação, se possível.

E, finalmente, a Microsoft projeta seu ambiente para funcionar no AD. A comunicação entre servidores é mais fácil e mais segura quando o AD está envolvido para arbitrar a autenticação e incentivar o uso seguro do protocolo.

    

Answer 2

Não apenas pense no custo do AD, pense no que ele adiciona

• gerenciamento centralizado de contas
• capacidade de definir e aplicar políticas de segurança consistentes
• capacidade de centralizar implantações de software
• capacidade de automatizar a instalação real do sistema operacional

Todas essas coisas podem reduzir a complexidade e melhorar a segurança em um site on-line - centralizando as coisas que, esperamos, facilitarão a implantação consistente.

Agora, não é o mesmo que implantar corretamente / com segurança, mas significa que, uma vez que você descubra qual implantação correta / segura significa que você só precisa acertar uma vez em sua imagem e configurações de sistema operacional centralizadas, e pode ser consistentemente enviado para novos servidores. Útil para expandir seus sistemas caso você precise fazer isso e para criar ambientes de teste / desenvolvimento que sejam iguais aos da rede de produção.

Se a maioria dos seus problemas se resume a erros (e, para a maioria de nós, eles são), então a AD facilita a automação e o compartilhamento de recursos, reduzindo as oportunidades de cometer esses erros.

Temos todos os nossos servidores em um domínio onde eu trabalho, pelas razões que dou acima (um domínio separado do lado da LAN). Há riscos e custos para essa abordagem também, é claro. Você precisa considerar os dois lados e tomar uma decisão equilibrada.