mar 142015
 

SOBRE A FERRAMENTA / INSTALAÇÃO

 

SOBRE A FERRAMENTA

Trata-se de uma ferramenta de compartilhamento de arquivos bem parecida com o Dropbox, Google Drive etc. Mas eu considero uma ferramenta bem mais interessante para minhas necessidades, pois posso controlar o tamanho da massa de arquivos e os arquivos propriamente ditos, pois o servidor está em minha infraestrutura física.

Caso queira conhecer melhor a ferramenta, acesse:

INSTALAÇÃO

Vou explicar a instalação tendo como base a minha, que foi feita em Debian 7:

# apt-get install apt-build apt-essentials build-essentials
# wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/Release.key
# apt-key add – < Release.key
# echo ‘deb http://download.opensuse.org/repositories/isv:/ownCloud:/community/Debian_7.0/ /’ >> /etc/apt/sources.list.d/owncloud.list

# apt-get update && upgrade
# apt-get install mysql-server
# apt-get install mysql-client php5-mysql
# apt-get install php5-ldap
# apt-get install php5-ffmpeg php5-imagick
# apt-get install libcurl3 curl php5-curl php5-mcrypt php5-intl
# apt-get install libreoffice
# apt-get install apache2 php5
# apt-get install owncloud

Continue reading »

Autenticação de servidores CentOS/Red Hat 6 em Windows 2008

 Clusterweb, Linux, Windows  Comentários desativados em Autenticação de servidores CentOS/Red Hat 6 em Windows 2008
ago 212012
 
Introdução – Pré-requisitos

Este artigo foi criado para ensinar a configuração de autenticação de servidores CentOS e Red Hat(versão 6) no Windows 2008.Diversos artigos encontrados na Internet, fazem uso do Winbind para possibilitar esta autenticação, contudo, como esta configuração depende da instalação do serviço Samba (e consequente abertura de portas, vulnerabilidades, etc), optei por fazer esta configuração utilizando-se apenas do serviço de LDAP, que já é disponibilizado pelo Windows 2008, e pelo serviço Kerberos 5.

Assim, não é necessária a abertura de nenhuma porta nos clientes de autenticação, e caso seja uma autenticação entre redes distintas com firewall, apenas a abertura das portas do LDAP, Kerberos 5 e DNS serão suficientes.

Definições

Estas definições serão utilizadas durante o artigo, e serão explicadas conforme o desenvolvimento do mesmo:

  • Domínio: SPRINGFIELD.CORP (LDAP: DC=SPRINGFIELD, DC=CORP)
  • Hostname do Domain Controller: Homer (HOMER.SPRINGFIELD.CORP)
  • IP do Domain Controller: 192.168.5.151
  • Conta de serviço LDAP: CN=AuthLinux,CN=Users,DC=Springfield,DC=Corp
  • Usuário criado para testes de Logon: rkatz@SPRINGFIELD.CORP
  • Grupo criado com atributos Unix: Linux

Configuração do Windows 2008 (Domain Controller)

Assumindo que o seu Domain Controller já esteja instalado e em funcionamento, as seguintes configurações abaixo deverão ser feitas:

1. Atualização do ambiente

Não é necessariamente um pré-requisito para o correto funcionamento do ambiente, mas recomendo executar um ‘Windows Update’ no ambiente, apenas por garantia. 😉

2. Instalação do Unix Integration Tools

Para que a autenticação funcione com sucesso, devemos instalar o Unix Integration Tools nos Domain Controllers. Esta nova rolecria atributos específicos necessários para a autenticação em Unix/Linux, como Home Directory e Default Shell.

  • Em Server Manager, na aba (lateral esquerda), selecionar ‘Roles’.
  • Na seção ‘Role Services’ da role ‘Active Directory Domain Services’, adicionar o serviço ‘Identity Management for Unix’, através do link ‘Add Role Services’, incluindo todos os demais serviços (Server for Network Information Services, Password Syncronization e Administration Tools).

Criação das contas no DC

Para o correto funcionamento da configuração, devemos criar uma conta de serviço que será utilizada para o BIND (conexão) ao LDAP, uma vez que o Windows 2008 não permite conexão anônima ao LDAP. Também criaremos um grupo e uma conta exemplo, que serão utilizados nos testes de Login.

Conta de serviço

Esta conta deverá ser criada com a política de “não expiração de senha”, pois esta senha será utilizada na configuração de todos os clientes. Caso a senha expire, a mesma deverá ser trocada no servidor, e consequentemente em todos os clientes.

* Importante: Lembre-se ao criar esta conta, de que o ‘Full Name’ da conta criada é utilizada como RDN no LDAP.

Exemplo:

  • FullName=Bart Simpson
  • CN=Bart Simpson
  • CN=Users
  • DC=Domínio.

Assim, recomenda-se criar a conta com um ‘Full Name’ de uma palavra, como ‘AuthLinux’, para não haver maiores problemas.

A conta será criada conforme abaixo:

  • FullName: AuthLinux
  • User Logon Name: AuthLinux
  • Senha (exemplo, alterar no seu ambiente): 12qw!@QW
  • Configurações: ‘User Cannot Change Password’, e ‘Password Never Expires’

Após a criação desta conta de serviço, alterar o seu grupo, colocando-o apenas como membro do grupo “Domain Guests” e removendo todos os demais grupos, de forma que este usuário não possua nenhuma permissão no domínio.

Criação do Grupo

Ou, alteração de grupo já existente.

Deve ser criado um grupo (ou alterado um já existente) para que o mesmo possua atributos Unix, possibilitando sua utilização em nosso ambiente. Isso deve ser feito, primeiro criando-se o grupo (caso já não exista) e depois, alterando-o conforme abaixo.

No nosso exemplo, foi criado o grupo “Linux”. Após isso, na aba ‘Unix Attributes’ das propriedades do grupo, alterar o NIS Domain para ‘SPRINGFIELD’ (ou o Domínio utilizado). Manter o GID criado padrão, e não adicionar nenhum usuário no grupo.

Criação de usuário com permissão de Login

Ou, alteração de usuário já existente.

Um usuário deve ser criado (ou alterado) de forma que possamos efetuar logon em um ambiente Unix. Nesse artigo, será criado o usuário ‘rkatz’, conforme abaixo:

  • Criar o usuário (ou alterar) desabilitando a opção ‘User Must Change Password on Next Logon’;
  • Editar o usuário, e na aba ‘Unix Attributes’ alterar o NIS Domain para ‘SPRINGFIELD’;
  • Alterar o ‘Login Shell’ para o Shell padrão utilizado no ambiente (como /bin/bash);
  • E, Primary group Name/GID para o grupo criado acima (Linux).
Configuração do S.O.

Assumindo que sua instalação do sistema operacional já esteja feita (eu utilizei o CentOS neste artigo), os seguintes passos devem ser feitos:

Atualização do sistema operacional

Tal como no ambiente Windows, esse não é um pré-requisito, mas altamente recomendável para garantirmos a estabilidade da autenticação.

Configuração de DNS e NTP

O nosso cliente deve ‘conhecer’ o domínio que será utilizado, para o seu correto funcionamento. Assim, no arquivo /etc/resolv.conf, o IP dos Domain Controllers do ambiente, deverão ser utilizados conforme abaixo:

nameserver 192.168.5.151

Testar o funcionamento, efetuando um nslookup (ou ping, mesmo) para o nome SPRINGFIELD.CORP (Domínio) e HOMER.SPRINGFIELD.CORP (Domain Controller) e verificar o correto funcionamento.

Também, o horário do cliente deverá estar sincronizado com o do restante do domínio. Assim, os pacotes do NTP deverão ser instalados:

# yum install ntp ntpdate

Após a instalação dos pacotes de NTP, uma primeira sincronização deverá ser efetuada com o comando ntpdate:

# ntpdate springfield.corp

Feita a primeira sincronização do horário, o arquivo /etc/ntp.conf deve ser editado, removendo-se todas as linhas ‘server’ e adicionando apenas a seguinte:

server springfield.corp

Após isso, adicionar o serviço de NTP à inicialização do ambiente, e iniciar o serviço. Então, verificar o funcionamento:

# chkconfig ntpd on
# /etc/init.d/ntpd on
# ntpq -c pe

remote             refid        st t  when poll reach  delay   offset   jitter
==============================================================================
192.168.5.151   200.160.7.186   2  u   12   64   377    0.762  449.851  17.746

Instalação dos pacotes de autenticação e Kerberos

Em uma instalação padrão os pacotes necessários para autenticação não vem instalados por padrão. Assim, devemos instalar os pacotes necessários, conforme abaixo:

# yum install nss-pam-ldapd krb5-workstation pam_krb5 nscd openldap-clients

Verificação de conta de serviço

Para garantirmos o correto funcionamento, a conta de serviço criada na configuração do Windows 2008 (AuthLinux) deverá ser testada. Podemos testar essa conta com o seguinte comando (será solicitada a senha da conta):

# ldapsearch -v -x -H “ldap://springfield.corp” -D “cn=AuthLinux,cn=Users,dc=Springfield,dc=corp” -b “dc=Springfield,dc=corp” -s sub -W

Caso o comando não retorne nenhum erro (mas uma saída LDIF), a conta de serviço está funcionando corretamente. Caso contrário, deverá ser verificado se os dados utilizados para autenticação (cn, senha) estão corretos.

Autenticação LDAP

Após a configuração do ambiente, devemos configurar o sistema operacional de forma a autenticar-se no AD. As seguintes configurações devem ser efetuadas:

NSLCD (Autenticação LDAP)

O NSLCD (local LDAP name service daemon) será utilizado para a autenticação ao LDAP. Antes configurado através do arquivo /etc/ldap.conf (no RHEL 5 e derivados), agora este recurso possui um daemon próprio.

Para configurá-lo, devemos alterar o arquivo /etc/nslcd.conf conforme abaixo (as explicações estão nos comentários do arquivo):

# Versao LDAP
ldap_version 3
# Usuario e grupo para executar o daemon
uid nslcd
gid ldap# Limite de timeout de bind e de busca
bind_timelimit 30
timelimit 30

# Servidor LDAP e BaseDN
uri ldap://springfield.corp
base dc=springfield,dc=corp

# O SSL ainda não será configurado
ssl no
tls_cacertdir /etc/openldap/cacerts

# usuário e senha de serviço
binddn cn=AuthLinux,cn=Users,dc=springfield,dc=corp
bindpw 12qw!@QW

scope sub
scope   group   sub scope   hosts   sub

# Ignorar lookup de grupos para os usuários de sistema
nss_initgroups_ignoreusers root,nslcd,bin,daemon,mail,nobody,sshd,nscd,ntp

# Caso seja necessário algum filtro, para apenas algum usuário de algum grupo logar
# pam_authz_search (gidNumber=10000)

# Configuracoes de Mapping – AD
pagesize 1000
referrals off
filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    passwd uid            sAMAccountName
map    passwd homeDirectory  unixHomeDirectory
map    passwd gecos          displayName
filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    shadow uid            sAMAccountName
map    shadow shadowLastChange pwdLastSet
filter group (objectClass=group)
map    group uniqueMember    member

Após isso, devemos iniciar o daemon do nslcd e colocá-lo na inicialização:

# chkconfig nslcd on
# /etc/init.d/nslcd on

Kerberos 5

A configuração do Kerberos deverá ser feita de forma a validar um usuário, e permitir, entre outras coisas, sua autenticação e posteriores operações (como query de grupos a que pertence, etc).

A configuração deverá ser feita conforme abaixo.

Alterar o arquivo /etc/krb5.conf, conforme abaixo (as explicações estão nos comentários do arquivo):

# Nao validar o hostname do servidor (senao precisa de entradas no DNS e Reverso)
[appdefaults]
validate = false# Locais de Logging
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

# Configuracoes Padrao
[libdefaults]
# Dominio Padrao – SPRINGFIELD.CORP – Deve ser o mesmo do AD
default_realm = SPRINGFIELD.CORP
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

[realms]
# Configuracao do servidor de KERBEROS
# Utilizando o nome do DOMINIO, ele vai para o DC
SPRINGFIELD.CORP = {
kdc = SPRINGFIELD.CORP
admin_server = SPRINGFIELD.CORP
}

# Configuracoes de DOMINIO – Qual REALM deve ser usado para qual dominio
[domain_realm]
springfield.corp = springfield.corp
.springfield.corp = springfield.corp

Testar a geração de um ticket de autenticação para um usuário qualquer do domínio, como o Administrador:

# kinit -V Administrator@SPRINGFIELD.CORP

A saída seria:

Using default cache: /tmp/krb5cc_0
Using principal: Administrator@SPRINGFIELD.CORP
Password for Administrator@SPRINGFIELD.CORP: [DIGITAR A SENHA]
Authenticated to Kerberos v5

Caso o retorno seja diferente de:

Authenticated to Kerberos v5

A configuração deve ser verificada novamente, pois alguma configuração foi efetuada incorretamente.

Configuração do NSCD e NSSWITCH

Devemos agora, configurar o daemon de cache de logins, e o NSSWITCH, que irá direcionar a autenticação de usuários e grupos para o NSLCD (LDAP), caso não seja encontrado um usuário local.

Por padrão, o arquivo /etc/nscd.conf já vem configurado com parâmetros aceitáveis, sendo necessário apenas descomentar a linha “logfile /var/log/nscd.log”, para que o daemon efetue log, caso algo dê errado.

Devemos então, alterar o arquivo /etc/nsswitch.conf, deixando as linhas: passwd, shadow e group, conforme abaixo:

  passwd:    files ldap
shadow:    files ldap
group:     files ldap

Por fim, o daemon do NSCD deve ser colocado na inicialização do S.O., e ser iniciado:

# chkconfig nscd on
# /etc/init.d/nscd start

Para verificar o funcionamento correto da configuração, utilizar o comando getent no usuário e grupo criado na etapa de “Pré requisitos”:

# getent passwd rkatz

A saída seria:

rkatz:*:10002:10000:Ricardo P. Katz:/home/rkatz:/bin/bash

E:

# getent group Linux

Linux:*:10000:rkatz

Configuração do PAM

A etapa final da configuração é a alteração do PAM (Plugable Authentication Modules), de forma que as autenticações do Sistema Operacional sejam enviadas ao servidor LDAP (Domain Controller).

Adicionalmente, quando um usuário não possuir diretório ‘home’ no ambiente, o esperado é que o PAM crie esse diretório.

O arquivo /etc/pam.d/system-auth deverá ser alterado para ficar conforme abaixo. O arquivo aqui é um exemplo, sugiro que verifique se não há nenhum mecanismo de autenticação já em uso no ambiente, e adeque as configurações às suas necessidades:

#%PAM-1.0
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so
password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    required      pam_deny.so
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     required      pam_mkhomedir.so skel=/etc/skel umask=0022
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so

Alterar também o arquivo /etc/pam.d/password-auth, conforme configuração abaixo:

#%PAM-1.0
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so
account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so
password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    required      pam_deny.so
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so

Após as alterações, logar-se em um novo terminal com o usuário criado no AD (no exemplo, o usuário: rkatz), e verificar se o login é autorizado, bem como o diretório home criado.

Verificar também com o comando id, se os grupos a que o usuário pertence são carregados. Caso não funcione, os arquivos /var/log/messages e /var/log/secure podem ser verificados em busca de erros.

Habilitação de SSL (LDAPs)

Para que as informações não fiquem trafegando em texto plano, faz-se necessária a configuração de comunicação utilizando-se de SSL.Assume-se que, o AD já esteja com essa funcionalidade (LDAPS) habilitada.

Caso não, pode ser verificado em

Alterar o arquivo /etc/openldap/ldap.conf, para que ele não reclame do certificado de CA inválido apresentado pelo servidor:

TLS_REQCERT never

Testar a comunicação com o comando abaixo (note que é o mesmo comando de teste anterior, chamando o protocolo LDAPS ao invés de LDAP apenas):

ldapsearch -v -x -H “ldaps://springfield.corp” -D “cn=AuthLinux,cn=Users,dc=Springfield,dc=corp” -b “dc=Springfield,dc=corp” -s sub -W

Conforme o teste funcione com sucesso, o arquivo /etc/nslcd.conf deverá ser alterado para permitir a utilização do SSL, alterando-se as seguintes linhas:

uri ldaps://springfield.corp
ssl yes
tls_cacertdir /etc/openldap/cacerts
tls_reqcert never

Reiniciar o NSLCD e o NSCD, e verificar o funcionamento com o:

# getent passwd USUARIO

Conclusões

Apesar de parecer complexa, a configuração de integração entre o GNU/Linux e o AD pode ser feita de forma bastante simples.

Esta é uma necessidade que muitas empresas têm, pois possuem seus controladores de domínio e, por diversas vezes, os seus servidores GNU/Linux não possuem uma forma de controle tão refinada quanto os servidores Windows.

Espero ter contribuído com qualquer necessidade.

Qualquer dúvida, estou à disposição. 😉

Squid autenticando em Windows 2003 com msnt_auth

 Clusterweb, Linux, Proxy  Comentários desativados em Squid autenticando em Windows 2003 com msnt_auth
jan 122012
 
Configurando o msnt_auth

Primeiramente iremos configurar o msnt_auth, que é responsável pela autenticação dos usuários no Windows 2003.

No diretório do Squid (/etc/squid/) temos o arquivo msntauth.conf, onde devemos inserir os nomes dos servidores 2003 e o nome do domínio.

Suponhamos que meus servidores estejam configurados da seguinte maneira:

  • PDC = srv01 > 192.168.0.1
  • BDC = srv02 > 192.168.0.2
  • domínio = meudominio

Deixe o conteúdo do msnauth.conf da forma como esta no exemplo abaixo, apenas alterando as informações dos servidores.

OBS: Caso você tenha apenas 1 controlador de domínio, informe o mesmo nome no BDC.

#################################################### # Sample MSNT authenticator configuration file # Antonino Iannella, Stellar-X Pty Ltd # Sun Sep 2 15:52:31 CST 2001 # NT hosts to use. Best to put their IP addresses in /etc/hosts.
server my_PDC           my_BDC          my_NTdomain
server srv01 srv02 meudominio

# Denied and allowed users. Comment these if not needed. #denyusers /usr/local/squid/etc/msntauth.denyusers #allowusers /usr/local/squid/etc/msntauth.allowusers ###################################################
Após configurado o arquivo, coloque em /etc/hosts o nome e o ip dos servidores da seguinte forma:
# Do not remove the following line, or various programs # that require network functionality will fail.
127.0.0.1       firewall localhost.localdomain localhost
192.168.0.1     srv01
192.168.0.2     srv02
Configuração do Squid

Agora devemos editar o arquivo squid.conf. Devemos inserir as seguintes linhas:
auth_param basic program /usr/lib/squid/msnt_auth
auth_param basic children 5
auth_param basic realm Proxy Cache Teste
A última linha pode ser alterada de acordo com sua preferência, pois é a mensagem que o mesmo mostrará na tela onde deverá ser informado usuário e senha.

Após criaremos 2 arquivos no diretório do Squid, “usuarios”, onde colocaremos os usuários que terão o acesso e no “usuarios-total” os usuários que não passaram por nenhuma restrição do proxy.

Criando as acl’s de acesso no squid.conf:

#usuarios-total
acl user-total proxy_auth “/etc/squid/usuarios-total”

#usuarios
acl users proxy_auth “/etc/squid/usuarios”

Não devemos esquecer de criar a ACL de autenticação:
acl autenticar proxy_auth REQUIRED
Após isso é só criar as acl’s de bloqueio normalmente e liberar a autenticação dos usuários como exemplo abaixo:
http_access allow autenticar user-total
bloqueia o que for preciso
http_access allow autenticar user
http_access deny all
Exemplo de squid.conf

Estou disponibilizando aqui meu squid.conf com alguns bloqueios por site, palavras, extensões e msn.
http_port 3128
visible_hostname squid
acl QUERY urlpath_regex cgi-bin \?

cache_dir ufs /var/spool/squid 2048 16 256
cache_mem 32 MB

auth_param basic program /usr/lib/squid/msnt_auth
auth_param basic children 5
auth_param basic realm Proxy Cache Teste
#auth_param basic credentialsttl 10 hours

#ACL PADRAO

acl all src 0.0.0.0/0.0.0.0
acl autenticar proxy_auth REQUIRED
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

#ACLS RISOTO

#ACL liberados

acl liberados url_regex “/etc/squid/control/liberados”

#ACL acesso TI

acl ti-usuarios proxy_auth “/etc/squid/control/ti/usuarios”

#ACL acesso DIRETORIA

acl diretoria src “/etc/squid/control/diretoria/usuarios”

#ACL acesso Usuarios

acl usuarios proxy_auth “/etc/squid/control/usuarios/usuarios”
acl usuarios-msn proxy_auth “/etc/squid/control/usuarios/usuarios-msn”
acl proibidos_usuarios url_regex “/etc/squid/control/usuarios/proibidos”
acl palavras_usuarios url_regex -i “/etc/squid/control/usuarios/palavras”
acl arquivos_usuarios urlpath_regex -i “/etc/squid/control/usuarios/arquivos”

#ACL acesso Gerencia

acl gerencia proxy_auth “/etc/squid/control/gerencia/usuarios”
acl proibidos_gerencia url_regex “/etc/squid/control/gerencia/proibidos”
acl palavras_gerencia url_regex -i “/etc/squid/control/gerencia/palavras”
acl arquivos_gerencia urlpath_regex -i “/etc/squid/control/gerencia/arquivos”

no_cache deny QUERY

#sem msn
acl bqmsn dstdomain passport.com
acl msnmessenger url_regex -i gateway.dll
acl msn req_mime_type -i ^application/x-msn-messenger$

#LIBERA/BLOQUEIA ACESSO A NET

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSl_ports
http_access allow localhost

http_access allow liberados
http_access allow diretoria
http_access allow autenticar ti-usuarios
http_access deny proibidos_gerencia
http_access deny palavras_gerencia
http_access deny arquivos_gerencia
http_access allow autenticar gerencia

http_access deny proibidos_usuarios
http_access deny palavras_usuarios
http_access deny arquivos_usuarios

http_access allow autenticar usuarios-msn

http_access deny bqmsn
http_access deny msnmessenger
http_access deny msn

http_access allow autenticar usuarios
http_access deny all