Arquivo
SSO: Apache e Samba4
Em um post anterior mostrei a configuração de autenticação do Apache no Samba2 utilizando o NTLM. Seguindo a mesma idéia, vou mostrar a configuração de autenticação do Apache em domínios Samba4 utilizando os usuários já autenticados na rede. Serão mostradas algumas configurações diferentes, dependentes dos clientes ou serviços utilizados.
Obs: Já estou considerando que o domínio samba4 já está funcional e com o kerberos e o DNS corretamente configurados.
– Configurações utilizando o NTLM
Nos testes realizados, o NTLM funcionou corretamente quando configurado em clientes rodando o samba3 e autenticando no samba4.
É necessário habilitar o módulo do NTLM no apache, vamos baixá-lo e habilitá-lo:
# apt-get install libapache2-mod-auth-ntlm-winbind # a2enmod auth_ntlm_winbind
Adicionar o usuário de execução do Apache ao grupo do Winbind:
# adduser www-data winbindd_priv
Nos arquivos de configurações dos alias (/etc/apache2/conf.d) ou sites do apache (/etc/apache2/sites-available) , adicionar as seguintes configurações:
AuthType NTLM AuthName "Autenticar Acesso" NTLMAuth on NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp \ --domain=dominio.com" NTLMBasicAuthoritative off require valid-user
Ou a seguinte para autenticação baseada em grupos de acesso:
AuthType NTLM AuthName "Autenticar Acesso" NTLMAuth on NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp \ --domain=dominio.com --require-membership-of=DOMINIO\\\grupo" NTLMBasicAuthoritative off require valid-user
Após as alterações aplicadas, reiniciar o serviço:
# /etc/init.d/apache2 restart
OBS: Nos servidores executando o samba4, a autenticação NTLM funcionou somente no primeiro caso. Quando a autenticação por grupos foi necessária, o serviço não funcionou corretamente.
– Configurações utilizando o Kerberos
É necessário criar uma zona de pesquisa inversa no DNS e adicionar um registro para o servidor onde o apache é executado:
# samba-tool dns zonecreate DC 0.168.192.in-addr.arpa # samba-tool dns add DC 0.168.192.in-addr.arpa 200 PTR webserver.domain.com
Onde:
– DC = nome do controlador de domínios
– webserver = servidor de IP 192.168.0.200
– domain.com = domínio DNS
Agora vamos criar um usuário com senha randômica que será usado para criação do SPN (Service Principal Name) e exportar o keytab do domínio:
# samba-tool user create --random-password http-server # samba-tool spn add HTTP/server.domain.com@SENIOR.LOCAL.TLD http-server # samba-tool domain exportkeytab http.keytab --principal=HTTP/server.domain.com@DOMAIN.COM.TLD
Vamos mover o arquivo criado para o diretório do apache e ajustar as permissões:
# mv http.keytab /etc/apache2/ # chown root:www-data /etc/apache2/http.keytab # chmod 640 /etc/apache2/http.keytab
Também é necessário habilitar o módulo do kerberos no apache:
# apt-get install libapache2-mod-auth-kerb # a2enmod auth_kerb # a2enmod authnz_ldap
No site (nesta caso a autenticação configurada no conf.d não funcionou) correspondente à aplicação que necessita de autenticação, adicionar as configurações:
<Directory /caminho_aplicacao> AuthType Kerberos AuthName "Intranet Login" KrbMethodNegotiate on KrbMethodK5Passwd on KrbLocalUserMapping on Krb5Keytab /etc/apache2/http.keytab KrbAuthRealms DOMAIN.COM Require valid-user </Directory>
Para a autenticação baseada em grupos de acesso deve ser usada a seguinte configuração:
<Directory /caminho_aplicacao>
AuthType Kerberos
AuthName "Intranet Login"
KrbMethodNegotiate on
KrbMethodK5Passwd on
KrbLocalUserMapping on
Krb5Keytab /etc/apache2/http.keytab
KrbAuthRealms DOMAIN.COM
Require valid-user
AuthLDAPURL "ldap://server1.domain.com/ou=users,dc=domain,dc=com?sAMAccountName"
AuthLDAPBindDN user@domain.com
AuthLDAPBindPassword password
require ldap-group cn=grupo,ou=groups,dc=domain,dc=com
</Directory>
Referências:
Proxy reverso com Apache
Muita gente enxerga o proxy apenas como um servidor que intermedia as requisições entre a rede local e a internet, fazendo cache de páginas e controle de acesso. Sem dúvidas, o serviço mais conhecido e utilizado para este fim é o Squid (http://www.squid-cache.org/). Mas o Proxy tem outra característica/função, pouco conhecida mas muito útil: o Proxy Reverso.
Proxy Web x Proxy Reverso
O Proxy Web corresponde à ‘função’ conhecida pela maioria das pessoas. Nesta configuração, o proxy tem a função de compartilhar a internet com a rede local, receber as requisições feitas pelos clientes e buscar o que foi solicitado nos servidores Web. Além disso, o Proxy oferece mais algumas vantagens a um administrador de redes, como:
- Controle de acesso: O acesso à internet pode ser controlado com base no horário, endereço IP do cliente, login e sites com conteúdo indesejado;
- Cache de páginas: o Proxy guarda informações das páginas acessadas. Quando alguém acessa um endereço, o servidor procura primeiro nos seus arquivos armazenados, caso já possua a página, não precisa buscá-la novamente. O que acaba tornando a navegação mais rápida e evitando acessos desnecessários à Web;
- Relatórios de acesso: Todos os logs de acesso são armazenados, o que permite que possam ser criados relatórios dos acessos realizados pelos clientes através do servidor;
O Proxy Web possui tanto função de servidor quanto de cliente. É servidor quando possui os objetos solicitados pelos navegadores e lhe envia as respostas. É cliente quando não possui algum objeto solicitado e precisa requisitá-lo ao servidor Web. Os proxies vêm sendo muito usados nas empresas, com o intuito de acelerar o acesso à Internet e evitar investimentos em ampliação de largura de banda.
O Proxy Reverso é um servidor instalado entre a internet e os servidores Web internos de uma empresa. As requisições externas, são direcionadas a um servidor interno por meio de um roteamento feito pelo Proxy Reverso. Dessa forma, ele é a única interface para as requisições externas.
Fonte: http://www.codeproject.com
Imagine a situação: Sua empresa possui o domínio xyz.com.br registrado, seu site (www.xyz.com.br) está em um servidor dentro da sua rede e, além do portal há outras aplicações que precisam ser disponibilizadas externamente. Para cada aplicação é necessário possuir um domínio ou subdomínio registrados? Não! Neste caso, pode ser usado o Proxy Reverso. Como?! É o que vou explicar daqui a pouco.
Além do roteamento de requisições externas, são vantagens do Proxy Reverso:
- Segurança: Como o Proxy é a única interface externa da rede, ele “esconde” os demais servidores;
- Criptografia: a criptografia SSL pode ser delegada o Proxy ao invés dos servidores internos;
- Balanceamento de carga: o servidor pode distribuir a carga para vários servidores da rede;
- Cache: assim como o Web Proxy, o Proxy Reverso pode manter em cache o conteúdo estático das requisições realizadas, ajudando assim a diminuir a carga dos servidores Web.
- Compressão: o Proxy Reverso pode tornar o acesso mais rápido através da compressão do conteúdo acessado;
Configuração do Proxy Reverso
- Habilitar os módulos do Proxy. Para isso, descomente as linhas:
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_connect_module modules/mod_proxy_connect.so
- Incluir vhosts na configuração. Para isso acrescente ou descomente a linha abaixo:
Nota: Os vhosts podem ser configurados no httpd.conf, optei pelo uso de um arquivo separado para organizar melhor o servidor.
Nota2: Os vhosts não são necessários na configuração do Proxy Reverso. São utilizados quando há mais de um nome para o mesmo servidor, e cada nome será direcionado para uma aplicação diferente.
Include conf/extra/httpd-vhosts.conf
- Incluir o arquivo de mod-proxy. Para isso acrescente ou descomente a linha abaixo:
Include conf/extra/mod_proxy.conf
Nota: Caso os dois arquivos citados acima não existam no servidor, os mesmos devem ser criados.
Para fazer o roteamento das requisições direcionadas aos servidores internos é utilizado o ProxyPass, a sintaxe é simples, basicamente temos a estrutura:
ProxyPass /destino http://servidor.da.app:porta/destino ProxyPassReverse /destino http://servidor.da.app:porta/destino
Para trabalhar com vhosts, crie ou edite o arquivo conf/extra/httpd-vhosts.conf e crie os vhosts com as seguintes configurações:
Nota: Sempre o contexto informado deve ser igual ao contexto da aplicação.
Nota2: Todos os diretórios referenciados pela aplicação no servidor de hospedagem devem ser configurados no Proxy, a não ser que eles sejam subdiretórios de algum que já tenha sido configurado.
<VirtualHost *:80> ServerName app1.xyz.com.br ErrorLog "logs/app1.xyz.com.br-error.log" CustomLog "logs/app1.xyz..com.br-access.log" common ProxyPass / http://app1.xyz.com.br:8040/ ProxyPassReverse / http://app1.xyz.com.br:8040/ ProxyPass /contexto1 http://app1.xyz.com.br:8040/contexto1 ProxyPassReverse /contexto1 http://app1.xyz.com.br:8040/contexto1 </VirtualHost>
Para trabalhar somente com o roteamento das requisições, apontando as requisições recebidas para outros servidores da rede, crie ou edite o arquivo conf/extra/mod_proxy.conf e insira as linhas de acordo com as aplicações e servidores da sua rede:
ProxyPass /aplicacao http://servidor.xyz.com.br:8040/aplicacao ProxyPassReverse /aplicacao http://servidor.xyz.com.br:8040/aplicacao ProxyPass /teste http://servidor2.xyz.com.br/teste ProxyPassReverse /teste http://servidor2.xyz.com.br/teste ProxyPass /teste_qa http://servidor2.xyz.com.br:8080/teste_qa ProxyPassReverse /teste_qa http://servidor2.xyz.com.br:8080/teste_qa
Sempre que uma alteração no apache for efetuada o mesmo deve ser reiniciado.
Fontes:
http://www.infoq.com/br/news/2010/06/proxy-reverso
http://pt.wikipedia.org/wiki/Proxy_reverso
Apache2 com SSL e MOD_JK no Solaris
Bom dia!!!
Sei que a configuração do SSL no Apache não é nenhum “bicho de 7 cabeças” e nem difícil de ser encontrada pela net, mas algumas distros apresentam particularidades quanto à instalação e configuração de serviços, por isso segue um passo a passo para configuração do SSL no Apache utilizando o Solaris.
Linux Natyworking 