Jean Carlos Bormanieri :: Website

Ontem fiz a prova 70-648. Fui muito bem e gabaritei ela (1000 pontos).

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

Todo administrador de redes sabe que identificar a origem de um bloqueio de conta de usuário pode ser uma dor de cabeça terrível. Normalmente o usuário liga informando que não consegue mais logar, você então vai no snap-in do Active Directory e visualiza que a conta do indivíduo está bloqueada por causa do número de tentativas inválidas de logon. O usuário afirma que não digitou tantas vezes errado sua senha, e no fim das contas você acaba desbloqueando a senha para que ele possa logar novamente.

A pergunta que fica no ar: Foi mesmo esse o motivo do bloqueio da conta? Será que foi o próprio usuário que digitou errado sua senha diversas vezes, ou foi algum indivíduo mal-intencionado que esta tentando fazer uma invasão em sua rede?

Realmente é bastante complicado identificar com 100% de certeza o motivo do bloqueio. Imagine que você trabalha em uma rede com 5 mil usuários e com 30 servidores de domínio espalhados por diversos sites diferentes. Fica bastante complicado analisar os logs de segurança de todos os servidores um por um para avaliar a origem da invasão.

Para facilitar, segue abaixo um link de um programa fornecido pela Microsoft que ajuda muito. Com ele, você consegue identificar de qual controlador de domínio partiu o bloqueio da conta do usuário. Após isso, você pode ir nos logs de evento deste servidor e fazer uma análise com mais calma, economizando muito tempo.

Link: Account Lockout and Management Tools

Após extrair o conteúdo do arquivo, execute o aplicativo LockoutStatus.exe e informe qual a conta que está bloqueada. O programa irá informar o status da conta em cada controlador de domínio, além do motivo do bloqueio. Irá informar também o principal, qual é o servidor que originou o bloqueio da conta.

Com a Microsoft anunciando que a partir de agora somente irá lançar Sistemas Operacionais para servidores apenas na plataforma 64-bits, alguns administradores de rede sentem que estão sendo forçados a migrar de arquitetura sem razão e sem escolha.

Tenho que dizer que concordo em parte com essa afirmação, realmente uma rede pequena onde não há grandes necessidades de recursos computacionais, não tem a necessidade de migrar de arquitetura apenas para manter seus Sistemas Operacionais atualizados.

Porém, essas pessoas desconhecem que mesmo a mais simples tarefa operacional de seus servidores pode ser mais vantajosa se estiver rodando em um ambiente com arquitetura 64-bits.

O artigo no link abaixo, descreve as vantagens de ter seu ambiente do Active Directory sendo executado em 64-bits.

64bit-only Windows Server is good for Active Directory

Todos os administradores de redes sabem que o Active Directory é um dos melhores serviços que a Microsoft já desenvolveu. Já imaginou como seria manter sua rede sem ele?

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.

Recentemente, fui solicitado a resolver um problema onde um determinado usuário não estava conseguindo identificar quais grupos de segurança um determinado usuário fazia parte.

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.