[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 7Anexo : 08
Quer receber novidades e e-books gratuitos?
›››
« Lição anterior Δ Página principal ¤ Capítulos Próxima lição »
WINDOWS 7 - CURSO COMPLETO - 2400 páginas
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 375 - Anexo - Active Directory - Conceitos, Estrutura e Componentes

Introdução:

O Active Directory foi, sem dúvidas, a grande novidade do Windows 2000 Server em relação ao Windows NT Server 4.0. No Windows Server 2003 o Active Directory também é o elemento central, fundamental, sobre o qual é planejada e implementada uma infraestrutura de rede. Nas versões mais recentes, tais como o Windows Server 2008 e o Windows Server 2012, o Active Directory continua presente e sendo o principal elemento de uma rede baseada em servidores Windows.

Neste tópico apresentarei um estudo teórico detalhado do Active Directory. Desde a definição e as vantagens de se usar um serviço de diretórios, passando pela definição dos componentes do Active Directory, da estrutura lógica e física, até a apresentação de conceitos mais elaborados como por exemplo o controle de replicação entre os Controladores de Domínio (abreviados como DC).

Vou iniciar falando sobre o conceito de diretório. Mostrarei o que exatamente é um diretório, porque hoje encontramos múltiplos diretórios nas redes das empresas, conforme já descrevi anteriormente, neste anexo. Também mostrarei os problemas advindos do fato de se ter múltiplos diretórios e de como este fato cria problemas para o desenvolvimento de aplicações e para a integração dos sistemas informatizados de uma empresa.

Em seguida vou fazer uma introdução ao Active Directory no Windows Server 2003. Mostrarei o seu papel em uma rede com servidores baseados no Windows Server 2003 e o que deve ser feito para que o Active Directory seja instalado em um servidor, tornando o servidor um DC – Domain Controller (Controlador de Domínio) .

Feitas as devidas apresentações e conceituações é hora de apresentar os elementos que compõem e mantêm em funcionamento o Active Directory. Vou iniciar pelos elementos individuais, apresentando conceitos tais como:

  • Domínios
  • Árvores
  • Florestas
  • Relações de confiança
  • Objetos do Active Directory (Contas de usuários, grupos, computadores, etc.)
  • Unidades Organizacionais
  • Schema

Estes elementos compõem a chamada estrutura lógica do Active Directory, ou seja, a maneira como o Active Directory é apresentado ao Administrador e aos usuários, quando estes utilizam as ferramentas de administração e pesquisa do Active Directory.

A estrutura lógica pode ser diferente (e normalmente o é) da estrutura física. A estrutura física determina onde são armazenadas as informações sobre o Active Directory, como as informações são sincronizadas entre os diferentes DCs do domínio (chamamos este processo de replicação). Também serão apresentados e explicados os conceitos de sites, replicação inter sites e intra sites. Na parte final do Anexo apresentarei as novidades do Active Directory no Windows Server 2003.

Acredite amigo leitor, pode parecer um pouco “chato”, um tópico inteiro, teórico, sobre o Active Directory. Mas posso garantir que conhecendo os conceitos apresentados neste capítulo, será muito mais fácil planejar, implementar e administrar uma infraestrutura de rede baseada no Windows Server 2003 e no Active Directory nos servidores e no Windows 7 nas estações de trabalho.

Fundamentos em: Conceito de diretório e exemplos:

No início deste Anexo fiz um histórico dos modelos de redes e aplicações desde a época do Mainframe (que continua mais vivo do que nunca), passando pelo modelo Cliente/Servidor tradicional, até chegar ao modelo Web, baseado no desenvolvimento de aplicações em 3 ou mais camadas. Cada fase deixou suas características “impressas” na rede da empresa, no conjunto de aplicações que é utilizado para manter a empresa funcionando. O que ocorre na prática, é que hoje, na empresa, existem, ao mesmo tempo, aplicações rodando no Mainframe, aplicações Cliente/Servidor tradicionais e aplicações baseadas no modelo Web. A Figura A.11 ilustra bem este “mix” de aplicações, onde um usuário a partir da sua estação de trabalho, acessa aplicações em diferentes ambientes, para poder realizar o seu trabalho diário:

Curso Completo de Windows 7 - Júlio Battisti

Figura A.11 - Aplicações em diferentes ambientes e baseadas em diferentes modelos.

Você pode pensar que dificilmente isso aconteceria na prática. É justamente o contrário. Esta é a situação na qual encontram-se a maioria das empresas, ou seja: Uma variedade de aplicações não integradas, em diferentes plataformas e modelos. Falando de uma maneira mais simples, uma verdadeira “salada-de-frutas”, ou de outras formas: salada de aplições e modelos.

No exemplo descrito na Figura A.11, o usuário, para realizar o seu trabalho diário, tem que acessar aplicações e serviços em diferentes plataformas e modelos:

  • No Mainframe: Alguns sistemas da empresa (muitas vezes a maioria dos sistemas) ainda estão no Mainframe, com acesso através de aplicativos Emuladores de Terminal, instalados na estação de trabalho do usuário. Estes aplicativos mantém a interface a caractere, típica da época do Mainframe. A tão famosa telinha preta com letras verdes. Por exemplo, pode ser que o sistema de RH (controle de férias, curriculum, treinamentos, etc) ainda esteja no Mainframe.
  • Em aplicações cliente/servidor de 2 camadas: A medida que houve uma migração do Mainframe em direção ao cliente/servidor tradicional, de 2 camadas, muitas aplicações do Mainframe foram substituídas por aplicações Cliente/Servidor tradicionais, conforme descrito anteriormente. Por exemplo, podemos ter uma situação onde o sistema de vendas foi migrado do Mainframe para uma aplicação cliente/servidor de duas camadas. Os dados estão em um ou mais servidores da rede e a aplicação cliente é instalada na estação de trabalho do usuário.
  • Sistema de email e Intranet da empresa: É praticamente impossível que a sua empresa não tenha um sistema de email instalado. Com isso você utiliza mais um aplicativo (o cliente de email), para acessar o seu correio eletrônico. Você também utiliza o navegador para acessar a Intranet da emprsa. Se a sua empresa já evolui bastante no uso da Tecnologia da Informação, é provável que você use o navegador para acessar o Portal Corporativo da empresa.
  • Além desta variedade de aplicações você também precisa acesso aos recursos básicos da rede, tais como pastas e impressoras compartilhadas. Para ter acesso a estes recursos você deve estar identificado na rede, para que o servidor onde estão os recursos a serem acessados, possa liberar o acesso, dependendo de você ter ou não as permissões adequadas. Ou seja, o seu nome de usuário na rede e a respectiva senha, devem estar cadastrados em uma base de dados. Logo você descobrirá que base é esta.

Bem apresentado a provável ambiente atual no qual encontra-se a rede da sua empresa, vou salientar um dos principais problemas deste ambiente, problema este que está diretamente relacionado ao conceito de Diretório e também com o Active Directory.

Senhas demais, por favor alguém me ajude!

No cenário descrito anteriormente, onde o usuário tem que acessar sistemas em diferentes ambientes, é necessário um logon e senha para cada ambiente. Por exemplo, no sistema de grande porte o logon pode ser a matrícula do funcionário e uma senha por ele escolhida. Na rede o logon é a primeira parte do seu email, por exemplo jsilva e uma senha por ele escolhida. No sistema de email mais uma senha. Em cada aplicação Cliente/Servidor mais uma senha e assim por diante.

Para piorar um pouco a situação, a senha do Mainframe expira, por exemplo, a cada 30 dias e ele não pode repetir as últimas cinco senhas. A senha da rede expira a cada 60 dias e ele não pode repetir as últimas treze. A senha do email expira a cada 45 dias e ele não pode repetir as últimas 10. A do sistema xyz expira a cada 40 dias e ele não pode repetir as últimas 6. Meu Deus, você deve estar pensando, a estas alturas o nosso usuário já deve estar “maluco”.

Na verdade maluco ele não está, mas acaba fazendo algo pior do que estivesse maluco: Ou seleciona senhas que facilmente são descobertas ou anota as senhas e guarda o papel na gaveta ou embaixo do teclado. A culpa é do usuário? Obviamente que não, mas sim de um ambiente onde existem múltiplas aplicações, com uma senha diferente para cada uma, ou melhor, de quem disponibiliza um ambiente como este, para o usuário.

Mas espere aí um pouco. O que tem a ver este monte de senhas com o conceito de Diretório. Tem muito a ver. Observe que em cada ambiente existe um banco de dados para cadastro do nome do usuário, senha e outras informações, como por exemplo seção, matrícula e assim por diante. Este banco de dados com informações sobre os usuários da rede é um exemplo típico de Diretório.

Então no Mainframe, onde existe um cadastro de usuários, senhas e perfil de acesso de cada usuário, existe um Diretório. Na rede, onde existe um cadastro de usuários, senha, nome, seção, matrícula, etc, temos mais um diretório. No sistema de email, onde está cadastrado o email do usuário, senha, grupos, etc, temos um terceiro diretório e assim por diante. Observe que para cada diretório (o que implica cadastro em um determinado sistema), o usuário tem uma senha.

Então um diretório nada mais é do que um cadastro, ou melhor ainda, um banco de dados com informações sobre usuários, senhas e outros elementos necessários ao funcionamento de um sistema, quer seja um conjunto de aplicações no Mainframe, um grupo de servidores da rede local, o sistema de email ou outro sistema qualquer.

Saindo do mundo da computação, uma lista telefônica com o cadastro do nome do usuário, telefone e endereço, é um exemplo típico de diretório. O termo Diretório não é muito conhecido para nós, no idioma Português. Talvez um termo mais adequado fosse Cadastro, Banco de dados do sistema ou algo parecido. Mas o termo já é consagrado no idioma Inglês e acabou sendo adotado também no idioma Português (não sei se oficialmente, mas na prática, pelos profissionais de TI).

O Active Directory, introduzido inicialmente com o Windows 2000 Server e agora presente no Windows Server 2003 é também um exemplo típico de diretório. No Active Directory ficam gravadas informações sobre contas de usuários, senhas, grupos de usuários, membros de cada grupo, contas de computadores, informações sobre o Domínio, Relações de confiança, Unidades organizacionais, enfim, todas as informações necessárias ao funcionamento de uma rede baseada no Windows Server 2003.

Nota: No decorrer deste Anexo você aprenderá em detalhes sobre os diversos elementos do Active Directory, tais como Unidades organizacionais, sites, relações de confiança e assim por diante.

Um diretório único para todas as aplicações:

Porém o projeto do Active Directory é bem mais ambicioso do que simplesmente ser um diretório para conter informações dos elementos de uma rede baseada no Windows Server 2003. Ele foi projetado para tornar-se, com o tempo, o único diretório necessário na rede da empresa.

Mas como seria esta migração da situação atual, caótica, com múltiplos diretórios e senhas, para uma situação mais gerenciável, com um único diretório e senha: O TÃO SONHADO LOGON ÚNICO??

A proposta da Microsoft é que aos poucos as aplicações sejam integradas com o Active Directory. O que seria uma aplicação Integrada com o Active Directory? Seria uma aplicação que, ao invés de ter o seu próprio cadastro de usuários, senhas e grupos (seu próprio diretório), fosse capaz de acessar as contas e grupos do Active Directory e atribuir permissões de acesso diretamente as contas e grupos do Active Directory. Por exemplo, vamos supor que você utilize o Exchange 2003 como servidor de e-mail. Este é um exemplo de aplicação que já é integrada com o Active Directory. Ao instalar o Exchange 2003, este é capaz de acessar a base de usuários do Active Directory e você pode criar contas de e-mail para os usuários do Active Directory. Com isso quando o usuário faz o logon na rede, ele também está sendo autenticado com o Exchange e poderá ter acesso a sua caixa de correio sem ter que fornecer um login e senha novamente.

Chegará o dia do logon único, quando todas as aplicações forem ou diretamente integradas com o Active Directory, o forem capaz de acessar a base de usuários do Active Directory e atribuir permissões de acesso aos usuários e grupos do Active Directory. Esta abordagem de um diretório único tem inúmeras vantagens. A mais saliente é o logon único. Outra vantagem é o fato de que atualizações feitas no diretório já são refletidas, automaticamente, em todas as aplicações, uma vez que o diretório é único.

Quando o diretório não é único, as alterações devem ser feitas em todos os diretórios, senão ficarão desatualizadas. Vamos voltar um pouco ao ambiente de múltiplos diretórios. Vamos supor que um usuário foi transferido de setor e o seu número de telefone foi atualizado no diretório do Mainframe. Se este número não for também atualizado (e isto tem que ser feito pelo administrador de cada sistema) em todos os demais diretórios, corre-se o risco de alguém pesquisar um dos diretórios que não foi atualizado e obter o número de telefone antigo. Agora considere essa situação em uma empresa grande, onde estão em uso 5 ou 6 diretórios diferentes e multiplique isso por 4 ou 5 mil funcionários, você terá uma idéia do problema que é manter sempre atualizados os diversos diretórios em uso na empresa.

Por isso que a proposta do diretório único é interessante e muito bem vinda. É claro que não se faz a migração de um ambiente baseado em vários diretórios para um ambiente de diretório único, da noite para o dia. É um trabalho longo, que envolve um inventário das aplicações em uso, uma análise do que é prioritário, do que pode ser integrado e do que deverá ser reescrito e assim por diante. Mas é um trabalho que vale a pena, sob risco de chegar-se a um ambiente caótico, com inúmeros diretórios, ambiente este praticamente impossível de gerenciar ou gerenciável a um custo muito elevado.

Fundamentos em: Workgroups e Redes Baseadas em Diretórios:

Nesta item mostrarei as diferenças entre uma rede baseada no modelo de Workgroup e uma rede baseada no modelo de diretórios.

Você entenderá porque uma rede baseada no conceito de Grupo de trabalho (Workgroup) somente é indicada para redes muito pequenas, entre cinco e dez usuários. E porque para redes maiores seria praticamente impossível administrar um modelo de redes baseado em Grupos de Trabalho ao invés de domínios.

Domínios e Grupos de Trabalho (Workgroups):

Um rede baseada no Windows Server 2003 pode ser criada utilizando-se dois conceitos diferentes, dependendo da maneira com que os Servidores Windows Server 2003 são configurados. Os servidores podem ser configurados para fazerem parte de um Domínio ou de um Grupo de Trabalho, mais comumente chamado de Workgroup, termo que utilizarei de agora em diante.

Entendendo o funcionamento de uma rede baseada no modelo de Workgroups:

Em uma rede baseada no modelo de Workgroups cada servidor é independente do outro. Em outras palavras, os servidores do Workgroup não compartilham uma lista de usuários, grupos, políticas de segurança e outras informações. Cada servidor tem a sua própria lista de usuários e grupos, conforme indicado no diagrama da Figura A.12:

Curso Completo de Windows 7 - Júlio Battisti

Figura A.12 - Uma rede baseada no conceito de Workgroup.

O diagrama demonstra uma rede baseada no modelo de Workgroup. Na rede de exemplo temos três servidores, onde cada servidor tem a sua própria base de usuários, senhas e grupos. Conforme pode ser visto no diagrama, as bases estão diferentes, existem contas de usuários que foram criadas em um servidor mas não foram criadas nos demais. Por exemplo, a conta paulo somente existe no Servidor 01, a conta mauro só existe no Servidor 02 e a conta cassia só existe no servidor 03.

Agora imagine o usuário paulo, que está utilizando a sua estação de trabalho. Ele tenta acessar um recurso (por exemplo uma pasta compartilhada) no Servidor 01. Uma janela de logon é exibida. Ele fornece o seu nome de usuário e senha e o acesso (desde que ele tenha as devidas permissões) é liberado.

Agora este mesmo usuário – paulo, tenta acessar um recurso no Servidor 02. Novamente uma tela de logon é exibida e ele fornece o seu nome de usuáro e senha. O acesso é negado, com uma mensagem de usuário inexistente. Orá, isso acontece porque o usuário paulo somente está cadastrado no Servidor 01; para o Servidor 02 e para o Servidor 03 é como se o usuáro paulo não existisse (usuário inválido ou inexistente). Para que o usuário paulo possa acessar recursos dos servidores 02 e 03, o Administrador deveria criar uma conta chamada “paulo” nestes dois servidores.

Mas a “confusão” pode ser maior ainda. Imagine que o usuário paulo foi cadastrado pelo administrador com a conta paulo e senha: abc123de. Muito bem, o administrador fez o cadastro do usuário paulo nos três servidores: Servidor 01, Servidor 02 e Servidor 03. Agora, cerca de 30 dias depois, o usuário paulo resolveu alterar a sua senha. Vamos supor que ele estava conectado ao Servidor 01, quando fez a alteração da sua senha para: xyz123kj. Agora o usuário paulo está na situação indicada a seguir:

Servidor                     Usuário                      Senha

Servidor 01                 paulo                           abc123de

Servidor 02                 paulo                           abc123de

Servidor 03                 paulo                           xyz123kj

Na concepção do usuário, a partir de agora vale a nova senha, independentemente do servidor que ele estiver acessando. Pois para o usuário interessa o recurso que ele está acessando. Para o usuário não interessa se o recurso está no servidor 01, 02 ou outro servidor qualquer. Agora vamos ver o que acontece com o usuário paulo.

O usuário paulo, que está utilizando a sua estação de trabalho. Ele tenta acessar um recurso (por exemplo uma pasta compartilhada) no Servidor 03. Uma janela de logon é exibida. Ele fornece o seu nome de usuário e a nova senha e o acesso (desde que ele tenha as devidas permissões) é liberado.

Agora este mesmo usuário – paulo, tenta acessar um recurso no Servidor 02. Novamente uma tela de logon é exibida e ele fornece o seu nome de usuáro e a nova senha (xyz123kj). O acesso é negado, com uma mensagem de falha na autenticação. Aí o usuário fica pensando: mas como é possível, eu recém troquei a senha. Ele trocou a senha no Servidor 03. Para os demais servidores continua valendo a senha antiga. A única maneira de ele conseguir alterar a senha é fazendo o logon com a senha antigo e alterando para a nova senha, em cada um dos demais servidores da rede. Agora imagine o problema em uma rede de grandes proporções, com dezenas de servidores e milhares de funcionários. Fica fácil concluir que o modelo de Workgroup ficaria insustentável, impossível de ser implementado na prática, para redes com mais do que meia-dúzia de usuários.

Eu somente recomendaria  modelo de Workgroup para redes pequenas, com um único servidor e com um número de, no máximo, 5 usuários.

Entendendo o funcionamento de uma rede baseada no conceito de Diretório – Domínio:

Agora vou apresentar o modelo de rede baseado em um diretório. Vamos iniciar considerando o diagrama da Figura A.13:

Curso Completo de Windows 7 - Júlio Battisti

Figura A.13 - Uma rede baseada no conceito de Diretório - Domínio.

No modelo baseado em diretório, nos temos uma base de usuários única, ou seja, todos os servidores da rede compartilham a mesma base de usuários. O que acontece, na prática, não é que existe uma única base, armazenada em um determinado servidor, e todos os demais servidores acessam esta base. Não, não é isso. O que ocorre na prática, é que todos os servidores contém uma cópia da base de informações do diretório. Alterações efetuadas em um dos servidores são repassadas para os demais servidores da rede, para que todos fiquem com uma cópia idêntica da base de dados do diretório (este processo é tecnicamente conhecido como replicação).

O que caracteriza uma rede baseada em diretório é o fato de todos os servidores terem acesso a mesma base de dados, ou seja, todos compartilham o mesmo diretório. Mais adiante será apresentado o conceito de domínio, floresta, relação de confiança, etc. Estes são outros elementos relacionados com o diretório e que permitem a criação de redes de grande extensão geográfica, como por exemplo redes de uma grande empresa com escritórios no mundo inteiro (Microsoft).

No modelo baseado em diretório, a vida do Administrador fica bem mais fácil. Vamos supor que o usuário paulo queira acessar um recurso em um dos servidores da rede. Sem problemas, qualquer servidor tem uma cópia da base de dados do diretório. Com isso a conta do usuário paulo estará disponível em qualquer servidor e para acesso a qualquer recurso, de qualquer servidor do domínio, desde que o usuário paulo tenha as devidas permissões de acesso. Com isso ele poderá acessar recursos em qualquer um destes servidores. Há, mas se o usuário paulo alterar a sua senha. Isso será feito na cópia do banco de dados do diretório de um dos servidores. Correto? Correto, porém em pouco tempo esta alteração será replicada para todos os demais servidores e a senha do usuário paulo estará sincronizada em todos os servidores do domínio.

O modelo baseado em diretórios (e no conceito de domínios, florestas, etc) é bem mais fácil para administrar e permite a implementação de redes de grandes proporções, tanto geográficas quanto em números de usuários. Em uma das empresas onde eu trabalhei, tínhamos uma rede baseada no Active Directory. A rede se estendia por todos os estados do território nacional e tinha cerca de 26.000 usuários. Uma rede e tanto. Seria literalmente impossível manter uma rede destas proporções sem utilizar o modelo baseado em diretórios.

Domínios, Árvores de domínios e Unidades Organizacionais – Conceitos:

Agora que você já conhece bem a diferença entre um modelo de rede baseada em Workgroup e outro de rede baseada em diretórios, é hora de avançar um pouco mais e nós aproximar da terminologia do Active Directory. Neste item vou apresentar o conceito de Domínio. Não um conceito formal, mas sim como ele é utilizado em redes baseadas no Active Directory e no Windows Server 2003 (ou Windows 2000 Server).

No Windows Server 2003 (e também no Windows 2000 Server), o conjunto de servidores, estações de trabalho, bem como as informações do diretório é que formam uma unidade conhecida como Domínio. Todos os servidores que contém uma cópia da base de dados do Active Directory, fazem parte do domínio. As estações de trabalho podem ser configuradas para fazer parte do domínio. No caso de estações de trabalho com o NT Workstation 4.0, Windows 2000 Professional, Windows XP ou Windows 7 Professional, cada estação de trabalho que faz parte do domínio, tem uma conta de computador criada no domínio. A conta de computador tem o mesmo nome do computador. Por exemplo, a estação de trabalho micro-cont-001, tem uma conta de computador, na base de dados do Active Directory, com o nome de micro-cont-001.

Um domínio pode também ser definido com um limite administrativo e de segurança. Ele é um limite administrativo, pois as contas de Administrador tem permissões de acesso em todos os recursos do domínio, mas não em recursos de outros domínios. Ele é um limite de segurança porque cada domínio tem definições de políticas de segurança que se aplicam as contas de usuários e demais recursos dentro de domínio e não a outros domínios. Ou seja, diferentes domínios podem ter diferentes políticas e configurações de segurança. Por exemplo, no domínio A, posso ter uma política de segurança que define um tamanho mínimo de senha como 8 caracteres. Esta política será válida para todas as contas de usuário do domínio A. Um segundo domínio B, pode ter uma política de segurança diferente, a qual define um tamanho mínimo de senha de 12 caracteres. Esta política será válida para todas as contas de usuários do domínio B.

Um Domínio é simplesmente um agrupamento lógico de contas e recursos, os quais compartilham políticas de segurança. As informações sobre os diversos elementos do domínio (contas de usuários, contas de computador, grupos de usuários, políticas de segurança, etc), estão contidas no banco de dados do Active Directory.

Em um domínio baseado no Active Directory e no Windows Server 2003 é possível ter dois tipos de servidores Windows Server 2003:

  • Controladores de Domínio (DC – Domain Controllers)
  • Servidores Membro (Member Servers).

Falarei um pouco mais sobre Controladores de Domínio e Servidores Membro no final deste tópico.

A criação de contas de usuários, grupos de usuários e outros elementos do Active Directory, bem como alterações nas contas de usuários, nas políticas de segurança e em outros elementos do Active Directory, podem ser feitas em qualquer um dos Controladores de Domínio. Uma alteração feita em um DC será automaticamente repassada (o termo técnico é “replicada”) para todos os demais Controladores de Domínio. Por isso se você cria uma conta para o usuário jsilva e cadastra uma senha para este usuário, essa conta passa a ser válida em todo o domínio, sendo que o usuário jsilva pode receber permissões para acessar recursos e serviços em qualquer servidor do Domínio, seja em um Controlador de Domínio ou em um Servidor Membro.

Por isso que o Domínio transmite a idéia de um agrupamento lógico de Contas de Usuários e Grupos, bem como de políticas de segurança, uma vez que todo o Domínio compartilha a mesma lista de Usuários, Grupos e políticas de segurança. A criação de domínios facilita enormemente a administração de uma rede baseada no Windows Server 2003, sendo altamente recomendada para qualquer rede de maior porte seja criada com base em um ou mais domínios (dependendo do porte da rede).

Nos Servidores Membros podem ser criadas contas de usuários e grupos, as quais somente serão válidas no Servidor Membro onde forem criadas. Embora isso seja tecnicamente possível, essa é uma prática não recomendada, uma vez que isso dificulta enormemente a administração de um Domínio. Você pode atribuir permissões para os Recursos de um Servidor Membro, à contas de Usuários e Grupos do domínio, sem a necessidade de criar esses usuários ou grupos localmente. Por exemplo, um usuário jsilva, que pertence ao domínio, pode receber permissões de acesso em uma pasta compartilhada de um Servidor Membro. Com isso você pode concluir que um Servidor Membro, é um servidor que embora não mantenha uma cópia da lista de usuários e grupos do Active Directory, este tem acesso a essa lista. Com isso podem ser atribuídas permissões nos recursos do Servidor Membro (tais como pastas compartilhadas, impressoras, etc ) para as contas e grupos do Domínio.

Em um Domínio todos os Controladores de Domínio, compartilham uma lista de usuários, grupos e políticas de segurança, além de algumas outras características que falarei no tópico sobre o Active Directory. Além disso alterações feitas em um dos Controladores de Domínio, são automaticamente replicadas para os demais.

Os DCs também são responsáveis por fazer a autenticação dos usuários na rede. Por exemplo, vamos supor que o usuário jsilva trabalha em uma estação de trabalho com o Windows 7 Professional instalado. Esta estação foi configurada para fazer parte de um domínio. Quando o usuário jsilva liga a estação de trabalho e o Windows é inicializado,  é apresentada a tela de logon para que ele forneça o seu nome de usuário e senha. O Windows precisa verificar se o nome de usuário e senha estão corretos. A Windows tenta localizar um DC na rede. É no DC que a verificação é feita, comparando as informações digitadas pelo usuário, com as informações da base de dados do Active Directory. Se as informações estão OK o logon é liberado, o usuário é autenticado e a área de trabalho do Windows é exibida. A partir deste momento, toda vez que o usuário tentar acessar um recurso do domínio, será apresentada a sua autenticação, para provar a identidade do usuário para a rede. Isso evita que o usuário tenha que entrar com o seu logon  e senha cada vez que for acessar um recurso em um servidor diferente (que é justamente o que acontece no modelo baseado em Workgroup, conforme descrito anteriormente).

Como os Servidores Membro não possuem uma cópia da lista de usuários e grupos, estes não efetuam a autenticação dos clientes e também não armazenam informações sobre as políticas de segurança para o Domínio – as quais também são conhecidas por GPO – Group Polices Objects.

Nota: Estações de trabalho com o Windows 7 Home, não podem ser configuradas para fazer parte de um domínio. Estações de trabalho com o Windows 95/98/Me podem ser configuradas para fazer parte de um domínio. Para ter acesso a maioria dos recursos do Active Directory, também é preciso instalar o Active Directory Client, nas estações de trabalho com o Windows 95/98/Me. Uma estação de trabalho com o NT Workstation 4.0 também pode ser configurada para fazer parte de um domínio baseado no Active Directory e no Windows Server 2003.

Quando os servidores Windows Server 2003 são configurados para trabalhar com um Workgroup, não existe o conceito de domínio e nem de Controlador de Domínio. Cada servidor mantém uma lista separada para contas de usuários, grupos e políticas de segurança. Com isso se um usuário precisa acessar recursos em três servidores, por exemplo, será necessário criar uma conta para esse usuário nos três servidores diferentes. Um Workgroup somente é recomendado para redes extremamente pequenas, normalmente com um único servidor Windows Server 2003 e não mais do que 5 estações clientes, conforme descrito anteriormente.

Active Directory:

Lembro de já ter escrito a seguinte frase, em um dos capítulos deste livro:

“O Active Directory é,  sem dúvidas, a mudança mais significativa incluída no Windows 2000 Server e que também faz parte do Windows Server 2003.”

Mas de uma maneira simples, o que é o Active Directory?

“O Active Directory é o serviço de diretórios do Windows Server 2003. Um Serviço de Diretórios é um serviço de rede, o qual identifica todos os recursos disponíveis em uma rede, mantendo informações sobre estes dispositivos (contas de usuários, grupos, computadores, recursos, políticas de segurança, etc) em um banco de dados e torna estes recursos disponíveis para usuários e aplicações.”

Pode parecer que o Active Directory é, na verdade um banco de dados. Mas não é só isso. Além do banco de dados com informações sobre os elementos (tecnicamente conhecidos como objetos) que compõem o domínio, o Active Directory também disponibiliza uma série de serviços que executam as seguintes funções:

  • Replicação entre os Controladores de domínio.
  • Autenticação
  • Pesquisa de objetos na base de dados
  • Interface de programação para acesso aos objetos do diretório

Pela descrição formal, é possível inferir que o Active Directory é um serviço de rede, no qual ficam armazenadas informações sobre dados dos usuários, impressoras, servidores, grupos de usuários, computadores e políticas de segurança. Cada um desses elementos são conhecidos como objetos.

O Active Directory além de armazenar uma série de informações sobre os objetos disponíveis na rede (contas de usuários, grupos de usuários, servidores, computadores, etc), torna fácil para o administrador localizar e fazer alterações nos objetos existentes, bem como criar novos objetos ou excluir objetos que não sejam mais necessários. Em resumo, com o conjunto de serviços oferecidos pelo Active Directory, a administração da rede fica bem mais fácil.

Os recursos de segurança são integrados com o Active Directory, através do mecanismo de logon e autenticação. Todo usuário tem que fazer o logon (informar o seu nome de usuário e senha), para ter acesso aos recursos da rede. Durante o logon o Active Directory verifica se as informações fornecidas pelo usuário estão corretas e então libera o acesso aos recursos para os quais o usuário tem permissão de acesso.

Os recursos disponíveis através do Active Directory , são organizados de uma maneira hierárquica, através do uso de Domínios. Uma rede na qual o Active Directory está instalado, pode ser formada por um ou mais Domínios. Com a utilização do Active Directory  um usuário somente precisa estar cadastrado em um único Domínio, sendo que este usuário pode receber permissões para acessar recursos em qualquer um dos Domínios.

A utilização do Active Directory simplifica em muito a administração, pois fornece um local centralizado, através do qual todos os recursos da rede podem ser administrados. Todos os Controladores de Domínio, possuem o Active Directory instalado. A Maneira de criar um domínio é instalar o Active Directory em um Member Server e informar que este é o primeiro Controlador de Domínio. Depois de criado o domínio (a parte prática da criação de domínios é abordada no Capítulo 8 do seguinte livro, de minha autoria: “Windows Server 2003 – Curso Completo”, 1568 páginas.) você pode criar DCs adicionais, simplesmente instalando o Active Directory em um ou mais servidores.

O Active Directory utiliza o DNS (Domain Name System)  como serviço de nomeação de servidores e recursos e de resolução de nomes. Por isso um dos pré-requisitos para que o Active Directory possa ser instalado e funcionar perfeitamente é que o DNS deve estar instalado e corretamente configurado.

Novidade: No Windows Server 2003, o assistente de instalação do Active Directory é capaz de instalar e configurar o DNS, caso ele não encontre um servidor DNS adequadamente configurado na rede. Esta não chega a ser exatamente uma novidade. O que ocorre na prática, é que o assistente de instalação do Active Directory, no Windows Server 2003, consegue na maioria das vezes configurar o DNS corretamente, o que não ocorria no Windows 2000 Server.

O Agrupamento de objetos em um ou mais Domínios permite que a rede de computadores reflita a organização da sua empresa. Para que um usuário cadastrado em um domínio, possa receber permissões para acessar recursos em outros domínios, o Windows Server 2003 cria e mantém relações de confiança entre os diversos domínios. As relações de confiança são bidirecionais e transitivas. Isso significa se o Domínio A confia no Domínio B, o qual por sua vez confia em  um Domínio C, então o Domínio A também confia no Domínio C. Isso é bastante diferente do que acontecia até o NT Server 4.0, uma vez que as relações de confiança tinham que ser criadas e mantidas manualmente pelos administradores dos domínios, uma a uma. Era um trabalho e tanto, o que dificultava a implementação de relações de confiança em uma rede com muitos domínios.

Todo Domínio possui as seguintes características:

  • Todos os objetos de uma rede (contas de usuários, grupos, impressoras, políticas de segurança, etc) fazem parte de um único domínio. Cada domínio somente armazena informações sobre os objetos do próprio domínio.
  • Cada domínio possui suas próprias políticas de segurança.

Árvore de domínios:

Quando existem diversos domínios relacionados através de relações de confiança, criadas e mantidas automaticamente pelo Active Directory, temos uma Árvore de domínios. Uma árvore nada mais é do que um agrupamento ou arranjo hierárquico de um ou mais domínios do Windows Server 2003, os quais “compartilham um espaço de nome.”

Vou explicar em detalhes o que significa a expressão “compartilham um espaço de nome”. Primeiramente observe a Figura A.14.

Curso Completo de Windows 7 - Júlio Battisti

Figura A.14 - Todos os domínios de uma árvore compartilham um espaço de nomes em comum.

Observe que é exibida uma árvore com 7 domínios. Mas o que significa mesmo “compartilham um espaço de nome”?

Observe que o domínio inicial é microsoft.com. Os domínios seguintes são: vendas.microsoft.com e suporte.microsoft.com. Quando é formada uma hierarquia de domínios, compartilhar um espaço de nomes, significa que os nomes dos objetos filho (de segundo nível, por exemplo: vendas.microsoft.com e suporte.microsoft.com), contém o nome completo do objeto pai (microsoft.com). Por exemplo, vendas.microsoft.com contém microsoft.com. Descendo mais ainda na hierarquia, você pode observar que este fato continua verdadeiro. Por exemplo o objeto filho sistemas.vendas.microsoft.com contém o nome do objeto Pai vendas.microsoft.com, o qual, por sua vez, contém o nome completo do seu objeto pai que é microsoft.com.

Com isso uma árvore de diretórios deste tipo forma um espaço de nomes contínuo, onde o nome do objeto filho sempre contém o nome do objeto pai.

Unidades Organizacionais:

Você pode ainda dividir um Domínio em “Unidades Organizacionais”. Uma Unidade Organizacional é uma divisão que pode ser utilizada para organizar os objetos de um determinado domínio em um agrupamento lógico para efeitos de administração. Isso resolve uma série de problemas que existiam em redes baseadas no NT Server 4.0. No Windows NT Server 4.0 se um usuário fosse adicionado ao grupo Administradores (grupo com poderes totais sobre qualquer recurso do domínio), ele poderia executar qualquer ação em qualquer servidor do domínio. Com a utilização de Unidades Organizacionais, é possível restringir os direitos administrativos apenas a nível da Unidade Organizacional, sem que com isso o usuário tenha poderes sobre todos os demais objetos do Domínio.

Cada domínio pode implementar a sua hierarquia de Unidades Organizacionais, independentemente dos demais domínios, isto é, os diversos domínios que formam uma árvore, não precisam ter a mesma estrutura hierárquica de unidades organizacionais.

No exemplo da Figura A.14, o domínio vendas.microsoft.com, poderia ter uma estrutura hierárquica de Unidades Organizacionais, projetada para atender as necessidades do domínio vendas. Essa estrutura poderia ser completamente diferente da estrutura do domínio suporte.microsoft.com, a qual será projetada para atender as necessidades do domínio suporte. Com isso tem-se uma flexibilidade bastante grande, de tal forma que a árvore de domínios e a organização dos domínios em uma hierarquia de Unidades Organizacionais, possa atender perfeitamente as necessidades da empresa. A utilização de Unidades Organizacionais não é obrigatória, porém altamente recomendada,conforme mostrarei em alguns exemplos mais adiante.

Utilize Unidades Organizacionais quando:

  • Você quiser representar a estrutura e organização da sua companhia em um domínio. Sem a utilização de Unidades Organizacionais, todas as contas de usuários são mantidas e exibidas em uma única lista, independente da localização, departamento ou função do usuário.
  • Você quiser delegar tarefas administrativas sem para isso ter que dar poderes administrativos em todo o Domínio. Com o uso de Unidades Organizacionais, você pode dar permissões para um usuário somente a nível da Unidade Organizacional.
  • Quiser facilitar e melhor acomodar alterações na estrutura da sua companhia. Por exemplo, é muito mais fácil mover contas de usuários entre Unidades Organizacionais do que entre domínios, embora no Windows Server 2003 seja bem mais fácil mover uma conta de um domínio para outro, do que era no Windows 2000 Server.

Com  a apresentação destes conceitos, você já está habilitado a estudar os elementos do Active Directory em mais detalhes.

Principais objetos de um domínio:

Até aqui apresentei os conceitos básicos sobre diretórios, domínios, unidades organizacionais e árvores de diretórios. A partir deste item passarei a descrever os objetos que fazem parte do Active Directory. Na seqüência falarei sobre os serviços que dão suporte ao Active Directory, tais como os serviços de replicação e o conceito de relações de confiança entre diretórios.

Contas de usuários, computadores e grupos de usuários:

Contas de usuários:

Todo usuário que quer ter acesso aos recursos dos computadores do domínio (pastas compartilhadas, impressoras compartilhadas, etc) deve ser cadastrado no Active Directory. Cadastrar o usuário, significa criar uma conta de usuário e uma senha. Ao cadastrar um usuário, outras informações tais como seção, nome completo, endereço, telefone, etc, podem ser cadastradas.

Uma conta de usuário é um objeto do Active Directory, o qual contém diversas informações sobre o usuário, conforme descrito anteriormente. É importante salientar que a conta somente precisa ser criada uma vez, em um dos Controladores de domínio. Uma vez criada, a conta será replicada para todos os demais DCs do domínio.

Você também pode criar contas nos servidores membros e nas estações de trabalho com Windows 2000 Professional, Windows XP Professional ou Windows 7 Professional. As contas criadas nestes computadores são conhecidas como contas locais, ou seja, somente existem no computador onde foram criadas. Vamos imaginar que você está trabalhando em uma estação de trabalho com o Windows 7 Professional instalado. Esta estação foi configurada para fazer parte do domínio abc.com.br. Como a estação de trabalho faz parte do domínio, você terá acesso a lista de usuários e grupos do domínio. Com isso você poderá, por exemplo, atribuir permissão de acesso para um usuário do domínio (ou um grupo de usuários) em uma pasta compartilhada na sua estação de trabalho. Nesta mesma estação você também poderá criar contas de usuários e grupos locais, os quais ficam gravados na base de usuários local e só existem neste computador. Estes usuários e grupos (criados localmente), somente podem receber permissões de acesso para os recursos do computador onde foram criados. Você não conseguirá atribuir permissão de acesso em uma pasta compartilhada no servidor, para um usuário local da sua estação de trabalho.

Embora seja tecnicamente possível a criação de usuários e grupos locais, nos Servidores Membros e nas estações de trabalho, esta prática não é recomendada. Quando você trabalha em um domínio, o ideal é que contas de usuários e grupos sejam criadas somente no domínio, isto é, nos DCs.

Importante: O Administrador pode utilizar o recurso de GPOs – Group Polices Objects para impedir que os usuários possam criar contas de usuários e grupos locais, em suas estações de trabalho.

Algumas recomendações e observações sobre contas de usuários:

  • Todo usuário que acessa a rede deve ter a sua própria conta. Não é recomendado que dois ou mais usuários compartilhem a mesma conta. A conta é a identidade do usuário para a rede. Por exemplo, quando o usuário jsilva faz o logon no domínio, a sua conta é a sua identidade para o sistema. Todas as ações realizadas pelo usuário estão associadas a sua conta. O Windows Server 2003 tem um sistema de auditoria de segurança, no qual o Administrador pode configurar quais ações devem ser registradas no Log de auditoria. Por exemplo, o administrador pode definir que toda tentativa de alterar um determinado arquivo seja registrada no log de auditoria. Se o usuário jsilva tentar alterar o referido arquivo, ficará registrado no logo de auditoria que o usuário jsilva, no dia tal, hora tal, tentou alterar o arquivo tal. Se dois ou mais usuários estão compartilhando a mesma conta, fica difícil identificar qual o usuário que estava logado no momento. Para o sistema é o jsilva. Agora quem dos diversos usuários que utilizam a conta jsilva é que estava logado e tentou alterar o referido arquivo? Fica difícil saber. Por isso a recomendação para que cada usuário seja cadastrado e tenha a sua própria conta e senha.
  • Com base nas contas de usuários e grupos, o administrador pode habilitar ou negar permissões de acesso aos recursos da rede. Por exemplo, o administrador pode restringir o acesso a pastas e arquivos compartilhados na rede, definindo quais usuários podem ter acesso e qual o nível de acesso de cada usuário – leitura, leitura e alteração, exclusão e assim por diante. Mais um bom motivo para que cada usuário tenha a sua própria conta e senha.

Outro detalhe que você deve observar, é a utilização de um padrão para o nome das contas de usuários. Você deve estabelecer um padrão para a criação de nomes, pois não podem existir dois usuários com o mesmo nome de logon dentro do mesmo Domínio. Por exemplo se existir no mesmo Domínio, dois “José da Silva” e os dois resolverem utilizar como logon “jsilva”, somente o primeiro conseguirá, o segundo terá que se conformar em escolher um outro nome de logon. Para isso é importante que seja definido um padrão e no caso de nomes iguais deve ser definido uma maneira de diferenciá-los. Por exemplo poderíamos usar como padrão a primeira letra do nome e o último sobrenome. No caso de nomes iguais, acrescenta-se números. No nosso exemplo o primeiro José da Silva cadastrado ficaria como jsilva, já o segundo a ser cadastrado ficaria como jsilva1. Caso no futuro tivéssemos mais um José da Silva dentro da mesma Unidade Organizacional, este seria o jsilva2 e assim por diante.

Quando for criar nomes de logon para os usuários, leve em consideração os seguintes detalhes:

  • Nomes de Usuários do Domínio devem ser únicos dentro do Domínio.
  • Podem ter no máximo 20 caracteres.
  • Os seguintes caracteres não podem ser utilizados:  “ / \ : ; [ ] | = , + *  ? < >

Sempre que você for cadastrar um usuário também deve ser cadastrada uma senha para o usuário. O administrador pode especificar um número mínimo de caracteres aceito para a senha. O número máximo de caracteres da senha é 128.

IMPORTANTE: Para as senhas, o Windows Server 2003 distingue letras maiúsculas de minúsculas. Por exemplo a senha “Abc123” é diferente da senha “abc123”.

Contas de Computador:

Estações de trabalho que rodam o Windows NT Workstation 4.0, Windows 2000 Professional, Windows XP Professional ou Windows 7 e que fazem parte do domínio, devem ter uma conta de computador no Active Directory. Servidores, quer sejam Member Servers ou DCs, rodando Windows NT Server 4.0, Windows 2000 Server ou Windows Server 2003, também tem contas de computador no Active Directory.

A conta de computador pode ser criada antes da instalação do computador ser adicionado ao domínio ou no momento em que o computador é configurado para fazer parte do domínio. A conta do computador deve ter o mesmo nome do computador na rede. Por exemplo, um computador com o nome de microxp01, terá uma conta no Active Directory, com o nome: microxp01.

Nota: Computadores rodando Windows 95/98/Me, mesmo tendo acesso a lista de usuários e grupos do domínio, não terão contas de computador criadas no Active Directory.

Grupos de usuários:

Um grupo de usuários é uma coleção de contas de usuários. Por exemplo, podemos criar um grupo chamado Contabilidade, do qual farão parte todos os usuários do departamento de Contabilidade (todas as contas de usuários dos funcionários do departamento de Contabilidade).

A principal função dos grupos de usuários é facilitar a administração e a atribuição de permissões para acesso a recursos, tais como: pastas compartilhadas, impressoras remotas, serviços diversos, etc.

Ao invés de dar permissões individualmente, para cada um dos usuários que necessitam acessar um determinado recurso, você cria um grupo, inclui os usuários no grupo e atribui permissões para o grupo. Para que um usuário tenha permissão ao recurso, basta incluir o usuário no grupo, pois todos os usuários de um determinado grupo, herdam as permissões dos grupos aos quais o usuário pertence.

Quando um usuário troca de seção, por exemplo, basta trocar o usuário de grupo. Vamos supor que o usuário jsilva trabalha na seção de contabilidade e pertence ao grupo Contabilidade. Com isso ele tem acesso a todos os recursos para os quais o grupo Contabilidade tem acesso. Ao ser transferido para a seção de Marketing, basta retirar o usuário jsilva do grupo Contabilidade e adicioná-lo ao grupo Marketing. Com isso o jsilva deixa de ter as permissões atribuídas ao grupo Contabilidade e passa a ter as mesmas permissões que tem o grupo Marketing. Este exemplo simples já consegue demonstrar o quanto a utilização de grupos pode facilitar a atribuição de permissões.

Vamos analisar mais um exemplo. Suponha que exista um sistema chamado SEAT, para o qual somente um número restrito de usuários deve ter acesso, sendo que são usuários de diferentes seções. A maneira mais simples de definir as permissões de acesso ao sistema SEAT é criar um grupo chamado SEAT e dar permissões para esse grupo. Assim cada usuário que precisar acessar o sistema SEAT, deve ser incluído no grupo SEAT. Quando o usuário não deve mais ter acesso ao sistema SEAT, basta removê-lo do grupo SEAT. Simples, fácil e muito prático.

Na Figura A.15 apresento uma ilustração para o conceito de Grupo de usuários. O Grupo Contabilidade possui direito para um recurso compartilhado, o qual pode ser acessado através da rede. Todos os usuários que pertencem ao grupo contabilidade, também possuem permissão para o recurso compartilhado, uma vez que os usuários de um grupo, herdam as permissões do grupo.

Curso Completo de Windows 7 - Júlio Battisti

Figura A.15 - O Usuário herda as permissões do grupo.

Quando estiver trabalhando com grupos de usuários, considere os fatos a seguir:

  • Grupos são uma coleção de contas de usuários.
  • Os membros de um grupo, herdam as permissões atribuídas ao grupo.
  • Os usuários podem ser membros de vários grupos
  • Grupos podem ser membros de outros grupos.
  • Contas de computadores podem ser membros de um grupo (novidade a partir do Windows Server 2003).

Unidades Organizacionais:

O conceito de Unidade organizacional foi introduzido no Windows 2000 Server, juntamente com o Active Directory e veio para solucionar um problema sério de Administração existente no Windows NT Server 4.0.

Com o NT Server 4.0, não havia como atribuir permissões de acesso apenas a uma parte do domínio. Ou você atribuía permissões de Administrador no domínio inteiro ou não tinha como atribuir permissões de administrador para um usuário. Imagine uma empresa que tem uma rede, com filiais em todos os estados brasileiros. Por questões de simplicidade vamos supor que a rede é composta de seis domínios, sendo que em cada domínio estão as filiais de 4 ou mais estados. Vamos supor que um dos domínios seja composto pelas redes das filiais do RS, SC, PR e SP. Com o NT Server 4.0, você não teria como definir que um usuário tivesse permissões de Administrador somente nos servidores da filial do RS. Uma vez que você atribuía permissões de Administrador, o usuário teria estas permissões em todos os recursos do domínio. No nosso exemplo, o usuário seria Administrador nos servidores das filiais do RS, SC, PR e SP, ou seja, em todos os servidores do domínio. Esta situação gerava inconvenientes (e noites de sono perdidas) muito sérios. Era comum a situação onde um domínio tinha 10 ou mais contas de usuários com permissão de Administrador. Ora, eram 10 ou mais contas com permissões total em todos os servidores e recursos do domínio. Nada bom.

Com a disponibilidade de Unidades Organizacionais, a partir do Windows 2000 Server, este problema foi minimizado. Agora você pode criar, dentro do domínio, várias Unidades organizacionais. Em seguida você desloca para dentro de cada unidade organizacional, as contas de usuários e computadores, de acordo com critérios geográficos ou funcionais. Em seguida você pode delegar tarefas administrativas a nível de Unidade organizacional (OU – Organizational Unit).

Vamos considerar o exemplo anterior, onde tínhamos um domínio formado pelas redes das filiais do RS, SC, PR e SP. Neste exemplo, o Administrador do domínio poderia criar quatro unidades organizacionais: RS, SC, PR e SP. Em seguida ele move as contas de usuários e computadores e contas de grupos para as respectivas OUs. O último passo é atribuir permissões de administração em cada OU. Por exemplo, para o Administrador da filial do RS, seriam delegadas permissões de administração na OU RS, para o Administrador da filial de SC, seriam delegadas permissões de administração na OU SC e assim por diante. O diagrama da Figura A.16 ilustra a divisão de um domínio em OUs.

Curso Completo de Windows 7 - Júlio Battisti

Figura A.16 - Divisão de um domínio em OUs.

No diagrama está representada a divisão do domínio regiao-01.abc.com.br em OUs. Dentro de uma OU é possível criar outras OUs. Por exemplo, dentro da Unidade Organizacional RS, o administrador poderia criar outras unidades organizacionais, tais como: Usuários,Grupos e Computadores. Em seguida, todas as contas de usuários da filial do RS, seriam deslocadas para a OU Usuários, dentro da OU RS; todas as contas dos computadores da filial do RS seriam deslocadas para a OU Computadores, dentro da OU RS e assim por diante.

Observem que, basicamente, a utilização de OUs facilita a descentralização das tarefas administrativas, através da delegação de tarefas para porções específicas de um domínio: as OUs. A utilização de OUs também desempenha um papel importante no gerenciamento das políticas de segurança, através do uso de Group Polices Objects (GPOs).

Relações de Confiança e Florestas:

É através do uso de relações de confiança entre domínios, que é possível que um usuário de um domínio possa fazer o logon com sua conta de usuário e senha, mesmo utilizando um computador que faça parte de um outro domínio. Por exemplo, o usuário jsilva está cadastrado no domínio A e viaja para a filial da empresa, a qual pertence ao domínio B. O usuário jsilva está utilizando um computador que faz parte do domínio B. Durante o processo de logon ele informa o seu nome de usuário, senha e seleciona o domínio no qual ele quer fazer o logon (no exemplo o domínio A) e consegue fazer o logon normalmente.

Como foi possível ao domínio B (mais especificamente a um DC do domínio B), verificar as credenciais do usuário do domínio A (logon e senha) e permitir o logon? Isso foi possível graças ao mecanismo de relações de confiança existente no Windows Server 2003, o qual é muito semelhante ao que existe no Windows 2000 Server, porém completamente diferente do que acontecia no Windows NT Server 4.0. Neste item apresentarei em mais detalhes, o mecanismo de relações de confiança entre domínios no Windows Server 2003.

Como eram as relações de confiança na época do NT Server 4.0?

As relações de confiança no NT Server 4.0 são definidas por três características principais:

  • São unilaterais: Se o domínio A confia no domínio B, isso não significa que o domínio B confia no domínio A automaticamente. Para que haja essa confiança recíproca é preciso criar duas relações de confiança: uma para definir que o domínio A confia no domínio B e outra para definir que o domínio B confia no domínio A. A Figura A.17, da ajuda do Windows Server 2003, ilustra este conceito:

Neste exemplo da Figura A.17, o Dom A confia no Dom B. Isso significa que as contas do Dom B são “visíveis” no Dom A, ou seja, é possível atribuir permissões de acesso para as contas do Dom B, em recursos do Dom A. O contrário não é verdadeiro, ou seja, não é possível atribuir permissões de acesso para as contas do Dom A, em recursos do domínio B. Para que isso fosse possível teria que ser criada mais uma relação de confiança, agora com o Dom B “confiando” nas contas do Dom A. Isso tudo acontece porque as relações de confiança no NT Server 4.0 são unilaterais.

Curso Completo de Windows 7 - Júlio Battisti

Figura A.17 - Relação de confiança unilateral.

  • Não são transitivas: Se o Dom A confia no Dom B e o Dom B confia no domínio C, isso não implica que o Dom A também confia no Dom C. Para que o Dom A confie no Dom C, uma relação de confiança entre os dois domínios tem que ser manualmente criada pelo Administrador.
  • Devem ser criadas manualmente pelos Administradores: As relações de confiança não são criadas automaticamente e devem ser criadas pelos Administradores de cada domínio. O processo é bem trabalhoso. Para que o Dom A possa confiar no Dom B, primeiro o Administrador do Dom B tem que fazer uma configuração “dizendo” que ele aceita que o Dom A confie no Dom B. O próximo passo é o Administrador do Dom A estabelecer a relação de confiança com o Dom B. Para que o Dom B também possa confiar no Dom A, todo o processo (só que na direção inversa) tem que ser repetido.

Para uma rede com 10 domínios, para que todos possam confiar em todos os outros, são necessárias 90 relações de confiança. O número de relações de confiança, com base no número de domínios, pode ser calculada pela fórmula a seguir:

n*(n-1)

onde n é o número de domínios.

Para 10 domínios teremos:

10*(10-1)

10*9

90

A Figura A.18, obtida do Resource Kit do Windows 2000 Server, mostra como seria uma árvore de domínios no NT Server 4.0, onde foram implementadas relações de confianças entre todos os domínios:

Curso Completo de Windows 7 - Júlio Battisti

Figura A.18 - Relações de confiança unidirecionais, não transitivas do NT Server 4.0.

E como são as relações de confiança no Windows Server 2003?

No Windows Server 2003 (bem como no Windows 2000 Server) as relações de confiança são criadas automaticamente entre os domínios de uma árvore de domínios. As relações são bidirecionais, ou seja, se o Dom A confia no Dom A, isso significa que o Dom B também confia no Dom A. As relações de confiança são transitivas, ou seja se o Dom A confia no Dom B, o qual confia no Dom C, então o dom A também confia no Dom C e vice-versa.  A Figura A.19 ilustra as relações de confiança no Windows Server 2003.

Curso Completo de Windows 7 - Júlio Battisti

Figura A.19 - Relações de confiança Bidirecionais e transitivas do Windows Server 2003.

Servidores de Catálogo Global (Global Catalogs):

Pelo que foi visto até aqui, é possível perceber que o Active Directory no Windows Server 2003 é bastante flexível, permitindo que usuários de um domínio acessem recursos em servidores de outro domínio ou até mesmo outra floresta, sem ter que entrar novamente com o seu login e senha. Para que isso seja possível, o Active Directory mantém uma base com algumas informações sobre objetos de todos os domínios. Esta base de informações é mantidas em Controladores de Domínio (DCs), configurados para atuar como Servidores de Catálogo Global (Global Catalog Servers). Nem todo DC é um Global Catalog, mas para ser Global Catalog tem que ser um DC, não pode ser um Member Server. Neste item vou apresentar informações detalhadas sobre os Servidores de Catálogo Global.

Um Servidor de Catálogo Global armazena uma cópia de todos os objetos do Active Directory, de todos os domínios em uma ou mais árvores de domínios de uma floresta. No Servidor de Catálogo Global fica uma cópia completa de todos os objetos do próprio domínio do servidor e uma cópia parcial de todos os objetos dos demais domínios. Esta estrutura é indicada na Figura A.20:

Curso Completo de Windows 7 - Júlio Battisti

Figura A.20 - Informações armazenadas em um Servidor de Catálogo Global.

Observe que um servidor que é DC mas não está configurado como Servidor de Catálogo Global, contém uma cópia completa de todos os objetos do seu domínio, mas não tem cópia de objetos de outros domínios. Já um DC habilitado como Servidor de Catálogo Global, tem, além da cópia completa dos objetos do seu próprio domínio, cópias parciais de todos os objetos dos demais domínios. Quando se fala em cópias parciais, significa que o Servidor de Catálogo Global não mantém cópia de todos os objetos, mas não de todos os atributos de um objeto de outro domínio. Por exemplo, o Servidor de Catálogo Global tem cópia de todos os usuários de outros domínios, mas para cada usuário de outro domínio, tem apenas alguns atributos (nome, senha, etc) são armazenados no Catálogo Global e não todos os atributos.

Os atributos de cada objeto que são copiados para o Catálogo Global são aqueles atributos mais utilizados para a realização de pesquisas no Active Directory. Por exemplo nome do usuário, nome de compartilhamento e tipo da impressora e assim por diante. A definição de quais atributos são armazenados no Catálogo Global e quais não são é feita no Schema. Conforme mostrarei mais adiante o Schema é como se fosse (na prática eu considero que é) a definição da estrutura do banco de dados do Active Directory. Falarei mais sobre Schema no próximo item.

Ao armazenar os atributos mais utilizados no Catálogo Global, o Windows Server 2003 aumenta o desempenho das pesquisa no Active Directory. Se não houvesse um Catálogo Global, as pesquisas teriam que percorrer todo o caminho da rede, da origem, até encontrar um servidor (um DC) no domínio de destino e os resultados percorrer o caminho inverso. Em redes maiores, com mais domínios, isso representaria um sério problema de desempenho, além de gerar um excessivo tráfego de rede. Evidentemente que a manutenção do Catálogo Global atualizado em todos os Servidor de Catálogo Global, gera tráfego de replicação, mas o resultado final é um ganho de performance e redução do tráfego de rede, em comparação se não existisse o Catálogo Global.

Quando um domínio é criado, com a instalação do primeiro DC do domínio, este DC é automaticamente configurado com Servidor de Catálogo Global. Os próximos DCs do domínio não serão automaticamente configurados como Servidor de Catálogo Global, mas você poderá configurá-los posteriormente.

Principais funções desempenhadas por um Servidor de Catálogo Global:

Um Servidor de Catálogo Global desempenha importantes funções, dentre as quais podemos destacar as indicadas a seguir:

  • Pesquisa de objetos no Active Directory: Com o uso de Servidor de Catálogo Global, o usuário é capaz de pesquisar objetos em todos os domínios de uma floresta. A velocidade das pesquisas melhora bastante, uma vez que a pesquisa é feita no Servidor de Catálogo Global mais próximo do usuário, no seu próprio domínio e não no servidor de destino ou no caso de uma pesquisa genérica (por exemplo, pesquisar silva no campo Sobrenome dos objetos usuários) em todos os servidores de todos os domínios.
  • Fornece autenticação para nomes de usuários de outros domínios: O Catálogo Global é utilizado para a resolução de nomes de usuários (ou de outros objetos do Active Directory), quando o DC que autenticou o usuário não tem informações sobre a referida conta. Por exemplo, se o usuário jsilva do domínio vendas.abc.com precisa fazer o logon como jsilva@vendas.abc.com em um computador pertencente ao domínio prod.abc.com, o DC do domínio prod.abc.com não será capaz de localizar o usuário jsilva@vendas.abc.com (pois o DC do domínio prod.abc.com tem informações somente sobre os usuários do seu próprio domínio e não dos demais domínios. Estas informações estão nos Servidores de Catálogo Global). O DC no domínio prod.abc.com irá contatar um Servidor de Catálogo Global para poder completar o processo de logon do usuário jsilva@abc.com, com sucesso.
  • Disponibiliza informações sobre os membros dos grupos universais, em um ambiente com múltiplos domínios: As informações sobre os membros dos grupos locais são armazenadas apenas no domínio onde o grupo é criado. Por isso que um grupo local somente pode receber permissões de acesso aos recursos do domínio onde o grupo foi criado. Já as informações sobre os membros dos grupos Universais são armazenadas somente nos Servidor de Catálogo Global. Por isso que recomenda-se que sejam inseridos como membros dos grupos Universais, apenas outros grupos e não usuários individualmente. Se forem inseridos usuários individualmente, cada vez que um usuário for adicionado ou excluído de um grupo universal, todas as informações do grupo Universal serão replicadas entre todos os Servidor de Catálogo Global da floresta. Por exemplo, quando um usuário que pertence a um grupo universal faz o logon em um domínio configurado para o modo Windows 2000 Nativo ou Windows Server 2003, o Catálogo Global fornece informações sobre a quais grupos universais a conta do usuário pertence.

Se não estiver disponível um Servidor de Catálogo Global, o computador no qual o usuário faz o logon irá utilizar as informações armazenadas no cache do computador, caso o usuário já tenha feito um logon anterior neste computador. Se for o primeiro logon do usuário neste computador e não estiver disponível um Servidor de Catálogo Global, o usuário não conseguirá fazer o logon no domínio. Ele conseguirá fazer o logon apenas localmente no computador, usando uma das contas locais ao invés de uma conta do domínio.

Existe uma exceção à esta regra, que é quando a conta do usuário pertence ao grupo Administradores do Domínio (Domain Admins). Neste caso, o usuário conseguirá fazer o logon, mesmo que um Servidor de Catálogo Global não esteja disponível e mesmo que seja o seu primeiro logon no computador.

Nota: Quando a rede é formada por um único domínio, não é necessário que os usuário obtenham informações sobre os grupos Universais durante o logon, a partir de um Servidor de Catálogo Global. Isso acontece porque quando existe um único domínio, o Active Directory é capaz de detectar que não existem outros domínios e que não é necessária uma pesquisa no Catálogo Global (uma vez que a pesquisa pode ser feita no próprio DC que está autenticando o usuário)

  • Validação de referências a objetos em uma floresta: O Catálogo Global é utilizado pelos DCs para validar referências a objetos de outros domínios de uma floresta. Quando um DC trata com um objeto onde um dos seus atributos contém referências a um objeto em outro domínio, esta referência é validada pelo Catálogo Global. Mais uma vez é importante salientar o papel dos Servidores de Catálogo Global em melhorar o desempenho do Active Directory. Nesta situação, se não existisse o Catálogo Global, a validação da referência ao objeto teria que ser feito por um DC do domínio do objeto referenciado. Só nestas situações (muito comuns na utilização diária da rede), imagine quanto tráfego de validação seria gerado através dos links de WAN da rede. Sem contar também a demora adicional até que a validação fosse feita através da rede, no domínio de destino e a resposta retornasse.

Replicação de informações entre os Servidor de Catálogo Global:

Conforme descrito anteriormente, o Catálogo Global contém informações completas sobre todos os objetos do seu domínio e informações parciais sobre todos os objetos dos demais domínios. Alterações são efetuadas diariamente em diversos objetos da rede. Por exemplo, usuários são renomeados, novos grupos criados, usuários são adicionados ou retirados de grupos e assim por diante. Todas estas alterações tem que ser replicadas entro os vários Servidores de Catálogo Global de todos os domínios, para que estes estejam sempre atualizados. A estrutura de replicação do Catálogo Global é criada e gerenciada automaticamente por um processo do Active Directory, conhecido como Knowledge Consistency Checker (KCC). O KCC é responsável por determinar a melhor “topologia” de replicação do Global Catalog, de tal maneira que a rede não seja sobrecarregada com tráfego excessivo devido à replicação.

Algumas considerações devem ser feitas em relação a replicação dos grupos Universais. Os grupos Universais e informações sobre os seus membros estão contidas somente no Catálogo Global, conforme descrito anteriormente. Grupos Globais e Locais são também listados no Catálogo Global, porém no Catálogo Global não são armazenadas informações sobre os membros dos grupos Globais e Locais. Com isso o tamanho do Catálogo Global é reduzido, bem como o tráfego de replicação associado com a atualização do Catálogo Global. Para recursos e objetos que sofrerão alterações constantes, é aconselhável que você utilize grupos Globais e Locais para a definição de permissões, pois com isso você reduzirá o tráfego de replicação, comparativamente se você utilizasse grupos Universais. Como as informações sobre os membros dos grupos Universais são armazenadas no Catálogo Global, sempre que houver uma alteração na lista de membros de um grupo Universal, será necessário replicar esta informação para todos os Servidores de Catálogo Global de todos os domínios. Isso justifica a recomendação feita anteriormente, de somente adicionar grupos como membros de grupos Universais e não usuários.

Além da replicação do Catálogo Global também temos a replicação do Active Directory, onde alterações feitas em um DC, devem ser repassadas para todos os demais DCs do domínio. Porém antes de tratar sobre Replicação do Active Directory, você deve entender o conceito de Site. Este será o assunto do próximo item.

Sites, replicação do Active Directory e estrutura física da rede:

Introdução e definição de sites:

Florestas, árvores, domínios e unidades organizacionais representam a divisão lógica do Active Directory, normalmente definida com base em critérios administrativos, ou seja, visando facilitar a administração dos recursos e usuários da rede. O Active Directory tem também um elemento conhecido como site, o qual é utilizado para representar a divisão física da rede e é muito importante para a implementação de um sistema de replicação otimizado das informações do Active Directory entre os diversos DCs de um domínio.

Um site no Active Directory é utilizado para representar a estrutura física da rede da empresa. As informações sobre a topologia da rede, contidas nos objetos site e link entre sites, são utilizadas pelo Active Directory para a criação de configurações de replicação otimizadas, sempre procurando reduzir o máximo possível o tráfego através dos links de WAN.

Nota: A criação e configuração de sites e dos links entre sites é feita utilizando o console Active Directory Sites and Services, o qual é descrito em detalhes no Capítulo 8 do seguinte livro, de minha autoria: Windows Server 2003 – Curso Completo, 1568 páginas. Para todos os detalhes sobre o livro acesse:

https://juliobattisti.com.br/loja/detalheproduto.asp?CodigoLivro=CWIN000019  

Um site normalmente é definido com uma ou mais redes conectadas por um caminho de alta velocidade. O termo alta velocidade é um pouco vago. Na prática, um site está intimamente ligado a uma localização física, ou seja, uma ou mais redes locais no mesmo prédio ou em prédios de um Campus, interligadas através de um barramento de 10 MBps, 100 MBps (mais comum hoje em dia) ou de 1GBps. Ou seja, um site é definido por um endereço IP e uma máscara de sub-rede, isto é: por uma rede local. No início deste Anexo você aprendeu que uma rede é definida pelo número IP da rede (por exemplo 10.10.20.0) e por uma máscara de sub-rede (por exemplo 255.255.255.0). Um site é formado por um ou mais conjuntos de número de rede/máscara de sub-rede. Em outras palavras, um site é um conjunto de uma ou mais redes locais conectadas por um barramento de alta velocidade.

Para que o Active Directory utiliza sites??

A utilização de sites e links entre sites facilita a implementação de várias atividades no Active Directory, dentre as quais destaco as listadas a seguir:

  • Replicação: Esta sem dúvidas é a principal utilização dos sites. O Active Directory procura equilibrar a necessidade de manter os dados atualizados em todos os DCs, com a necessidade de otimizar o volume de tráfego nos links de WAN, gerado devido a replicação. A replicação entre os DCs de um mesmo site ocorre mais frequentemente do que a replicação entre DCs de sites diferentes. Isso faz sentido, pois os DCs de um mesmo site estão dentro da mesma rede local, conectados por um barramento de alta velocidade. Por isso é possível fazer a replicação mais frequentemente. Já os DCs de sites diferentes estão conectados através de links de WAN de baixa velocidade (quando comparada com a velocidade do barramento de uma rede local), por isso a replicação deve ocorrer em intervalos maiores, para evitar um excesso de tráfego e um sobrecarga nos links de WAN da rede. Você também pode atribuir diferentes “custos” para os links entre sites, de tal maneira que a replicação através de links de baixa velocidade, ocorre em intervalos maiores do que a replicação através de links de maior velocidade. Todas estas possibilidades de configuração são sempre pensando na otimização do tráfego de WAN gerado pela replicação.
  • Autenticação: A informação sobre sites auxilia o Active Directory a fazer a autenticação dos usuários de uma maneira mais rápida e eficiente. Quando o usuário faz o logon no domínio, o Active Directory primeiro tenta localizar um DC dentro do site definido para a rede do usuário. Com isso, se houver um DC no site do usuário, na maioria das vezes, este DC será utilizado para autenticar o logon do usuário no domínio, evitando que tráfego de autenticação seja gerado, desnecessariamente, no link de WAN.

Definição de sites utilizando sub-redes:

Conforme descrito anteriormente, para o Active Directory, um site é um grupo de computadores “bem conectados”, onde bem conectado significa conectado através de um barramento de alta velocidade, tal como uma Rede Local com barramento de 100 Mbps. Normalmente um site é associado a uma rede local de um escritório da empresa. Um site é definido por uma ou mais sub-redes. Uma rede é definida pelo endereço de rede mais a máscara de sub-rede, conforme descrito no início deste anexo. A figura A.21 ilustra a utilização de uma sub-rede para a definição de um site:

Curso Completo de Windows 7 - Júlio Battisti

Figura A.21 - Definição de um site.

Nota: 172.16.32.0/19, significa 19 bits para a máscara de sub-rede, é o mesmo que escrever 172.16.32.0/255.255.224.0

No Active Directory você pode criar objetos do tipo sub-rede e do tipo site, utilizando o console Active Directory Sites and Services. Após criar objetos do tipo sub-rede, você cria um objeto do tipo site, associando uma ou mais sub-redes com o objeto site que está sendo criado. 

A Relação entre Sites e Domínios:

Conforme descrevi anteriormente, o domínio representa uma das divisões lógicas da rede e do Active Directory, já sites representam a estrutura física da rede. Com isso é possível ter computadores de diferentes domínios dentro do mesmo site, ou diferentes sites dentro do mesmo domínio e outras combinações possíveis.

Repetindo para fixar bem: “No Active Directory, sites estão relacionados com a estrutura física da rede, já domínios estão relacionados com a estrutura lógica da rede”. Esta separação traz alguns benefícios, dentre os quais destaco os indicados a seguir:

  • É possível manter o design da estrutura lógica, independente da estrutura física. Ou seja, alterações em uma das estruturas não irão implicar, necessariamente, em alterações na outra estrutura. Com isso você pode ter computadores de mais de um domínio no mesmo site ou mais de um site no mesmo domínio e assim por diante.
  • A nomeação dos domínios é absolutamente independente da estrutura física/geográfica da rede, o que facilita alterações na estrutura física, sem que isso implique em um reestruturação lógica de toda a rede.
  • Você pode instalar DCs de múltiplos domínios no mesmo site ou você pode colocar DCs do mesmo domínio em diferentes sites ou uma combinação destas duas configurações, conforme ilustrado na Figura A.22:

Curso Completo de Windows 7 - Júlio Battisti

Figura A.22 - Flexibilidade na definição de sites e domínios.

Replicação no Active Directory:

A base de dados do Active Directory, com informações completas sobre todos os objetos do Active Directory é armazenada nos DCs do domínio. Alterações podem ser efetuadas em qualquer DC. Estas alterações devem ser replicadas para todos os demais DCs do domínio, de tal maneira que todos os DCs estejam sincronizados e com uma cópia idêntica da base de dados do Active Directory. Este processo ocorre o tempo todo, pois alterações no Active Directory são feitas diariamente. Claro que existe um tempo entre o momento em que uma alteração é feita em um DC, até que esta alteração tenha sido replicada para todos os demais DCs do domínio. A replicação é um processo contínuo.

O Active Directory procura determinar, automaticamente, qual a melhor configuração de replicação, procurando obter o menor tempo possível para atualização dos DCs do domínio, mas balanceando com o volume de tráfego gerado na rede, de tal maneira que o tráfego gerado pela replicação não venha a sobrecarregar os links de WAN.

As configurações de replicação do Active Directory são feitas, automaticamente, pelo processo conhecido como Knowledge Consistency Checker (KCC), que é um processo que roda em todos os DCs. O KCC automaticamente identifica as configurações de replicação mais eficientes, com base nas configurações de sites e links do Active Directory (estrutura física da rede). Por exemplo, a replicação entre DCs dentro do mesmo site são feitas mais frequentemente do que entre DCs de sites diferentes. O KCC regularmente recalcula a topologia de replicação para ajustar o processo para quaisquer alterações que tenham ocorrido na estrutura física da rede, como a criação de novos sites ou a inserção de novas sub-redes em um site existente.

Schema do Active Directory:

A definição de todos os objetos do Active Directory e demais informações está contida no que é conhecido como Schema do Active Directory. O Active Directory utiliza um modelo de banco de dados hierárquico, diferente do Modelo Relacional de Dados com o qual estamos mais habituados. Mas, me permitam esta analogia, o Schema é como se fosse (na verdade é) a definição da estrutura do banco de dados do Active Directory. Por exemplo, a definição do objeto usuário, quais atributos tem este objeto, o tipo de cada atributo e demais informações sobre o objeto usuário, estão todas contidas no Schema. A definição de cada objeto, de cada atributo, está contida no Schema.

O Schema contém a definição para todos os objetos do Active Directory. Quando você cria um novo objeto, as informações fornecidas são validadas com base nas definições contidas no Schema, antes que o objeto seja salvo na base de dados do Active Directory. Por exemplo, se você preencheu um atributo do tipo número, com valores de texto, o Active Directory não irá gravar o objeto no Active Directory e uma mensagem de erro será exibida.

O Schema é feito de objetos, classes e atributos. O Schema definido por padrão com o Active Directory, contém um grande número de classes e atributos, os quais atendem as necessidades da maioria das empresas. Porém o Schema pode ser modificado, o Administrador pode modificar as classes existentes ou adicionar novas classes ou atributos. Qualquer alteração no Schema deve ser cuidadosamente planejada, pois alterações feitas no Schema afetam toda a árvore de domínios. Todos os domínios de uma árvore tem que utilizar o mesmo Schema, ou seja, não podem ser utilizados diferentes esquemas para os diferentes domínios de uma árvore de domínios.

Como os objetos do Active Directory são definidos no Schema:

No Schema, uma classe de objetos representa uma categoria de objetos do Active Directory, como por exemplo contas de usuários, contas de computadores, impressoras ou pastas compartilhadas publicadas no Active Directory e assim por diante. Na definição de cada classe de objetos do Active Directory, está contida uma lista de atributos que podem ser utilizados para descrever um objeto da referida classe. Por exemplo, um objeto usuário contém atributos de nome, senha, validade da conta, descrição, etc. Quando um novo usuário é criado no Active Directory, o usuário torna-se uma nova instância da classe User do Schema e as informações que você digita sobre o usuário, tornam-se instâncias dos atributos definidos na classe user.

Como o Schema é armazenado no Active Directory:

Cada floresta pode conter um único Schema, ou seja, o Schema tem que ser único ao longo de todos os domínios de uma floresta. O Schema é armazenado nas partições de Schema do Active Directory. A partição de Schema do Active Directory, bem como a partição de definição do Active Directory, são replicadas para todos os DCs da floresta. Porém um único DC controla a estrutura do Schema,  DC este conhecido como Schema Master. Ou seja, somente no DC configurado como Schema Master é que o Administrador poderá fazer alterações no Schema.

Cache do Schema:

Cada DC mantém uma cópia do Schema na memória do servidor (bem como uma cópia em disco), para melhorar a performance das operações relacionadas ao Schema, tais como validação de novos objetos. A versão armazenada no Cache do servidor é automaticamente atualizada (em intervalos de tempos definidos) cada vez que o Schema é atualizado (o que não ocorre como frequência, na verdade é muito raro fazer alterações no Schema).

Níveis de Funcionalidade de um Domínio:

É comum a rede da empresa “conviver” com diferentes versões do Windows. Isso aconteceu na migração do NT Server 4.0 para o Windows 2000 Server, onde durante um bom tempo ainda existiam (na prática sabemos que ainda existem) servidores com o NT Server 4.0 em utilização na rede.

O Windows Server 2003 (a exemplo do que acontecia com o Windows 2000 Server), tem diferentes níveis de funcionalidade, com base nos tipos de DCs instalados na rede. Neste tópico vou descrever os níveis de funcionalidade disponíveis e as diferentes funcionalidades que estão disponíveis em cada nível de funcionalidade.

Com o Windows Server 2003 foi introduzido o nível de funcionalidade da floresta, o que não existia com o Windows 2000 Server.

O nível de funcionalidade do domínio determina quais características estão ou não disponíveis.

Existem quatro níveis de funcionalidade no Windows Server 2003: Windows 2000 mixed, Windows 2000 native, Windows Server 2003 interim e Windows Server 2003.

Por padrão é selecionado o nível de funcionalidade Windows 2000 mixed. Muitos dos recursos mais avançados, tais como grupos Universais, somente estão disponíveis nos demais níveis de funcionalidade: Windows 2000 native, Windows Server 2003 interim ou Windows Server 2003.

O nível de funcionalidade da floresta é uma novidade do Windows Server 2003. Existem três níveis de funcionalidade da floresta disponíveis: Windows 2000, Windows Server 2003 interim, and Windows Server 2003. Por padrão é selecionado o nível Windows 2000. Muitas das novidades do Windows Server 2003 em relação ao Active Directory somente estão disponíveis nos níveis mais avançados: Windows Server 2003 interim ou Windows Server 2003.

Para que o nível de funcionalidade da floresta seja configurado para Windows Server 2003, todos os DCs de todos os domínios devem estar com o Windows Server 2003 instalado. Somente neste nível é que estarão disponíveis todos os recursos do Active Directory, incluindo a maioria das novidades introduzidas com o Windows Server 2003.

O que define se é possível ou não utilizar um determinado nível de funcionalidade é a existência ou não de DCs com versões anteriores do Windows, tais como o Windows 2000 Server e o Windows NT Server 4.0.

A seguir descrevo quais as versões do Windows que podem ser utilizadas nos DCs, para cada um dos modos de funcionalidade de domínio:

  • Windows 2000 mixed: Suporta DCs com o Windows NT Server 4.0, Windows 2000 Server ou Windows Server 2003. Neste nível de funcionalidade não é possível a utilização de grupos Universais.
  • Windows 2000 native: Suporta DCs com o Windows 2000 Server ou com o Windows 2003 Server. Neste nível de funcionalidade são suportados grupos Universais.
  • Windows Server 2003 interim: Suporta DCs com o NT Server 4.0 ou com o Windows Server 2003. Este nível de funcionalidade é utilizado quando você está em processo de migração de uma rede baseada no Windows NT Server 4.0 para o Windows Server 2003.
  • Windows Server 2003: Somente DCs com o Windows Server 2003. Este é o nível onde estão disponíveis todos os recursos e novidades do Active Directory.

Nota: Quando você altera de um modo de funcionalidade para o outro, não será mais possível criar DCs com versões não suportadas do Windows. Por exemplo, quando você passa do modo Windows 2000 mixed para o modo Windows 2000 Native, não será mais possível inserir DCs com o NT Server 4.0 e nem será voltar para o nível de funcionalidade anterior.


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 »

Quer Aprender VBA no Excel, Sem Dificuldades, com Exemplos
Práticos Passo a Passo e com Explicações Detalhadas?

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

Junto com o livro você Recebe 11 Bônus Incluindo 50 horas de Vídeo Aulas.

Mesmo que Você não Saiba Nada de Programação VBA ou já Tenha Tentado
Aprender VBA e Desistiu ou Achou Difícil, com Este Livro EU GARANTO que Você Aprenderá, SEM DIFICULDADES. APRENDIZADO GARANTIDO.

Clique Aqui Para Todos os Detalhes sobre Esta Oferta

- É com alegria que Comunico o lançamento do meu 42º Livro.

 

- Perfeito para Iniciantes em Programação VBA.

 

- Abordo desde o Básico até Comandos Avançados.

 

- Códigos detalhadamente explicados, linha por linha.

 

- Criação de Funções e Procedimentos com VBA.

 

- O Modelo de Objetos do Excel - Exemplos Práticos.

 

- Criação de Formulários - UseForms.

 

- Criação de um Sistema de Cadastro Completo, com Foto.

 

- Como trabalhar com Tabelas Dinâmicas na Programação VBA.

 

- Como trabalhar com Gráficos na Programação VBA.

 

- Rotina que Escreve um número por Extenso usando VBA.

 

- E muito, muito mais mesmo...

 

- Junto com o livro você recebe 50 horas de Vídeo Aulas sobre Macros, Programação VBA, Fórmulas e Funções Avançadas, Dashboards e Muito mais.

 

[Bônus]: 60 horas de Vídeo Aulas sobre Macros, Programação VBA, Fórmulas e Funções Avançadas no Excel, Recursos Avançados, Dashboards e Muito mais.

 

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

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

A BÍBLIA DA
PROGRAMAÇÃO
VBA NO EXCEL

 

Livros Que O Júlio Battisti Indica:

Todos com excelentes bônus e pode parcelar no cartão!

Windows Server 2012 R2 e Active Directory

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

 

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

 

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

Universidade Redes

Curso Online: Universidade de Redes

 

Autor: André Stato | Carga horária: 170h

 

Curso Online: Universidade de Redes

A Bíblia do Excel

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

 

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

 

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

Macros e VBA no Access 2010

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

 

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

 

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

Macros e VBA no Excel 2010

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

 

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

 

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

Universidade Java

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

 

Autor: Neri Zeritzke | Duração: 250h | Aulas: 1922

 

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

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