[MEU 50º LIVRO]: BANCOS DE DADOS E ACESS - CURSO COMPLETO - DO BÁSICO AO VBA - 1602 páginas

Páginas: 1602 | Autor: Júlio Battisti | 40% de Desconto e 70h de Vídeo Aulas de Bônus

Você está em: PrincipalArtigosWindows 2003 Server › Capítulo 06 : 04
Quer receber novidades e e-books gratuitos?
›››
« Lição anterior Δ Página principal ¤ Capítulos Próxima lição »
WINDOWS 2003 SERVER - CURSO COMPLETO
Autor: Júlio Battisti


Promoção: Livro Windows Server 2012 R2 e Active Directory - Curso Completo, 2100 Páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!

Promoção: Livro Windows Server 2012 R2 e Active Directory

Curso Completo, 2100 páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!


Lição 068 - Capítulo 06 - Fundamentos em: Planejamento de domínios e unidades organizacionais

Pré-Requisitos: Conceitos básicos do Active Directory.

Metodologia: Apresentar aspectos importantes a serem considerados no planejamento de domínios e unidades organizacionais.

Para projetar o espaço de nomes, você deve ter definido (ou pelo menos ter uma idéia muito clara) de quantos domínios e de qual critério de divisão (geográfico, funcional ou misto) você utilizará. Neste tópico apresento algumas considerações para ajuda-lo a definir quando criar um novo domínio, como implementar unidades organizacionais em cada domínio. Vou iniciar o tópico com um item sobre as novas funcionalidades do Windows Server 2003 (em relação ao Windows 2000 Server), relacionadas a domínios. São funcionalidades que podem influenciar o projeto dos domínios da sua rede.

Novidades do Windows Server 2003 em relação à domínios.

O Windows Server 2003 nos trás muitas novidades em relação a domínios e florestas do Active Directory. São novas ferramentas e novas funcionalidades, tais como a possibilidade de renomear um domínio, melhorias na replicação dos servidores de catálogo global e assim por diante. Porém é importante salientar que as novas funcionalidades de domínio somente estão disponíveis quando o domínio estiver no modo de funcionalidade Windows Server 2003 e as novas funcionalidades de floresta, somente estarão disponíveis quando a floresta estiver no nível de funcionalidade Windows Server 2003.

Para uma descrição detalhada sobre domínios, árvores, florestas, níveis de funcionalidade de domínios e níveis de funcionalidade de florestas, consulte o Capítulo 5.

A seguir descrevo as novidades que mais tem impacto no projeto de domínios e da árvore de domínios da rede da sua empresa:

  • Renomear um domínio: Esta com certeza é uma das melhores novidades introduzidas no Windows Server 2003. Com a possibilidade de renomear domínios, você tem uma flexibilidade muito maior para alterar a estrutura da árvore de domínios da rede da empresa. Desde uma simples renomeação, até uma reestruturação da árvore toda, fica mais acessível com a possibilidade de renomear domínios. Situações de fusão entre empresas, aquisição de novas empresas ou reestruturações internas, podem fazer com que seja necessário alterar a estrutura de domínios da empresa. Com a possibilidade de renomear domínios, isso fica bem mais fácil. Com esta ferramenta você pode fazer o seguinte:

1.         Alterar o nome DNS e o nome NetBios de qualquer domínio, inclusive do domínio root.

2.         Alterar a posição de qualquer domínio na árvore de domínios, com exceção do domínio root, o qual não pode ser reposicionado. O administrador pode usar o recurso de renomear domínios, para reestrutuar a sua árvore de domínios. Por exemplo, com essa funcionalidade, um domínio que faz parte de uma árvore pode ser movido para outra árvore de domínios dentro da floresta. Com esta funcionalidade você pode mover um domínio para qualquer posição na floresta na qual o domínio resido, com exceção do domínio root, o qual não pode ser movido. É importante salientar que somente o domínio root da floresta é que não pode ser movido. Com esta ferramenta, você pode mover um domínio qualquer, de tal maneira a torna-lo o domínio root da sua árvore de domínios. Repito, o único domínio que não pode ser movido é o domínio root da floresta (lembrando que uma floresta é formada por duas ou mais árvores de domínio, sendo que todos os domínios em uma floresta compartilham o mesmo Schema. Para detalhes sobre domínios, árvores, florestas e schema, consulte o Capítulo 5).

Somente é possível renomear domínios, quando todos os DCs estiverem rodando o Windows Server 2003 e o nível de funcionalidade da floresta estiver configurado como nível Windows Server 2003. Para detalhes sobre níveis de funcionalidade da floresta, consulte o Capítulo 5.

Para renomear domínios o administrador utiliza o utilitário Rendom.exe. Este utilitário encontra-se na pasta Valueadd\Msft\Mgmt\Domren, do CD de instalação do Windows Server 2003. A operação de renomear um domínio irá afetar todos os DCs da floresta e é uma operação em várias etapas. No endereço a seguir, você encontra informações detalhadas sobre o processo de renomeação de domínios usando o utilitário Rendom.exe:

http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx

No endereço a seguir você pode fazer o download de um documento do Word, com uma explicação detalhada, passo-a-passo, das etapas envolvidas no processo de renomear um domínio:

http://www.microsoft.com/windowsserver2003/docs/Domain-Rename-Intro.doc

  • Possibilidade de criar relações de confiança, transitivas, unidirecionais ou bi-direcionais, entre diferentes florestas: Este tipo de relacionamento é criado entre os domínios root de duas diferentes florestas. Pode ser do tipo unidirecional ou bi-direcional Se for do tipo bi-direcional, os usuários de uma floresta podem receber permissões de acesso nos recursos nos domínios da outra floresta e vice-versa. Um exemplo prático de uso deste tipo de relação de confiança seria quando é feita a fusão de duas empresas e o administrador precisa permitir que os usuários de uma empresa possam acessar recursos nos servidores da rede da outra empresa e vice-versa. Esta também é uma novidade muito bem vinda, a qual aumenta a flexibilidade em situações de fusões ou aquisições de empresa. Vamos imaginar o case de uma fusão entre duas empresas. Duas redes diferentes, cada uma com a sua floresta de domínios. Sem esta funcionalidade, o que acontecia, na prática, é que durante um bom tempo, conviviam duas redes completamente separadas. Quando um usuário de uma rede precisa acessar recursos na outra rede, cadastrava-se este usuáro na outra rede. Aí começam a surgir problemas de senhas não sincronizadas (diferentes em cada floresta) e outros problemas. Aos poucos, os domínios de uma das florestas vão sendo desativados e os usuários e recursos migrados para a outra floresta. Isto tudo antes do Windows Server 2003 e antes da possibilidade de criar relações de confianças entre diferentes florestas.
  • Instalação de novos DCs a partir de uma mídia de Backup: No Windows 2000 Server, a única maneira de crair um novo DC é rodando o assistente para instalação do Active Directory (dcpromo.exe) e após a execução do assistente, aguardar que os dados do Active Directory sejam replicados para o novo DC. Em localidades conectadas por links de baixa velocidade a replicação pode demorar dias para estar completa, dependendo do volume de informações do Active Directory. É comum a base de dados do Active Directory ter tamanho de mais de 1GB. Replicar tudo isso através de links de WAN (mesmo que sendo necessária a cópia completa só quando da instalação do DC) é uma tarefa nada animadora. Já com o Windows Server 2003 é possível instalar novos DCs a partir de uma mídia de Backup. Assim, a base do Active Directory é copiada para a mídia e ao criar o novo DC, esta cópia já é passada para o novo DC, não tendo que ser completamente copiada através do link de WAN. Evidentemente que esta cópia estará desatualizada (mesmo que apenas algumas horas). Mas neste caso, somente será necessário replicar as alterações que foram efetuadas no Active Directory, desde o momento de geração da mídia de backup. Bem melhor do que ter que replicar a base completa do Active Directory, através do link de Wan. Esta funcionalidade pode ser decisiva para o projetista decidir em quais locais serão instalados DCs.

Projetando a Árvore de Domínios da Empresa

Assim como projetar o espaço de nomes não é uma ciência exata (coforme descrito anteriormente), projetar a árvore de domínios também não é uma ciência exata. Inicialmente pode até haver uma confusão no seguinte sentido: “Projetar o espaço de nomes não é a mesma coisa que projetar a árvore de domíniod?”.

Não. Projetar o espçao de nomes significa tomar decisões sobre os nomes a serem utilizados para os domínios, se serão utilizados critérios geográficos, funcionais ou mistos e se será utilizado o mesmo DNS internamente a na Internet ou se serão utilizados diferentes nomes DNS. Já projetar a árvore de domínios significa, efetivamente, decidir quantos domínios serão necessárias e em quantos níveis eles estarão ligados. Você pode pensar que basta definir o número de domínios e depois nomeá-los com base no projeto do espaço de nomes. Não é bem assim. Observe a Figura 6.8, onde apresento duas árvores com cinco domínios, porém com estruturas bem diferentes.


Figura 6.8 Número de domínios x níveis de domínios.

Com o exemplo da Figura 6.8 fica claro que com o mesmo número de domínios (cinco nesse exemplo) é possível criar redes absolutamente diferentes. Determinar a maneira como os domínios são arranjados, em quantos níveis, qual domínio fica em cada nível e quais os domínios realmente necessários é no que constitui o projeto de definir a árvore de domínios da sua empresa.

Uma regra citada em praticamente toda bibliografia sobre o assunto e também na documentação oficial da Microsoft é: SIMPLICIDADE. Se você não tem a menor idéia de como começar, comece pelas mais simples das árvores possíveis (que nem chega a ser uma árvore), qual seja: um único domínio. Isso mesmo, um domínio simples. Você verá neste item que o modelo de um único domínio é capaz de atender um número muito grande de empresas pequenas e médias, com algo entre 20 e 5000 usuários. Claro que não é somente o tamanho da rede,  o número de computadores e usuários que irão determinar se pode ou não ser utilizado um único domínio. Mais adiante analisarei os diversos fatores que devem ser considerados na hora de definir a árvore de domínios.

Nesse momento não esqueça desta palavrinha mágica: SIMPLICIDADE. Não adianta iniciar por uma árvore com dezenas de domínios, distribuídos ao longo de múltiplos níveis, procurando atender todos os detalhes e situações imaginados pela equipe de projeto. Me permitam a expressão: Isso é bobagem. Comece simples, uns poucos domínios (se não um único). Depois continue com uma análise mais detalhada, para determinar a necessidade de domínios adicionais.

Com o Windows Server 2003, o Active Directory é ainda mais flexível e fornece muito mais opções do que no Windows 2000 Server. Basta citar apenas a ferramenta de renomeação de domínios, citada anteriormente. Com esta ferramenta, reposicionar um domínio dentro da árvore, torna-se uma simples questão de renomear o domínio.

Com esta flexibilidade toda, você pode projetar praticamente qualquer modelo imaginável de árvore de domínios. Existem alguns modelos mais conhecidos e mais utilizados, os quais são apresentados no “Windows Server 2003 Deployment Kit”, já citado em capítulos anteriores e que está disponível para download (os capítulos no formato .PDF), no seguinte endereço:

http://www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx

Os principais modelos de domínios são os seguintes:

  • Single domain model (Domínio simples)
  • Multiple subdomain model (Múltiplos subdomínios)
  • Multiple trees ina a single forest model (Múltiplas árvores em uma única floresta)
  • Federated forest design model (Federação de florestas)
  • Peer-root model (Modelo Peer-root)
  • Placeholder domain model
  • Special-purpose domains (Domínios para objetivos especiais)

A seguir vou apresentar e analisar alguns detalhes sobre cada um destes modelos.

Single domain model (Domínio simples)

Conforme sugerido anteriormente você deve partir de um modelo simplificado. Nada mais simples do que o modelo de um único domínio. A primeira pergunta a ser feita é a seguinte: O modelo de um único domínio é suficiente para as necessidades da minha empresa? O trabalho a ser feito é provar que este modelo é suficiente, ou encontrar argumentos para provar o contrário, ou seja, que o modelo de um único domínio não é suficiente.

Quem trabalhou com o NT Server 4.0 (e muitos talvez ainda administrem uma rede baseada no Windows Server 2003), sabe que no NT Server 4.0 havia limitações em relação ao tamanho máximo que o banco de dados de usuários, grupos e outros objetos do domínio, podia atingir. Com bases próximas ou maiores do que 40 MB, sérios problemas de desempenho começavam a surgir. A partir do Windows 2000 Server não existe mais esta limitação. Você pode criar domínios onde a base do Active Directory facilmente passa de 1 GB sem problemas de desempenho. Com isso pode acontecer de você estar migrando do NT Server 4.0 (com um modelo baseado em múltiplos domínios), para o Windows Server 2003, onde você chega a conclusão de que um único domínio é suficiente. Não estranhe esta conclusão. A situação descrita neste parágrafo se encaixa em muitas situações de empresas da vida real. Então é perfeitamente possível que uma estrutura baseada em múltiplos domínios no NT Server 4.0, possa ser migrada para um modelo de domínio único no Windows Server 2003.

O modelo de domínio único tem várias vantagens, dentre as quais destaco as indicadas a seguir:

  • Sem necessidade de relações de confiança: Relações de confiança somente existem entre domínios. Se existe um único domínio, nada de relações de confiança.
  • Todos os objetos e recursos pertencem ao mesmo domínio. Com isso fica fácil para o administrador atribuir permissões de acesso a qualquer usuário do domínio, em qualquer recurso disponível.
  • Política de segurança única: Como uma das características do domínio é ser um limite de segurança, no sentido de que determinadas políticas de segurança são válidas em todo o domínio, com o uso de um único domínio, fica fácil definir a mesma política de segurança para todos os usuários e computadores da rede.
  • Estrutura centralizada: Facilita a criação de uma estrutura centralizada, onde os recursos do domínio são administrados a partir de um ponto central, delegando apenas tarefas específicas. O modelo de administração centralizada reduz custos e facilita a manutenção de um padrão ao longo de todo o domínio.

Alguns fatores devem ser levados em consideração para decidir se pode ser utilizado um único domínio ou não. Evidentemente que o tamanho da rede e o número de usuários é um deles. O difícil é precisar (se é que existe este número), um número limite de usuários, a partir do qual devam ser criados mais domínios. Eu poderia “chutar” 5.000, 10.000 ou algo parecido, mas o fato é que isso seria “chute”. Na prática, o que acontece, é que outros fatores determinam a criação de novos domínios e não o número de usuários em si. Eu conheço redes baseadas em um único domínio, no qual estão cadastradas cerca de 15.000 contas de usuários e cerca de 10.500 estações de trabalho. Esta rede é baseada no Windows 2000 Server (em fase de migração para o Windows Server 2003) e o Active Directory trabalha, sem problemas, com este número de usuários e computadores em um único domínio. Com certeza o Windows Server 2003 continuará trabalhando com este número de usuários, sem problemas.

Agora imagine esta mesma rede, com os mesmos 15.000 usuários, porém com algumas necessidades específicas. Imagine que após um estudo detalhado da situação atual da rede, chegou-se à conclusão de que existem três diferentes grupos de usuários e que cada um destes grupos precisa de diferentes políticas de segurança, precisa de um conjunto diferente de programas, os quais serão instalados e gerenciados via GPOs – Group Policy Objects e precisa de separação entre a administração dos recursos e usuários de cada grupo. Qual seria a solução?

Agora ficou fácil. Eu poderia ter citado um único motivo, mas preferi citar logo três:

  • Diferentes políticas de segurança
  • Conjunto diferente de programas, os quais serão distribuídos via GPO
  • Necessidade de administração separada

Estes são motivos, absolutamente independentes do número de usuários e computadores da rede, que justificariam a criação de mais domínios. Ou seja, ao invés do modelo baseado em um domínio simples, teríamos um modelo baseado em quatro domínios. Espera aí um pouco Júlio, não são três grupos de usuários e recursos com necessidades diferentes? Sim. Então não seriam necessários três domínios? Sim. Acontece que nestes casos o mais usual é criar um domínio Root, para servir de elo de ligação entre os demais domínios, conforme exemplo da Figura 6.9:


Figura 6.9 Múltiplos domínios devido a diferentes necessidades de segurança e administração.

Neste exemplo, o número de usuários, computadores e demais recursos não mudou. O que mudou foram algumas necessidades específicas (segurança, distribuição de software e administração dos recursos), que determinaram a necessidade de dividir a rede em mais de um domínio criando desta maneira uma árvore de domínios.

Porém observe que o procedimento é sempre baseado na palavra SIMPLICIDADE. Parto, sempre, de um projeto baseado em domínio único. Em seguida começo analisar as necessidades e detalhes que podem me levar a optar pela criação de novos domínios.

Outra técnica que é utilizada (e será detalhada mais adiante), é a criação de domínios que conterão apenas contas de usuários, grupos e computadores e a criação de domínios que conterão apenas recursos (além das contas built-in criadas, automaticamente). Um dos usos desta separação é a criação do domínio root, o qual não contém contas de usuários, apenas as contas e grupos criados automaticamente, durante a criação do domínio root. Esta separação é muito utilizada, em questões de segurança. Por exemplo, para proteger o servidor que está configurado como Schema Máster (veja detalhes no Capítulo 5), coloca-se o Schema Máster no domínio root, onde existe apenas a conta Administrator, criada automaticamente (supondo que a conta Guest esteja devidamente desabilitada). O Schema Máster é um servidor crítico para toda a árvore ou floresta de domínios. Se um usuário mal intencionado conseguir acesso ao Schema Máster e fizer uma verdadeira “bagunça” no Schema do Active Directory, você corre o risco de ter que iniciar a sua rede a partir do zero (rezando é claro para que todos os Backups Funcionem). Ao colocar o Schema Master em um domínio separado (no domínio root, no nosso exemplo), você está isolando este servidor em um domínio que não tem contas de usuários, apenas a conta Administrator. Isso reduz o risco de ataque contra o Schema Master, com o objetivo de alterar indevidamente o Schema do Active Directory, o que poderia até tornar indisponíveis todos os recursos da rede. O que tem isso tudo a ver com o modelo de domínio único? Muito, no modelo de domínio único, não tem escapatória, o servidor configurado com Schema Master (o único no qual é possível fazer alterações no Schema), estará no mesmo domínio onde estão as contas de todos os usuários, ou seja, não tenho como isolar o servidor configurado com Schema Master. Esta é talvez a maior desvantagem, em termos de segurança, do modelo de domínio único.

Multiple Subdomain Model (Múltiplos Subdomínios)

Existem situações que podem definir a necessidade de domínios adicionais. Uma das mais comuns é a necessidade de definir diferentes políticas de segurança, para diferentes grupos de usuários ou para diferentes divisões da empresa. Neste caso, a solução é a criação de um domínio para cada conjunto específico de necessidades de segurança. Mais adiante apresentarei outros motivos que podem fazer com que seja necessária a criação de múltiplos domínios.

Motivos que justificam (ou definem) a necessidade de criação de novos domínios:

  • Questões geográficas e links de baixa velocidade: Para empresas muito grandes, até mesmo com escritórios em dois ou mais continentes, pode ser conveniente a separação da rede em grupos distintos. Isso limita o tráfego de replicação dentro de domínios mais restritos. Por exemplo, se a sua empresa tem escritórios na América Latina, na Europa, nos EUA e na Ásia, pode ser mais indicado criar um domínio para cada continente. Com isso o tráfego de replicação dentro do domínio, ficaria mais restrito, aos DCs de cada domínio. Isso evitaria replicação através de links intercontinentais. Mesmo uma empresa, por exemplo, com escritórios e filiais apenas no Brasil. Pode ser necessária a divisão da rede em domínios para evitar a replicação através de links de baixa velocidade.
  • Administração descentralizada: Se a estrutura da empresa for constituída por divisões, onde cada divisão tem autonomia em relação as questões de TI, é indicado criar um domínio diferente para cada divisão. Com isso, a administração fica restrita dentro de cada domínio, ou seja, um administrador do domínio da Divisão A, não terá permissões administrativas no domínio da divisão B e vice-versa. Conforme já comentado anteriormente, este modelo também permite a definição de diferentes políticas de segurança para cada domínio. Esta pode ser uma necessidade real. Por exemplo, pode ser que no domínio onde está a divisão de pesquisa, seja exigida a criptografia de todas as informações que circulam na rede, através do uso do protocolo IPSec (veja Capítulo 20). Já em outros domínios pode ser que não seja necessário o IPSec. Neste caso você pode implementar o uso do IPSec no domínio de pesquisa e não implementar nos demais domínios. Outra vantagem de descentralizar a administração é que você tem a equipe de suporte e administração “próxima” aos usuários finais. Por exemplo, se você tivesse um único domínio, quando der um problema em um servidor no escritório do Japão, ao meio-dia, ou você terá que tirar o administrador da cama (que faz a administração centralizadamente a partir do Brasil) ou tem que aguardar até anoitecer no Japão (quando será dia no Brasil), para ser atendido pelo administrador. Já com uma estrutura descentralizada, você teria um domínio para o escritório no Japão e teria um administrador responsável no próprio domínio.
  • Necessidade de políticas de senhas diferentes: As políticas de senhas são definidas para o domínio como um todo. Ou seja, todos as contas de usuários do domínio “obedecem” as mesmas políticas de senhas. Se houver necessidade de diferentes políticas de senhas, para diferentes usuários, a única solução será a utilização de diferentes domínios.

No Capítulo 9 você encontra todos os detalhes sobre a definição de políticas de senhas para o domínio, tais como: tamanho mínimo de senha, dias para que a senha expire, número de tentativas de logon sem sucesso até que a conta seja bloqueada, se as senhas devem ou não atender a requisitos de complexidade e assim por diante.

  • Devido a importância do Schema e do servidor configurado como Schema Master, pode ser que, por medidas de segurança, seja necessária a criação de um domínio adicional, como domínio root, apenas para conter o servidor que atua como Schema Master, isolando este servidor e o acesso de administrador a este servidor. Esta é uma situação bastante específica, mas pode ser um determinante da criação de, pelo menos, mais um domínio, para conter o servidor que atua como Schema Master.

Existem algumas considerações importantes que devem ser feitas, quando você cria múltiplos domínios, formando desta maneira uma árvore de domínios. A primeira delas, já detalhadamente descrita no item “Planejando o Espaço de Nomes”, é que os domínios que formam uma árvore, devem formar um espaço contínuo de nomes. Devido a importância deste fato, repito ele novamente aqui. Vou apresentar mais algumas considerações, baseado na árvore de domínios da Figura 6.


Figura 6.10 Um modelo com múltiplos domínios.

Ao criar uma árvore de domínios, o Windows Server 2003 cria, automaticamente, relações de confianças bi-direcionais e transitivas entre o domínio filho e o domínio pai. No exemplo da Figura 6.10, automaticamente é criada uma relação de confiança bi-direcional e transitiva entre o domínio abc.com e x.abc.com, outra entre o domínio abc.com e y.abc.com, uma terceira entre x.abc.com e t.x.abc.com e mais uma entre x.abc.com e q.x.abc.com. Porém criar a relação de confiança, não significa que contas de um domínio, automaticamente recebem permissões de acesso a recursoso dos outros domínios. Não, não é isso. As relações de confiança significam que as contas de um domínio são “visíveis” nos outros domínios, isto é, podem receber permissões de acesso a recursos de outros domínios. Por exemplo, para que um usuário do domínio abc.com, possa acessar uma pasta compartilhada em um servidor do domínio x.abc.com, o administrador deste recurso deve, explicitamente, incluir o usuário do domínio abc.com na lista de usuários com permissão de acesso e configurar o nível de permissão deste usuário.

A seguir vou apresentar alguns exemplos práticos, onde você deve decidir qual domínio utilizar e ver se concorda com as justificativas apresentadas. Em seguida continuaremos a estudar os demais modelos de projeto de domínios, disponíveis.

Exercício 01: Você é o responsável por definir o modelo de domínios para a rede da empresa ABC. Já está definido que será utilizado o nome DNS abc.com e o nome NetBios ABC. A empresa tem a matriz na cidade de São Paulo e filias em Campinas, Ribeirão Preto, Santo André e Rio de Janeiro. Ao todo são cerca de 2000 usuários. O seu trabalho é definir, inicialmente, que tipo de modelo de domínios deve ser adotado. Para ajuda-la na sua decisão, os seguintes fatos devem ser levados em consideração:

  • Algumas tarefas administrativas devem ser descentralizadas. Mais especificamente, em cada escritório deve haver um administrador com a capacidade de desbloquear as contas dos usuários do respectivo escritório, bem como gerenciar pastas compartilhadas e impressoras compartilhadas, nos servidores do respectivo escritório.
  • Em cada escritório terão que ser aplicadas diferentes configurações para as estações de trabalho do respectivo escritório. Por exemplo, o comando Run (Executar) deve estar disponível nos computadores de alguns escritórios e não em outros, o Painel de controle deve estar disponível apenas nas estações de trabalho dos administradores e assim por diante.
  • As políticas de segurança em relação a senhas e a bloqueio de senhas serão únicas, para todos os usuários do domínio.
  • A replicação das informações do Active Directory deve ser otimizada, para evitar sobrecarga nos links de WAN, devido ao excesso de tráfego de replicação.

Com base no que foi exposto, qual dos modelos a seguir você indicaria:

a (  ) Múltiplos domínios, um para cada escritório e criação de um site associado com a rede local de cada localidade.

b (  ) Múltiplos domínios, um para a matriz e um que englobe todos os demais escritórios. Criação de um site associado com a rede local de cada localidade

c (  ) Domínio único e criação de um site associado com a rede local de cada localidade.

d (  ) Domínio único, com a criação de uma unidade organizacional para cada escritório e para a matriz em SP. Criação de um site associado com a rede local de cada localidade.

e (  ) Domínio único, com a criação de uma unidade organizacional para cada escritório e para a matriz em SP. Criação de um site associado com cada unidade organizacional.

Esta questão é interessante por diversos fatores. Primeiro por ser um exemplo prático, muito comum, de projeto de domínios de uma rede. Também é interessante porque permitirá uma revisão de diversos pontos importantes do Active Directory, porém uma revisão associada com um exemplo real, o que facilita a fixação dos conceitos. Então vamos lá: resposta e comentários.

Neste caso o modelo mais indicado é o descrito na alternativa “d”. Vamos a algumas questões que podem surgir. A primeira delas seria:

Por que domínio único? Como existe a necessidade de administração descentralizada de senhas, bloqueios/desbloqueios de contas, pasta e impressoras compartilhadas, o mais indicado não seria um modelo baseado em múltiplos domínios?

Não. Com o uso de Unidades Organizacionais, conforme descrito no Capítulo 5, é possível delegar uma série de tarefas a nível de unidade organizacional. No exemplo proposto, utiliza-se um único domínio e cria-se uma unidade organizacional para a matriz e uma unidade organizacional para cada escritório. As contas de usuários, grupos e computadores de cada escritório, devem ser criadas dentro da respectiva OU. Podem até ser criadas outras OUs, dentro da OU de cada escritório. Por exemplo, dentro da OU Campinas, o administrador poderia criar as OUs: Usuários, Grupos e Computadores, para separar as contas por tipos. Após criadas as OUs, basta delegar as devidas permissões administrativas em cada OU. Por exemplo, na OU Campinas, você poderia delegar as permissões necessárias para um administrador de Campinas, responsável pela administração dos usuários e computadores da OU Campinas. A seguir abro uma breve parênteses na nossa discussão teórica, para explicar os passos necessários para efetuar a delegação de permissões administrativas a nível de unidade organizacional.

Delegando permissões administrativas a nível de Unidade Organizacional:

Para delegar permissões administrativas a nível de Unidade Organizacional, siga os passos indicados a seguir:

1.         Faça o logon como administrador ou com uma conta com permissão de administrador.

2.         Abra o console Active Directory Users and Computers (Usuários e Computadores do Active Directory): Start -> Administrative Tools -> Active Directory Users and Computers (Iniciar -> Tarefas Administrativas -> Usuários e Computadores do Active Directory)

3.         Na árvore de opções do painel da esquerda, localize a OU na qual você deseja delegar permissões administrativas.

4.         Clique com o botão direito do mouse nesta OU. No menu de opções que é exibido, clique na opção Delegate control… (Delegar controle…).

5.         Será aberto o assistente para delegação de controle. Clique em Next (Avançar), para seguir para a próxima etapa do assistente.

6.         Na segunda etapa você deve selecionar os usuários ou grupos para os quais delegará permissões sobre os objetos da OU. Clique no botão Add… (Adicionar…). Será exibida a janela Select Users, Computers or Groups (Selecionar Usuários, Computadores ou Grupos). Selecione os usuários ou grupos para os quais deseja atribuir permissões e clique em OK. Você estará de volta ao assistente, com os usuários e grupos selecionados já sendo exibidos, conforme indicado na Figura 6.


Figura 6.11 Usuários que receberão permissões administrativas na OU.

Para maiores detalhes sobre a seleção de usuários e grupos, consulte o Capítulo 9.

7.         Clique em Avançar para seguir para a próxima etapa do assistente.

8.         Nesta etapa você seleciona quais permissões irá delegar para os usuários selecionados na etapa anterior. Por exemplo, existe a opção de delegar permissão para criar, excluir e gerenciar contas de usuários do OU (Create, delete and manage user accounts), de resetar as senhas dos usuários e forçar a troca da senha no próximo logon (Reste user passwords and force password change at next logon) e assim por diante.

9.         Marque as opções desejadas, conforme exemplo da Figura 16.12 e clique em Next (Avançar), para seguir para a próxima etapa do assistente.

10.       Será exibida a tela final do assistente. Se você quiser alterar alguma opção pode utilizar o botão Back (Voltar). Clique em Finisch (Concluir) e as permissões serão delegada aos usuários selecionados na segunta etapa.

Por fim resta analisar o motivo para a criação de um site associado com a rede local de cada escritório. Conforme descrito no Capítulo 5, o conceito de site é utilizado para representar a organização física da rede.Lembrando que um site é definido por um número de rede e a respectiva máscara de sub-rede. Ao criar um site para cada localidade, você está ajudando o Active Directory a otimizar a estrutura de replicação do Active Directory, principalmente, minimizando o tráfego de replicação. O Active Directory trata a replicação entre DCs do mesmo site, diferentemente da replicação entre DCs de site diferente. O objetivo desta estrutura toda é reduzir o tráfego de replicação para evitar o congestionamento dos links de WAN. Por exemplo, o tráfego de replicação entre os DCs do mesmo site não é compactado, já o tráfego de replicação entre DCs de sites diferentes é compactado.

A questão de aplicar diferentes configurações para os computadores de cada escritório, tais como o comando Run (Executar) deve estar disponível em alguns escritórios e não em outros, pode ser resolvida com o uso de GPOs – Group Polices Objects, assunto que será visto no Capítulo 18.

Para detalhes sobre a criação e administração de sites no Active Directory, consulte os Capítulos 17 e 18.

Com estas considerações, creio que está justificada a opção pela alternativa d. Antes de partir para o estudo do próximo modelo de domínios, vamos analisar mais um exemplo prático de projeto da árvore de domínios de uma empresa.

Exercício 02: Você é o responsável por definir o modelo de domínios para a rede da empresa ABC. Já está definido que será utilizado o nome DNS abc.com e o nome NetBios ABC. A empresa tem a matriz na cidade de São Paulo e filias em Campinas, Ribeirão Preto, Santo André e Rio de Janeiro. Ao todo são cerca de 15000 usuários. O seu trabalho é definir, inicialmente, que tipo de modelo de domínios deve ser adotado. Para ajuda-la na sua decisão, os seguintes fatos devem ser levados em consideração:

  • Algumas tarefas administrativas devem ser descentralizadas. Mais especificamente, em cada escritório deve haver um administrador com permissão de administrar completamente os servidores e recursos da rede do escritório.
  • Em cada escritório terão que ser aplicadas diferentes configurações para as estações de trabalho do respectivo escritório. Por exemplo, o comando Run (Executar) deve estar disponível nos computadores de alguns escritórios e não em outros, o Painel de controle deve estar disponível apenas nas estações de trabalho dos administradores e assim por diante. Diferentes conjuntos de softwares também serão distribuídos para cada escritório.
  • As políticas de segurança em relação a senhas e a bloqueio de senhas serão diferentes para cada escritório. Por exemplo, no escritório de Campinas estão as atividades de pesquisa e desenvolvimento de novos produtos. Segurança é uma questão fundamental para os usuários deste escritório, os quais devem atender a políticas de senha rigorosas, bem como outras políticas de segurança que serão únicas para este escritório.
  • A replicação das informações do Active Directory deve ser otimizada, para evitar sobrecarga nos links de WAN, devido ao excesso de tráfego de replicação.

Com base no que foi exposto, qual dos modelos a seguir você indicaria:

a (  ) Múltiplos domínios, um para cada escritório e criação de um site associado com a rede local de cada localidade.

b (  ) Múltiplos domínios, um para a matriz e um que englobe todos os demais escritórios. Criação de um site associado com a rede local de cada localidade

c (  ) Domínio único e criação de um site associado com a rede local de cada localidade.

d (  ) Domínio único, com a criação de uma unidade organizacional para cada escritório e para a matriz em SP. Criação de um site associado com a rede local de cada localidade.

e (  ) Domínio único, com a criação de uma unidade organizacional para cada escritório e para a matriz em SP. Criação de um site associado com cada unidade organizacional.

Mais um exercício bastante interessante. Primeiro por ser um exemplo prático, muito comum, de projeto de domínios de uma rede. Também é interessante porque permitirá uma revisão de diversos pontos importantes do Active Directory, porém uma revisão associada com um exemplo real, o que facilita a fixação dos conceitos. Então vamos lá: resposta e comentários.

Neste caso o modelo mais indicado é o descrito na alternativa “a”. Vamos a algumas questões que podem surgir e que servem para justificar a resposta apresentada. A primeira delas seria:

Primeiro a decisão por múltiplos domínios: Esta, convenhamos, que ficou fácil. Ao definir que as redes de cada escritório, terão políticas de segurança diferentes, estou apresentando o principal motivo para a criação de uma rede com múltiplos domínios. O amigo leitor poderia pensar que o numero de 15000 usuários é que seria decisivo para a decisão por múltiplos domínios. De maneira alguma, o Active Directory pode suportar um número muito maior do que 15000 em um domínio único. As questões relacionadas às políticas de segurança (diferentes para cada localidade) é que são decisivas em favor da decisão por múltiplos domínios.

Com a criação de uma árvore de domínios, as relações de confiança entre domínios são criadas e mantidas, automaticamente pelo Active Directory. Sempre lembrando que estas relações de confiança são transitivas e bidirecionais.

A criação de um site para cada localidade é de fundamental importância para auxiliar o Active Directory na determinação de uma estrutura otimizada de replicação. Conforme descrito anteriormente, o Active Directory configura de maneira diferente a replicação entre DCs do mesmo site e entre DCs de sites diferentes. Nesta situação, em cada localidade, haverá DCs somente do domínio da localidade. Por exemplo, na filial de Campinas haverá apenas DCs do domínio de Campinas. Outro fato interessante é que não haverá DCs do domínio de Campinas em nenhum outro local, a não ser na filial em Campinas. Este é um exemplo (bastante raro), onde cada site está associado com um único domínio e cada domínio está contido em um único site.

As diferentes configurações para as estações de trabalho de cada localidade podem ser aplicadas via GPOs. Só este fato não seria o suficiente para justificar o modelo de múltiplos domínios, uma vez que seria possível criar várias OUs dentro de um único domínio e aplicar diferentes GPOs em cada OU. Neste exemplo, o que determina de maneira definitiva a necessidade de múltiplos domínios é a necessidade de diferentes configurações de segurança em cada localidade. Por exemplo, Para os usuários do escritório em Campinas, onde são desenvolvidas atividades de pesquisa e desenvolvimento de novos produtos, segurança é uma questão fundamental. Para os usuários da filial em Campinas, o administrador pode pensar em usar tecnologias como IPSec, Certificados Digitais e autenticação usando Smart Card.

Multiple Trees in a Single Forest Model (Múltiplas Árvores em um Modelo de Floresta Simples):

Lembrando os conceitos do Capítulo 5, você pode criar um ou mais domínios, formando um espaço de nomes contínuo, para formar uma floresta de domínios. Espaço de nomes contínuo significa que os domínios “filho” sempre contém o nome do domínio “pai”. Por exemplo, se o domínio root for abc.com, todos os domínios de segundo nível conterão abc.com: vendas.abc.com, marketing.abc.com, suporte.abc.com e assim por diante, para todos os demais níveis. Existem situações em que você terá a necessidade de juntar duas ou mais árvores de domínios, onde dentro de cada árvore o espaço de nomes é contínuo, mas cada árvore usa um espaço de nomes diferente. Este arranjo é ilustrado na Figura 6.12:


Figura 6.12 Uma floresta formada por três árvores de domínios.

No exemplo da Figura 612 é apresentada uma floresta com três árvores de domínios: abc.com, jbt.com e cb.com. Dentro de cada árvore, o espaço de nomes é contínuo. Entre árvores não, pois cada árvore tem um espaço de nomes diferente.

Muitos administradores pensam que pelo fato de o espaço de nomes ter que ser contínuo dentro de uma árvore de domínios, o espaço de nomes, obrigatoriamente, também teria que ser contínuo entre as árvores de uma floresta. Isso não é verdadeiro, ou seja, esta percepção é um erro de interpretação. Numa estrutura como esta, existe um único domínio funcionando como domínio root (pode ser o domínio root de qualquer uma das árvores de domínio). Através de relações de confiança entre árvores (criadas pelo administrador), é possível criar uma floresta como a do exemplo da Figura 6.12.

Nota: Existem algumas condições que devem ser atendidas para que você possa implementar um modelo como este. Primeiro, existe um único domínio root. Por exemplo, poderia ser o domínio abc.com. Somente o domínio root é que tem um servidor configurado como Schema Master, ou seja, um servidor a partir do qual (e com as devidas permissões), é possível fazer alterações no Schema. Também é importante salientar que, mesmo sendo a floresta formada por diferentes árvores de domínios, todos os domínios da floresta utilizam o mesmo schema para o Active Directory. Em outras palavras, não seria possível juntar árvores, para formar uma floresta, se as árvores utilizassem diferentes esquemas.

Um modelo baseado em múltiplas árvores para formar uma floresta única pode ser necessário se a sua empresa é formada por diferentes unidades de negócio, sendo que cada unidade utiliza um DNS próprio. Ou em caso de aquisições e fusões, durante um período de transição, até que a estrutura da empresa que foi adquirida seja migrada para a rede da empresa. Por exemplo, vamos supor que a empresa A compra a empresa B. O processo de migração de todos os usuários, recursos e configurações da rede B para a rede A é um processo demorado. Porém os usuários da rede A precisam acessar recursos em servidores da rede B e vice-versa. Um usuário tem que poder ser autenticado em qualquer computador da rede e assim por diante. Neste caso, uma das soluções seria juntar as árvores de domínios da rede A e da rede B. Na medida do possível os usuários e recursos da rede B vão sendo migrados para a rede A, até que a rede B possa ser completamente desativada.

Na maioria das vezes este tipo de modelo torna-se necessário por questões externas, tais como uma mesma empresa formada por diferentes unidades de negócio, cada uma das unidades com DNS próprio, ou em casos de fusões e aquisições. Dificilmente você utilizará este modelo para uma empresa que não é dividida em unidades de negócios ou que não está passando por processos de aquisição ou fusão. Outra situação que pode exigir este tipo de modelo é se houver necessidade de integrar a rede da sua empresa, com a rede de parceiros de negócios ou no caso de órgãos públicos, que queiram integrar suas redes para facilitar a troca de informações e agilizar processos de pesquisa, auditoria e fiscalização.

Por exemplo, vamos supor que tenha sido editada uma lei unificando vários órgãos de combate e repreensão ao crime. Cada órgão tem a sua própria estrutura de rede, todas baseadas no Windows Server 2003 e no Active Directory (claro que na vida real, complicações adicionais existiriam, inclusive a necessidade de integração com outros sistemas operacionais – assunto tratado no Capítulo 17. O objetivo é integrar a rede dos vários órgãos envolvidos em uma rede única, para facilitar o compartilhamento de informações. Esta é uma situação típica onde o uso de um modelo de múltiplas árvores integradas em uma floresta, se mostra adequado. Inicialmente uma das árvores de domínios tem que ser selecionada de tal forma que o domínio root desta árvore se torne o domínio root de toda a floresta. Em seguida as demais árvores de domínios são integradas através para formar uma única floresta. Nunca é demais repetir que a condição fundamental para que essa estrutura possa ser montada, é que todas as árvores devem compartilhar o mesmo Schema do Active Directory. Não é possível integrar árvores de domínios que utilizam diferentes esquemas.

Federated Forest Model (Modelo de uma Federação de Florestas):

Este modelo leva o nível de integração um passo adiante. Se é possível integrar diferentes árvores para formar uma floresta, também é possível (somente no Windows Server 2003, ou seja, esta é uma das novidades do Windows Server 2003), estabelecer relações entre duas ou mais florestas para formar uma federação de florestas. Esta é uma nova funcionalidade do Windows Server 2003, onde a partir do uso de relações de confiança transitivas, entre florestas (cross-forest transitive trusts). No Windows Server 2003 é possível para o administrador, criar relações de confiança entre florestas que utilizam diferentes schemas. Por exemplo, imagine que sejam estabelecidas relações de confiança entre as florestas A e B. Com isso usuários de um domínio da floresta A, podem acessar recursos em domínios da floresta B e vice-versa. Os usuários de uma floresta também poderão ser autenticados, mesmo utilizando computadores que fazem parte de um domínio da outra floresta. Estou citando um exemplo onde foram relacionadas duas florestas, mas este modelo é extensível para mais de duas florestas, o que dá grande flexibilidade aos administradores de diferentes florestas, na criação de uma estrutura integrada.

Este modelo somente é possível de ser implementado quando todas as florestas estiverem no nível de funcionalidade Windows Server 2003. E isso somente é possível quando todos os DCs, de todos os domínios de todas as florestas a serem relacionadas, já tiverem migrado para o Windows Server 2003.

Para maiores detalhes sobre níveis de funcionalidade do domínio e da floresta e sobre relações de confiança, consulte o Capítulo 5.

Existem algumas situações em que este modelo é especialmente recomendado. A primeira delas é no caso de uma fusão entre duas empresas (ou no caso de aquisição de uma empresa por outra), onde existem cada empresa tem uma diferente estrutura de rede baseada no Active Directory, sendo que estas estruturas utilizam diferentes schemas e não poderiam ser integradas em uma única floresta. Nesta situação, se os requisitos para criar uma federação de florestas forem atendidos (nível de funcionalidade de todas as florestas como Windows Server 2003), pode ser criada uma federação de florestas, para facilitar o acesso aos recursos e a autenticação nos domínios das duas empresas, até que seja concluído o processo de migração e integração em uma estrutura única. Nesta situação, basta criar uma relação de confiança bi-direcional entre os domínios root de cada floresta. Com isso os usuários de uma floresta poderão receber permissões de acesso aos recursos da outra floresta e vice-versa.

Outra situação em que este modelo se aplica é quando, dentro da mesma empresa, são criadas diferentes florestas para atender a necessidades específicas. Por exemplo, uma divisão da empresa tem a necessidade de muitas alterações no schema do Active Directory. Por isso esta divisão terá que ter a sua própria floresta. Já outra divisão precisa ser isolada por questões econômicas e legais. Porém, ao mesmo tempo que apresentam necessidades específicas, as diferentes divisões precisam trocar informações entre si. Neste caso você pode criar relações de confiança entre os domínios root de cada divisão, para criar um modelo baseado em uma federação de florestas. Ou seja, ao mesmo tempo que cada divisão mantém a sua liberdade de fazer configurações que atendam suas necessidades específicas, é possível também a troca de informações entre as divisões.

Você deve ter percebido que este é um modelo bastante flexível, porém normalmente aplicado somente a empresas com redes realmente muito grandes, com divisões com diferentes necessidades ou em fase de fusão ou aquisição de novas empresas.

As relações de confiança entre florestas são unidirecionais. Ou seja, se você cria uma relação de confiança no sentido de que a floresta A confia na floresta B, então os usuários da floresta A poderão receber permissões de acesso aos recursos da floresta B. Para que os usuários da floresta B possam receber permissões de acesso aos recursos da floresta A, mais uma relação de confiança deve ser estabelecida, agora no sentido contrário, ou seja, a floresta A,confiando nas contas da floresta B. As relações de confiança entre florestas são transitivas, ou seja, se a floresta A confia na floresta B e a floresta B confia na floresta C, então a floresta A também confia na floresta C. Observe que para criar uma relação de confiança bidirecional, entre duas florestas, é preciso criar duas relações de confiança unidirecionais, uma em cada sentido.

O uso deste modelo também é indicado em situações onde você quer que diferentes partes da rede possam ter liberdade completa para definir suas configurações. Por exemplo, pode haver divisões que precisam de configurações de segurança extremamente avançadas, inclusive com modificações no Schema do Active Directory e implementação de restrições de segurança bastante severas. Nestas situações você pode separar cada grupo/divisão com necessidades específicas em sua própria floresta e depois integrar estas florestas em uma federação, para permitir a troca de informações.

Peer-Root Domain Model

A premissa básica deste modelo é o fato de que o schema é o elemento mais importante, mais crítico do Active Directory. Em outras palavras, se um usuário mal intencionado, tiver acesso ao servidor configurado como Schema Master e conseguir fazer o logon com permissões de administrador neste servidor, está feita a festa. Alterações indevidas no schema podem causar problemas irreversíveis em toda a rede, a ponto de simplesmente paralisar o Active Directory e não ser mais possível utilizar a rede. Por isso proteger, isolar e guardar com o maior zelo o servidor que atua como schema master é de fundamental importância.

Cabe aqui lembrar novamente alguns detalhes em relação ao schema. O schema é a definição da base de dados do Active Directory. No schema está a definição das classes existentes (usuários, grupos, computadores, etc), dos atributos de cada classe e das características (tipo de dados, permite ou não valores múltiplos, valor máximo e mínimo, etc) de cada atributo. Vários domínios podem ser criados para formar uma árvore de domínios e várias árvores podem ser interligadas para formar uma floresta, porém é uma condição obrigatório, que todos os domínios compartilhem o mesmo schema.

O schema é administrado em um servidor que exerce a função de schema master. O schema master normalmente é o primeiro DC do primeiro domínio a ser criado. Somente no schema master é possível fazer alterações no schema, tal como criar novos atributos ou desativar atributos que foram criados e não são mais necessários (esta é uma novidade do Windows Server 2003). Como o schema é um componente crítico (talvez o mais crítico) para o correto funcionamento do Active Directory, é de fundamental importância que o servidor que atua com schema master tenha o máximo de proteção possível.

É neste ponto que entra o modelo proposto neste item: Peer-Root Domain Model. Neste modelo, cria-se duas árvores de domínios. Uma é a árvore normal que contém os domínios da empresa, onde ficam os servidores e as contas de usuários. Outra árvore é criada com um único domínio, justamente o domínio que conterá o schema master. Normalmente esta segunda árvore tem, tipicamente, um único servidor que é o DC do domínio e também o servidor configurado como schema master. A única função deste servidor é ser o schema master da floresta. O próximo passo é simplesmente isolar (fisicamente) o servidor que atua como schema master, para protege-lo do acesso de usuários mal intencionados que queiram, propositadamente, alterar o schema para corromper o Active Directory. Na Figura 16.13, apresento um diagrama com a proposta do modelo Peer-Root Domain Model:


Figura 6.13 O modelo Peer-Root Domain Model.

No exemplo da figura, a rede da empresa é formada pela árvore de domínios abc.com, x.abc.com, y.abc.com, rh.x.abc.com e ti.x.abc.com. Uma segunda árvore (com um único domínio) é criada, com um único domínio: abcschema.abc.com. As duas árvores são unidas para formar uma floresta, onde o domínio root é o domínio abcschema.abc.com. O objetivo é que o servidor que atua como schema master esteja no domínio abcschema.abc.com e isolado fisicamente e logicamente (através das configurações de permissões de acesso e de diretivas de segurança) do restante da rede. O administrador pode usar recurso sofisticados, tais como limitar qual ou quais contas podem acessar o schema master pela rede, quais contas podem ter acesso a registry do servidor e quais contas podem fazer o logon localmente no schema master.

Mesmo com todas estas restrições é aconselhável ter backup sempre atualizado do schema master e armazenar o backup em local separado de onde está o servidor. Com todas as precauções e configurações de segurança, se alguém tiver acesso físico ao servidor configurado como schema master, dificilmente conseguirá fazer o logon e ter as permissões necessárias para alterar o schema, mas sempre será possível danificar fisicamente o HD ou até mesmo roubar o HD. Neste caso o backup é a alternativa mais viável. É recomendado que seja feito, sempre, um backup completo, de todo o servidor, conforme descreverei no item “Fazendo o backup do sistema”, no Capítulo 21.

Não só por causa do schema, mas também por outras funções que irá exercer este servidor, as chamadas master roles. Existem algumas funções de domínio que são exercidas por um único DC dentro do domínio e outras que são únicas em toda a floresta. Como o servidor que é o schema master, também foi o primeiro a ser instalado, o que forma a raiz de toda a floresta, muitas master roles da floresta serão exercidas por este servidor. Por isso que deve-se pensar em um bom esquema de backup e, se possível, até em sistemas redundantes de discos.

Este modelo tem uma vantagem adicional (não diretamente ligada à segurança) que é a flexibilidade para adição de novas árvores a floresta de domínios. Com esse modelo, caso seja feita a fusão com outra companhia, fica fácil juntar a floresta de domínios da outra companhia, com a floresta existente na sua companhia. É só uma questão de ligar o domínio root da outra companhia, com o domínio root da floresta da sua empresa. Bem mais fácil do que no caso de um modelo com múltiplos domínios e uma única floresta.

Mas a diretiva principal, ou melhor, a justificativa principal para o uso deste modelo é segurança. Para empresas onde a segurança é o fator principal, tal como organizações militares, órgãos governamentais ligados a investigação e a repreensão contra o crime, empresas de pesquisa e desenvolvimento de novas tecnologias, enfim, onde a segurança for um fator vital, determinante, o modelo Peer-Root Domain Model pode ser indicado.

Em poucas palavras as grandes vantagens deste modelo são: segurança em primeiro lugar e depois flexibilidade para incorporação de novas árvores e florestas ou incorporação da rede da empresa em outras florestas de domínios, como no caso de a empresa ser adquirida por outra. Se é que pode ser considerada uma desvantagem, podemos citar o custo adicional para aquisição de mais um servidor (ou quem sabe dois para garantir a redundância), o qual será utilizada como schema master, no domínio root. Para uma grande empresa, com centenas de servidores e milhares de estações de trabalho, este custo, certamente, não é algo significativo. Já para uma empresa menor, este custo pode pesar. Mas, com certeza, uma empresa de pequeno a médio porte não precisará deste modelo, a não ser que esteja em um ramo de atividade tal como pesquisa e desenvolvimento de novas tecnologias, onde a segurança e a proteção contra espionagem é um fator crítico.

Uma medida importante em relação à segurança é que não devem ser criadas contas de usuários no domínio root deste modelo, onde fica o schema master. Preferencialmente deve ser utilizado somente o grupo Administrators e criadas contas somente para os administradores que realmente devem ter acesso a este servidor. Você poderia dizer que o ideal, então, seria ter apenas a conta Administrator e dar acesso somente a esta conta. Porém ter uma única conta significa ou que você terá um único administrador com acesso (quem tem um pode ficar sem nenhum) ou que você teria que compartilhar a senha de administrador com dois ou mais usuários (o que também não é uma boa prática). O ideal é você ter algo entre dois ou três administradores com acesso e criar uma conta separada para cada um dos administradores. Com isso cada administrador utiliza a sua própria conta e senha.

Placeholder Domain Model

Inicialmente vou me arriscar a traduzir Placeholder como sendo “guardador de lugar”. Mas o que seria um modelo de domínio “guardador de lugar”? É isso que vamos apresentar neste item.

A idéia básica deste modelo é ter um domínio root, cuja única função é ser o domínio root de uma árvore de domínios: Hiii!, Agora complicou um pouco mais. Não, nada disso. Na prática, você cria um domínio root no qual não são criadas contas de usuários, não são instalados novos servidores e nem são disponibilizados recursos. A única função deste domínio é ocupar o lugar do root (ou exagerando na tradução: guardar o lugar do root). É um domínio criado para facilitar a implementação da árvore de domínios da empresa e atuar como root. Na Figura 6.14, apresento um exemplo deste tipo de modelo:


Figura 6.14 O modelo Placeholder Domain Model.

O domínio abc.com é o domínio placeholder (marcador de lugar), que está atuando como domínio root, porém somente isso. Não são criadas novas contas de usuários (apenas as contas dos administradores da rede) e nem são disponibilizados recursos. Já os demais domínios contém as contas de usuários e os recursos da rede, tais como pastas e impressoras compartilhadas, servidores da Intranet baseados no IIS, servidores de banco de dados e assim por diante.

Este modelo tem a mesma vantagem do modelo Peer-Root Domain Model em relação a segurança do schema master. Neste modelo, o schema master está no domínio root (que foi o primeiro domínio a ser criado) e está isolado dos demais domínios, o que facilita a restrição de acesso e outras medidas de segurança descritas no item: Peer-Root Domain Model.

Com este modelo também fica fácil criar a árvore de domínios baseada em critérios geográficos ou funcionais. Por exemplo, uma empresa chamada ABC Ltda., poderia criar um domínio root chamado abc.com. Em seguida, usando critérios geográficos, poderiam ser criados domínios chamados: eua.abc.com, europa.abc.com, amerlatina.abc.com, asia.abc.com, Oceania.abc.com e áfrica.abc.com. Estes domínios é que iriam conter contas de usuários, servidores e recursos. Dentro de cada domínio poderiam ser criadas unidades organizacionais para separar as contas de usuários e recursos por função.

Nota: Para mais detalhes sobre as vantagens e desvantagens do uso de critérios geográficos e sobre as vantagens e desvantagens do uso de critérios funcionais, para o projeto da árvore de domínios, consulte o item: Fundamentos em: Planejamento do espaço de nomes, anteriormente neste capítulo. Para detalhes sobre o projeto de unidades organizacionais, consulte o item “Projetando Unidades Organizacionais”, mais adiante neste capítulo.


Promoção: Livro Windows Server 2012 R2 e Active Directory - Curso Completo, 2100 Páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!

Promoção: Livro Windows Server 2012 R2 e Active Directory

Curso Completo, 2100 páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!


« Lição anterior Δ Página principal ¤ Capítulos Próxima lição »

Best Sellers de Excel do Julio Battisti

Todos com Vídeo Aulas, E-books e Planilhas de Bônus!

Aprenda com Júlio Battisti:
Excel 2010 Básico em 140 Lições - Através de Exemplos Práticos - Passo a Passo

 Aprenda com Júlio Battisti: Excel 2010 Básico em 140 Lições - Através de Exemplos Práticos

 

Autor: Júlio Battisti | Páginas: 540 | Editora: Instituto Alpha

 

[Livro]: Aprenda com Júlio Battisti: Excel 2010 Básico em 140 Lições - Através de Exemplos Práticos

Aprenda com Júlio Battisti: Excel 2010 Avançado, Análise de Dados, Tabelas Dinâmicas, Funções Avançadas, Macros e Programação VBA - Passo a Passo

Livro: Aprenda com Júlio Battisti: Excel 2010 Avançado, Análise de Dados, Tabelas Dinâmicas, Funções Avançadas, Macros e Programação VBA - Passo a Passo

 

Autor: Júlio Battisti | Páginas: 952 | Editora: Instituto Alpha

 

Livro: Aprenda com Júlio Battisti: Excel 2010 Avançado, Análise de Dados, Tabelas Dinâmicas, Funções Avançadas, Macros e Programação VBA - Passo a Passo

Aprenda com Júlio Battisti: Macros e Programação VBA no Excel 2010 Através de Exemplos Práticos e Úteis - Passo a Passo

 

[LIVRO]: Aprenda com Júlio Battisti: Macros e Programação VBA no Excel 2010 Através de Exemplos Práticos e Úteis - Passo a Passo

 

Autor: Júlio Battisti | Páginas: 1124 | Editora: Instituto Alpha

 

[LIVRO]: Aprenda com Júlio Battisti: Macros e Programação VBA no Excel 2010 Através de Exemplos Práticos e Úteis - Passo a Passo

Aprenda com Júlio Battisti: Excel 2010 - Curso Completo - Do Básico ao Avançado, Incluindo Macros e Programação VBA - Através de Exemplos Práticos

 

[A BÍBLIA DO EXCEL]: Aprenda com Júlio Battisti: Excel 2010 - Curso Completo - Do Básico ao Avançado, Incluindo Macros e Programação VBA - Através de Exemplos Práticos Passo a Passo

 

Autor: Júlio Battisti | Páginas: 1338 | Editora: Instituto Alpha

 

[A BÍBLIA DO EXCEL]: Aprenda com Júlio Battisti: Excel 2010 - Curso Completo - Do Básico ao Avançado, Incluindo Macros e Programação VBA - Através de Exemplos Práticos Passo a Passo

Todos os livros com dezenas de horas de vídeo aulas de bônus, preço especial (alguns com 50% de desconto). Aproveite. São poucas unidades de cada livro e por tempo limitado.

Dúvidas?

Utilize a área de comentários a seguir.

Me ajude a divulgar este conteúdo gratuito!

Use a área de comentários a seguir, diga o que achou desta lição, o que está achando do curso.
Compartilhe no Facebook, no Google+, Twitter e Pinterest.

Indique para seus amigos. Quanto mais comentários forem feitos, mais lições serão publicadas.

Quer receber novidades e e-books gratuitos?
›››

Novidades e E-books grátis

Fique por dentro das novidades, lançamento de livros, cursos, e-books e vídeo-aulas, e receba ofertas de e-books e vídeo-aulas gratuitas para download.



Institucional

  • Quem somos
  • Garantia de Entrega
  • Formas de Pagamento
  • Contato
  • O Autor
  • Endereço

  • Júlio Battisti Livros e Cursos Ltda
  • CNPJ: 08.916.484/0001-25
  • Rua Vereador Ivo Cláudio Weigel, 537 Universitário
  • Santa Cruz do Sul/RS
  • CEP 96816-208
  • Todos os direitos reservados, Júlio Battisti 2001-2017 ®

    [LIVRO]: MACROS E PROGRAMAÇÃO VBA NO EXCEL 2010 - PASSO-A-PASSO

    APRENDA COM JULIO BATTISTI - 1124 PÁGINAS: CLIQUE AQUI