Heimdal Kerberos + Samba PDC + OpenLDAP + Squid no Debian Etch
De Eduardo Sachs Wiki
Sobre a documentação
Escrito por Eduardo Sachs (edu.sachs@terra.com.br).
Versão do HOWTO: 4.0
Introdução
A autenticação em um ambiente Unix/Linux foi forçada a evoluir no sentido de satisfazer as necessidades em evolução de um modelo de rede. No início, tínhamos um modelo centralizado em que um grande computador prestando serviços a uma grande quantidade de terminais ligados através de linhas seriais. Neste cenário, a autenticação e a autorização de informação foi armazenada em arquivos texto sob diretório /etc. Esses arquivos (normalmente /etc/ passwd, /etc/shadow e /etc/group) ainda são usados em instalações simples envolvendo apenas alguns computadores (estações individuais de trabalho e as pequenas redes domésticas).
No entanto, com o poder da evolução a computação se tornou mais barata, os terminais foram sendo progressivamente abandonados em favor dos computadores individuais. O sistema de arquivos simples se tornou obsoleto, como a criação ou modificação de um usuários implícita modificar esses arquivos em cada computador na rede. Isto é, onde NIS (Network Information System) apareceu, desenvolvida pela Sun Microsystems em seu sistema operacional chamado Solaris, o fornecimento de um servidor central onde todas essas informações foram armazenadas. NIS apareceu como uma evolução do NIS, com uma remodelação completa do sistema. NIS e NIS não estão sendo mais desenvolvidas, e o Solaris 9 é a última versão do sistema operacional que suporta NIS e NIS, por padrão.
De qualquer maneira, perder a garantia prestada pelos seriais links foram apresentados novos e significativos problemas, especialmente a necessidade de garantir interações em um ambiente não confiável. Em 1983, Massachusetts Institute of Technology (MIT) embarcou em uma rede de grande escala com um projeto chamado Athena, enfrentando esses problemas. Para superar esses problemas, Kerberos foi desenvolvido. Autenticação Kerberos é um protocolo de rede, projetado para fornecer autenticação forte para o cliente/servidor de aplicativos usando criptografia de chaves secretas.
Outra peça que entra em jogo quando se fala de serviços de autenticação é LDAP (Lightweight Directory Access Protocol). LDAP é um padrão para um Directory Access Protocol, derivado do muito e mais complicado e caro para implementar, o X.500. A relativa simplicidade do protocolo que tornou possível a existência de um grande número de servidores LDAP, incluindo soluções de fonte aberta como OpenLDAP. A possibilidade de armazenar as informações centralizadas em um diretório LDAP fez um pedaço da autenticação encontradas nas redes de infra-estrutura com mais de alguns computadores.
Além disto, sistemas Unix e Linux fornecem o serviço PAM (Pluggable Authentication Modules). Este serviço fornece um método padrão para configurar sistemas de autenticação em sistemas operacionais Unix e Linux. Diferentes modulos do PAM podem ser usadas para oferecer diferentes métodos de autenticar um usuário e obter as informações sobre a conta a partir de várias fontes (de arquivos simples, NIS/NIS, Kerberos, LDAP, o que você puder imaginar). Utilizado em combinação com o PAM temos NSS (Name Service Switch). Este serviço controla como uma máquina cliente ou aplicação obtém informações da rede. Particularmente, este serviço pode controlar a fonte de onde uma máquina pode obter a autorização para um usuário procurando, informações para fazer login (user id e grupos que o usuário está incluído).
Neste ponto temos apresentado quase todas as peças que irão participar da nossa infra-estrutura de autenticação desejada. Temos a intenção de ter um servidor de autenticação central, usando o Kerberos, LDAP e Samba, todas as informações de autenticação e autorização dos usuários da nossa rede. Cada computador da nossa rede será configurado usando PAM, NSS e o Samba assim o processo de autenticação e autorização é feita contra este servidor central. Este HOWTO tem a intenção de fornecer um guia para instalar e configurar um servidor de autenticação central usando Kerberos, LDAP, Samba, Squid, PAM e NSS. Proporcionar um tutorial de como funciona cada serviço como o Kerberos, LDAP, Samba, Squid, PAM e NSS está fora do escopo deste HOWTO, por isso, pelo menos um conhecimento básico lhes é exigido, a fim de compreender os conceitos e os passos explicados neste HOWTO. Caso precise de mais informações sobre esses tópicos, sinta-se livre para navegar nos links fornecidos no final deste HOWTO.
Tenha em mente que, clientes Linux utilizam autenticação Kerberos, clientes Windows utilizam autenticação NTLM. Porque isso? Nos clientes Linux nós podemos colocar ele no domínio Kerberos e no domínio Samba ao mesmo tempo, mas, para os clientes Windows nós podemos colocar ele somente em um domínio, Kerberos ou Samba, por convenção eu prefiro colocar no domínio Samba por que ele utiliza a autenticação NTLM que seria mais difundida para clientes Windows, você até poderia colocar o Windows no domínio Kerberos, mas a administração disso séria quase inviável em uma rede de média e grande escala, no Samba4 (versão alpha) o Kerberos já é implementado para o domínio Samba.
Nós estaremos usando o Debian Etch para executar a instalação do servidor de autenticação como a nossa principal distribuição escolhida. De qualquer maneira, os conceitos e arquivos de configuração aqui apresentados podem ser utilizados com poucas mudanças em qualquer outra distribuição Linux.
Procurando por uma solução
Tenho uma rede a onde os clientes são Windows e Linux, e o meu PDC é Samba.
Quando se usa o cliente Windows a autenticação para entrar em algum compartilhamento de algum servidor que esteja no DOMINIO, é automático, via NTLM.
Porém, nos clientes Linux a história é outra, toda vez que você entra em algum compartilhamento de algum servidor que esteja no DOMINIO, é solicitado um usuário/senha, sendo que você já está logado com o usuário/senha do PDC, via PAM.
Quando se tem uma rede com muitas maquinas Linux, fica inviável ficar digitando usuário/senha para cada compartilhamento que você for entrar ou até mesmo montar. Eu pensei melhor e tive a certeza de que isso não era bom para a minha rede e para os meus usuários, além de gerar suporte a insegurança, era muita, pois ficar trafegando senhas na rede todo tempo, ou até mesmo aquelas pessoas que ficam de olho na senha que o usuário está digitando no teclado (losers).
Eu procurei, procurei e procurei sobre como eu poderia automatizar a autenticação dos meus clientes Linux, até que me falaram que uma tal de Autenticação Kerberos poderia resolver a situação, porém, a implementação desse tipo de protocolo em servidores Linux seria BEEEM complicado.
Novamente, eu pensei, porque não tornar a minha vida e a vida dos meus usuários mais facil, ou até mesmo mais segura, e então eu resolvi estudar afundo a implementação do Protocolo de Autenticação Kerberos em servidores Linux. Eu já tinha o conhecimento de como funcionava o LDAP com o Samba PDC, eu tive que aprender a usar a autenticação Kerberos e a integração desse serviço com o Samba PDC e o LDAP.
Os desenvolvedores do Samba já estão desenvolvendo o Samba4 que vai vir com esse tipo de autenticação, mas vai demorar BASTAAAAAAANTE para sair a versão estavél do Samba4, provavelmente em 2010.
Esse HOWTO não existe em nenhum lugar, eu achei somente o HOWTO de como se integra o Kerberos com o LDAP, mas foi muito VAGO, eu tive que procurar outras fontes no Google, mas nada muito explícito, e o HOWTO da integração do Kerberos com o Samba PDC não existe, eu tive que entrar em contato com o Andrew Bartlett (Desenvolvedor Samba) para coletar informações sobre esse tipo de integração, o tempo que eu perdi nisso foi mais ou menos uns 10 meses, mas valeu a pena.
Leia antes de fazer a integração (caso você não saiba o que é Kerberos)
Segue alguns sites que explicam o protocolo de Autenticação Kerberos.
Mas, esses sites NÃO FAZEM parte do HOWTO, eu só quis colocar porque explica o funcionamento do protocolo Kerberos.
Algumas dicas e comentarios
- Esse HOWTO é para usuário avançado, que já tenha conhecimento em DNS, Samba, LDAP, NTP e um pouquinho da teoria do Kerberos.
- Leia com atenção, pois um esquecimento de algum detalhe pode inteferir em muitas coisas e acabar não funcionando.
- Você deve seguir a risca a ordem desse HOWTO.
- O mundo seria melhor se as pessoas fossem mais persistentes no que querem.
- Tenha objetivo.
- Faça disso uma brincadeira, ou até mesmo, um desafio.
- Há coisas melhores no mundo do que ficar Kerberizando serviços, porém, eu não tenho dinheiro para ficar viajando pela Europa ou até mesmo ficar andando de Audi, por isso resolvido pirar em um mundo desconhecido.
- Se tudo fosse facil, ninguem daria bola.
- Você precisa se fuder para dar valor no que fez ou no que recebeu em troca.
- Foda-se Bill Gates e seu Active Directory.
- Porque existe HOWTOS complexos somente em inglês?
- Seja mais cooperativo.
- Porque resolvi fazer esse HOWTO?
- Esse tipo de integração é MUITO pouco divulgado na Internet, eu não achei documentação que explique sobre isso.
Quem deve usar esse HOWTO?
Esse HOWTO deve ser usado por pessoas que tenham clientes Linux (estação de trabalho) e Windows.
Caso você use somente cliente Windows, esqueça esse HOWTO e vá procurar um HOWTO sobre a integração do Samba PDC com LDAP, está cheio desses HOWTOs na Internet.
Script de auto-instalação dessa integração
Eu fiz alguns scripts para automatizar essa integração, eles são:
- SambaKerberosLDAP-Server: Faz toda a instalação dessa magnifica integração.
- Configuração feita tudo pelo dialog.
- Pergunta do script "Digite o dominio DNS (ex.: foo.com.br)", responda o domínio que você colocou no /etc/hosts.
- Exemplo:
- Caso você tenha colocado isso "192.168.0.70 bioquimik.exemplo-lab.int.br bioquimik", responda isso exemplo-lab.int.br .
- SambaKerberosLDAP-Cliente: Faz toda a configuração do cliente Linux.
- Você precisa editar esse script com as variaveis do Servidor e do cliente Linux.
- Squid-auth-kerberos/Squid-install: Configura o Squid para autenticar no Kerberos.
Faça o download dos scripts em: http://www.eduardosachs.org/mediawiki/files-howtos/scripts/SambaKerberosLDAP-auto-installer-Debian-Etch.tar
Para o correto funcionamento dos scripts, primeiro é preciso ajustar o /etc/hosts e /etc/hostname, DEPOIS DISSO REINICIE O SERVIDOR! Em seguida terá um exemplo de configuração desses dois arquivos.
Técnologias usadas
Nesta seção, nós fornecemos uma visão geral dos softwares necessários para a nossa integração.
Heimdal Kerberos
A primeira peça usada para a nossa integração é o Kerberos. Neste momento, existem duas implementações de código aberto do Kerberos: Heimdal e MIT Kerberos. Heimdal é uma implementação do protocolo Kerberos implementada pela KTH (Royal Institute of Technology, em Estocolmo), enquanto MIT Kerberos é fornecido pelo MIT (Massachussets Institute of Technology), como diz seu nome.
Autenticação Kerberos é um protocolo de rede. Foi concebido para fornecer autenticação forte para o cliente/servidores de aplicativos usando criptografia de chaves secretas, então um cliente pode provar a sua identidade para um servidor (e vice-versa) em uma conexão de rede insegura. Depois de um cliente e servidor Kerberos tem usado para provar a sua identidade, eles também podem criptografar todas as suas comunicações para garantir a privacidade e a integridade dos dados, uma vez que realizado o seu trabalho.
Porque é que escolhemos o Heimdal ao invés do MIT Kerberos?
- Heimdal suporta armazenar seus dados em LDAP, para que possamos centralizar todos os nossos dados em apenas um lugar, e mais, nós seremos capazes de criar um novo Kerberos principal apenas criando a entrada apropriada no LDAP. Tem mais, o Andrew Bartlett (desenvolvedor samba) fez um patch para o Heimdal conseguir ler os hashs de senhas do Samba (sambaLMPassword e sambaNTPassword), assim sendo, quando o Heimdal encontra os objetos do Samba no usuário ele vai começar a usar as senhas do hash do Samba.
- MIT tem sido historicamente problemático em relação com as questões de desenvolvimento, embora estar mudando em suas versões mais recentes.
Pacotes usados:
heimdal-kdc heimdal-clients-x heimdal-clients heimdal-docs heimdal-servers-x heimdal-servers libkadm5clnt4-heimdal libkadm5srv7-heimdal libhdb7-heimdal libkafs0-heimdal libgssapi4-heimdal libkrb5-17-heimdal libasn1-6-heimdal krb5-config heimdal-kcm
OpenLDAP
O Kerberos irá nos fornecer um protocolo de autentificação, mas o que dizer de autorização de informações? Nós ainda precisamos armazenar essas informações de modo centralizado para facilitar as tarefas administrativas. Este é o LDAP quando entrar em vigor. Nós estaremos usando um diretório LDAP como serviço, onde irá guardar as informações relativas a todos os usuários da nossa rede.
OpenLDAP é uma implementação open source do Lightweight Directory Access Protocol (LDAP). A suite inclui:
slapd ldap-utils
OpenLDAP tornou-se o padrão para diretório de serviços em open source.
OpenSSL
Nós usamos o SSL (Secure Socket Layers) para fornecer conexões seguras e criptografadas para o servidor LDAP.
Pacotes usados:
openssl ssl-cert
Cyrus SASL
Citando em http://asg.web.cmu.edu/sasl/: SASL é o Simple Authentication and Security Layer, um método de autenticação adicionando suporte para conexão com base em protocolos. Para usar SASL, um protocolo inclui um comando para identificar e autenticar um usuário a um servidor e opcionalmente para a proteção das negociações subsequentes do protocolo de interações. Se a sua utilização é negociada, uma camada de segurança é inserido entre o protocolo e a conexão.
Em nossa integração o SASL será usado para fornecer suporte a autenticação ao nosso servidor LDAP. Por outro lado, SASL, em combinação com Kerberos, utiliza o GSSAPI (Generic Security Services Application Programming Interface) que será capaz de fornecer 'single sign on' sobre as capacidades de todos os servidores Kerberos localizados na nossa rede.
Pacotes usados:
libsasl2 libsasl2-modules sasl2-bin libsasl2-modules-gssapi-heimdal
NSSWitch
O libnss-ldap é um módulo que vai deixar-nos obter a autorização das informações (user id, grupos) a partir do nosso servidor LDAP.
Pacote usado:
libnss-ldap
Bind
Outro serviço importante no funcionamento do Kerberos é o Domain Name Service (DNS), definido nas RFC 1034 [MOCKAPETRIS (1987) (1)] e RFC 1035 [MOCKAPETRIS (1987) (2)]. Certos aspectos do Kerberos dependem de que o DNS e máquinas da rede estejam corretamente configurados.
Pacote usado:
bind9
Samba
O SAMBA é um servidor e conjunto de ferramentas que permite que máquinas Linux e Windows se comuniquem entre si, compartilhando serviços (arquivos, diretório, impressão) através do protocolo SMB (Server Message Block)/CIFS (Common Internet File System), equivalentes a implementação NetBEUI no Windows. O SAMBA é uma das soluções em ambiente UNIX capaz de interligar redes heterogênea.
Na lógica da rede Windows o NetBEUI é o protocolo e o NETBIOS define a forma com que os dados são transportados. Não é correto dizer que o NetBIOS é o protocolo, como muitos fazem.
Com o SAMBA, é possível construir domínios completos, fazer controle de acesso a nível de usuário, compartilhamento, montar um servidor WINS, servidor de domínio, impressão, etc. Na maioria dos casos o controle de acesso e exibição de diretórios no samba é mais minucioso e personalizável que no próprio Windows.
O Kerberos em conjunto com o Samba vai nos proporcionar segurança e automatização na parte de autenticação para os clientes Linux que estiverem usando os recursos do Samba, os clientes Windows utiliza a autenticação NTLM quando ele está em um domínio Samba, assim sendo, os clientes Windows não irão utilizar a autenticação Kerberos.
Pacotes usados:
smbclient samba samba-common samba-doc smbfs libsmbclient smbldap-tools
CUPS
O CUPS é usado como ferramenta de apoio ao gerenciamento de impressão, onde é grande o número de impressoras. Aproveitamos e colocamos esse pacote para ser instalado, caso precise de um servidor de impressão, não será discutido nada sobre isso, só será instalado o pacote através do apt-get.
Pacotes usados:
libcupsys2-gnutls10 cupsys-common libcupsys2
NTP
O NTP é um protocolo para sincronização dos relógios dos computadores, ou seja, ele define um jeito para um grupo de computadores conversar entre si e acertar seus relógios, baseados em alguma fonte confiável de tempo, como os relógios atômicos do Observatório Nacional, que definem a Hora Legal do seu país. Com o NTP é fácil manter o relógio do computador sempre com a hora certa, com exatidão de alguns milésimos de segundo, e só há vantagens em se fazer isso! O Kerberos necessita que o relógio do cliente esteja sincronizado com o servidor Kerberos.
Pacotes usados:
ntp
Dependencias importantes
Bibliotecas para compilação de fontes, servira para compilar o Squid e o OpenLDAP, ou algum outro programa que use o Kerberos ou até mesmo o LDAP.
libpam0g-dev libssl-dev libsasl2-dev comerr-dev libdb4.4-dev libldap-dev heimdal-dev dpkg-dev libldap-dev libsmbclient-dev libpam-dev dpkg-dev libltdl3-dev
Pacotes para compilação de fontes, alguns programas essencias para compilar fontes.
debconf-utils libltdl3 build-essential fakeroot dpatch
Instalação dos pacotes
Ajustes na configuração de nome do servidor
Faça os seguintes ajustes nos arquivos /etc/hosts e /etc/hostname antes de instalar os pacotes.
Configuração do arquivo /etc/hosts
192.168.0.70 bioquimik.exemplo-lab.int.br bioquimik
127.0.0.1 localhost.localdomain localhost
Configuração do arquivo /etc/hostname
bioquimik
Reinicie o servidor após configurar o /etc/hosts e /etc/hostname.
É preciso instalar os pacotes com o hostname correto que será usado para a integração.
server root# reboot
Remover alguns pacotes desnecessarios
Não precisamos desses pacotes.
server root# apt-get remove -y --purge dhcp3-client dhcp-client
Estamos removendo o cliente DHCP pois esse servidor deve ter IP fixo, e para previnir futuros problemas estamos fazendo isso.
Ajustar o debconf
No nosso caso, nós vamos desabilitar aquelas perguntas que o pacote faz quando está sendo instalado.
server root# export DEBIAN_PRIORITY=critical server root# export DEBIAN_FRONTEND=noninteractive
Instalar os pacotes necessarios para a integração
server root# apt-get update server root# apt-get install -y bind9 openssl ssl-cert libsasl2 libsasl2-modules \ libsasl2-modules-gssapi-heimdal sasl2-bin libnss-ldap slapd ldap-utils heimdal-dev libldap-dev \ heimdal-kdc heimdal-clients-x heimdal-clients heimdal-docs heimdal-servers-x heimdal-servers \ libkadm5clnt4-heimdal libkadm5srv7-heimdal libhdb7-heimdal libkafs0-heimdal \ libgssapi4-heimdal libkrb5-17-heimdal libasn1-6-heimdal krb5-config heimdal-kcm \ smbclient samba samba-common samba-doc libcupsys2-gnutls10 smbfs \ libsmbclient cupsys-common libcupsys2 smbldap-tools ntp dpkg-dev
Instalação do overlay smbk5pwd
Precisamos compilar o OpenLDAP para compilar o overlay smbk5pwd, pois ele não vem no pacote slapd do Debian Etch, nos não vamos utilizar esse OpenLDAP compilado, estamos compilando ele somente para pegar esse overlay, ele vai fazer a automatização da sincronização das senhas do Samba e Kerberos, assim sendo, nós vamos utilizar o smbpasswd para trocar a senha do usuário para ter essa sincronização.
Sobre a senha do LDAP que está no atributo userPassword vai ter o valor {K5KEY}, assim sendo, vai usar a senha do atributo do Kerberos (krb5Key), por isso não precisamos sincronizar a senha do userPassword, apenas deixar o userPassword com o valor {K5KEY} estático.
Um detalhe muito importante, para essa sincronização funcionar é preciso trocar a senha do usuário através de SIMPLE BIND, isso quer dizer, você não pode simplesmente trocar o valor do atributo das senhas na base LDAP. Leia mais em contrib/slapd-modules/smbk5pwd/README, isso está dentro do source do OpenLDAP. Preferencialmente você deve usar o smbpasswd para trocar a senha do usuário, porém, você também pode usar o ldappasswd e o kpasswd, mas eu não indico para esse tipo de cenário que estou montado,
server root# cd /usr/src server root# apt-get source slapd server root# cd openldap* server root# apt-get install -y $( cat debian/control | grep ^Build-Depends: | cut -d : -f2-200 | sed 's/([^)]*)//g' | sed 's/,//g' ) server root# ./configure $(cat debian/configure.options | grep -v '#' | xargs) server root# make depend server root# make server root# cd contrib/slapd-modules/smbk5pwd/ server root# make server root# cp -a smbk5pwd.la .libs/smbk5pwd.so.0.0.0 .libs/smbk5pwd.so \ .libs/smbk5pwd.so.0 /usr/lib/ldap server root# chmod -x /usr/lib/ldap/smbk5pwd.so.0.0.0 server root# chmod 644 /usr/lib/ldap/smbk5pwd.la /usr/lib/ldap/smbk5pwd.so \ /usr/lib/ldap/smbk5pwd.so.0 /usr/lib/ldap/smbk5pwd.so.0.0.0 server root# cd /usr/src/ server root# rm -rf openldap*
Reajustar o debconf
Vamos voltar ao normal o debconf, como estava antes de fazer a alteração.
server root# unset DEBIAN_PRIORITY server root# unset DEBIAN_FRONTEND
Parar alguns serviços
Vamos parar todos os serviços que fazem parte da integração, será melhor, para manter organizada a instalação.
server root# /etc/init.d/samba stop server root# /etc/init.d/slapd stop server root# /etc/init.d/saslauthd stop server root# /etc/init.d/heimdal-kcm stop server root# /etc/init.d/heimdal-kdc stop server root# /etc/init.d/bind9 stop server root# /etc/init.d/ntp stop
Configurando a integração do Heimdal Kerberos com Samba PDC, OpenLDAP e Squid Proxy Cache
Definindo variaveis de configuração do servidor
Deve ser substituido tudo que estiver em VERMELHO.
Hostname do servidor: bioquimik
Dominio DNS: exemplo-lab.int.br
Dominio Samba PDC: EXEMPLO-LAB
Kerberos Domain Controller: EXEMPLO-LAB.INT.BR
Obs.: O dominio Kerberos deve ser o mesmo do DNS.
IP do servidor: 192.168.0.70
Broadcast: 192.168.0.255
Definições de senhas:
Usuário ldapmaster/admin (admin da base LDAP)
Senha em texto puro: secret1
Senha criptografada em MD5: {MD5}5S2YxFmBmhF3WTbY37t5KQ==
Obs.: você vai precisar dessa senha em MD5 para colocar no slapd.conf.
Usuário kadmin/admin (admin da base Kerberos)
Senha em texto puro: secret2
Usuário addmachine (usuario para adicionar maquinas no dominio)
Senha em texto puro: secret3
Usuário root da base LDAP (isso não é a senha do usuário local)
Senha em texto puro: secret4
Backup dos arquivos de configuração
Vamos fazer o backup dos arquivos originais das configurações de quando os pacotes foram instalados.
server root# mkdir -p /root/backup-confs/ server root# mkdir -p /root/backup-confs/etc/ server root# mkdir -p /root/backup-confs/etc/ldap/ server root# mkdir -p /root/backup-confs/etc/default/ server root# mkdir -p /root/backup-confs/etc/samba/ server root# mkdir -p /root/backup-confs/etc/network/ server root# cp -Rap /etc/hosts /root/backup-confs/etc/ server root# cp -Rap /etc/resolv.conf /root/backup-confs/etc/ server root# cp -Rap /etc/libnss-ldap.conf /root/backup-confs/etc/ server root# cp -Rap /etc/inetd.conf /root/backup-confs/etc/ server root# cp -Rap /etc/nsswitch.conf /root/backup-confs/etc/ server root# cp -Rap /etc/krb5.conf /root/backup-confs/etc/ server root# cp -Rap /etc/ntp.conf /root/backup-confs/etc/ server root# cp -Rap /etc/network/interfaces /root/backup-confs/etc/network/ server root# cp -Rap /etc/samba/smb.conf /root/backup-confs/etc/samba/ server root# cp -Rap /etc/bind/ /root/backup-confs/etc/ server root# cp -Rap /etc/ldap/ /root/backup-confs/etc/ server root# cp -Rap /etc/default/slapd /root/backup-confs/etc/default/ server root# cp -Rap /etc/default/saslauthd /root/backup-confs/etc/default/ server root# cp -Rap /usr/sbin/smbldap-useradd /root/backup-confs/ server root# cp -Rap /usr/sbin/smbldap-passwd /root/backup-confs/
Configuração do Servidor NTP
Para o correto funcionamento do Kerberos, é necessário que a data/hora dos computadores clientes estejam perfeitamente sincronizados, por isso estamos configurado o NTP. O Kerberos suporta uma diferença de apenas 5 minutos.
Configuração do arquivo /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic
server 127.127.1.0
fudge 127.127.1.0 stratum 13
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1 nomodify
broadcast 192.168.0.255
- Você deve alterar o parâmetro broadcast, conforme for a configuração da sua rede.
- Estou usando os servidores NTP do Debian, porém, você pode escolher outros servidores NTP para fazer a sincronização.
Reinicie o serviço NTP:
server root# /etc/init.d/ntp restart
Configuração do DNS
Configuração do arquivo /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Configuração do arquivo /etc/bind/named.conf
Estou configurando o dominio e o reverso da rede interna.
include "/etc/bind/named.conf.options";
logging {
category default { log_syslog; };
channel log_syslog { syslog; };
};
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "exemplo-lab.int.br" in {
file "/etc/bind/exemplo-lab.int.br";
type master;
};
zone "0.168.192.in-addr.arpa" in {
file "/etc/bind/0.168.192.in-addr.arpa.zone";
type master;
};
include "/etc/bind/named.conf.local";
Configuração do dominio /etc/bind/exemplo-lab.int.br
$TTL 2d @ IN SOA bioquimik.exemplo-lab.int.br. root.bioquimik.exemplo-lab.int.br. ( 2008011901 ; serial 3h ; refresh 1h ; retry 1w ; expiry 1d ) ; minimum exemplo-lab.int.br. IN NS ns.exemplo-lab.int.br. $ORIGIN exemplo-lab.int.br. exemplo-lab.int.br. IN A 192.168.0.70 bioquimik IN A 192.168.0.70 ns IN CNAME bioquimik.exemplo-lab.int.br. kerberos IN CNAME bioquimik.exemplo-lab.int.br. ldap IN CNAME bioquimik.exemplo-lab.int.br. ; The Kerberos realm _kerberos IN TXT "EXEMPLO-LAB.INT.BR" _kerberos.it IN TXT "EXEMPLO-LAB.INT.BR" _kerberos.srv IN TXT "EXEMPLO-LAB.INT.BR" _kerberos._tcp IN SRV 10 1 88 bioquimik.exemplo-lab.int.br. _kerberos._udp IN SRV 10 1 88 bioquimik.exemplo-lab.int.br. _kerberos-adm._tcp IN SRV 10 1 749 bioquimik.exemplo-lab.int.br. _kerberos-master._udp IN SRV 0 0 88 bioquimik.exemplo-lab.int.br. _kpasswd._udp IN SRV 10 1 464 bioquimik.exemplo-lab.int.br. _ldap._tcp IN SRV 10 1 389 bioquimik.exemplo-lab.int.br.
Configuração do reverso /etc/bind/0.168.192.in-addr.arpa.zone
$TTL 2d @ IN SOA bioquimik.exemplo-lab.int.br. root.bioquimik.exemplo-lab.int.br. ( 2008011901 ; serial 3h ; refresh 1h ; retry 1w ; expiry 1d ) ; minimum @ IN NS ns.exemplo-lab.int.br. 70 IN PTR bioquimik.exemplo-lab.int.br.
Configuração do arquivo /etc/resolv.conf
Vamos configurar o servidor para que ele possa resolver o dominio configurado.
search exemplo-lab.int.br nameserver 192.168.0.70
Reinicialização do serviço bind
server root# /etc/init.d/bind9 restart
Testes com o dominio DNS
Esses testes mostram se o dominio está funcionando corretamente.
server root# nslookup > server 192.168.0.70 Default server: 192.168.0.70 Address: 192.168.0.70#53 > set q=ns > exemplo-lab.int.br Server: 192.168.0.70 Address: 192.168.0.70#53 exemplo-lab.int.br nameserver = ns.exemplo-lab.int.br. >
Configuração do LDAP
Estrutura da DIT
A estrutura da base LDAP é bem simples, vamos ter somente quatro OUs.
- DC=exemplo-lab,DC=int,DC=br
- OU=Grupos (Todos os grupos do Samba e do sistema operacional)
- OU=Computadores (Todos os computadores cadastrados pelo Samba)
- OU=Usuarios (Usuários do Samba/Kerberos)
- OU=KerberosPrincipals (Principals do Kerberos)
- Obs.: Use o mesmo domínio DNS para o domínio LDAP.
- Exemplo:
- Caso o seu domínio DNS for exemplo-lab.int.br use o domínio LDAP como dc=exemplo-lab,dc=int,dc=br .
Gerando o certificado digital
Vamos gerar o certificado digital para uma conexão criptografada no serviço LDAP.
server root# mkdir -p /etc/ldap/ssl server root# cd /etc/ldap/ssl server root# mkdir certs server root# mkdir private server root# chmod 700 private server root# echo '01' > serial server root# touch index.txt
Configuração do arquivo /etc/ldap/ssl/CA.conf
[ ca ] default_ca = local_ca [ local_ca ] dir = /etc/ldap/ssl certificate = /etc/ldap/ssl/cacert.pem database = /etc/ldap/ssl/index.txt new_certs_dir = /etc/ldap/ssl/certs private_key = /etc/ldap/ssl/private/cakey.pem serial = /etc/ldap/ssl/serial default_crl_days = 3650 default_days = 3650 default_md = md5 default_bits = 1024 encrypt_key = yes policy = local_ca_policy x509_extensions = local_ca_extensions unique_subject = no [ local_ca_policy ] commonName = supplied stateOrProvinceName = supplied countryName = supplied emailAddress = supplied organizationName = supplied organizationalUnitName = supplied [ local_ca_extensions ] subjectAltName = DNS:bioquimik.exemplo-lab.int.br basicConstraints = CA:false nsCertType = server [ req ] default_bits = 2048 default_keyfile = /etc/ldap/ssl/private/cakey.pem default_md = md5 prompt = no distinguished_name = exemplo-lab x509_extensions = x509_cert [ exemplo-lab ] countryName = BR stateOrProvinceName = Rio Grande do Sul localityName = Porto Alegre emailAddress = admin@exemplo-lab.int.br organizationName = Tabajara organizationalUnitName = CPD commonName = bioquimik.exemplo-lab.int.br [ x509_cert ] nsCertType = server basicConstraints = CA:true
Configuração do arquivo /etc/ldap/ssl/LocalServer.conf
[ req ] prompt = no distinguished_name = exemplo-lab [ exemplo-lab ] countryName = BR stateOrProvinceName = Rio Grande do Sul localityName = Porto Alegre emailAddress = admin@exemplo-lab.int.br organizationName = Tabajara organizationalUnitName = CPD commonName = bioquimik.exemplo-lab.int.br
Comandos para gerar o certificado digital
server root# cd /etc/ldap/ssl/ server root# export OPENSSL_CONF=/etc/ldap/ssl/CA.conf server root# openssl req -x509 -newkey rsa:1024 -out cacert.pem -outform PEM -days 3650 -passout pass:SENHA server root# export OPENSSL_CONF=/etc/ldap/ssl/LocalServer.conf server root# openssl req -newkey rsa:1024 -keyout tempkey.pem -keyform PEM -out tempreq.pem -outform PEM -passout pass:SENHA server root# openssl rsa < tempkey.pem > serverkey.pem -passin pass:SENHA server root# chmod 400 serverkey.pem server root# export OPENSSL_CONF=/etc/ldap/ssl/CA.conf server root# openssl ca -in tempreq.pem -out servercrt.pem -passin pass:SENHA server root# rm -rf tempkey.pem tempreq.pem certs index.txt.attr LocalServer.conf serial CA.conf index.txt \ index.txt.old private serial.old
Configuração do arquivo /etc/ldap/slapd.conf
A senha em MD5 do ldapmaster/admin deve ser colocada no parametro rootpw, ela deve ser gerada com o comando abaixo:
server root# slappasswd -h {MD5} -s secret1
Temos que editar o arquivo /etc/ldap/slapd.conf, por isso, vamos fazer a configuração inicial do nosso servidor LDAP e criar o nosso banco de dados. As modificações que fizemos para a configuração padrão incluem o seguinte: inclusão de vários schemas a serem usados pelo servidor, algumas restrições básicas de segurança, localização de certificados para permitir conexões criptografadas SSL, configuração da autenticação Kerberos via SASL, e a definição da nossa base de dados:
# Allow LDAPv2 binds allow bind_v2 # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: sizelimit 20 timelimit -1 threads 8 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/qmailuser.schema include /etc/ldap/schema/phpgwaccount.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/phpgwcontact.schema include /etc/ldap/schema/hdb.schema TLSCertificateFile /etc/ldap/ssl/servercrt.pem TLSCertificateKeyFile /etc/ldap/ssl/serverkey.pem TLSCACertificateFile /etc/ldap/ssl/cacert.pem sasl-host bioquimik.exemplo-lab.int.br sasl-realm EXEMPLO-LAB.INT.BR # Mapping of SASL authentication identities to LDAP entries authz-regexp uid=(.+),cn=(.+),cn=gssapi,cn=auth ldap:///dc=exemplo-lab,dc=int,dc=br??sub?(|(krb5PrincipalName=$1@EXEMPLO-LAB.INT.BR)(krb5PrincipalName=$1/admin@EXEMPLO-LAB.INT.BR)) sasl-secprops noanonymous security ssf=0 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 modulepath /usr/lib/ldap moduleload back_bdb moduleload smbk5pwd checkpoint 512 30 cachesize 10000 dbcachesize 1000000 schemacheck on idletimeout 30 backend bdb database bdb suffix "dc=exemplo-lab,dc=int,dc=br" rootdn "krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br" rootpw {MD5}5S2YxFmBmhF3WTbY37t5KQ== directory "/var/lib/ldap" # Indices to maintain index mail,mailAlternateAddress,objectClass,deliveryMode,accountStatus,phpgwAccountType,phpgwAccountStatus,ou pres,eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index mailHost eq index givenName pres,sub,eq index default sub index krb5PrincipalName,krb5PrincipalRealm eq,pres # Overlay smbk5pwd overlay smbk5pwd smbk5pwd-enable krb5 smbk5pwd-enable samba smbk5pwd-must-change 2592000 password-hash {K5KEY} # Save the time that the entry gets modified, for database # lastmod on include /etc/ldap/slapd.access
Certifique-se de usar o nome canônico da máquina em sasl-host, caso contrário o OpenLDAP não será capaz de oferecer autenticação GSSAPI.
É muito importante definir corretamente os índices, com isso nós vamos ter uma performance decente no banco de dados para as pesquisas. Você poderá perceber que se faltar indices a linha abaixo é lançada no syslog:
Aug 17 11:10:00 bioquimik slapd[7346]: <= bdb_equality_candidates: (memberUid) index_param failed (18)
Neste caso, tivemos uma falta de igualdade no índice memberUid para o atributo.
Configuração do arquivo /etc/ldap/slapd.access
# Autorizacao para o heimdal poder acessar a base de dados do ldap
authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
"krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br"
authz-regexp ^uid=([^,]+),cn=[^,]+,cn=auth$ uid=$1,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPasswordHistory,krb5Key,krb5KeyVersionNumber
by dn="krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br" write
by anonymous auth
by self write
by * none
# Everyone must be able to read password expiry attributes,
# if you are not granting rootdn access to workstations.
# Otherwise, the client system won't be able to know if
# user's password has expired, and will prompt him/her to
# change his/her password everytime he/she logs in.
# The owner must also be able to write it when he/she
# changes his/her own password.
access to attrs=shadowLastChange,sambaPwdLastSet,sambaPwdMustChange
by dn="krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br" write
by self write
by * read
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base= by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br" write
by * read
Copiando schemas para o LDAP
Vamos fazer o download dos schemas do LDAP.
server root# wget http://www.eduardosachs.org/mediawiki/files-howtos/schema/phpgwaccount.schema -P /etc/ldap/schema/ server root# wget http://www.eduardosachs.org/mediawiki/files-howtos/schema/phpgwcontact.schema -P /etc/ldap/schema/ server root# wget http://www.eduardosachs.org/mediawiki/files-howtos/schema/qmailuser.schema -P /etc/ldap/schema/ server root# cp /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz /etc/ldap/schema/ server root# gunzip -f /etc/ldap/schema/samba.schema.gz
Configuração do arquivo /etc/ldap/ldap.conf
Antes de acessar o diretório LDAP, temos que verificar a configuração incluída no arquivo /etc/ldap/ldap.conf de forma que eles apontem para o servidor que estamos instalando. Desta maneira não vamos ser obrigados a incluir estas informações em cada utilização das ferramentos do LDAP (ldapsearch, ldapmodify, etc...). Deve conter a configuração abaixo:
host bioquimik.exemplo-lab.int.br base dc=exemplo-lab,dc=int,dc=br uri ldaps://bioquimik.exemplo-lab.int.br port 636 TLS_CACERT /etc/ldap/ssl/cacert.pem TIMELIMIT 2
Configuração do arquivo /etc/libnss-ldap.conf
base dc=exemplo-lab,dc=int,dc=br uri ldaps://bioquimik.exemplo-lab.int.br/ rootbinddn krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br port 636 ldap_version 3 bind_policy soft bind_timelimit 2 timelimit 2 scope sub nss_reconnect_maxsleeptime 8 nss_reconnect_sleeptime 1 nss_initgroups_ignoreusers root nss_srv_domain exemplo.int.br pam_password exop pam_filter objectclass=posixAccount pam_login_attribute uid pam_member_attribute memberUid nss_base_passwd ou=Usuarios,dc=exemplo-lab,dc=int,dc=br?one nss_base_shadow ou=Usuarios,dc=exemplo-lab,dc=int,dc=br?one nss_base_passwd ou=Computadores,dc=exemplo-lab,dc=int,dc=br?one nss_base_shadow ou=Computadores,dc=exemplo-lab,dc=int,dc=br?one nss_base_group ou=Grupos,dc=exemplo-lab,dc=int,dc=br?one ssl on tls_ciphers TLSv1 tls_checkpeer yes tls_cacertdir /etc/ldap/ssl
Altere a permissão do arquivo /etc/libnss-ldap.conf:
server root# chmod 644 /etc/libnss-ldap.conf
Crie o arquivo /etc/libnss-ldap.secret, contendo somente a senha do administrador da base LDAP:
secret1
Altere a permissão do arquivo /etc/libnss-ldap.secret, pois nele tem a senha da base LDAP em clear text:
server root# chmod 600 /etc/libnss-ldap.secret
Configuração do arquivo /etc/nsswitch.conf
passwd: files ldap [notfound=continue] shadow: files ldap [notfound=continue] group: files ldap [notfound=continue] hosts: files dns wins networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
Configuração do arquivo /etc/default/slapd
Aqui nós vamos ativar os seguintes serviços: LDAP, ldaps, e ldap unix socket:
SLAPD_CONF= SLAPD_PIDFILE= SLURPD_START=auto SLAPD_OPTIONS="" SLURPD_OPTIONS="" SLAPD_USER="root" SLAPD_GROUP="root" SLAPD_SERVICES="ldap:/// ldaps:/// ldapi://%2fvar%2frun%2fldapi/"
O Heimdal Kerberos vai acessar a base LDAP através do socket em sua localização (/var/run/ldapi).
A configuração padrão fornecido pelo Debian Etch coloca o socket unix do LDAP em /var/run/slapd/ldapi. No entanto, o Heimdal espera encontrar este socket em seu local padrão /var/lib/ldapi e este local não tem como alterar. É por isso que temos que mudar isto para o local padrão, suprimindo a localização desde arquivos na configuração padrão.
Gerando a base LDAP
Deletando a base antiga
server root# /etc/init.d/slapd stop server root# rm -f /var/lib/ldap/*
Configuração do arquivo /var/lib/ldap/DB_CONFIG
Esses valores foram recolhidos da página do Samba e da configuração padrão do DB_CONFIG do slapd.
set_cachesize 0 150000000 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_lk_max_objects 1500 set_lk_max_locks 1500 set_lk_max_lockers 1500 set_flags DB_LOG_AUTOREMOVE
Iniciando o serviço slapd
A fim de criar nosso banco de dados, devemos iniciar o servidor LDAP.
server root# /etc/init.d/slapd start
Configuração do arquivo /etc/ldap/base.ldif
Vamos criar a nossa primeira estrutura básica. Vamos ter um diretório raiz para a nossa base, em seguida, várias OUs contendo grupos, usuários e computadores. A fim de criar essa estrutura básica nos primeiro vamos editar o base.ldif contendo o seguinte:
O atributo userPassword do ldapmaster/admin está com o valor {K5KEY} porque ele vai utilizar a senha do Kerberos, assim sendo, o userPassword é redirecionado para o atributo da senha do Kerberos (krb5Key).
dn: dc=exemplo-lab,dc=int,dc=br dc: exemplo-lab objectClass: top objectClass: domain dn: ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br ou: KerberosPrincipals objectClass: top objectClass: organizationalUnit dn: ou=Grupos,dc=exemplo-lab,dc=int,dc=br ou: Grupos objectClass: top objectClass: organizationalUnit dn: ou=Computadores,dc=exemplo-lab,dc=int,dc=br ou: Computadores objectClass: top objectClass: organizationalUnit dn: krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br objectClass: top objectClass: person objectClass: krb5Principal objectClass: krb5KDCEntry krb5PrincipalName: ldapmaster/admin@EXEMPLO-LAB.INT.BR krb5KeyVersionNumber: 1 krb5MaxLife: 86400 krb5MaxRenew: 604800 krb5KDCFlags: 126 cn: ldapmaster/admin@exemplo-lab.int.br sn: ldapmaster/admin@exemplo-lab.int.br userPassword: {K5KEY}
Inserindo a base no LDAP
Agora, vamos importar a estrutura para a base LDAP:
server root# ldapadd -x -D krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br \ -w secret1 -f /etc/ldap/base.ldif
Saida do comando:
adding new entry "dc=exemplo-lab,dc=int,dc=br" adding new entry "ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br" adding new entry "ou=Grupos,dc=exemplo-lab,dc=int,dc=br" adding new entry "ou=Computadores,dc=exemplo-lab,dc=int,dc=br" adding new entry "krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br"
Configuração do Heimdal Kerberos
Configuração do arquivo /etc/inetd.conf
Comente alguns serviços desnecessarios para o funcionamento da integração.
.... #ident stream tcp wait identd /usr/sbin/identd identd .... #krb_prop stream tcp nowait root /usr/sbin/tcpd /usr/sbin/hpropd #kshell stream tcp nowait root /usr/sbin/tcpd /usr/lib/heimdal-servers/rshd -k #ftp stream tcp nowait root /usr/sbin/tcpd /usr/lib/heimdal-servers/ftpd -a plain #telnet stream tcp nowait root /usr/sbin/tcpd /usr/lib/heimdal-servers/telnetd -a none #pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/lib/heimdal-servers/popper #kx stream tcp nowait root /usr/sbin/tcpd /usr/lib/heimdal-servers/kxd
Reinicie o inetd:
server root# /etc/init.d/openbsd-inetd restart
Configuração do arquivo /etc/krb5.conf
Primeiro, crie o arquivo de configuração /etc/krb5.conf, com a informação relativa ao domínio Kerberos, iremos criar:
[libdefaults]
ticket_lifetime = 80000
renew_lifetime = 80000
default_realm = EXEMPLO-LAB.INT.BR
default_keytab_name = FILE:/etc/krb5.keytab
default_etypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5 des-cbc-md4 aes256-cts arcfour-hmac-md5
default_etypes_des = des3-hmac-sha1 des-cbc-crc des-cbc-md5 des-cbc-md4 aes256-cts arcfour-hmac-md5
default_tkt_enctypes= des3-hmac-sha1 des-cbc-crc des-cbc-md5 des-cbc-md4 aes256-cts arcfour-hmac-md5
default_tgs_enctypes= des3-hmac-sha1 des-cbc-crc des-cbc-md5 des-cbc-md4 aes256-cts arcfour-hmac-md5
kdc_timesync = 1
forwardable = true
proxiable = true
# The following libdefaults parameters are only for Heimdal Kerberos.
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
[realms]
EXEMPLO-LAB.INT.BR = {
kdc = bioquimik.exemplo-lab.int.br
admin_server = bioquimik.exemplo-lab.int.br
default_domain = exemplo-lab.int.br
}
[domain_realm]
.exemplo-lab.int.br = EXEMPLO-LAB.INT.BR
exemplo-lab.int.br = EXEMPLO-LAB.INT.BR
[kdc]
enable-kerberos4 = false
kdc_warn_pwexpire = 7
database = {
realm = EXEMPLO-LAB.INT.BR
dbname = ldap:dc=exemplo-lab,dc=int,dc=br
mkey_file = /var/lib/heimdal-kdc/m-key
acl_file = /etc/kadmind.acl
log_file = /var/log/kdc-db.log
}
hdb-ldap-create-base = ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br
[logging]
kdc = FILE:/var/log/heimdal/kdc.log
admin_server = FILE:/var/log/heimdal/admin.log
default = FILE:/var/log/heimdal/default.log
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = true
}
Configuração das ACLs dos usuários do Kerberos
As ACLs define o que o usuário pode fazer na base do Kerberos.
Configuração do arquivo /etc/kadmind.acl
ldapmaster/admin@EXEMPLO-LAB.INT.BR add,delete,get host/*@EXEMPLO-LAB.INT.BR * NO cpw *@EXEMPLO-LAB.INT.BR kadmin/admin@EXEMPLO-LAB.INT.BR all root/admin@EXEMPLO-LAB.INT.BR all addmachine/admin@EXEMPLO-LAB.INT.BR all
Criando diretório de LOG e renovando o keytab e chave mestre do servidor
server root# mkdir -p /var/log/heimdal server root# rm -rf /etc/krb5.keytab server root# rm -rf /var/lib/heimdal-kdc/m-key
Reinicialização dos serviços do Kerberos
server root# /etc/init.d/heimdal-kcm restart server root# /etc/init.d/heimdal-kdc restart
Gerando a chave mestre do dominio Kerberos
Podemos ter todas as chaves dos nossos principals encriptadas com uma chave mestra. Para criar esta chave mestra invoque o kstash:
server root# kstash --random-key
Gerando o dominio Kerberos
Uma vez criada a chave mestra podemos inicializar o nosso domínio, com o seguinte comando abaixo:
server root# kadmin -l init --realm-max-ticket-life=unlimited --realm-max-renewable-life=unlimited EXEMPLO-LAB.INT.BR
Com esse comando deve ter criado várias entradas em nosso diretório LDAP.
Criando principal e keytab para os serviços LDAP e Samba
Para cada serviço de autenticação Kerberos aceitar conexões autenticadas precisamos criar um principal para o serviço, e depois, temos que extrair um ticket de serviço e colocá-lo em um keytab. Temos que fazer isto, a fim de proporcionar autenticação Kerberos no LDAP, Samba, etc:
server root# kadmin -l add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= host/bioquimik.exemplo-lab.int.br server root# kadmin -l add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= host/bioquimik server root# kadmin -l ext_keytab host/bioquimik.exemplo-lab.int.br server root# kadmin -l ext_keytab host/bioquimik server root# kadmin -l add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= ldap/bioquimik.exemplo-lab.int.br server root# kadmin -l add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= ldap/bioquimik server root# kadmin -l ext_keytab ldap/bioquimik.exemplo-lab.int.br server root# kadmin -l ext_keytab ldap/bioquimik server root# kadmin -l add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= cifs/bioquimik.exemplo-lab.int.br server root# kadmin -l add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= cifs/bioquimik server root# kadmin -l ext_keytab cifs/bioquimik.exemplo-lab.int.br server root# kadmin -l ext_keytab cifs/bioquimik
É de extrema importancia usar o nome completo da maquina (bioquimik.exemplo-lab.int.br) onde o servidor está localizado, pois o Kerberos utiliza este nome para obter o ticket do serviço, apesar do acesso ao serviço utilizar um alias (bioquimik). Se não usar o nome completo da maquina nós podemos enfrentar um erro como este "GSSAPI Error: Miscellaneous failure (Server not found in Kerberos database)" quando tentamos acessar o serviço.
Atribundo senha para o ldapmaster/admin e kadmin/admin
server root# kadmin -l cpw --password=secret1 ldapmaster/admin server root# kadmin -l cpw --password=secret2 kadmin/admin
O redirecionamento da senha do usuário ldapmaster/admin é feita automaticamente, porque o atributo userPassword está com o valor {K5KEY}, isso quer dizer, que a senha do Kerberos é a mesma do LDAP.
O usuário kadmin/admin só vai servir para o acesso a base do Kerberos através do administrador do Kerberos, isso quer dizer, esse usuário não vai se autenticar no LDAP e no Samba.
Novamente! Reinicialização dos serviços do Kerberos
server root# /etc/init.d/heimdal-kcm restart server root# /etc/init.d/heimdal-kdc restart
Configuração do saslauthd
Configuração do arquivo /etc/default/saslauthd
MECH_OPTIONS="" THREADS=5 START=yes MECHANISMS="ldap" #OPTIONS="-c"
Configuração do arquivo /usr/lib/sasl2/slapd.conf
pwcheck_method: saslauthd
Configuração do arquivo /etc/saslauthd.conf
ldap_servers: ldapi:///
ldap_version: 3
ldap_referrals: no
ldap_auth_method: fastbind
ldap_filter: uid=%u,ou=Usuarios,dc=exemplo-lab,dc=int,dc=br
Reinicialização do serviço
server root# /etc/init.d/saslauthd restart
Configuração do Samba PDC
Configuração do arquivo /etc/samba/smb.conf
[global]
workgroup = EXEMPLO-LAB
realm = EXEMPLO-LAB.INT.BR
netbios name = bioquimik
server string = Linux PDC/KDC
use kerberos keytab = yes
use spnego = yes
client NTLMv2 auth = yes
debug level = 1
log file = /var/log/samba/%m.log
max log size = 5000
syslog = 0
log level = 1
utmp = Yes
guest account = nobody
map to guest = Never
admin users = root @"Domain Admins"
enable privileges = yes
security = user
encrypt passwords = yes
os level = 255
local master = yes
domain master = yes
preferred master = yes
domain logons = yes
keepalive = 20
time server = yes
preserve case = yes
short preserve case = yes
case sensitive = no
null passwords = no
logon script = %U.bat
logon path =
logon drive = H:
logon home = /home/%U
bind interfaces only = yes
interfaces = eth0, lo
hosts allow = 192.168.0. 127.
wins support = yes
dns proxy = yes
passdb backend = ldapsam:ldaps://bioquimik.exemplo-lab.int.br/
ldap admin dn = krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br
ldap suffix = dc=exemplo-lab,dc=int,dc=br
ldap group suffix = ou=Grupos
ldap user suffix = ou=Usuarios
ldap machine suffix = ou=Computadores
ldap idmap suffix = ou=Idmap
ldap ssl = On
ldap delete dn = Yes
ldapsam:trusted = yes
idmap backend = ldap:ldaps://bioquimik.exemplo-lab.int.br/
idmap uid = 10000-15000
idmap gid = 10000-15000
#
# Utilizando o smbldap-passwd para a troca de senha
#
#unix password sync = yes
#ldap passwd sync = yes
#passwd program = /usr/sbin/smbldap-passwd %u
#passwd chat = "Changing UNIX and samba passwords for*\nNew password*" %n\n "*Retype new password*" %n\n"
#
# Utilizando recursos internos do Samba para
# para troca de senha.
#
ldap passwd sync = Only
unix password sync = no
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192
add machine script = /usr/sbin/smbldap-useradd -w "%u"
add user script = /usr/sbin/smbldap-useradd -m -a "%u"
delete user script = /usr/sbin/smbldap-userdel "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
delete group script = /usr/sbin/smbldap-groupdel "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"
dos charset = cp850
unix charset = iso8859-1
display charset = LOCALE
restrict anonymous = 0
[homes]
comment = Home Directories
valid users = %S
browseable = no
writable = yes
admin users = %u
write list = %u
read list = %u
create mask = 0700
directory mask = 0700
[netlogon]
path = /samba/netlogon
writable = yes
browseable = no
share modes = no
admin users = @"Domain Admins"
Criação do diretorio NETLOGON e remoção de arquivos desnecessarios
server root# mkdir -p /samba/netlogon server root# rm -rf /etc/samba/*tdb server root# rm -rf /etc/samba/gdbcommands server root# rm -rf /var/lib/samba/*tdb server root# rm -rf /var/lib/samba/*dat server root# rm -rf /var/log/samba/*
Armazenamento da senha do ldapmaster/admin no Samba
server root# smbpasswd -w secret1
Saida do comando:
Setting stored password for "krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals, dc=exemplo-lab,dc=int,dc=br" in secrets.tdb
Reiniciar o serviço Samba, LDAP e Heimdal Kerberos
server root# /etc/init.d/slapd restart server root# /etc/init.d/heimdal-kdc restart server root# /etc/init.d/heimdal-kcm restart server root# /etc/init.d/samba restart
Gerar SID do dominio Samba
server root# net getlocalsid EXEMPLO-LAB
Saida do comando:
SID for domain EXEMPLO-LAB is: S-1-5-21-2002721591-2688508835-2701232019
Novamente! reinicie o serviço Samba
server root# /etc/init.d/samba restart
Configuração do arquivo /etc/smbldap-tools/smbldap.conf
SID="S-1-5-21-2002721591-2688508835-2701232019" sambaDomain="EXEMPLO-LAB" realm="EXEMPLO-LAB.INT.BR" slaveLDAP="ldaps://bioquimik.exemplo-lab.int.br" slavePort="636" masterLDAP="ldaps://bioquimik.exemplo-lab.int.br" masterPort="636" ldapTLS="1" verify="require" cafile="/etc/ldap/ssl/cacert.pem" clientcert="/etc/ldap/ssl/servercrt.pem" clientkey="/etc/ldap/ssl/serverkey.pem" suffix="dc=exemplo-lab,dc=int,dc=br" usersdn="ou=Usuarios,${suffix}" computersdn="ou=Computadores,${suffix}" groupsdn="ou=Grupos,${suffix}" idmapdn="ou=Idmap,${suffix}" sambaUnixIdPooldn="sambaDomainName=EXEMPLO-LAB,${suffix}" scope="sub" hash_encrypt="MD5" crypt_salt_format="%s" userLoginShell="/bin/false" userHome="/home/%U" userHomeDirectoryMode="700" userGecos="LDAP-Kerberos User" defaultUserGid="513" defaultComputerGid="515" skeletonDir="/etc/skel" defaultMaxPasswordAge="45" userSmbHome="\\bioquimik\%U" #userProfile="\\bioquimik\profiles\%U" userHomeDrive="H:" userScript="%U.bat" mailDomain="exemplo-lab.int.br" with_smbpasswd="0" smbpasswd="/usr/bin/smbpasswd" with_slappasswd="0" slappasswd="/usr/sbin/slappasswd" # no_banner="1"
Configuração do arquivo /etc/smbldap-tools/smbldap_bind.conf
slaveDN="krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br" slavePw="secret1" masterDN="krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals,dc=exemplo-lab,dc=int,dc=br" masterPw="secret1"
Copiar smbldap-useradd modificado para o Kerberos
Quando é usado a opção '-a' no smbldap-useradd é adicionado/alterado alguns atributos do Kerberos e do posixAccount, eles são:
- objectClass -> krb5Principal
- objectClass -> krb5KDCEntry
- krb5KeyVersionNumber -> 0
- krb5PrincipalName -> usuario@REALM (dominio Kerberos)
- krb5KDCFlags -> 126
- krb5MaxRenew -> 604800
- krb5MaxLife -> 86400
- userPassword -> {K5KEY}
server root# wget http://www.eduardosachs.org/mediawiki/files-howtos/etch/smbldap-useradd -P /tmp/ server root# mv /tmp/smbldap-useradd /usr/sbin/ server root# chmod +x /usr/sbin/smbldap-useradd
Ajustes de permissões
server root# chmod 700 /etc/smbldap-tools/ server root# chmod 600 /etc/smbldap-tools/smbldap.conf server root# chmod 600 /etc/smbldap-tools/smbldap_bind.conf server root# chmod 700 /usr/sbin/smbldap-*
Preparando a base LDAP para o Samba
server root# smbldap-populate -a root -k 0 -m 0
Saida do comando:
Populating LDAP directory for domain EXEMPLO-LAB (S-1-5-21-2002721591-2688508835-2701232019) (using builtin directory structure) entry dc=exemplo-lab,dc=int,dc=br already exist. adding new entry: ou=Usuarios,dc=local,dc=int,dc=br entry ou=Grupos,dc=exemplo-lab,dc=int,dc=br already exist. entry ou=Computadores,dc=exemplo-lab,dc=int,dc=br already exist. adding new entry: ou=Idmap,dc=exemplo-lab,dc=int,dc=br adding new entry: uid=root,ou=Usuarios,dc=exemplo-lab,dc=int,dc=br adding new entry: uid=nobody,ou=Usuarios,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Domain Admins,ou=Grupos,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Domain Users,ou=Grupos,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Domain Guests,ou=Grupos,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Domain Computers,ou=Grupos,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Administrators,ou=Grupos,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Account Operators,ou=Grupos,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Print Operators,ou=Grupos,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Backup Operators,ou=Grupos,dc=exemplo-lab,dc=int,dc=br adding new entry: cn=Replicators,ou=Grupos,dc=exemplo-lab,dc=int,dc=br entry sambaDomainName=EXEMPLO-LAB,dc=exemplo-lab,dc=int,dc=br already exist. Updating it... Please provide a password for the domain root: Changing UNIX and samba passwords for root New password: Retype new password:
Ajustando o NextUserRid
Isso vai servir para que o proximo usuário ou grupo a ser adicionando tenha um uidNumber/gidNumber maior que 2000.
Configuração do arquivo /etc/ldap/nextsambaid.ldif
dn: sambaDomainName=EXEMPLO-LAB,dc=exemplo-lab,dc=int,dc=br changetype: modify uidNumber: 2000 gidNumber: 2000
Inserindo as modificações no NextUserRid
server root# ldapmodify -x -D "krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals, \ dc=exemplo-lab,dc=int,dc=br" -w secret1 -f /etc/ldap/nextsambaid.ldif
Saida do comando:
modifying entry "sambaDomainName=EXEMPLO-LAB,dc=exemplo-lab,dc=int,dc=br"
Ajustando os atributos do Kerberos no usuário root
Configuração do arquivo /etc/ldap/rootmodify.ldif
O usuário root vai ser admin da base Kerberos.
dn: uid=root,ou=Usuarios,dc=exemplo-lab,dc=int,dc=br changetype: modify add: objectClass objectClass: krb5Principal objectClass: krb5KDCEntry - add: krb5KeyVersionNumber krb5KeyVersionNumber: 1 - add: krb5PrincipalName krb5PrincipalName: root/admin@EXEMPLO-LAB.INT.BR - add: krb5KDCFlags krb5KDCFlags: 126 - add: krb5MaxRenew krb5MaxRenew: 604800 - add: krb5MaxLife krb5MaxLife: 86400 - changetype: modify homeDirectory: /root - changetype: modify gidNumber: 512 - changetype: modify userPassword: {K5KEY}
Precisamos colocar manualmente os atributos do Kerberos no usuário root, pois ele não foi adicionado através do comando smbldap-useradd, ele usou o smbldap-populate (esse comando não tem os atributos do Kerberos) para adicionar o usuário root, aproveitando, deixei o usuário como Administrador da base Kerberos.
Inserindo as modificações no usuário root
server root# ldapmodify -x -D "krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals, \ dc=exemplo-lab,dc=int,dc=br" -w secret1 -f /etc/ldap/rootmodify.ldif
Saida do comando:
modifying entry "uid=root,ou=Usuarios,dc=exemplo-lab,dc=int,dc=br"
Alterar a senha do usuário root
Precisamos usar o smbpasswd para trocar a senha do usuário root, para ficar compativel com o overlay smbk5pwd, mas, antes disso precisamos reiniciar o Samba:
server root# /etc/init.d/samba restart server root# smbpasswd root
Adicionando o usuário addmachine no Samba e no Kerberos
Usando o smbldap-useradd modificado para o Kerberos
server root# smbldap-useradd -a -m addmachine server root# smbpasswd addmachine
Configuração do arquivo /etc/ldap/addmachinemodify.ldif
É preciso colocar o /admin depois do nome do usuário no atributo krb5PrincipalName, pois esse usuário vai ser admin da base Kerberos.
dn: uid=addmachine,ou=Usuarios,dc=exemplo-lab,dc=int,dc=br changetype: modify krb5PrincipalName: addmachine/admin@EXEMPLO-LAB.INT.BR
Isso você precisa adicionar no usuário manualmente, pois não vai ser qualquer usuário que será Administrador da base Kerberos, eu não coloquei esse tipo de operação no smbldap-tools porque não houve necessidade.
Inserir as modificações do usuário addmachine
server root# ldapmodify -x -D "krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=KerberosPrincipals, \ dc=exemplo-lab,dc=int,dc=br" -w secret1 -f /etc/ldap/addmachinemodify.ldif
Saida do comando:
modifying entry "uid=addmachine,ou=Usuarios,dc=exemplo-lab,dc=int,dc=br"
Reiniciar o Samba
server root# /etc/init.d/samba restart
Permissão para o usuário addmachine
Precisamos dar permissão para o usuário addmachine poder colocar computadores no domínio Samba PDC, com o comando abaixo:
server root# net rpc rights grant "EXEMPLO-LAB\addmachine" SeMachineAccountPrivilege -U root%secret4
Adicionando um usuário normal para o Samba e Kerberos
server root# smbldap-useradd -m -a sachs server root# smbpasswd sachs server root# smbldap-userinfo sachs
Saida do comando smbldap-userinfo:
Changing the user information for sachs Enter the new value, or press ENTER for the default User Shell [/bin/false]:/bin/bash Full Name [LDAP-Kerberos User]: Room Number []: Work Phone []: Home Phone []: Other []: LDAP updated
Veja bem, você não precisa mexer em LDIF quando se adiciona um usuário normal para o Samba/Kerberos ao mesmo tempo, isso quer dizer, você usando o smbldap-useradd o usuário já existe na base Samba e Kerberos.
Foi colocado o User Shell como /bin/bash porque o usuário vai se logar em uma estação Linux.
Remover o smbldap-passwd
Precisamos alterar a senha do usuário através do smbpasswd, por isso vamos remover o smbldap-passwd e criar um link simbólico do smbpasswd para smbldap-passwd.
server root# rm /usr/sbin/smbldap-passwd server root# ln -s /usr/bin/smbpasswd /usr/sbin/smbldap-passwd
Reinicialização dos serviços
server root# /etc/init.d/bind9 restart server root# /etc/init.d/slapd restart server root# /etc/init.d/samba restart server root# /etc/init.d/saslauthd restart server root# /etc/init.d/heimdal-kcm restart server root# /etc/init.d/heimdal-kdc restart server root# /etc/init.d/ntp restart server root# /etc/init.d/openbsd-inetd restart
Testes de autenticação Single Sign-On
Autenticação LDAP
Vamos primeiro se autenticar com o usuário ldapmaster/admin no Kerberos.
server root# kinit ldapmaster/admin
ldapmaster/admin@EXEMPLO-LAB.INT.BR's Password:
Verifique o ticket de autenticação Kerberos.
server root# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: ldapmaster/admin@EXEMPLO-LAB.INT.BR
Issued Expires Principal
Jan 20 14:15:03 Jan 21 12:28:23 krbtgt/EXEMPLO-LAB.INT.BR@EXEMPLO-LAB.INT.BR
Vamos verificar se a autenticação do LDAP está funcionando corretamento com o Kerberos.
server root# ldapwhoami -Y GSSAPI SASL/GSSAPI authentication started SASL username: ldapmaster/admin@EXEMPLO-LAB.INT.BR SASL SSF: 56 SASL installing layers dn:krb5PrincipalName=ldapmaster/admin@EXEMPLO-LAB.INT.BR,ou=kerberosprincipals,dc=exemplo-lab,dc=int,dc=br Result: Success (0)
Vamos verificar o ticket do LDAP no usuário autenticado no Kerberos.
server root# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: ldapmaster/admin@EXEMPLO-LAB.INT.BR
Issued Expires Principal
Jan 20 14:21:17 Jan 21 12:34:37 krbtgt/EXEMPLO-LAB.INT.BR@EXEMPLO-LAB.INT.BR
Jan 20 14:21:25 Jan 21 12:34:37 ldap/bioquimik.exemplo-lab.int.br@EXEMPLO-LAB.INT.BR
Autenticação Samba
Vamos nos autenticar no Kerberos:
server root# kdestroy server root# kinit addmachine
Vamos nos autenticar no Samba utilizando o Kerberos.
server root# smbclient //bioquimik/netlogon -k
OS=[Unix] Server=[Samba 3.0.24]
smb: \>
Vamos verificar o ticket do Samba no usuário autenticado no Kerberos.
server root# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: addmachine@EXEMPLO-LAB.INT.BR
Issued Expires Principal
Jan 20 14:18:19 Jan 21 12:31:39 krbtgt/EXEMPLO-LAB.INT.BR@EXEMPLO-LAB.INT.BR
Jan 20 14:18:24 Jan 21 12:31:39 cifs/bioquimik.exemplo-lab.int.br@EXEMPLO-LAB.INT.BR
Montando compartilhamento do Samba via autenticação Kerberos.
server root# mkdir -p /tmp/netlogon server root# smbmount //bioquimik/netlogon /tmp/netlogon/ -o krb Warning: kerberos support will only work for samba servers server root# df Sist. Arq. 1K-blocos Usad Dispon. Uso% Montado em .... //bioquimik/netlogon 7305344 1244544 6060800 18% /tmp/netlogon .... server root# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: addmachine@EXEMPLO-LAB.INT.BR Issued Expires Principal Jan 20 14:31:06 Jan 21 12:44:26 krbtgt/EXEMPLO-LAB.INT.BR@EXEMPLO-LAB.INT.BR Jan 20 14:31:09 Jan 21 12:44:26 cifs/bioquimik.exemplo-lab.int.br@EXEMPLO-LAB.INT.BR
Vamos nos autenticar via Kerberos no LDAP com o usuário addmachine.
server root# ldapwhoami -Y GSSAPI SASL/GSSAPI authentication started SASL username: addmachine@EXEMPLO-LAB.INT.BR SASL SSF: 56 SASL installing layers dn:uid=addmachine,ou=usuarios,dc=exemplo-lab,dc=int,dc=br Result: Success (0)
Compilação e configuração do Squid com suporte há Kerberos (OPCIONAL)
Instalando dependências do Squid
server root# apt-get install -y dialog debconf-utils libltdl3 build-essential \ fakeroot dpatch libpam0g-dev libssl-dev libsasl2-dev comerr-dev libdb4.2-dev \ libldap-dev heimdal-dev libsmbclient-dev libpam-dev dpkg-dev libltdl3-dev
Fazendo download do Squid
Você deve fazer o download da ultima versão do Squid:
server root# wget http://www.squid-cache.org/Versions/v2/2.6/squid-2.6.STABLE22.tar.gz server root# tar -zxvf squid-2.6.STABLE22.tar.gz server root# cd squid-2.6.STABLE22
Compilando o Squid com suporte há Kerberos
server root# ./configure --prefix=/usr --exec_prefix=/usr --bindir=/usr/sbin --sbindir=/usr/sbin --libexecdir=/usr/lib/squid \ --sysconfdir=/etc/squid --localstatedir=/var/spool/squid --datadir=/usr/share/squid --enable-async-io \ --with-pthreads --enable-storeio=ufs,aufs,coss,diskd,null --enable-linux-netfilter --enable-arp-acl --enable-epoll \ --enable-removal-policies=lru,heap --enable-snmp --enable-delay-pools --enable-htcp --enable-cache-digests \ --enable-underscores --enable-referer-log --enable-useragent-log --enable-auth="basic,digest,ntlm,negotiate" \ --enable-basic-auth-helpers="LDAP,MSNT,multi-domain-NTLM,NCSA,SASL,PAM,SMB,squid_radius_auth" \ --enable-ntlm-auth-helpers="SMB,no_check" --enable-digest-auth-helpers="ldap,password" \ --enable-external-acl-helpers="ip_user,ldap_group,session,unix_group,wbinfo_group" \ --enable-ntlm-fail-open --enable-carp --enable-follow-x-forwarded-for --with-large-files --with-maxfd=65536 server root# make server root# make install server root# cd helpers/negotiate_auth/squid_kerb_auth server root# ./do.sh HEIMDAL server root# cp squid_kerb_auth /usr/lib/squid
Criando usuario/grupo para o squid
server root# useradd -s /bin/false -r squid server root# usermod -d /var/spool/squid squid
Criando diretórios para o squid e ajustando suas permissões
server root# mkdir -p /var/log/squid server root# mkdir -p /var/spool/squid server root# mkdir -p /etc/squid server root# chown squid.squid /var/spool/squid -R server root# chown squid.squid /var/log/squid -R server root# chown squid.squid /etc/squid -R
Configuração do arquivo /etc/squid/squid.conf (basico)
http_port 3128 icp_port 0 hierarchy_stoplist cgi-bin ? acl QUERY urlpath_regex cgi-bin \? cache deny QUERY acl apache rep_header Server ^Apache broken_vary_encoding allow apache cache_mem 64 MB maximum_object_size_in_memory 128 KB emulate_httpd_log on pid_filename /var/run/squid.pid cache_dir diskd /var/spool/squid/cache 2048 16 256 access_log /var/log/squid/access.log squid cache_store_log /var/spool/squid/store.log cache_log /var/spool/squid/cache.log hosts_file /etc/hosts # Kerberos authentication auth_param negotiate program /usr/lib/squid/squid_kerb_auth auth_param negotiate children 10 auth_param negotiate keep_alive on # ntlm authentication auth_param ntlm program /usr/lib/squid/ntlm_auth -d EXEMPLO-LAB\\bioquimik auth_param ntlm children 5 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern . 0 20% 4320 acl all src 0.0.0.0/0.0.0.0 acl localnet src 192.168.0.0/24 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl purge method PURGE acl SSL_ports port 443 563 acl Safe_ports port 80 acl Safe_ports port 21 acl Safe_ports port 443 563 acl Safe_ports port 70 acl Safe_ports port 210 acl Safe_ports port 1025-65535 acl Safe_ports port 280 acl Safe_ports port 488 acl Safe_ports port 591 acl Safe_ports port 777 acl CONNECT method CONNECT acl Authenticated proxy_auth REQUIRED http_access allow manager localhost http_access deny manager http_access allow purge localhost http_access deny purge http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow Authenticated http_access allow localhost http_access deny all http_reply_access allow all icp_access allow all cache_effective_user squid cache_effective_group squid error_directory /usr/share/squid/errors/Portuguese
Adicionando o serviço do Squid no Kerberos
server root# kinit kadmin/admin server root# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= HTTP/bioquimik.exemplo-lab.int.br server root# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= HTTP/bioquimik server root# ktutil -k /etc/squid/HTTP.keytab get HTTP/bioquimik.exemplo-lab.int.br server root# ktutil -k /etc/squid/HTTP.keytab get HTTP/bioquimik server root# chown squid.squid /etc/squid/HTTP.keytab server root# kdestroy
- Caso você for instalar o Squid em um outro servidor, etapas:
- Você precisa configurar o cliente Kerberos e além de adicionar o principal HTTP você precisa adicionar o principal host (host/servidor e host/servidor.exemplo-lab.int.br), e o keytab DEVE ficar no servidor que está configurado o Squid.
- Você deve colocar o servidor no domínio Samba para funcionar a autenticação NTLM para o Windows.
Criando o cache do Squid
server root# squid -z
Ajustando inicialização do Squid
Eu tive que editar o init do Squid para funcionar corretamente com o Kerberos, adicionando as duas linhas abaixo:
KRB5_KTNAME=/etc/squid/HTTP.keytab export KRB5_KTNAME
server root# wget http://www.eduardosachs.org/mediawiki/files-howtos/etch/squid/default/squid -P /etc/default/ server root# wget http://www.eduardosachs.org/mediawiki/files-howtos/etch/squid/init.d/squid -P /etc/init.d/ server root# chmod +x /etc/init.d/squid server root# ln -s /etc/init.d/squid /etc/rc5.d/S21squid server root# ln -s /etc/init.d/squid /etc/rc6.d/K21squid server root# ln -s /etc/init.d/squid /etc/rc3.d/S21squid server root# ln -s /etc/init.d/squid /etc/rc4.d/S21squid server root# ln -s /etc/init.d/squid /etc/rc2.d/S21squid server root# ln -s /etc/init.d/squid /etc/rc1.d/K21squid server root# /etc/init.d/squid start
Autenticação do Squid no Cliente Linux
Quando você for se autenticar no cliente Linux via PAM, você precisará configurar o proxy normalmente no Firefox, e após isso, a autenticação do proxy será feita automáticamente pelo Kerberos.
Configuração do cliente Linux
Configurações do computador na rede
Deve ser alterado tudo que estiver em VERMELHO
- Endereço IP: 192.168.0.121
- Nome do PC: cliente
Ajustes na configuração de nome do cliente
Faça os seguintes ajustes nos arquivos /etc/hosts e /etc/hostname antes de instalar os pacotes.
Configuração do arquivo /etc/hosts
192.168.0.121 cliente.exemplo-lab.int.br cliente
127.0.0.1 localhost.localdomain localhost
Configuração do arquivo /etc/hostname
cliente
Reinicie o cliente após configurar o /etc/hosts e /etc/hostname.
É preciso instalar os pacotes com o hostname correto que será usado para a autenticação do cliente.
root client# reboot
Ajustar o debconf
No nosso caso, nós vamos desabilitar aquelas perguntas que o pacote faz quando está sendo instalado.
root client# export DEBIAN_PRIORITY=critical root client# export DEBIAN_FRONTEND=noninteractive
Instalação dos pacotes
root client# apt-get update root client# apt-get install -y heimdal-clients krb5-config libpam-krb5 \ libnss-ldap ldap-utils libpam-ldap libsasl2-modules-gssapi-heimdal \ smbclient samba samba-common smbfs smbfs libsmbclient libcupsys2-gnutls10 \ cupsys-common libcupsys2 winbind ntp dialog
Reajustar o debconf
Vamos voltar ao normal o debconf, como estava antes de fazer a alteração.
root client# unset DEBIAN_PRIORITY root client# unset DEBIAN_FRONTEND
Parar o serviço Samba
Vamos parar o serviço Samba, será melhor, para manter organizada a configuração.
root client# /etc/init.d/samba stop root client# /etc/init.d/winbind stop
Ajustar dia/hora
É preciso sincronizar a data/hora do cliente com a data/hora do servidor Kerberos.
Configuração do arquivo /etc/ntp.conf
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server 192.168.0.70
driftfile /etc/ntp/drift
multicastclient
broadcastdelay 0.008
Reinicie o serviço NTP:
server root# /etc/init.d/ntp restart
Configuração do arquivo /etc/resolv.conf
search exemplo-lab.int.br nameserver 192.168.0.70
Configuração do arquivo /etc/libnss-ldap.conf
- Você pode usar a porta 389 para se conectar no LDAP, mas como eu sou neorótico, preferi colocar a 636 com certificado.
base dc=exemplo-lab,dc=int,dc=br uri ldaps://bioquimik.exemplo-lab.int.br/ port 636 ldap_version 3 bind_policy soft bind_timelimit 2 timelimit 2 scope sub nss_reconnect_maxsleeptime 8 nss_reconnect_sleeptime 1 nss_initgroups_ignoreusers root nss_srv_domain exemplo-lab.int.br pam_password exop pam_filter objectclass=posixAccount pam_login_attribute uid pam_member_attribute memberUid nss_base_passwd ou=Usuarios,dc=exemplo-lab,dc=int,dc=br?one nss_base_shadow ou=Usuarios,dc=exemplo-lab,dc=int,dc=br?one nss_base_passwd ou=Computadores,dc=exemplo-lab,dc=int,dc=br?one nss_base_shadow ou=Computadores,dc=exemplo-lab,dc=int,dc=br?one nss_base_group ou=Grupos,dc=exemplo-lab,dc=int,dc=br?one ssl on tls_ciphers TLSv1
Configuração do arquivo /etc/ldap/ldap.conf
host bioquimik.exemplo-lab.int.br base dc=exemplo-lab,dc=int,dc=br uri ldaps://bioquimik.exemplo-lab.int.br/ port 636 TLS_REQCERT allow
Configuração do arquivo /etc/nsswitch.conf
passwd: files ldap [notfound=continue] shadow: files ldap [notfound=continue] group: files ldap [notfound=continue] hosts: files dns wins networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
Configuração do arquivo /etc/krb5.conf
[libdefaults]
default_realm = EXEMPLO-LAB.INT.BR
ticket_lifetime = 80000
kdc_timesync = 1
forwardable = true
proxiable = true
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
[realms]
EXEMPLO-LAB.INT.BR = {
kdc = bioquimik.exemplo-lab.int.br
admin_server = bioquimik.exemplo-lab.int.br
}
Configuração do PAM
Configuração do arquivo /etc/pam.d/common-auth
auth sufficient pam_unix.so nullok_secure auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so
Configuração do arquivo /etc/pam.d/common-account
account sufficient pam_unix.so account sufficient pam_krb5.so account required pam_deny.so
Configuração do arquivo /etc/pam.d/common-password
password sufficient pam_unix.so nullok obscure md5 password required pam_winbind.so
Configuração do arquivo /etc/pam.d/common-session
session optional pam_unix.so session optional pam_krb5.so session optional pam_mkhomedir.so skel=/etc/skel/ umask=077
Reinciar o GDM
Você precisar reinciar o GDM para funcionar as novas configurações do PAM no GDM.
root client# /etc/init.d/gdm restart
Configuração do arquivo /etc/samba/smb.conf
[global]
workgroup = EXEMPLO-LAB
netbios name = cliente
realm = EXEMPLO-LAB.INT.BR
security = domain
wins server = 192.168.0.70
use kerberos keytab = yes
client use spnego = yes
client NTLMv2 auth = yes
bind interfaces only = yes
interfaces = eth0, lo
hosts allow = 192.168.0.0/24, 127.0.0.1
debug level = 2
log file = /var/log/samba/%m.log
max log size = 50
log level = 1
syslog = 0
utmp = Yes
idmap uid = 10000-15000
idmap gid = 10000-15000
template shell = /bin/bash
template homedir = /home/%U
winbind separator = +
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
encrypt passwords = yes
invalid users = root
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192
local master = no
domain master = no
dns proxy = no
preserve case = yes
short preserve case = no
default case = lower
case sensitive = no
dos charset = cp850
unix charset = iso8859-1
display charset = LOCALE
restrict anonymous = 0
[publico]
path = /samba/publico
writable = yes
browseable = no
share modes = no
admin users = @"Domain Admins"
Criação de pasta e remoção de arquivos desnecessarios
root client# mkdir -p /samba/publico root client# chgrp "Domain Admins" /samba/publico root client# rm -rf /etc/samba/*tdb root client# rm -rf /var/lib/samba/*tdb root client# rm -rf /var/lib/samba/*dat root client# rm -rf /var/log/samba/*
Reinicialização do Samba
root client# /etc/init.d/samba stop root client# /etc/init.d/winbind stop root client# /etc/init.d/samba start root client# /etc/init.d/winbind start
Adicionando a maquina no dominio Samba
root client# net rpc join member -U addmachine
Digite a senha do addmachine. Saida do comando:
Password: Joined domain EXEMPLO-LAB.
Adicionando a maquina no dominio Kerberos
Digite a senha do addmachine/admin.
root client# kinit addmachine/admin
Após estar logado no Kerberos com o usuário addmachine/admin, digite os seguintes comandos:
root client# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= host/cliente.exemplo-lab.int.br root client# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= host/cliente root client# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= cifs/cliente.exemplo-lab.int.br root client# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= cifs/cliente root client# ktutil -k /etc/krb5.keytab get host/cliente.exemplo-lab.int.br root client# ktutil -k /etc/krb5.keytab get host/cliente root client# ktutil -k /etc/krb5.keytab get cifs/cliente.exemplo-lab.int.br root client# ktutil -k /etc/krb5.keytab get cifs/cliente
Novamente! Reinicie o Samba
root client# /etc/init.d/samba restart root client# /etc/init.d/winbind restart
Testes de autenticação Single Sign-On
Vamos nos logar no Kerberos:
root client# kinit sachs sachs@EXEMPLO-LAB.INT.BR's Password:
Usuário se autenticando no LDAP via GSSAPI/Kerberos:
root client# ldapwhoami -Y GSSAPI SASL/GSSAPI authentication started SASL username: sachs@EXEMPLO-LAB.INT.BR SASL SSF: 56 SASL installing layers dn:uid=sachs,ou=usuarios,dc=exemplo-lab,dc=int,dc=br Result: Success (0)
Usuário se autenticando no Samba via Kerberos:
root client# smbclient //bioquimik/netlogon -k
OS=[Unix] Server=[Samba 3.0.24]
smb: \> ls
. D 0 Sat Jan 19 14:44:05 2008
.. D 0 Sat Jan 19 14:44:05 2008
57073 blocks of size 131072. 47323 blocks available
smb: \> quit
Verificar os tickets:
root client# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: sachs@EXEMPLO-LAB.INT.BR
Issued Expires Principal
Jan 22 14:50:07 Jan 23 13:03:38 krbtgt/EXEMPLO-LAB.INT.BR@EXEMPLO-LAB.INT.BR
Jan 22 14:50:12 Jan 23 13:03:38 ldap/bioquimik.exemplo-lab.int.br@EXEMPLO-LAB.INT.BR
Jan 22 14:50:47 Jan 23 13:03:38 cifs/bioquimik.exemplo-lab.int.br@EXEMPLO-LAB.INT.BR
Alguns detalhes do cliente Linux que não podem ser esquecidos
Pré-requisitos para alguém acessar o cliente Samba através da autenticação Kerberos:
- DNS
- FQDN válido do cliente
- DNS Reverso do cliente
- Deve ser criado o ticket para o serviço CIFS:
- host/cliente.exemplo-lab.int.br
- host/cliente
- cifs/cliente.exemplo-lab.int.br
- cifs/cliente
- Exemplo:
root client# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= host/cliente.exemplo-lab.int.br root client# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= host/cliente root client# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= cifs/cliente.exemplo-lab.int.br root client# kadmin add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --expiration-time=never \ --pw-expiration-time=never --attributes= cifs/cliente
- Deve ser adicionado os tickets acima no keytab do cliente.
- Exemplo:
root client# ktutil -k /etc/krb5.keytab get host/cliente.exemplo-lab.int.br root client# ktutil -k /etc/krb5.keytab get host/cliente root client# ktutil -k /etc/krb5.keytab get cifs/cliente.exemplo-lab.int.br root client# ktutil -k /etc/krb5.keytab get cifs/cliente
- Habilitar as seguintes variaveis no /etc/samba/smb.conf:
- realm = EXEMPLO-LAB.INT.BR
- use kerberos keytab = yes
- client use spnego = yes
Outras observações:
- Troca de senha do usuário:
- Com o PAM corretamente configurado, você poderá trocar a senha através do comando passwd na própria estação de trabalho.
- Você também pode usar o comando 'smbpasswd -r hostname_do_servidor -U usuario'
- VOCÊ NÃO PODE USAR O KPASSWD PARA ALTERAR SENHAS, VOCÊ DEVE ALTERAR SENHAS DOS USUÁRIOS ATRAVÉS DO SAMBA, FAZENDO O USO DO OVERLAY SMBK5PWD UTILIZANDO O COMANDO SMBPASSWD (comando acima), ou algum mecanismo de troca de senhas do Samba, por exemplo, através do PAM usando Winbind.
- Para o usuário se logar em alguma estação Linux, é preciso que o atributo 'loginShell' seja '/bin/bash', você pode usar o smbldap-userinfo para mudar esse atributo.
Funcionamento do mecanismo de autenticação Kerberos/Samba
O Heimdal Kerberos vai usar as senhas dos objetos 'sambaLMPassword' e 'sambaNTPassword' para se autenticar no Kerberos, isso só vai acontecer caso ele encontrar os objetos do Samba no usuário.
- Fluxograma de autenticação: http://www.eduardosachs.org/mediawiki/files-howtos/imagens/SenhaLDAPSambaKerberos.gif
Se o usuário não for do Samba, o Heimdal Kerberos irá usar a senha que está no objeto 'krb5Key'.
- Fluxograma de autenticação: http://www.eduardosachs.org/mediawiki/files-howtos/imagens/SenhaLDAPKerberos.gif
Porém, quando é usado o overlay smbk5pwd, o Kerberos começa a usar a senha do atributo krb5Key, esses diagramas serve para as implementações sem esse overlay, pois foi assim que eu tinha feito a algum tempo.
Informações úteis
Aqui você tem alguns links de interesse:
* SSL
o OpenSSL: The Open Source toolkit for SSL/TLS (http://www.openssl.org/)
o SSL Certificates HOWTO (http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html)
* Kerberos
o The Moron's Guide to Kerberos, Version 1.2.2 (http://www.isi.edu/gost/brian/security/kerberos.html)
o Designing an Authentication System: a Dialogue in Four Scenes (http://web.mit.edu/kerberos/www/dialogue.html)
o Kerberos: The Network Authentication Protocol (http://web.mit.edu/kerberos/www/)
o Heimdal (http://www.pdc.kth.se/heimdal/)
o Kerberos Papers and Documentation (http://web.mit.edu/kerberos/www/papers.html)
* OpenLDAP
o OpenLDAP.org (http://www.openldap.org/)
o OpenLDAP Admin Guide (http://www.openldap.org/doc/admin/)
* Cyrus SASL
o SASL: Simple Authentication and Security Layer (http://asg.web.cmu.edu/sasl/)
o Cyrus SASL Library (http://asg.web.cmu.edu/sasl/sasl-library.html)
* PAM
o Linux-PAM (http://www.kernel.org/pub/linux/libs/pam/)
o The Linux-PAM System Administrators' Guide (http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html)
o pam_krb5 project (http://sourceforge.net/projects/pam-krb5/)
* nss_ldap (http://www.padl.com/OSS/nss_ldap.html)
* Samba (http://www.samba.org/)
* Outros HOWTOS sobre Kerberos/LDAP
o LDAP Linux HOWTO (http://www.padl.com/OSS/nss_ldap.html)
o LDAP Implementation HOWTO (http://www.tldp.org/HOWTO/LDAP-Implementation-HOWTO/index.html)
o OpenLDAP, OpenSSL, SASL and KerberosV HOWTO (http://www.bayour.com/LDAPv3-HOWTO.html)
o The Heimdal, Samba and LDAP howto (https://sec.miljovern.no/bin/view/Info/HeimdalKerberosSambaAndOpenLdap)
o Replacing NIS with Kerberos and LDAP HOWTO (http://ofb.net/~jheiss/krbldap/howto.html)
o Central authentication server HOWTO (http://www.openinput.com/auth-howto/index.html)
o Projects/OpenLDAP DIT - Mandriva Community Wiki (http://wiki.mandriva.com/en/Projects/OpenLDAP_DIT)
Outros serviços que suporta autenticação Kerberos/GSSAPI
- Apache 2 (já fiz funcionar)
- Browser: Iceweasel e Firefox
- SSH (já fiz funcionar)
- Postfix (já fiz funcionar)
- Cliente de email: Thunderbird
- Cyrus IMAP e POP (já fiz funcionar)
- Cliente de email: Thunderbird
- FTP (ainda não fiz)
- Cliente de FTP: não sei.
Agradecimentos
Gostaria de agradecer as seguintes pessoas que me ajudaram nessa integração:
- Diego Lima
- William Merllto (Prognus)
- Andrew Barlett (Samba Team)
- André Avelino da Costa (Elaborate)
- Andreas Hasenack (Ubuntu)
