Verificando o evento de Error para obter maiores detalhes:

Após fazer uma pesquisa encontrei um post que explica essa situação.

Aparentemente, a conta que está levantando o SQL Server e está executando o pakage do DTS não está tendo acesso ao diretório necessário. Para corrigir isso fazer o seguinte:

1. Abrir o SQL Server Management Studio
2. Conectar a seu servidor
3. Expandir Management->Legacy->Data Transformation Services
4. Botão direito em  ‘Microsoft Forefront Client Security’ e escolher ‘Open’
5. Clicar no menu ‘Package’ e escolher ‘Properties’
6. Navegar até a aba ‘Global Variables’ e verificar o valor do campo ‘ScriptFileDirectory’.
7. Agora abra este diretório usando o Windows Explorer e atribua direitos de leitura e gravação para a conta que esta subindo os serviços do SQL Server (no meu caso o NETWORK SERVICE) neste diretório
8. Pronto, o problema esta corrigido.
9. Para forçar a execução da tarefa, volte ao SQL Server Management Studio
10. Expandir SQL Server  Agent -> Jobs
11. Clicar com o botão direito em Microsoft Forefront Client Security e escolher Start Job at Step

Estou participando de um grande projeto de implantação dessa tecnologia  e estou estudando a fundo esta ferramenta. Já trabalhei com outras soluções de antivírus corporativo, dentre elas, Trend, Kaspersky e Symantec. Definitivamente, não existe uma solução perfeita. Cada uma delas tem seus pontos fortes e fracos e cabe a você identificar qual a melhor solução para seu ambiente. Em se tratando do Forefront (FCS) a grande vantagem é de ser um produto Microsoft, e como outros produtos da empresa, foca muito a integração entre todos os produtos. Você receberá as atualizações através do seu servidor WSUS, você fará seu deployment através de GPOs criadas pela console do FCS, etc.. Soma-se a isso o fato de contar com uma grande quantidade de documentação disponível, marca registrada dos produtos Microsoft.

Estarei montando uma série de posts aqui neste site informando algumas dúvidas pelas quais passei ao implantar essa ferramenta e as alternativas para corrigi-las.

Como primeiro caso, vou tratar de resolver um problema que na minha concepção é uma falha extremamente grave. Infelizmente, nativamente, a ferramenta não possue nenhum mecanismo que impeça os usuários que possuem privilégios de administradores de pararem os serviços do FCS, ficando desta maneira desprotegidos. Outras soluções de Antivírus permitem que o administrador da rede configure uma senha para isso e somente com essa senha o usuário pode parar a proteção em sua máquina.
Sabemos que os usuários são leigos e muitos, ao perceberem que seu equipamento fica lento, acabam culpando o antivírus pela lentidão e então fecham a aplicação.

Para corrigir essa situação, podemos criar uma GPO que impeça os usuários de parar os serviços do FCS. Para isso:

01: Em um servidor abra a ferramenta Group Policy Management.

02:  Edite uma GPO aplicada a seus usuários (no meu caso a Default Domain Policy, porém você pode criar uma nova). Para isso, clique com o botão direito em cima da GPO e selecione Edit

03: Agora navegue até o caminho Computer Configuration \ Windows Settings \ Security Settings \ System Services

04: Agora para cada um dos 3 serviços do FCS (Microsoft Forefront Client Security Antimalware  Service, Microsoft Forefront Client SecurityManagement Service e Microsoft Forefront Client Security State Assessment Service) clique duas vezes no serviço. Habilite a opção Define this policy setting e marque a opção Automatic. Clique no botão Edit Security e selecione o grupo Administrators (que é o grupo de administradores locais). Desmarque a permissão de Start, stop and pause para este grupo. Adicionalmente, como boa prática, você pode incluir um determinado grupo com privilégios de poder fazer essas alterações, no meu caso, incluí o grupo JEANBLU\Domain Admins. Após isso confirme as alterações clicando duas vezes no botão OK.

05: Após fazer essas mudanças nos três serviços, como podemos observar na imagem abaixo, a segurança para esses três serviços foi definida. Agora, após a GPO ser aplicada nas estações (você pode forçar isso executando o comando gpupdate /force) os usuários não poderão mais parar os serviços do FCS.

06: Desta maneira, os usuários ainda poderão fechar o aplicativo que fica no systray do windows, mas mesmo assim eles continuarão protegidos.

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

Se você alterou as credenciais do serviço, ao tentar iniciá-lo, deve ter percebido que o serviço não inicia e o seguinte erro é gerado no Visualizador de Eventos:

Detailed Message: TF224004: The Visual Studio Team Foundation Build service failed to start because “account” does not have the required access permissions for address http://”server”:9191/Build/v2.0/AgentService.asmx.
Exception Message: HTTP could not register URL http://+:9191/Build/v2.0/AgentService.asmx/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). (type AddressAccessDeniedException)

Obviamente , o problema aqui trata-se de falta de privilégios para acessar esse webservice. Para corrigir o problema, execute a sequencia abaixo:

• No servidor do TFS, abrir um prompt de comando e acessar o diretório “c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies”
• Executar o comando:  wcfhttpconfig.exe reserve DOMAIN\UserAccount 9191 obviamente incluindo a conta com a qual você esta configurando o serviço de Build
• Após isso, é possível iniciar o serviço de Build novamente.

Understanding the ISA 2004 Access Rule Processing

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.

Por padrão, a descrição das contas continham o nome completo do recurso, como por exemplo, João da Silva. Acontece que uma requisição da diretoria solicitava que essas descrições aparecessem no aplicativo Web Acess com a conta SAM do usuário (ex: joao.silva).  Isso porque existem diversos usuários que possuem um nome muito comprido, o que ocasionava quebras de páginas em algumas páginas ou relatórios.

Para atingir este objetivo, diferentemente do que muitos podem imaginar, apenas alterar a descrição do campo Display Name na conta de cada usuário no Active Directory não resolve o problema. Isso porque essas informações (nome, descrição, conta SAM) são importadas apenas na primeira vez que o recurso é cadastrado no EPM e após isso, é feito um cadastro salvando essas informações no aplicativo de SSP (Shared Services Provider) criado no ambiente.

Para alterar essas informações, acesse o site de administração central do Sharepoint e clique no serviço SSP que você criou para o seu farm no Sharepoint. No meu caso abaixo, o SSP foi chamado de EPMSSP.

Após isso, no site do SSP,e na seção Perfis de Usuário e Meus Sites, clique no item Perfis de usuários e Propriedades.

Agora clique na opção Exibir Perfis de Usuário

Agora é só clicar na conta do usuário e no menu Drop Down, selecionar a opção Editar

Agora é só editar as informações e salvar.

Com o passar dos tempos, nós – administradores de redes – adquirimos uma certa experiência em busca dessas soluções.  Uma frase que sempre lembrarei é a de que “Em um ambiente computacional, tudo está interconectado.” Essa frase se aplica bem ao caso abaixo:

Em um projeto de expansão e modernização, uma empresa de desenvolvimento de softwares adquiriu novos equipamentos (servidores e estações). Esses equipamentos foram instalados e distribuídos aos usuários. Entretanto, logo começaram reclamações informando que o programa Live Messenger apresentava erro ao se tentar estabelecer uma conversa com qualquer contato.

Basicamente, o usuário logava na aplicação com sua conta Live e o programa abria normalmente, inclusive carregando toda a lista de contatos. Porém, era só clicar duas vezes em qualquer contato para que uma excessão fatal ocorresse no aplicativo, e o mesmo fosse fechado.

Inicie minha busca para a solução pesquisando na internet sobre o problema. Para quem nunca teve problema com o Messenger, sinta-se um privilegiado, pois existe literalmente milhares de soluções para os mais diversos problemas. Várias soluções apontam para registrar manualmente arquivos .dll, arquivos .ocx, fazer alterações no registro, etc… Fiz algumas tentativas que se assemelhavam com meu caso, porém todas em vão.

Verifiquei no log de eventos do windows e  o seguinte erro era registrado:

Problem Event Name: APPCRASH
Application Name: msnmsgr.exe
Application Version: 14.0.8050.1202
Application Timestamp: 493623f7
Fault Module Name: UXCore.dll
Fault Module Version: 14.0.8050.1202
Fault Module Timestamp: 49361b1c
Exception Code: c0000005
Exception Offset: 00073f70
OS Version: 6.0.6001.2.1.0.256.1
Local ID: 11274

Mesmo com essa informações, outros milhares de soluções eram apresentados na ferramenta de busca. Então comecei a pensar de uma forma diferente. Percebi que esse problema estava acontecendo apenas com as pessoas que trabalhavam na área de desenvolvimento. Outros setores não eram afetados. Fiz buscas incluindo os softwares utilizados pela equipe de desenvolvimento e descobri o seguinte:

Tortoise CVS crashes Windows Live Messenger on Vista/7 – ID: 2834625

O Tortoise é um software de repositório de fontes usados por diversas empresas de desenvolvimento, e a versão 1.10.10 (usada pela empresa em questão) possui uma incompatibilidade com o Windows Vista e o Windows 7. Após usar a versão mais recente do aplicativo, o problema parou de ocorrer.

Ou seja, o Tortoise estava afetando o funcionamento do Live Messenger. Por isso, smpre temos que levar em conta o ambiente como um todo, pois tudo o que está instalado no computador pode afetar indiretamente o funcionamento do mesmo.

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.