Na console do SCCM você acessa a opção Site Database -> Security Rights -> Users e adiciona os privilégios de leitura na classe Report para o usuário.

Entretanto, se o usuário abrir a console se depara com um erro 500 no navegador:

Para corrigir este problema, além de dar privilégio de leitura nos relatórios para o usuário no SCCM (passo feito acima), ainda é necessário adicionar a conta deste usuário no grupo local chamado SMS Reporting Users.
Para isso, vá no gerenciamento do servidor e expanda a opção Configuration -> Local Users and Groups e de um duplo clique no grupo SMS Reporting Users. Então adicione a conta do usuário e clique OK.

Após isso, o usuário irá conseguir fazer as consultas nos relatórios do SCCM.

Após configurar o envio de emails utilizando a console de Administração do MOM 2005, o seguinte erro começou a aparecer na console:

Failed to send SMTP message. The message could not be sent to the SMTP server. The transport error code was 0×80040217. The server response was not available hr=-2147220975

Esse erro acontece porque o MOM 2005 por padrão tenta enviar os emails utilizando como autenticação o protocolo NTLM. Para resolver este problem, é necessário criar uma chave no registro que habilita o MOM a enviar emails de notificação sem usar autenticação NTLM. Para isso, seguir os passos abaixo:

1. Abrir o regedit;
2. Localizar a chave HKEY_LOCAL_MACHINE\Software\Mission Critical Software\OnePoint\Configurations\<Configuration group name>\Operations\Consolidator
3. Criar um novo item chamado SendSmtpAnonymous;
4. Modificar o valor dele de 0 para 1;

Após isso, seu MOM conseguirá enviar os emails de notificações.

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.

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.

A verdade é que hoje em dia, devido ao baixo custo, o uso de dispositivos de armazenamento Usb creceram vertiginosamente. É possivel comprar um pen drive de 8 Gb por menos de R$ 40,00.

Com isso, cresce nas empresas uma preocupação a mais. Como garantir que os usuários não copiem arquivos confidenciais nesses dispositivos Usb? Imagine uma empresa de softwares que tenha uma cópia dos seus fontes “vazados” na internet por um funcionário. O prejuízo seria inestimável.

Felizmente, existem mecanismos para os administradores de redes coibirem a utilização desses dispositivos em ambientes corporativos. Recentemente, encontrei um artigo da Microsoft que trata dessa questão, e ensina a desativar o uso de dispositivos de armazenamento Usb. Com essas informações, os administradores podem criar GPO’s ou scripts e implementar isso em sua rede.

O artigo pode ser encontrado neste link.

Após um dia inteiro de trabalho, a migração foi concluída com sucesso. Os testes preliminares pós-migração foram feitos e tudo estava funcionando perfeitamente.

Alguns dias depois, quando este farm entrou em produção, os usuários estavam encontrando problemas ao acessar algumas páginas do Project Server. O erro retornado era:

Aliás, o mais estranho mesmo, era que apenas essa informação era retornada. Nenhum código Html era retornado, apenas a string “403 – Forbidden”.  Executando algumas ferramentas de tracing, observei que antes dessa mensagem, o servidor respondia com dois pacotes de erro 401.1 do IIS.

Partindo disso, podemos identificar que o problema está relacionado a autenticação do IIS. Se um usuário tivesse privilégios de Administrador do servidor onde estava instalado esse EPM entrasse nessa mesma página, ele conseguia acessar normalmente. E após isso, todos os outros usuários, mesmos os que estavam com problemas, conseguiam abrir a página.

Estranho não? Pesquisando mais a fundo, consegui identificar um padrão para esse comportamento. Todas as vezes que o pool que executava esse contexto no IIS era reiniciado, o problema voltava a ocorrer.

Após alguns testes, finalmente descobri a razão disso e uma maneira de corrigir. O problema estava ocorrendo porque os usuários do meu domínio não tinham privilégios de leitura nos recursos do sistema usados pelo Sharepoint. Para corrigir isso, adicionei o grupo DOMINIO\Domains Users ao grupo local WSS_WPG  do servidor onde esta sendo executado o EPM.

Após um reinício do IIS, as coisas voltaram a funcionar perfeitamente.

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.