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.
Recentemente tive o seguinte problema a o acessar um servidor Microsoft SQL Server 2008:
Não estava sendo possível fazer logon utilizando a autenticação do Windows (Windows Autentication) no SQL.
A princípio, parecia ser problema de permissões. No caso em questão, o grupo DOMINIO\Domain Admins estava configurado no SQL com o role de SysAdmin, entretanto, mesmo logando com uma conta de domínio que faz parte deste equipamento, não estava sendo possível se autenticar.
Fui verificar nos logs do windows e o seguinte evento me chamou a atenção:
Login failed for user ‘DOMAIN\admin’. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: <local machine>]
Após uma busca na internet, encontrei um artigo que indicava que o problema poderia ser ocasionado pelo UAC (User Account Control) do Windows 2008 R2. Fui no painel de controle e desabilitei o UAC deste equipamento. Após reiniciar ele, o problema foi resolvido.
Aparentemente, com o recurso do UAC ativado, o windows não consegue “encaminhar” para o SQL Server todo o Membership da conta utilizada. No caso, o SQL sabia que o grupo DOMAIN\Domain Admins era SysAdmin do SQL, porém ele não conseguia identificar que a conta DOMAIN\admin fazia parte deste grupo. Ao meu ver, esse comportamento é muito estranho, principalmente em se tratando de dois produtos da Microsoft.
Uma outra alternatia seria dar permissões diretamente para a conta DOMAIN\admin no SQL Server, apesar desta não ser uma boa prática de segurança.