Bom,  como não existe um mundo perfeito, talvez você possa ter alguma necessidade extrema e ainda ter em seu ambiente um Windows 2000 Server rodando. Em nossa realidade e nossa cultura, as empresas ainda pesam muito o custo X benefício entre fazer as migrações dos sistemas operacionais de servidores. Se hoje eles tem um servidor que atende muito bem a necessidade, para quê investir na instalação de um novo sistema operacional? Nós profissionais de TI sabemos da importância que um ambiente atualizado demanda, porém, ficamos a mercê dos administradores das empresas que nem sempre tem essa visão do negócio.

Esses dias, estava analisando a Console do Operador do Forefront Client Security e me deparei com a seguinte mensagem de erro:

Forefront Error Code: 0x8007007f Error description: The specified procedure could not be found.

Esse erro estava sendo remetido de um servidor rodando um sistema operacional Windows 2000 Server. Após uma investigação mais detalhada (e algumas pesquisas no Google é claro), encontrei essa página.

Aparentemente, em um dos updates de definições que a Microsoft fez para o FCS, comprometeu o forefront executado em ambientes com Windows 2000 de carregar e executar alguns drivers de filtros necessários para a execução do serviço de Antimalware. Com isso, este ambiente não estava conseguindo executar o serviço adequadamente e consequentemente submetia informações de erros ao servidor do Forefront.

Para corrigir a situação é necessário:

1. Remover o client do serviço de Antimalware: para isso, executar o comando:
   msiexec.exe /x {A22989EE-AE7A-42F8-A0C0-9C99CFB644FB} /qn
2. Depois, é necessário acessar o site http://catalog.update.microsoft.com/v7/site/Home.aspx e procurar pelo update 2394433. Após fazer o download dele, executar esse novo instalador no ambiente afetado.
3. Com isso será instalado novamente o serviço do Antimalware. Agora é só fazer uma nova atualização dos arquivos de definição e o problema está resolvido.

Essa prova é na verdade composta de 2 sub-provas. Na primeira parte, são 27 questões e na segunda foram 30. Essa prova é uma espécie de junção das provas 70-640 e 70-642, tanto que após passar nelas você ganha o título de Techology Specialist em Active Directory e Technology Specialist em Network Infraestructure.

Comentários sobre a prova:

Eu achei extremamente fácil, nem parece uma prova de upgrade de um sistema operacional server. Surpreendemente não houveram questões relacionadas a DNS, porém caiu muitas perguntas RRAS. Achei estranho também cair tantas perguntas relacionadas a DHCP.
Outro tópico bastante abordado foi o de backup. Das roles novas do Windows 2008, sugiro estudar profundamente NAP e ADFS.
Sugiro também a vocês montarem um ambiente de testes para implementarem soluções de IPSEC, pois é um tópico que também é muito abordado no exame. Adicionalmente, monte uma infraestrutura de PKI com o ADCS.

Próximo passo:

A próxima prova que irei fazer será a 70-646 (Pro: Windows Server 2008, Server Administrator). Com essa prova receberei o título de MCITP – Server Administrator

Em ambientes pequenos não haveria problemas, agora imagine gerenciar uma rede com 2 mil usuários, separados em 16 sites (filiais) em 3 continentes? Pois é, agradeça todos os dias ao tio Bill por isso.

Pouca gente sabe, mas como tudo no mundo, esse serviço tem algumas limitações técnicas. Esse artigo descreve algumas das limitações que existem no Active Directory atualmente.

Número máximo de objetos:  cada controlador de domínio na floresta pode criar aproximadamente 2,15 bilhões de objetos durante sua vida;

Número máximo de SSIDs: aproximadamente 1 bilhão de SSIDs únicas;

Associação de Grupos: cada objeto (conta, grupo) pode fazer parte de no máximo 1.015 grupos. Mais informação sobre isso aqui;

Tamanho de FQDNs: Fully qualified domain names não podem exceder 64 caracteres, incluindo traços e pontos;

Tamanho de Nome de Arquivos: o nome e o path do arquivo não podem exceder 255 caracteres.

A explicação dessa e de outras limitações pode ser encontrada neste link.

Entendendo e simulando o problema:

Na situação reportada, um programa de terceiros precisava descobrir se uma conta de usuário fazia parte de um determinado grupo no AD. Para isso, fazia uma consulta através do protocolo LDAP usando um usuário com privilégios mínimos cadastrado neste domínio. Através dessa consulta, o programa lia o atributo memberOf dessa conta. Entretanto, o resultado obtido não era o esperado.

Primeiramente, para identificar se havia algum problema relacionado a maneira como esta equipe estava fazendo essa consulta com o LDAP, tentei atingir o ‘goal’ solicitado (retornar o grupo de usuários de um determinado login) utilizando as próprias ferramentas do Windows. Para isso, usei o utilitário dsget.exe. Esse utilitário nos permite fazer consultas aos medados do Active Directory. Para isso, executei com a seguinte sintaxe:

dsget user “CN=user1,OU=Usuarios,DC=cetil,DC=com,DC=br” -memberof

Vejam que 0 segundo parâmetro é o caminho exato desta conta no Active Directory. Utilizei o parâmetro -memberof para que fosse retornado alista de grupos deste usuário.

Verifiquei que ao executar este comando no contexto do usuário utilizado para fazer as consultas LDAP, apenas o Grupo Primário desta conta era retornado, embora ela faça parte de outros grupos. Porque isso acontece então?

Muito simples. A conta utilizada para fazer essa consulta não possui privilégios suficientes para ler os atributos necessários no Schema do Active Directory. Para resolver isso é muito simples:

1- Abra a guia Active Directoy Users and Computers (dsa.msc) , clique com o botão direito em cima do domínio desejado e escolha a opção Delegate Control;

2- Na tela de boas vindas, clique em Next;

3- Na tela de seleção de grupos e usuários, clique em Adicionar e informe a conta a qual você irá atribuir esse privilégio. Após isso, clique em Next;

4- Na tela Tasks to delegate, escolha a opção Create a custom task to delegate e depois clique no botão Next;

5- Na tela Active Directory Object Type, clique em Only the following objects in folder. Após, habilite na lista o item User Objects e clique em Next;

6- Na janela Permissions, desmarque a opção General e habilite a opção Property-specific. Após isso, habilite a opção Read MemberOf e clique em Next;

7- Na tela final, temos um sumário da operação que será realizada. Clique em Finish para que a operação seja confirmada.

8- A partir de agora, a conta de usuário que você atribuiu terá privilégios para ler o atributo MemberOf do metadados do Active Directory, como podemos identificar na imagem abaixo.

Essa operação pode ser feita para delegar o acesso (leitura ou escrita) a qualquer objeto do schema do Active Directory.

Estou re-inaugurando hoje este blog, no qual a partir de agora pretendo manter atualizado com alguns artigos que acho que sejam pertinentes a minha área de atuação profissional. Os assuntos focados aqui são o de uso diário de administradores de redes, profissionais da área de infraestrutura e apaixonados por tecnologia. Portanto, divirtam-se!