Navegando na Internet, achei esse artigo muito interessante que descreve a maneira como o Isa Server processa suas regras, vale a pena ler.
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.
Em uma implementação de um ambiente de EPM 2007, estava com um problema no qual necessitava atualizar a descrição das contas dos usuários (ou recursos) do sistema.
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.
Durante o trabalho de administração de rede em uma empresa, as vezes surgem problemas que parecem inexplicáveis. Problemas que parecem insignificantes acabam tomando um enorme tempo em pesquisas e tentativas de resoluções.
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.
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.
Todos sabemos que o serviço de DNS mal configurado trás enormes problemas a funcionalidade de seu domínio. Pesquisando na internet, achei esse excelente site que faz a análise de toda a configuração dos serviços de DNS de sua infraestrutura, baseado em melhores práticas.
Link para o Site: IPOK
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.
Essa foi complicada de resolver. Em um determinado ambiente, após a instalação do Service Pack 3 do Windows XP, o equipamento parava de responder a alguns tipos de requisições de rede, como por exemplo uma simples requisição de ping.
Os equipamentos remotos não conseguem “pingar” a máquina com o Service Pack 3 instalado. Entretanto, a máquina com o SP3 consegue acessar normalmente a rede.
As configurações de firewall estão corretas na máquina com o SP3, inclusive com regras que permitem a conexão do protocolo ICMP (usado pelo ping), tanto de entrada como saída.
Após fazer uma breve avaliação do ambiente, identifiquei que existem algumas GPO´s aplicadas ao serviço de firewall do Windows, liberando algumas portas e restringindo outras. Fiz uma pesquisa na internet e achei o problema.
O administrador desse ambiente criou essas GPO´s utilizando um modelo administrativo do Windows Xp de uma versão mais antiga, e com isso, as permissões padrões de acesso a interface WMI não são compatíveis com algumas das alterações feitas com o SP3 do windows XP. Para resolver isso, o administrador tem de excluir essas políticas e criá-las novamente utilizando um arquivo de modelo mais recente ou então, como “workaround” pode-se executar o seguinte comando no prompt de comando (com privilégios de administrador):
SC sdset SharedAccess D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
Esse comando irá resetar as permissões padrões dos componentes que estão com problemas. Após isso, reinicie o computador que tudo volta ao normal.
Todos sabemos da utilidade que dispositivos com interface USB podem fornecer. Seja o simples fato de fazer backups de arquivos em um Pen Drive, copiar aqueles arquivos de mídia em seu Ipod ou mesmo carregar a bateria do seu celular.
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.
O Microsoft Isa Server 2006 é uma ferramenta de controle, otimização e proteção de rede. Ela age como servidor de firewall e proxy da sua rede, além de ter um poderoso recurso de cache, o que em muitos casos pode diminuir a utilização do seu link de Internet.
A partir da versão 2004 do produto, o recurso de Log foi aprimorado permitindo inclusive que acompanhemos o tráfego de dados em modo real-time.
Em contrapartida, esse recurso tem um pequeno problema. Caso um usuário acesse alguma página de internet, no log, será gravado o IP do site acessado, e não o endereço real do site. Veja o exemplo abaixo:
No campo URL, podemos observar que consta o IP do site, e não o endereço real. Se pensarmos de modo “gerencial”, essa informação acaba não nos servindo muito, certo ? Já existem diversas alternativas comerciais que modificam esse comportamento e gravam os log’s já com o endereço correto do site.
Procurando na Internet, encontrei um plugin gratuito feito por Tarek Majdalani, um russo que tem o título de MVP da Microsoft em Isa Server. Apos baixar o plugin (aqui):
Pronto, a partir de agora o seu Isa Server irá gerar os log’s das Url’s reais acessadas pelos usuários:
