Usuários restristos não conseguem acessar conteúdo da lixeira!

Olá pessoal,

Neste post falaremos sobre um caso onde os usuários que não tem direito administrativo, não conseguem visualizar o conteúdo da lixeira do Windows.
Ao acessar a lixeira, nada é exibido, mesmo que o icone da lixeira apareça como cheio.

Usuários que tem o perfil de administrador conseguem acessar e visualizar o conteúdo da lixeira normalmente.

Uma vez que usuários com direitos administrativos são capazes de visualizar o conteúdo da lixeira do Windows sem nenhum problema e os usuários restritos não conseguiam, o primeiro ponto a ser verificado são as permissões e direitos para os usuários.

Para identificarmos qual acesso estava sendo negado, utilizamos a ferramenta Process Monitor, disponível em http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

O Process Monitor é uma ferramenta de monitoramento avançado para Windows que nos mostra em tempo real as atividades no sistema de arquivos,  registro, processos, e atividades de threads.

Com isso, simulamos o problema (acessando a lixeira com o usuário restrito) rodando o monitoramento do Process Monitor.
O Process Monitor nos trouxe a informação de que o acesso estava sendo negado para o usuário para a pasta $Recycle.bin no disco C:\

A partir desse ponto, partimos para verificar que tipo de permissão estava faltando nesta pasta, comparando-a com a de um sistema sem problemas.
Usamos a ferramenta CACLS, para comparar as permissões:
No disco C: o CACLS nos mostrou as seguintes permissões para a pasta $Recycle.bin

*********************************************
C:\>CACLS $RECYCLE.BIN
C:\$RECYCLE.BIN AUTORIDADE NT\SISTEMA:(OI)(CI)(ID)F
                BUILTIN\Administradores:(OI)(CI)(ID)F
                BUILTIN\Usuários:(OI)(CI)(ID)R
*********************************************

O resultado esperado para as permissões da pasta $Recycle.bin seriam:

*********************************************
E:\$RECYCLE.BIN BUILTIN\Administrators:(OI)(CI)F
                NT AUTHORITY\SYSTEM:(OI)(CI)F
                BUILTIN\Users:(NP)(special access:)
                                  READ_CONTROL
                                  SYNCHRONIZE
                                  FILE_GENERIC_READ
                                  FILE_GENERIC_EXECUTE
                                  FILE_READ_DATA
                                  FILE_APPEND_DATA
                                  FILE_READ_EA
                                  FILE_EXECUTE
                                  FILE_READ_ATTRIBUTES
                                  FILE_WRITE_ATTRIBUTES
*********************************************

A partir desse ponto podemos observar que algumas permissões para o grupo Users estavam faltando.
Verificamos manualmente estas permissões e identificamos que o grupo users não tinham as permissões marcadas abaixo:

• Create Folders / Append data
• Write Attributes

Marcamos as entradas conforme a imagem abaixo, para o grupo Users, e após essas permissões os usuários restritos conseguiram visualizar o conteúdo da lixeira normalmente.

Como diversas máquinas possuíam este mesmo problema e foram instaladas a partir de uma imagem, sugerimos que as permissões da pasta $Recycle.bin fossem restauradas utilizando o comando CACLS abaixo:

*************************************************************************************
cacls C:\$Recycle.Bin /S:"D:PAI(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;;0x1201ad;;;BU)"
*************************************************************************************

Esta linha de comando restaura as permissões originais para a pasta $Recycle.bin.
Através dessa linha de comando é possível criar um script para que o processo de de restauração das pastas sejam realizados de forma automática. (é necessário direitos administrativos para rodar  a linha de comando)

Com o script abaixo você consegue realizar a mudança de forma automática para diversas máquinas.

***************************************************
::BEGIN BATCH FILE
@echo Y> Y.txt
@cacls C:\$Recycle.Bin /S:"D:PAI(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;;0x1201ad;;;BU)" <Y.txt
@del Y.txt
::END BATCH FILE
***************************************************
Espero que este post ajude quem tem o mesmo sintoma a resolver o problema, caso tenha algum problema parecido você pode seguir a mesma linha de troubleshooting, através do Procmon e verificando se existe algum acesso negado.

Abraços e até o próximo post!

GPO que configura "Trusted Sites" não é aplicada à Servidores de TS 2003

Neste caso uma GPO que configura a opção de trusted sites  (Sites Confiávies ) no Internet Explorer não está sendo aplicada, na verdade a GPO é aplicada, porém o Internet Explorer não traz as configurações. Porquê isso acontece? Hoje vamos falar um pouco deste estranho comportamento e como conseguimos descobrir a causa desse problema e por fim, resolvê-lo de maneira definitiva.

Identificamos que a GPO que configura os sites confiáveis no Ineternet Explorer (TS Group policy Object) estava sendo aplicada com sucesso na máquina cliente, pois através do comando Gpresult /Z e verificando as chaves de Registro as quais as políticas devem ser aplicadas na máquina cliente estava comfiguradas conforme as imagens abaixo:

Trechos do “Output” do comando Gpresult /z (Modo verbose) que identificam que a política estava sendo aplicada:

Além do Gpresult, se abríssemos o registro do Windows na máquina cliente podiámos ver que o registro aceitou as configurações da GPO conforme a saída do Gpresult

Habilitamos o log de userenv para nos certificar se algum erro estava ocorrendo quando a GPO estava sendo aplicada. Para habilitar o log seguimos o procedimento abaixo:

Para habilitar o log de userenv:

Criar a entrada:

Entrada: UserEnvDebugLevel
Tipo: REG_DWORD
Valor: 30002 Hexadecimal

Esta entrada deve ser criada em: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Simulamos o logoff e logon e identificamos que um erro era exibido no log de uservenv ao aplicar a GPO que configura o Trusted Sites ao Internet Explorer.
O log de userenv é salvo em  %Systemroot%\Debug\UserMode\Userenv.log

Neste log identificamos que a GPO exibia um erro ao ser aplicada:


O erro 0x57 Significa parâmetro inválido conforme podemos comprovar na ferramenta Err disponível para download em:
http://www.microsoft.com/en-us/download/details.aspx?id=985 - Microsoft Exchange Server Error Code Look-up

Além desses erro, no log de aplication do Event Viewer podiámos perceber que a GPO exibia erros ao ser aplicada:

Partindo desse ponto, sugerimos o plano de ação a seguir para isolar qualquer problema com a sintaxe das URLs configuradas no trusted sites.

Criar ou modificar a GPO existente para que apenas uma entrada seja adicionada aos sites confiávies. Uma entrada simples por exemplo  http://www.microsoft.com  
O objetivo era  verificarmos se a GPO está funcionando como deveria apenas com esta entrada simples, pois na entrada que temos no ambiente atualmente temos listas duplicadas, e com problemas de sintaxe que podem acarretar em problemas como esses.

Configuramos a GPO para que apenas o site http://www.microsoft.com fosse configurado como Trusted Sites.
Após este procedimento o log de userven não registrou mais erros, porém a GPO continuava não sendo aplicada no Internet Explorer.

A partir desse ponto, passamos a verificar outros pontos que não estivessem ligados com a GPO, pois todas as evidências apontavam de que a GPO estava sendo aplicada corretamente, porém o Internet Explorer não exibia as configurações recebidas pela política.

Indentificamos que a feature Internet Enhanced Security estava habilitada no servidor em questão, e que a mesma não podia ser desabilitada, pois no adicionar e remover componentes do Windows o checkbox já encontrava desmarcado.

Imagem que indica que o Internet Enhanced Security estava habilitado no servidor e ao tentar removê-lo no Windows Components o checkbox já se encontrava desmarcado

Com isso identificamos o seguinte cenário descrito no artigo  http://support.microsoft.com/kb/933991/en-us - Standard users cannot turn off the Internet Explorer Enhanced Security feature on a Windows Server 2003-based terminal server

Onde o sintoma descrito é exatamente o do checkbox:

“After you configure a Microsoft Windows Server 2003-based terminal server, standard users cannot turn off the Internet Explorer Enhanced Security Configuration feature. When a standard user clicks to clear the Internet Explorer Enhanced Security Configuration check box, the check box remains clear as expected. However, Internet Explorer Enhanced Security Configuration is still enabled.”

Para isso seguimos a solução descrita no método 3 do artigo, deletando a entrada IEHarden do registro em “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zonemap”

Após esse procedimento a política foi aplicada com sucesso e as configurações apareceram no Internet Explorer. Inclusive voltando a GPO antiga que apresentava problemas de sintaxe

Caso você queira realizar este procedimento automaticamente, sugiro que a linha abaixo seja incluída em um script de logon:

*********************************************************************************
REG DELETE "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap" /v "IEHarden" /f
*********************************************************************************

Com a linha abaixo a entrada no registro será deletada desabilitando o Enhanced Security de forma automática para os usuários através do script de logon, automatizando o processo para todos os usuários.

Artigos relacionados:

Abaixo disponibilizo uma lista de artigos que usamos para a resolução deste problema e que nos serviu de apoio em todo o processo de troubleshooting.

http://support.microsoft.com/kb/933991/en-us - Standard users cannot turn off the Internet Explorer Enhanced Security feature on a Windows Server 2003-based terminal server

http://support.microsoft.com/default.aspx?scid=KB;EN-US;221833  - How to enable user environment debug logging in retail builds of Windows (221833)

http://support.microsoft.com/kb/259493  - Problemas ao adicionar domínios de nível superior à lista de Sites da zona