Author: Diogo Molina de Sa

Erro ao concluir backup database Exchange Server 2010

 

Introdução

O backup das database do Exchange Server 2010 apresenta falhas durante a operação e aborta a operação de backup com falhas. Esses erros podem estar relacionados ao VSS, tecnologia utilizada pelo Exchange Server 2010 para realização do backup das databases.

 

Problema

Ao executar o backup das databases do Exchange Server 2010 com o Windows Server Backup ou ferramentas de terceiro, apresenta falhas e o backup é abortado.

 

Solução

O Exchange Server 2010 trabalha com a tecnologia de VSS para executar o backup das databases.  Com o VSS o backup não é realizado direto no banco de dados do Exchange e sim em uma copia que é criada pelo VSS, como o VSS cria essa copia, é necessário ter espaço disponível para essa copia, dentro das configurações de cada unidade, podemos selecionar esse tamanho ou deixar a opção de “no limit”.

Untitled

Temos que selecionar o tamanho que o VSS irá utilizar para a copia ou deixar com a opção de “no limit”, porém quando deixamos a opção de “no limit” temos que ficar atentos ao espaço em disco.

 

http://technet.microsoft.com/en-us/library/cc785914(v=ws.10).aspx

 

Abs!

Diogo Molina

Share

Post to Twitter

Credencias de domínio armazenadas em cache local

 

Em um ambiente de domínio do Active Directory, quem faz a autenticação dos usuários são os Controladores de domínio.

Porém existem muitas situações em que o usuário ou trabalha com seu notebook pessoal ou utiliza o notebook da empresa para executar trabalhos em outros lugares fora da empresa.

Vamos pegar um exemplo, o usuário “fulano” utiliza seu notebook pessoal para o trabalho, seu notebook está no domínio da empresa que ele trabalha e para ele conseguir se logar e acessar os recursos da rede empresarial ele utiliza o usuário “fulano”, porém nos finais de semana ele utiliza seu notebook para acessar noticias, jogar, etc… . Mais como ele consegue logar no seu notebook sendo que quem faz a autenticação é o Controlador de domínio que está na empresa?

Nesse caso é utilizado as credencias que são armazenadas em cache local, quando um usuário faz a autenticação em um Controlador de domínio essa credencias é armazenada em cache, para que esse usuário consiga fazer o logon mesmo se o Controlador de domínio estiver indisponível. Importante, o usuário consegue fazer o logon, porém se tiver tentando acessar algum recurso da rede a partir da sua casa, não será possível (a menos que tenha uma VPN ou Direct Access configurado, etc) pois o Controlador de domínio precisa autenticar e enviar o ticket kerberos para o usuário conseguir acessar os recursos da rede, ou seja a credencial em cache só irá permitir com que o usuário consiga fazer o logon mesmo quando o Controlador de domínio estiver inacessível.

Quem controla essas credencias em cache é a seguinte chave de registro:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\ 

   ValueName: CachedLogonsCount
   Data Type: REG_SZ
   Values: 0 - 50
			

Onde podemos definir um valor de 0 – 50, onde o zero significa que nenhuma credencial será armazenada em cache e 50 permite que 50 contas sejam armazenadas em cache.

Também conseguimos controlar esse armazenamento das credencias em cache através de GPO:

image

 

Link de referencia: http://support.microsoft.com/kb/172931/en-us

 

Abs!

Diogo Molina

Share

Post to Twitter

Windows Server 2012 – Storage Space

 

O Windows Server 2012 traz um novo recurso para ajudar nos profissionais de TI com o gerenciamento de armazenamento, esse recurso é o “Storage Space”.

Com esse recurso conseguimos agrupar vários discos em um Storage Pool e apresentar para o S.O como se fosse apenas um disco. Conseguimos através do Storage Pool configurar a solução de alta disponibilidade, onde eu posso ter, por exemplo, dois discos configurados no Storage Pool, se um dos discos falhar, eu continuo tendo acesso aos dados que estão armazenados nos discos, pois conseguimos configurar para que o Storage Pool faça um espelhamento entre os discos.

Quando configuramos os discos para fazer parte do um Storage Pool devemos configurar um armazenamento virtual que será a unidade apresentada para o S.O, qualquer dado criado nesse armazenamento virtual será gravado nos discos que fazem parte do Storage Pool.

Outra coisa bacana que conseguimos com o Storage Space é, por exemplo, temos dois discos de 250 GB, criamos um Storage Pool com os dois discos e configuramos a opção de espelhamento, ou seja, os dados gravados em um disco serão copiados para o outro, então temos um espaço de 500 GB para armazenamento, porém conseguimos criar um armazenamento virtual com 100 GB, não precisamos utilizar todo espaço em disco para criação de armazenamento virtual (unidade que será apresentada para o S.O), diferente com que temos quando utilizamos as configurações de “RAID” onde temos que utilizar todo o espaço em disco para criação do RAID. Com isso conseguimos criar vários armazenamentos virtuais para o mesmo Storage Pool, podemos criar armazenamentos virtuais para diferentes situações, fazendo algo bem parecido que temos quando apresentamos uma LUN para o Servidor.

 

Para ver o artigo completo acesse:

http://social.technet.microsoft.com/wiki/pt-br/contents/articles/15322.windows-server-2012-storage-space.aspx

 

Abraços.

Diogo Molina

Share

Post to Twitter

Windows Server 2012 – Remover permissão para usuários ingressar máquinas no domínio

 

 

Qualquer usuário do Active Directory tem a permissão de inserir até dez máquinas no domínio, isso é um comportamento padrão. Porém para a maioria das organizações esse comportamento não é recomendável.
Temos a opção de remover essas permissões, fazendo com que apenas usuários com as devidas permissões (concedidas pelo administrador) consigam inserir máquinas no domínio.
Existe um atributo no Active Directory que faz com que qualquer usuário consiga inserir até dez máquinas no domínio, esse atributo é o "ms-DS-MachineAccountQuota" ele é definido a nível de domínio,  ele é definido com o valor "10", ou seja, qualquer usuário do domínio consegue inserir até dez máquinas no domínio por padrão. Para removermos essa permissão, basta zerar esse valor, para isso devemos abrir a ferramenta "Usuários e computadores do Active Directory", após devemos habilitar os recursos avançados:

 

Para ver o artigo completo acesse:

 

http://social.technet.microsoft.com/wiki/pt-br/contents/articles/15190.windows-server-2012-remover-permissao-para-usuarios-ingressar-maquinas-no-dominio.aspx

 

Abraços

 

Diogo Molina

Share

Post to Twitter

Windows Server 2012 – Ativação automatizada do Windows baseada no Active Directory

Quando precisamos gerenciar a ativação de varias máquinas no nosso ambiente, fica inviável e de difícil administração fazer essa ativação de forma manual, ou seja, fazer a ativação de máquina por máquina. Temos a opção de fazer esse gerenciamento e ativação de forma automatizada.
No Windows Server temos uma função "Serviço de ativação de volumes", onde iremos inserir a chave de múltipla ativação, ou seja, uma chave que pode ativer varias máquinas.
Quando instalamos a função de Serviço de ativação de volumes, temos a opção de ativação baseada no Active Directory, com essa opção conseguimos ativar as máquinas que fazem parte do domínio automaticamente, sem a intervenção manual.  Quando utilizamos essa opção são criados objetos de ativação no Active Directory, e esses computadores ficaram ativados pelo período em que fizerem parte do domínio do Active Diretcory. Quando uma máquina que não está ativada ingressa no domínio, a máquina irá consultar esses objetos  de ativação no Active Directory e irá ativar a máquina automaticamente.

 

Para ler o artigo completo acesse:

http://social.technet.microsoft.com/wiki/pt-br/contents/articles/15114.windows-server-2012-ativacao-automatizada-do-windows-baseada-no-active-directory.aspx

 

Abraços

Diogo Molina

Share

Post to Twitter

Ingresso Off-line para domino Windows Server 2012

 

Assim como tínhamos no Windows Server 2008 R2 a opção de fazer o ingresso off-line no domínio para estações e Servidores , essa função foi mantida no Windows Server 2012.

Utilizamos essa função em ambientes onde o link de rede entre o Controlador de domínio e as estações de trabalho ou Servidores é intermitente (por exemplo no cenário onde temo o Controlador de domínio apenas na matriz e as estações e Servidores precisam contatar o Controlador de domínio da matriz para fazer a ingressão em um domínio). Conseguimos a partir do Controlador de domínio gerar um arquivo que será posteriormente utilizado pela estação de trabalho ou Servidor para fazer o ingresso off-line ao domínio. Com essa opção não precisamos da conexão de rede entre o Controlador de domínio e as estações para fazer o ingresso ao domínio, pois isso será realizado pelo arquivo criado no Controlador de domínio.

O bacana é que conseguimos gerar esse arquivo a partir de um Servidor membro do domínio também, não precisamos executar esse procedimento apenas nos Controladores de domínio.

 

Para ver o artigo completo acesse:

http://social.technet.microsoft.com/wiki/pt-br/contents/articles/15084.ingresso-off-line-para-domino-windows-server-2012.aspx

 

Abraços

 

Diogo Molina

Share

Post to Twitter

Alta disponibilidade com Failover DHCP Windows Server 2012

 

 

Nas versões anteriores do Windows Server, os administradores de redes enfrentavam um grande desafio quando era necessário garantir a alta disponibilidade do Servidor DHCP.

Existiam duas opções para garantir essa alta disponibilidade, a primeira utilizando a regra 80/20, onde 80% dos endereços IPs ficavam em um Servidor DHCP e ou outros 20% em outro Servidor DHCP. Enfrentávamos alguns problemas com esse cenário, por exemplo, para muitas organizações se o Servidor DHCP que ficava com o escopo 80% dos endereços IPs sofresse alguma parada, os 20% dos endereços IPs disponíveis no segundo Servidor DHCP não atenderia a demanda, pois poderia ser um numero insuficiente de endereços. Nesse caso teríamos que intervir de forma manual no ambiente aumentando o range do Servidor DHCP que mantinha os 20% dos endereços.

A segunda opção era utiliza o Cluster do DHCP, nesse cenário teríamos dois Servidores com DHCP configurados em cluster, onde teríamos um Servidor DHCP no modo ativo e o outro passivo, ou seja, apenas um Servidor iria distribuir endereços para os clientes enquanto o outro Servidor ficaria em standby, sendo utilizado apenas no caso de falha do Servidor DHCP ativo. Nesse cenário o custo muitas vezes impedia a configuração do Cluster do DHCP, pois para configurar o Cluster do DHCP era necessário um armazenamento compartilhado (por exemplo uma Storage), sem dizer na complexidade de configuração do Cluster de DHCP, onde o administrador deveria dominar os conceitos de Cluster.

Com o Windows Server 2012 temos duas opções para garantir a alta disponibilidade, utilizando o balanceamento entre os Servidores DHCP e a opção de Failover (nó ativo e passivo). Esse artigo se concentra apenas na opção de Failover, posteriormente irei escrever um artigo sobre a opção de balanceamento.

Diferentemente do que temos com as versões anteriores do serviço de DHCP, a opção de Failover do DHCP no Windows 2012 não depende mais de um armazenamento compartilhado, ele não utiliza mais o recurso de Cluster do Windows, ele utiliza a própria solução de HA do DHCP.

Com o Failover DHCP do Windows 2012, configuramos o Servidor DHCP que atuará como ativo, ou seja, concedendo os endereços IPs para os clientes e o outro Servidor será definido como standby (passivo). O Servidor standby só será utilizado no caso de falha do Servidor ativo, quando configuramos o Failover do DHCP temos que definir qual será a porcentagem utilizada pelo Servidor DHCP passivo no caso de parada do nó ativo. Devemos planejar bem essa porcentagem, pois o Servidor DHCP definido como standby só irá atribuir endereços IPs definidos por essa porcentagem. Outra coisa interessante é que quando o Servidor DHCP ativo atribui um endereço IP para o cliente, esse leasing é replicado para o Servidor DHCP standby.

Esse artigo já leva em consideração que o serviço de DHCP já esteja instalado e configurado nas duas máquinas.

Configurei um Servidor com o serviço de DHCP, criei um escopo chamado “Corporativo”, conforme imagem abaixo:

 

clip_image002

 

 

No segundo Servidor com DHCP, não temos nenhum escopo definido:

 

clip_image004

 

 

Para configurarmos o Failover no DHCP, basta selecionarmos o escopo, clicar com o botão direito e selecionar “Configure Failover”:

 

clip_image006

 

 

Na primeira janela do assistente devemos selecionar o escopo que iremos configurar o Failover, no meu caso só tenho um escopo, mais se tivesse mais do que um, era só selecionar.

Na próxima janela o assistente irá perguntar qual será o Servidor parceiro, no nosso caso o Servidor que será standby (nó passivo), só clicar em “add” e escolher o Servidor parceiro:

 

clip_image008

 

 

OBS: O Servidor com DHCP tem que estar autorizado no AD!

Só clicar em OK e depois Next.

Na próxima janela devemos definir as opções de Failover, onde temos o Load Balance (que irei detalhar em um próximo artigo) e a opção de Hot Standby (ativo e passivo). No nosso caso vamos selecionar Hot Standby. Devemos definir também se o nosso Servidor parceiro será o Servidor DHCP ativo ou o standby (passivo), assim como definir a porcentagem de endereços que será disponibilizado para o Servidor DHCP standby utilizarem no caso de falha do Servidor DHCP ativo. Temos também a opção de habilitar a opção de uma senha para autenticação dos Servidores DHCP.

 

clip_image010

 

 

A próxima janela do assistente traz um resumo, clique em finish.

Agora precisamos validar se as alterações foram refletidas no Servidor DHCP que foi definido como Standby, para isso devemos abrir a console administrativa do DHCP no outro Servidor.

 

clip_image012

 

 

Conforme imagem acima, o escopo “corporativo” foi replicado para o Servidor DHCP passivo.

Se clicarmos com o botão direito em cima do escopo e selecionarmos propriedades e Failover, veremos as opções de Failover que configuramos.

 

clip_image014

 

 

Agora vamos fazer o teste com a estação de trabalho, conforme imagem abaixo a estação de trabalho pegou o endereço IP “10.0.0.100” do Servidor DHCP “10.0.0.1” (Servidor DHCP ativo).

 

clip_image016

 

 

As duas imagens abaixo mostra a concessão tanto no Servidor DHCP ativo quanto no standby (passivo).

 

clip_image018

clip_image020

 

 

Agora iremos simular uma queda do Servidor DHCP ativo, para isso irei para o serviço de DHCP Server.

 

clip_image022

 

 

Agora vamos para o Servidor DHCP standby (passivo), clicar com o botão direito no escopo e selecionar propriedade, e a opção Failover. Podemos observar que em “State of this Server” está como “Lost contact with partner”.

 

clip_image024

 

 

Nessa etapa o Servidor DHCP ativo está fora, então o Servidor DHCP standby deverá fornecer os endereços IPs para os clientes.

Agora vamos fazer um novo teste na estação de trabalho, vamos rodar o comando ipconfig /release e depois ipconfig /renew para forçar a estação a pegar um novo endereço IP.

Podemos notar na imagem abaixo que a estação de trabalho pegou o endereço IP “10.0.0.196” e o Servidor DHCP que atribui o endereço foi o “10.0.0.2” (Servidor DHCP Standby).

 

clip_image026

 

 

Nesse artigo vimos a nova funcionalidade de alta disponibilidade do serviço de DHCP no Windows Server 2012, a nova funcionalidade irá ajudar os administradores de rede a configurar de forma fácil e rápida a alta disponibilidade do DHCP no Windows Server 2012.

Abs

Diogo Molina de Sá

Share

Post to Twitter

Clonando configurações do Edge Transport Exchange 2010

 

As vezes precisamos configurar mais de um Servidor com Edge Transport, seja para atender a demanda ou para balanceamento de carga.

O Edge Transport utiliza uma instancia do AD LDS para sincronizar as informações do Active Directory, ou seja, as informações do Edge Transport não são armazenadas no Active Directory, por isso quando instalamos servidores adicionais com Edge Transport o novo Servidor não irá conter as mesmas configurações, para isso precisamos importar as configurações para o novo Servidor com Edge Transport.

Quando instalamos a função de Edge Transport, é criada uma pasta onde contém alguns scripts (c:\Program Files\Microsoft\Exchange Server\V14\Scripts), nesse diretório temos dois scripts que utilizaremos para importar as configurações de um Servidor com Edge Transport para Servidores Edge Transport adicionais.

Para esse cenário tenho dois Servidores com Edge Transport (Edge01 e Edge02), conforme imagem abaixo configurei o filtro de conteúdo para bloquear algumas palavras no Servidor Edge01:

Configurações filtro de conteudo Edge01

 

Na imagem abaixo podemos verificar que o filtro de conteúdo do Edge02 está configurado de forma padrão ou seja não tem nenhum tipo de bloquei de acordo com palavras, podemos entender que como essas configurações não armazenadas no Active Directory, ela não é replicada para o Edge02:

 

Configurações filtro de conteudo Edge02

 

Precisamos agora Clonar as configurações do Edge01 para o Edge02, para que todas as configurações do Edge01 seja importadas para o Edge02.

 

A primeira tarefa que devemos executar é exportar as configurações do Edge01, para isso iremos utilizar o script “ExportEdgeConfig” que está localizado no diretório de instalação do Exchange 2010, na pasta Scripts.

Para isso devemos abrir o Exchange Management Shell e ir até o diretório onde fica os scripts do Exchange (padrão c:\program files\Microsoft\Exchange Server\V14\Scripts), devemos digitar:

./ExportEdgeConfig –CloneConfigData:c:\cloneconfigdata.xml, conforme imagem abaixo:

 

Exportando Configurações Edge01

 

Após executar esse comando o arquivo será exportado para o diretório que definimos (c:\CloneConfigData.xml).

As seguintes configurações são exportadas para o arquivo XML:

  • Informações dos caminhos dos arquivos de log dos seguintes recursos:
    • ReceiveProtocolLogPath
    • SendProtocolLogPath
    • MessageTrackingLogPath
    • PickupDirectoryPath
    • RoutingTableLogPath
  • Informações relacionadas com os conectores de envio
  • Informações relacionadas com os conectores de recebimentos
  • Configurações de domínios aceitos
  • Configuração de domínios remotos

 

  • Configurações de filtros anti-spam. As seguintes informações são exportadas:
    • Listas de IPs permitidos. Somente listas de IPs criadas manualmente são exportadas.
    • Listas de IPs bloqueados.
    • Filtro de conteúdo.
    • Recipient filter configuration.
    • Address rewrite entries.
    • Filtros de anexos.

O próximo passo será validar as informações contidas no arquivo que acabamos de criar e criar um arquivo de resposta para posteriormente importar as configurações para o Edge02.

Para isso devemos copiar o arquivo “CloneConfigData.xml” para o Edge02.

Após copiar o arquivo para o Edge02, devemos executar digitar o seguinte cmdlet no Exchange Managament Shell:

./ImportEdgeConfig -CloneConfigData:”C:\CloneConfigData.xml” -IsImport $false -CloneConfigAnswer:”C:\CloneConfigAnswer.xml” , conforme imagem abaixo:

Importando Configuração Edge02

 

Após executar o comando acima, devemos validas as informações contidas no arquivo de resposta recém criado, devemos alterar as informações para apontar para o Edge02, para isso devemos editar o arquivo “CloneConfigAnswer” e fazer as alterações para apontar para Edge02.

Agora devemos importar esse arquivo de resposta para o Edge02 (lembrando que o comando acima só utilizamos para validar as configurações e não foi realizada a importação). Para isso devemos utilizar o seguinte comando:

./ImportEdgeConfig -CloneConfigData:”C:\CloneConfigData.xml” -IsImport $true -CloneConfigAnswer:”C:\CloneConfigAnswer.xml”, conforme imagem abaixo:

 

Importando Configuração Edge02 - 02

 

Devemos receber a informação de sucesso no processo de importação.

Conforme imagem abaixo, a opção de filtro de conteúdo que configuramos no Edge01, foi importada (clonada) para o Edge02:

 

Filtro de conteudo Edge02

 

Nesse cenário utilizamos uma configuração simples, que são três palavras para o filtro de conteúdo fazer o bloqueio, porém imagine um ambiente mais complexo onde temos varias configurações de filtros anti-spam e varias personalizações nas configurações do Edge Transport, ficaria inviável fazer essas alterações de forma manual, é aqui que entra a opção de clonar as configurações do Edge Transport, apenas em algumas etapas temos todas as configurações do Edge Transport clonadas para os outros Servidores Edge Transport.

 

Um ponto que devemos nos atentar é em relação a inscrição do Edge Transport, nesse nosso cenário, após a realização de clonar o Edge Transport precisamos inscrever o Edge02 no Hub Transport, pois a configuração de “clonar” não irá importar qualquer inscrição do Edge Transport.

 

Abraços

Diogo Molina

 

Share

Post to Twitter

Delegando a Instalação do Exchange 2010

 

Com o Exchange 2010 temos a opção de delegar a instalação para usuários que não tenham credencias administrativas no Servidor onde será realizada a instalação do Exchange. Após a instalação os usuários não terão qualquer poder administrativo no Exchange, somente será delegada o permissão para instalação, se o usuário precisar de permissões para administrar o Exchange, as devidas permissões deverá ser atribuídas.

Podemos usar a delegação de instalação por exemplo, em cenários de filiais onde não possui um administrador do ambiente do Exchange, nesse cenário podemos delegar a permissão de instalação do Exchange para qualquer usuário, e após a instalação o usuário não poderá fazer qualquer tipo de alteração no ambiente, a menos que seja atribuída permissões adicionais para o usuário em questão.

Para delegar a permissão de instalação do Exchange devemos seguir os seguintes passos:

 

1- Devemos inserir o usuário que fará a instalação no grupo “Delegated Setup” (esse grupo é criado quando preparamos o AD para o Exchange 2010).

Delegando instalação Exchange 01

 

 

2- No Servidor Exchange 2010 existente no ambiente devemos inserir a mídia de instalação do Exchange 2010, abrir o prompt de comando, navegar até o diretório onde se encontra a mídia de instalação do Exchange 2010, na figura abaixo o diretório de instalação é o “D:\”, após devemos digitar “Setup.com /NewProvisionedServer:<nomedoservidor>.

O parâmetro “/NewProvisionedServer” devemos inserir o nome do Servidor que será delegada a instalação do Exchange 2010.

Esse comando irá preparar o Servidor e permitirá que usuários membros do grupo “Delegated Setup” instalar o Exchange 2010, porém o usuário só conseguirá instalar o Servidor que foi declarado no comando acima, se por exemplo o usuário precisar instalar outros Servidores, os mesmos deverá ser declarado também.

 

Delegando instalação Exchange 02

 

3-  A preparação do Servidor deverá ocorrer com êxito, conforme figura abaixo.

 

Delegando instalação Exchange 03

 

4- Agora devemos logar no Servidor (onde será instalado o Exchange 2010) com o usuário que delegamos  a permissão de instalar o Exchange, no meu caso o usuário “instalacao exchange”.

 

Delegando instalação Exchange 04

 

5- Devemos inserir a mídia de instalação do Exchange 2010, podemos executar o assistente de instalação do Exchange 2010 e seguir os passos, no meu caso estou fazendo a instalação pela linha de comando.

 

Delegando instalação Exchange 05

 

 

Após  instalação ser realizada com êxito, podemos abrir  console de gerenciamento do Exchange e verificar que o usuário não consegue alterar parâmetros do Exchange, para isso deverá ser atribuída permissão adicionais.

 

Abraços,

Diogo Molina

Share

Post to Twitter

RODC Filtered Attribut Set

 

Sabemos que o RODC possui uma copia somente leitura do banco de dados do DC gravavel, porém somente alguns atributos são replicados para o RODC. Temos uma opção chamada de RODC filtered Attribut Set onde podemos filtrar (não permitir) de forma dinamica que certos atributos seja replicado para o RODC.

Abaixo segue uma lista com os atributos que são configurados no RODC Filtered Attribut Set por padrão:

ms-PKI-DPAPIMasterKeys
ms-PKI-AccountCredentials
ms-PKI-RoamingTimeStamp
ms-FVE-KeyPackage
ms-FVE-RecoveryPassword
ms-TPM-OwnerInformation

Esses atributos que são configurados por padrão no RODC Fileterd Attribut Set, está relacioanado a credenciais de usuários.

Vamos então a um seguinte cenario:

Temos uma aplicação em nosso ambiente que armazena alguns dados no banco de dados do AD, e não queremos que os atributos com informações dessa aplicação seja replicado para os RODCs do nosso ambiente, o que temos que fazer?

Existem duas forma de se fazer isso no nosso ambiente, segue abaixo as duas formas:

1º Podemos inserir esses atributos no RODC Filtered Attribut Set (irei mostrar mais adiante o processo para inserir os atributos no RODC Filtered Attribut Set), com isso os atributos não serão replicados.

2º Marcar o atributo como confidencial (irei mostrar mais adiante o processo para marcar o atributo como confidencial), isso faz com que o grupo Authenticated Users não tenha a permissão de ler os atributos incluidos no RODC, ou seja, se o Servidor RODC for comprometido a conta do RODC não terá permissão sobre os atributos que são marcados como confidencial. Só como observação, no ambiente do AD padrão o grupo Authenticated Users possui permissão de leitura em todos os atributos.

Temos uma outra situação em que um usuário malicioso pode tentar forçar a replicação dos atributos que estão no RODC Filtered Attribut Set, nesse caso se o RODC tentar replicar esses atributos a partir de um DC com Windows Server 2008, esse replicação será negada. Porém se esse replicação for a partir de um DC com Windows Server 2003, a replicação poderá acontecer. Por esse motivo a Microsoft recomenda para que quando utilizar o RODC Filtered Attribut Set, que o nivel funcional da floresta esteja selecionado para Windows Server 2008. Só lembrando que se o nivel funcional da floresta for alterado para Windows Server 2008, não será possivel termos DC com Windows Server 2003.

Sabemos também que quando temos um RODC no ambiente, por padrão ele irá tentar fazer a replicação atraves de um DC com Windows Server 2008, porém um usuário malicioso pode forçar o RODC replicar atraves de um DC com Windows Server 2003, por essa razão é recomendavel que o nivel da floresta seja no minimo Windows Server 2008. Uma outra observação, para utilizarmos o RODC temos que ter pelo menos um DC com Windows Server 2008. Abaixo segue link que explica como essa replicação pode ser feita atravez de um DC com Windows Server 2003:

http://technet.microsoft.com/pt-br/library/cc755310(WS.10).aspx

Existem alguns atributos que não podem ser adicionados no RODC FAS, são os atributos critio de sistema que são fundamentais para o funcionamento do ambiente de AD, um exemplo de atributos criticos estão relacionados com: LSA, SAM, Kerberos, etc.

Agora vamos aprender como inserimos atributos no RODC FAS (utilizaremos um atributo ficticio chamado “Contoso-App-Password”:

1 – A primeira coisa a fazer é determinar o atual valor do atributo searchFlags, para isso vá em Start > Prompt de Comando > e digite o seguinte comando “ldifde –d CN=Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain> –f en_ldif –l searchflags

2 – O resultado desse comando devera ser o seguinte:

dn: CN=Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain>

changetype: add

searchFlags: 0

3 – Copie o resultado do comando para um novo arquivo de nome “en-fas.ldif”.

4 – Modifique o novo arquivo “en-fas.ldif” com os seguintes valores, e após salve o arquivo:

dn: CN=Contoso-App-Password,CN=Schema,CN=Configuration,DC=<domain>

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

replace: searchFlags

searchFlags: 640

5 – Digite o seguinte comando para importar o arquivo “en-fas.ldif” que foi modificado:

ldifde –i -f en-fas.ldif

Agora vamos verificar se o o atributo foi adicionado ao RODC FAS corretamento:

1 – Vá em Start > Administrative tolls > ADSI Edit.

2 – No ADSI Edit clique em connect to.

3 – Slecione Schema e clique ok.

4 – Na arvore de console clique em Schema e clique em CN=Schema,CN=Configuration,DC=<domain> container.

5 – No painel de detalhe procure o atributo CN=Contoso-App-Password e clique em propriedades.

6 – Na lista verifique se que as flag RODC_Filtered esteja selecionada. Para colocar o atributo como confidencial, basta selecionar a flag Confidential.

 

Segue abaixo link de referencia:

 

http://technet.microsoft.com/pt-br/library/cc754794(WS.10).aspx

Share

Post to Twitter