Forefront TMG + Symantec Endpoint Protection + cabo de rede conectado = blue screen (WTF...?!!)

Recentemente, lidei com dois casos semelhantes e no mínimo curiosos: servidor Windows Server 2008 R2 com Forefront TMG 2010. Ao conectar o cabo de rede, após alguns segundos, aparecia a famosa tela azul do Windows com a mensagem IRQL_NOT_LESS_OR_EQUAL e várias outras informações como bugcheck, nome do driver, etc.

Nos dois casos, se máquina fosse iniciada sem o cabo de rede, ela funcionava normalmente.

Bem, como um firewall depende de conexão com a rede, propor como solução não conectar o cabo de rede não daria muito certo :-)

Assim, foi efetuada a análise do dump gerado e descobriu-se que o componente Teefer2, era o culpado.

Em consulta rápida na internet, consegui o documento What is the Teefer2 driver?. Se vocês acessarem-no obterão que ele é o driver do componente de firewall do Symantec Endpoint Protection (SEP). De fato, este anti-virus estava instalado no servidor em ambos os casos.

Assim, como teste inicial, foi proposto desinstalar o suspeito e, bingo! O servidor de firewall Forefront TMG 2010 continuou operando mesmo após conectar o cabo de rede!

De acordo com o documento acima, não é possível apenas desabilitar o Teefer2:

Please note that it is not possible to disable the Teefer2 driver without removing SEP 11's firewall component.

Assim, para permitir que o servidor não ficasse sem anti-virus, a solução foi instalar o SEP sem o componente de firewall. De acordo com este link, a feature Network Threat Protection é responsável pelo firewall do SEP.

O Forefront TMG 2010 possui um driver (fweng) que captura o tráfego de rede da máquina para efetuar as inspeções necessárias e liberá-lo ou bloqueá-lo, de acordo com as regras. Neste caso, dois drivers em modo kernel estavam tentando efetuar a mesma operação e possivelmente, um acessou a área de memória do outro. Estou supondo isso, baseado na explicação acerca do erro IRQL_NOT_LESS_OR_EQUAL, na documentação oficial da Microsoft:

This Stop message indicates that a kernel-mode process or driver attempted to access a memory address to which it did not have permission to access. The most common cause of this error is an incorrect or corrupted pointer that references an incorrect location in memory.

Antes de instalar algum software anti-virus em um servidor com o Forefront TMG ou ISA Server, consulte o documento da Microsoft: Considerations when using antivirus software on FF Edge Products.

Espero ter contribuido de alguma forma. Em breve novos artigos!

Um abraço e até a próxima!

Printbrm, cadê as minhas portas?

Para quem deseja migrar servidores de impressão Windows, a Microsoft disponibiliza o Print Migration Wizard. Bem, mas este não é o foco do artigo. Vamos ao que realmente interessa.

Dias atrás me deparei com o seguinte problema: haviam dois servidores de terminal service. No primeiro deles foram instaladas e configuradas mais de 400 impressoras com portas UNC que direcionavam as impressões para outro servidor de impressão. Para não repetir a instalação das mais de 400 impressoras na segunda máquina, foi utilizado o Print Migration Wizard (Printbrm) para facilitar a tarefa. As impressoras foram exportadas da primeira máquina e importadas para a segunda, no entanto, após a conclusão da operação, verificou-se que as portas UNC não foram importadas no segundo servidor.

Bem, nenhum erro foi gerado em lugar algum e a importação tanto pela interface gráfica, quanto pela linha de comando, informava que a operação havia sido concluída com sucesso.

Após quebrar a cabeça um pouco verifiquei que no registro do primeiro servidor, a chave HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Ports, possuia todos os valores correspondentes as portas das impressoras e, na segunda máquina, não constavam os mesmos dados.

Fiquei intrigado e resolvi fazer alguns testes com o Printbrm e cheguei a uma conclusão. A ferramenta apenas transfere portas LPR e Standard TCP/IP, o que faz todo sentido, pois, nos servidores de impressão, as portas de impressoras sempre apontam para o endereço IP da impressora ou elas são conectadas diretamente a máquina.

As portas configuradas com UNC path são portas locais que contém o caminho \\ServidorDeImpressao\Impressora. Por se tratar de portas locais, elas não devem ser exportadas mesmo, pois são portas locais e pode variar entre diferentes computadores.

Bem, com tudo isso, para resolver o problema, no servidor de origem, as impressoras foram migradas entre as máquinas utilizando o Printbrm. Para transferir as portas, foi exportada a chave de registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Ports da máquina de origem para um arquivo .reg. Em seguida, o mesmo foi importado no servidor de destino. Para finalizar, foi necessário reiniciar o serviço Print Spooler:

> net stop spooler && net start spooler

Voilà! As impressoras e as respectivas portas UNC foram transferidas entre os servidores.

Um abraço e até a próxima!

Erro "Access is denied" ao efetuar logon em servidor de terminal service

Recentemente, me deparei com um problema um tanto bizarro. Ao tentar efetuar logon em servidor de terminal services com o Windows Server 2008 R2 SP1 instalado, utilizando uma conta do Active Directory que era membro de muitos grupos, era obtida a mensagem de erro: "Access is Denied".

Bem, ao olhar no event viewer, nenhum erro foi encontrado. Ao efetuar logon com conta, diretamente na máquina, o erro não acontecia. Ao testar em um servidor com o Windows Server 2008 SP2, o logon era efetuado com sucesso, sem erros.

Primeiramente, poderia-se pensar no problema do limite de 1015 grupos suportado pelo Active Directory, conforme descrito no artigo http://support.microsoft.com/kb/328889/en-us, porém, a conta era membro de muitos grupos, mas não chegava a 1015.

Após várias pesquisas e testes, um companheiro meu encontrou a reposta. Neste artigo da Microsoft, é descrito o valor MaxTokenSize e fala justamente sobre o problema do usuário ser membro de muitos grupos. No entanto, o documento diz que é só instalar o último service pack do sistema operacional que o problema é resolvido.

Neste caso, o último service pack estava instalado :( . Bem, encontrou-se então outro documento, situado neste link: http://support.microsoft.com/kb/938118/en-us. Ele mostra como alterar o valor MaxTokenSize.

Assim, no servidor de terminal service com problemas, foi criado o valor abaixo no registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Entrada: MaxTokenSize
Tipo: REG_DWORD
Valor: 65535

Em seguida, o servidor foi reiniciado. Após isso, o problema foi resolvido e os usuários conseguiram efetuar logon sem problemas!

 

Um abraço e até a próxima!

Bloquear gravação de arquivos indesejados em compartilhamentos do Samba

O Windows Server, a partir da versão 2003 R2, possui o recurso File Screening, o qual é possível bloquear a gravação de arquivos no servidor, utilizando uma lista com extensões. Por exemplo, para a criação de uma política que bloqueia arquivos de música, as extensões mp3, wma, ogg, entrariam para a lista.

Bem, felizmente, para quem utiliza a dupla Linux/Samba, também é possível realizar tal bloqueio e de forma simples. Vamos supor que se deseja negar a gravação dos arquivos de música citados acima nos compartilhamentos.

No arquivo de configuração do Samba, vá até a seção das opções do compartilhamento e insira a diretiva abaixo:

veto files = /*.mp3/*.wma/*.ogg/

Na realidade, a política se aplica a arquivos que terminam com o nome .mp3, .wma e .ogg. Desta forma, também possível, por exemplo, bloquear arquivos que contém a string xxx no nome:

veto files = /*xxx*/

Abaixo há um exemplo da diretiva aplicada a um compartilhamento:

[documentos]
        comment = Documentos da rede
        path = /var/documentos
        valid users = @usuarios
        write list = @admin
        read only = No
        create mask = 0770
        directory mask = 0770
        veto files = /*.mp3/

Lembrando que após esta alteração é necessário reiniciar o daemon do Samba.

Esta diretiva irá não só bloquear a gravação dos arquivos, mas também irá ocultar os que já existem. Os usuários não conseguirão visualizá-los ao acessar a pasta compartilhada.

Uma outra dica é excluir ou mover os arquivos indesejados nas pastas compartilhadas do servidor de arquivos:

# find /var/documentos -name "*.mp3" -exec rm -fv {} \; (Para excluir os arquivos)

# find /var/documentos -name "*.mp3" -exec mv {} /var/lixo \; (Para mover os arquivos)

Um abraço e até a próxima.