Ir para o conteúdo
ou

Software livre Brasil

0 comunidades

Nenhum(a)

Tela cheia
 Feed RSS

Blog

27 de Maio de 2009, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

Alta Disponibilidade de servidor LDAP (OpenLDAP)

14 de Janeiro de 2010, 0:00, por Software Livre Brasil - 0sem comentários ainda

Alta disponibilidade é uma solução de cluster que possibilita que um serviço fique mais tempo disponível.

Muitos definem cluster como sendo um conjunto de servidores agrupados com intenção de ganho de desempenho ou disponibilidade.

Segundo Pitanga (2003), no ano de 1994 o primeiro projeto de cluster foi realizado pela NASA.

Os clusters normalmente são compostos por máquinas convencionais ligadas em rede oferecendo abstração para o usuário utilize apenas uma única máquina.

O cluster de alta disponibilidade tem a intenção de manter a maior disponibilidade possível dos serviços, através da duplicação de servidores e recursos.

O funcionamento basicamente é baseado em um sistema de monitoração interna no cluster, que em caso de falha do servidor ativo, aciona automaticamente o servidor standby.

O serviço de alta disponibilidade envolve os seguintes recursos:

  • Redundância de estrutura;
  • Camada de software de monitoração;
  • Mecanismo de sincronia.

A nossa tarefa agora é implementar um serviço de OpenLDAP que atenda esses recursos de alta disponibilidade.

A figura 1 mostra o modelo que estaremos tratando nesse artigo. Os clientes acessam o OpenLDAP através de uma interface virtual.

Enquanto o heartbeat estiver ativo, o servidor master estará ativo, porém quando heartbeat parar o servidor slave assumira o controle e a interface virtual estará apontando para o slave.

 HA

Figura 1 – Esquema do OpenLDAP com HA

Um elemento fundamental para o sucesso da alta disponibilidade é a parte da replicação dos dados do LDAP master para o LDAP slave.

Pode-se pensar em várias possibilidades, entre as quais podemos destacar.

  • DRBD: Pode-se usar o DRBD para fazer a replicação dos dados, porém essa ferramenta forçaria que o LDAP estive-se parado no slave.
  • Syncrepl: Pode-se utilizar replicação master – slave; esse recurso é bem interessante porque o slave fica disponível para consulta mas trás o problema no failback.
  • Rsync: pode-se também utilizar o rsync para enviar os arquivos ldifs da base LDAP, porém existe o mesmo problema do DRDB.
  • N-Way Multimaster: Esse recurso usa o rsync para fazer replicação master – master. Esse recurso é muito importante porque mantém o slave ligado para consulta e resolver o problema do failback.

A primeira coisa a fazer é instalar o OpenLDAP e configurá-lo para replicação master – master.

Antes da configuração do slapd.conf, ajuste os hosts do servidor master e slave. Neste caso serão utilizados os seguintes nomes e ip. O hostname das maquinas deve estar dessa forma.

Server1     10.0.0.90 (Master)
Server2    10.0.0.91  (Slave)
LDAP        10.0.0.99 (IP Virtual)

Com esses dados podemos configurar o arquivo slapd.conf. Segue a configuração slapd.conf do servidor master.

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/misc.schema

password-hash {CRYPT}
defaultsearchbase dc=nisled,dc=org

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

loglevel 1024

modulepath /usr/lib/ldap
moduleload back_bdb
moduleload back_monitor
moduleload syncprov

database monitor
database bdb
cachesize 5000
mode 0600

suffix "dc=nisled,dc=org"
rootdn "cn=manager,dc=nisled,dc=org"
rootpw pedra

index default sub
index uid,mail eq
index entryCSN      eq
index entryUUID eq
directory "/var/lib/ldap"

lastmod on

# provedor
serverID 001
syncrepl rid=001
provider=ldap://server2:389
searchbase="dc=nisled,dc=org"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=manager,dc=nisled,dc=org"
credentials=pedra
type=refreshAndPersist
retry="5 + 5 +"
interval=00:00:00:05

mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10

Após a configuração do master também configure o slave. Lembre-se de ajustar os hostname e os ip da maquina slave.

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/misc.schema
password-hash {CRYPT}

defaultsearchbase dc=nisled,dc=org
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel 1024

modulepath /usr/lib/ldap
moduleload back_bdb
moduleload back_monitor
moduleload syncprov


database monitor
database bdb
cachesize 5000
mode 0600
suffix "dc=nisled,dc=org"
checkpoint 512 720
rootdn "cn=manager,dc=nisled,dc=org"
rootpw pedra

index default sub
index uid,mail eq
index entryCSN         eq
index entryUUID         eq

directory "/var/lib/ldap"
lastmod on

#replicacao
serverID 002
syncrepl rid=002
provider=ldap://server1:389
searchbase="dc=nisled,dc=org"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=manager,dc=nisled,dc=org"
credentials=pedra
type=refreshAndPersist
retry="5 + 5 +"
interval=00:00:00:05

mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10

Com essa configuração a replicação do LDAP master – master deverá está funcionando corretamente.

O próximo passo é configurar o programa heartbeat. Esse programa tem basicamente a função de mudar o "ip virtual" da maquina master para o slave quando ocorrer um problema no servidor master.

O heartbeat funciona enviado pacotes entre duas interfaces que pode ser rede ou serial. Caso o heartbeat do slave pare de receber os pacotes, ele assume que o master está com problema e aciona os recursos programados.

Para o heartbeat será utilizado outra interface (eth1) de rede que neste caso são as seguintes:

server1    192.168.100.1
Server2     192.168.100.2

A configuração do heartbeat envolve basicamente 3 arquivos que são eles:

  • ha.cf
  • haresources
  • authkeys

No arquivo ha.cf é definido todos os parâmetros de transferência dos pacotes entre o master e o slave. Já no arquivo haresources é definido todos os recursos que serão iniciados quando o slave assumir. E no arquivo authkeys define o método de autenticação entre os hosts.

Os arquivos basicamente são iguais nos servidores.

Segue o arquivo ha.cf:

Debugfile        /var/log/ha-debug
logfile          /var/log/ha-log
logfacility        local0
keepalive        2
deadtime        30
warntime        10
initdead        120
udpport        694
ucast    eth1    192.168.100.2
node            server1
node            server2
auto_failback        on

No arquivo haresources basicamente ativa o "IP Virtual".

Segue o arquivo haresources:

server1 IPaddr::10.0.0.99/24/eth0

Essa configuração deverá ativar o "IP Virtual" 10.0.0.99 na interface eth0 no server1.

Já no arquivo authkeys é o método de autenticação.

Segue o arquivo authkeys:

auth 1
1 crc

Essas configurações é para o master, porém a configuração do slave é a mesma exceto no arquivo há.cf que devemos mudar a seguinte linha.

ucast    eth1    192.168.100.1

Com a configuração pronta, podemos testar o heartbeat da seguinte forma:

  • Inicieo o heartbeat no master e no slave;
  • Perceba que o IP Virtual tá no computador master;
  • Pare o heartbeart no master;
  • Perceba que o IP Virtual agora tá configurado no slave.

Dessa forma podemos disser que o heartbeat está configurado e funcionando.

Entretanto o serviço ainda não está terminando, imagine que o slapd do master parou ou simplesmente a conexão com a interface 10.0.0.90 (eth0) parou.

O heartbeat vai continuar comunicando com o slave através da interface eth1 (192.168.100.1), dessa forma o slave não ira assumir o serviço.

Para resolver esse problema usamos a ferramenta mon no servidor master. Com ela podemos monitorar tanto a conexão com aplicação. Se eles apresentarem problema, o mon desativa o heartbeat fazendo o slave assumir os serviços.

A configuração do mon se resumiu na edição do arquivo mon.cf.

alertdir=/usr/lib/mon/alert.d
mondir=/usr/lib/mon/mon.d
randstart=60s

hostgroup ldapserver 10.0.0.90

watch    ldapserver
service    ldap
interval     20s
monitor ldap.monitor -basedn "dc=nisled,dc=org" -filter "uid=clodonil" -attribute    uid    -value    clodonil
period
numalerts    2    
alert    heartbeat.alert
alert    mail.alert -S "Problema com servidor OpenLdap" clodonil@nisled.org

upalert    heartbeat.alert
upalert mail.alert -S "Servidor OpenLdap esta ok" clodonil@nisle.dorg

service    ping
interval    1m
monitor    fping.monitor
period
     numalerts    2
alert    heartbeat.alert
alert     mail.alert -S "Link ta com problema" clodonil@nisled.org

upalert    heartbeat.alert
upalert mail.alert -S "Link ta OK" clodonil@nisled.org

Agora temos o sistema completo. Se LDAP ou a conexão apresentarem problema o slave assumira o serviço. O mais interessante que o administrador vai receber um email informando que o sistema parou ou voltou. E quando voltar, após uma parada, o master ira receber os dados do slave devido a replicação master-master.



Lista OpenLDAP-Brasil

7 de Dezembro de 2009, 0:00, por Software Livre Brasil - 0sem comentários ainda

 

 

Olá Pessoal, estamos abrindo uma nova lista de discussão que trata basicamente do Openldap e suas implementações.

Participe, colabore e aprenda.

 

Segue o link do grupo: http://groups.google.com/group/openldap-brasil

 



Pure-ftp integrando com o LDAP (GOsa)

28 de Outubro de 2009, 0:00, por Software Livre Brasil - 22 comentários

Um amigo estava com dificuldade em fazer a integração do Pure-FTP com o GOsa. Nunca tinha testado esse pequeno FTP, mas já implementei várias vezes o Proftpd. Por esse motivo aceitei o desafio de implementar esse FTP com o LDAP.

No primeiro contato foi bem fácil a configuração com o LDAP. Antes de mostrar os arquivos que alterei para fazer o Pure-FTP funcionar, vou mostrar a criação do usuário no GOsa.

A figura 1 e figura 2 mostram a criação do usuário utilizando o GOsa. A criação é normal não tem nada de especial, perceba que a criptografia utilizada foi a crypt.

Na figura 2 colocamos o atributos Unix.

Nessa tela definimos o "Home directory" do usuário. Teremos que criar esse diretório.

 Após a criação do usuário no GOsa temos que habilitar o linux para reconhecer os usuários que estão na base LDAP para poder dar a permissão na pasta do usuário.

Para fazer o Linux reconhecer os usuários da base LDAP, olhe este artigo [reconhecendo usuário da base LDAP] até a parte do getent.

O passo seguinte foi criar a pasta do usuário e dar a permissão certa.

[root@servidor]# mkdir  -p /home/ldap/julia

[root@servidor]# chown julia:julia /home/ldap/julia

Até esse ponto estavamos criando a base para a instalação do Pure-FTP.

Instalação do Pure-FTP no ubuntu Server

Para instalar o Pure-FTP vamos utilizar o apt-get.

[root@servidor]# apt-get install pure-ftp-ldap

Após a instalação vamos editar o arquivo /etc/pure-ftp/db/ldap.conf.

LDAPServer localhost
LDAPPort   389
LDAPBaseDN ou=people,dc=curso,dc=ldap
LDAPBindDN cn=Manager,dc=curso,dc=ldap
LDAPBindPW pedra
LDAPFilter (&(objectClass=posixAccount)(uid=\L))
LDAPHomeDir homeDirectory
LDAPVersion 3

Ao termino da configuração é necessário reinicar o Pure-FTP

[root@servidor]#/etc/init.d/pure-ftp-ldap restart

Agora já podemos testar com um programa ftp. A figura 3 mostra o teste com ftp.

Então temos o Pure-FTP funcionando corretamente.



cn=Monitor

22 de Outubro de 2009, 0:00, por Software Livre Brasil - 0sem comentários ainda

O pós-instalação de um servidor de diretório como o LDAP (OpenLDAP) é um dos momentos mais críticos para uma rede e para o administrador. O Servidor está instalado e funcionando, porém alguns informações de performance são fundamentais para determinar que o trabalho realmente terminou. Em muitos casos após a instalação e configurações que começa realmente o serviço pesado de ajustes finos e otimização do servidor.
Para que essa otimização acontecer é necessário obter informações reais do servidor, tais como acesso por segundo, os tipos de acesso e assim por diante. Antes do surgimento da função monitor do LDAP, essa tarefa era muito completa e árdua.
Entretanto com a função monitor, ficou mais fácil o administrador obter esses dados. Usando a função monitor, têm surgido ferramentas que apresentam esses dados em forma de gráficos e tabelas, e uma dessas ferramentas é o CN=MONITOR.

Essa ferramenta tem as seguintes características:

 

  • Verify Load Balancing, DNS and Server level (RedHat / Fedora / Sun Only)
  • Verify Replication, (RedHat / Fedora / Sun Only)
  • Verify Cache Size, (RedHat / Fedora / Sun Only)
  • Mail Report of weekly load
  • Summary Graph of monitoring
  • View Schema (Most Vendors)

CN=Monitor trabalhar com os seguintes servidores:

  • RedHat and Fedora/389 Directory Server
  • Novell eDirectory Server
  • General Monitoring such as response time, server availability (All)
  • OpenLDAP

 

Particularmente gostei muito dessa ferramenta porque centraliza os dados e com poucos clicks e através de gráficos é possível visualizar a situação do servidor.

 

O CN=MONITOR, apresenta informações sobre o tipo de operações que o LDAP está realizado, tais como pesquisa, escrita,alteração.

 



Instalação e Configuração do Samba4

7 de Outubro de 2009, 0:00, por Software Livre Brasil - 33 comentários

by: Diego Pereira Grassato

Instalação Samba4

Em janeiro de 2006 foi lançando a primeira versão beta do samba4. Mesmo antes desta data várias informações já eram dadas sobre as características do novo "servidor de arquivos". Uma das informações que mais chama a nossa atenção era sobre a integração do SAMBA com o AD.

Agora com a versão ALPHA 9 já podemos testar e verificar as principais características do SAMBA4.

 Softwares utilizados:

 

·       Linux: Slackware 12.2 – Current Version

ftp://ftp.slackware.no/pub/linux/ISO-images/slackware/Current-ISO-build/

 ·       PhpLDAPadmin 1.1.0.7

http://phpldapadmin.sourceforge.net/

·       Samba 4 Alpha9

Via Git: "git clone git://git.samba.org/samba.git samba-master; cd samba-master && git checkout -b master origin/master; cd .."

 ·       Heimdal Kerberos

http://www.h5l.org/dist/src/heimdal-1.2.1.tar.gz

 ·       Bind 9

ftp://ftp.isc.org/isc/bind9/9.5.2/bind-9.5.2.tar.gz  

 

Dependências de Outros softwares para o perfeito funcionamento

Para o perfeito funcionamento do Samba4 depois de vários testes foi visto que o DNS é um dos requisito primordiais para seu funcionamento adequado e reconhecimento de algumas diretivas impostas pelo samba4. Por isso recopilaremos o BIND com suporte a Heimdal Kerberos, 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.

Em nosso caso utilizaremos BIND com suporte ao Heimdal Kerberos por causa do GSS-TSIG algoritmo de serviço de segurança genérico para autenticação de transação com chave secreta de DNS (GSS-TSIG) este mecanismo é utilizado para estabelecer relações TSIG para autenticação do tipo Kerberos, necessário para interagir BIND com Samba4, com essas credenciais o DNS aceita atualizações GSS-TSIG assinadas e verifica as credenciais de correspondentes com as credencias cadastradas no Samba4, isso permite aos usuários descarregar o DNS dos usuários do Microsoft Windows sem ter a segurança comprometida.

 Compilação e Instalação

Começaremos pelo Heimdal:

#tar –zxvf heimdal-1.2.1.tar.gz

#cd heimdal-1.2.1

#./configure –prefix=/usr –libdir=/usr/lib \
–sysconfdir=/etc  –localstatedir=/var  \
–mandir=/usr/man –with-openssl=/usr –bindir=/usr/bin/ \
–sbindir=/usr/sbin/ –enable-kcm

#make && make install

Criaremos o usuário e o grupo responsável pelo "Bind", e efetuaremos a compilação:

# groupadd named && useradd named –g named
#tar –zxvf bind-9.5.2.tar.gz
#cd bind-9.5.2
#./configure   –prefix=/usr   –libdir=/usr/lib  \
–sysconfdir=/etc –localstatedir=/var   –with-libtool   \
–mandir=/usr/man   –enable-shared   –disable-static   \
–enable-threads –with-openssl=/usr –with-gssapi=/usr/include/gssapi –bindir=/usr/bin/ –sbindir=/usr/sbin/

#make && make install

Adicione seu host em "/etc/hosts", para ajudar na resolução de nomes, em meu caso ficou deste modo:

#vi /etc/hosts

127.0.0.1               localhost
192.168.11.1            dtux.org dtux

Testando o funcionamento do "Bind":

#named –u named -g
25-Sep-2009 11:00:21.348 zone dtux.org/IN: loaded serial 2009091112
25-Sep-2009 11:00:21.350 running
25-Sep-2009 11:00:21.350 zone dtux.org/IN: sending notifies (serial 2009091112)

Compilação

Após fazer o download, foi criado um diretório chamando samba-master. Os fontes do SAMBA4 ficaram dentro do diretório source4, criaremos um link simbólico apontando para source.

# cd samba-master/
# ln –s source4 source
# cd source
#./autogen.sh

#./configure –prefix=/usr/local/samba –sysconfdir=/etc/ –localstatedir=/var –mandir=/usr/man/ –enable-fhs –enable-debug    –bindir=/usr/bin  –sbindir=/usr/sbin  –libdir=/lib –enable-developer

# make && make install

Após a instalação rode o utilitário "provision" para a criação do domínio e do usuário administrator e sua respectiva senha:

#./setup/provision –realm=DTUX.ORG –domain=DTUX –admin=anna –server-role=’domain controller’

O parâmetro "realm" é para definir o domínio do servidor Kerberos e o "domain" para o domínio SAMBA.

O SAMBA4 trás embutido os protocolos:

DNS – ( Bind )
SMB-( Samba 3 )
LDAP( OpenLdap )
KERBEROS( Heimdal )
MS-RPC – ( GPO )

Credenciais Utilizando base SamDB

… que são responsáveis pela autenticação Active Directory.

O diretório “/usr/local/samba” é gerado pela compilação do SAMBA e tem os seguintes subdiretórios:

·  /usr/bin:  Programas para gerenciamento do samba, tais como smbstatus, net, etc.
·  /usr/sbin: Programa responsável por inicializar o samba.
·  /etc/samba:  Neste diretório fica o arquivo de configuração smb.conf
·  /usr/lib: Todas as libs compiladas do samba
·  /var/lib/samba/private: Exemplos de arquivos de configuração

Configuração do Bind

Após a instalação, configuramos o servidor DNS para trabalhar juntamente com o KERBEROS e KERBERO com BIND. Utilize os arquivos exemplos gerados pelo próprio SAMBA que estão dentro do diretório "/var/lib/samba/private". Edite o arquivo "/etc/named/named.conf" adicione as seguintes linhas:

#vi /etc/named/named.conf

Na sessão “option{}” adicione as linhas que irão fazer a comunicação ente o Keberos e o Bind:

options{
directory "/var/named";
tkey-gssapi-credential "DNS/dtux.org";
tkey-domain "DTUX.ORG";
}

Depois de configurado a sessão "options" incluiremos o arquivo "named.conf" do Samba4 no BIND, abaixo da sessão "options" adicione:

options{

   directory "/var/named";
   tkey-gssapi-credential "DNS/dtux.org";
   tkey-domain "DTUX.ORG";

}

include "/var/lib/samba/private/named.conf";  

Nesse arquivo está a zona configurada pelo Samba4 quando foi utilizado o utilitário “provision”. Antes de testar o funcionamento do Bind, temos que setar as variáveis de localização do arquivo “dns.keytab”, que é onde estão as informações de DNS registradas pelo Samba4:

# KEYTAB_FILE=“/var/lib/samba/private/dns.keytab"
# export KRB5_KTNAME=“/var/lib/samba/private/dns.keytab"

Para não termos que ficar digitando essas linhas a todo o momento coloquemos elas no inicio do arquivo “/etc/rc.d/rc.bind”, responsável pela inicialização do daemon do named.

#killall -9 named
#named –u named
#ps ax |grep named
4450 ?        Ssl    0:00 named -u named
4455 pts/3    R+     0:00 grep named

Pronto seu Bind já estará rodando e trocando informações com o Samba4, vamos fazer um teste para verificar se seu funcionamento está ok, utilizaremos a ferramenta “nsloockup”:

 

 

Caso você queira configurar um DNS reverso para o IP de seu samba fica a seu critério. Também copiaremos o arquivo krb5.conf” que está em “/var/lib/samba/private/“ para o diretório “/etc/”.

Por utilizar o Kerberos, é necessário que todas as máquinas envolvidas estejam com os mesmos horários (segundos) sincronizados. Para isso nada melhor do que setar o “Samba” para ser o nosso time server, adicione ao "/etc/samba/smb.conf"  na sessão “[globlas] “time server     = yes”, nos cliente é só setar “net time \\dtux.org /set /Yes”, que o horário ficará sincronizado o com o do servidor.

Acerte o sistema de arquivo para trabalhar com o “xattr” alterando o arquivo “/etc/fstab”.

/dev/sda1         ext3    defaults,user_xattr    0    1

Remonte o sistema para ativar as alterações.

# mount -o remount,rw /

Para testar, criemos alguns compartilhamentos. Para isso edite o arquivo smb.conf que está dentro do diretório /etc/samba/”.

[profiles]
       comment = Profiles Remotos
       path = /home/profiles
       read only = no
       browseable = no

 O compartilhamento “Profiles” indica a localização dos profiles dos usuários nesse caso se tratando de uma configuração para “Perfil Móvel(Roaming Profile)

Agora testaremos alguns serviços e verificar se estão todos funcionais.

 Iniciando do Samba

#samba -i -M single

 Iniciando do Samba em modo debug

#samba -i -M single –d3

 Iniciando do Bind

#/etc/rc.d/rc.bind start

 Pronto com isso no servidor já está no ar com DNS funcionado, vamos a alguns testes:

 Samba4

 Autentique algum usuário do Samba4 com:



# smbclient //dtux.org/profiles -Uadministrator%anna

smb: \> dir
  .                              D        0  Wed Sep 23 11:31:36 2009
  ..                             D        0  Tue Sep 22 17:26:38 2009
  Admin                          D        0  Tue Sep 22 15:28:02 2009
  alexandro                      D        0  Tue Sep 22 17:19:31 2009
  diego                          D        0  Mon Sep 21 16:42:47 2009
  nazir                          D        0  Wed Sep 23 11:31:36 2009
  danilo                         D        0  Tue Sep 22 12:04:42 2009
  gustavo                        D        0  Tue Sep 22 12:16:04 2009
  zeh                            D        0  Tue Sep 22 17:32:59 2009
  satarosa                       D        0  Tue Sep 22 17:26:38 2009
  anna                           D        0  Mon Sep 21 16:51:32 2009

Kerberos

Autentique algum usuário do Samba4 com e ofereça a senha quando pedido:

#kinit administrator@DTUX.ORG
Password for administrator@DTUX.ORG:
Verificando os tickets de conexão:

 #klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@DTUX.ORG
Valid starting     Expires            Service principal
09/25/09 14:22:50  09/26/09 14:22:48  krbtgt/DTUX.ORG@DTUX.ORG

Verificando os tickets de conexão e os métodos de autenticação aplicados:

#klist -e

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@DTUX.ORG
Valid starting     Expires            Service principal
09/25/09 14:22:50  09/26/09 14:22:48  krbtgt/DTUX.ORG@DTUX.ORG
Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5

 Windows sendo Dominado pelo Samba4

Para colocar o Windows XP no domínio do samba, além da configuração de hora já foi falado, devemos configurar o ip da máquina onde está o samba4 no DNS do micro com Windows XP/2003/2008/7.

 

No Windows XP segue as seguintes configurações para se entrar em domínio, este procedimento serve para Windows XP/2000/2003/2008/7:

·  Menu Iniciar -> Painel de Controle -> Sistema

·  Guia “Nome do Computador”

·  Alterar

·  Marque o checkbox “Domínio”

·  Coloque o seu domínio (DTUX.ORG) -> OK

·  Caso ocorrer algum problema de apontamento de DN, pode-se editar o arquivo “C:\WINDOWS\system32\drivers\etc\hosts”, no arquivo “hosts” você coloca o IP do servidor samba e na frente o seu respectivo DNS name desta forma:

o  127.0.0.1       localhost

o  192.168.11.2   dtux.org dtux

 

 

Simple no primeiro logon logue como administrator, caso você queira fazer parte da administração do Samba4 através do Windows Server 2003 Administration Tools Pack” antes de instalá-lo, instale o “Windows Server 2003 Suporte Tools”:

·      http://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&displaylang=en

·      http://download.microsoft.com/download/3/e/4/3e438f5e-24ef-4637-abd1-981341d349c7/WindowsServer2003-KB892777-SupportTools-x86-ENU.exe

Aproveitando vamos criar um “Perfil Remoto”, um problema encontrado com perfil remoto foi encontrado quando você cria um usuário pelo “Administrator Tolls” esse usuário não terá acesso ao Shell do Linux e com isso ele não irá conseguir ditar permissões de escrita e leitura. Portanto para criar usuário utilize o script da pasta: /usr/local/samba/share/samba/setup/.

·       newuser

Antes de utilizá-lo você tem que adicionar o usuário no Linux usando o comando comum “useradd”.

Iremos simular o seguinte ambiente, criaremos um grupo e adicionaremos um usuário no Linux a colocaremos esse usuário no grupo criado entre no “Administrator Tools”, criaremos o grupo também e utilizaremos o script “newuser” para adicionar o usuário no samba4.

·  Criando grupo:

#groupadd samba4

·  Criando usuário no Linux:

#useradd teste –g samba4 -p senha –c “Teste Samba4 Users”

·  Criando a pasta do profile do usuário, levando em consideração que “/home/profiles”, já foi feito acima:

#mkdir -p /home/profiles/teste

·  Ditando permissões de acesso a pasta para este usuário recém criado:

#chown teste:samba4 /home/profiles/teste

      Agora usaremos o script “newuser” para fazer a importação, um problema encontrado foram as bibliotecas python utilizadas por esse scripts elas estão localizadas em “/usr/local/samba/lib/python2.6/site-packages”, temos que copiar todo esses arquivos para a pasta real do python do sistema “/usr/lib/python2.6/site-packages/”:

#cd /usr/local/samba/lib/python2.6/site-packages
#cp –rp  *  /usr/lib/python2.6/site-packages/

Vamos fazer a copia do “newuser” para nosso diretório “/usr/sbin”:

#cp /usr/local/samba/share/samba/setup/newuser /usr/sbin

Tudo pronto para a execução do script:

#newuser teste senha –unixname=teste -k KERBEROS –workgroup=dtux.org

·           –unixname: Usuário criado no Linux/Unix

·           -k KERBEROS: Utiliza autenticação Kerberos

·           –workgroup: Domínio Criado

 

Agora quando você autenticar no Windows com este usuário que ele já está sincronizado, quando você abrir o “Administrator Tools” pelo menu “Iniciar -> Executar”, digite dsa.msc”.

 

Depois clique em seu domínio e vá em “Users” o usuário já irá aparecer na listagem, criaremos o grupo “samba4” pelo “Administrator Tools”     e adicionaremos o usuário “teste” neste grupo, e configuraremos o seu profile remoto.

Criando o grupo: “Botão direito em Builtin ->Novo -> Group”, dê um nome uma descrição.

 

 

 

 

Agora na guia “Members” você define os usuários que farão parte deste grupo.

 

 

 

Os usuários que foi importamos já estão criados agora é só acertar alguns detalhes em User logon name” que é o nome de logon é só colocar o nome do usuário e na frente o “@DOMINIO”, marque as opções “Use cannot chance password” se não quer que os usuários alterem a senha, e “Password never expires”, pra ela numca expirar.

Iremos agora á guia “Profile” e em “Profile Path” definiremos o caminho do diretório remoto onde serão armazenados os arquivos do usuário.

 

Em “Map Folder”, podemos colocar esse caminho do profile do usuário para ser montado em uma unidade de mapeamento de rede.

 

Podemos através do Windows os tickets do Kerberos através do “Windows Server 2003 Resource Kit Tools” (http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en). Utilizaremos Klist e o Kerbtray, que ficam localizadas em: “Iniciar -> Windows Resource Kit Tolls -> Command Shell”.

 

KLIST

A ferramenta klist é uma ferramenta de linha de comando que permite que você exiba o conteúdo dos cache de credenciais e pode ser usada em um cliente Windows para exibir ou destruir credenciais existentes de Kerberos.

A ferramenta klist exige um argumento. O argumento "tgt" mostra as credenciais no cache atual, e o argumento “tickets” mostram as credenciais em cache.

 

 

KerbTray

A ferramenta Kerberos Tray, KerbTray, (kerbtray.exe) é uma ferramenta gráfica da plataforma Windows que exibe informações de tickets Kerberos em um computador de plataforma Windows onde os tickets Kerberos foram armazenados no cache de credenciais. Os tickets Kerberos são adquiridos e armazenados nas credenciais de cache quando um usuário autenticar em um computador de plataforma Windows (cliente ou servidor) como um usuário de domínio. O KerbTray permite que você visualize e limpe o cache de ticket.

Quando executado, a ferramenta coloca um ícone na bandeja do sistema. Esse ícone exibe o status com base na presença ou ausência de credenciais válidas. Dados disponibilizados pela interface KerbTray incluem os selos de tempo nos tickets, os marcadores associados às credenciais e o(s) tipo(s) de criptografia dos tickets.

Administração do Samba4 via phpLDAPadmin

phpLDAPadmin é uma interface gráfica para gerenciar a base de dados LDAP. Para seu funcionamento será necessário ter instalação do Apache com suporte à PHP versão 5 ou 4 se preferir. O seu site oficial é (http://phpldapadmin.sourceforge.net).

#wget –C http://ufpr.dl.sourceforge.net/sourceforge/phpldapadmin/phpldapadmin-1.1.0.7.tar.gz  # tar -zvzf phpldapadmin-1.1.0.7.tar.gz # mv phpldapadmin-1.1.0.7 phpldapadmin
Copiaremos a pasta “phpldapadmin na pasta do apache
# mv phpldapadmin /srv/www/htdocs
Acesse a pasta onde estão as configurações de seu samba, lá você irá encontrar um arquivo de configuração devidamente configurado para se conectar ao samba4, copie para a pasta de configuração do phpLDAPadmin”.
# cd /var/lib/samba/private # cp phpldapadmin-config.php /srv/www/htdocs/ldap/config/config.php
Seu apache deve estar devidamente configurado com suporte a PHP. Caso você esteje utilizando o Slackware Linux, apenas descomente a linha “Include /etc/httpd/mod_php.conf” de seu “httpd.conf” em “/etc/httpd” e reinicie o apache:
# apachectl restart
Abra seu navegador no seguinte endereço:
http://localhost/phpldapadmin/index.php
Irá abrir a pagina lhe pedindo usuário e senha, você pode conectar usando o usuário “Anônimo” ou como “Administrator”. Para se conectar como “Administrator” você deve indicar o caminho completo da localização do usuário, neste caso ele se encontra em CN=Users,DC=dtux,DC=org”, para o usuário “Administrator” ficará assim:
 CN=Administrator,CN=Users,DC=dtux,DC=org
Você pode se conectar com qualquer usuário desde que indique o seu caminho completo, assim como o “Administrator” 

 

 

 

Arquivos de configuração, lembrando que esse foram usados na minha estrutura, lembre-se cada caso é um caso:

Unknownsmb.conf - Arquivo de configuração do samba
Unknownnamed.conf - Arquivo principal do bind
Unknowndtux.org.zone - Zona principal criada pelo samba e adaptada
Unknown11.168.192.in-addr.arpa - Zona Reversa baseada na Zona Principal
Unknownkrb5.conf - Arquivo de configuração do Keberos criado pelo samba
UnknownadminSamba4.sh - Script criado por mim, para ajuda na tarefa de criar usuários no linux e im porta-los para Active Directory do Samba4, simple que pode evoluir, sujestões são aceitas.

 

Fontes de Apoio:
 
http://wiki.samba.org/index.php/Samba4/HOWTO 
http://www.vivaolinux.com.br/artigo/Samba-4-como-controlador-de-dominio-com-Active-Directory-da-MShttp://www.nisled.org/?p=68