Escolha o seu curso, vagas limitadas 

Entretanto em algumas tarefas administrativas essas ferramentas são ineficazes e o administrador se depara com situações que ele mesmo tem que desenvolver soluções pontuais.

É com essa visão que apresento um conjunto de scripts que podem auxiliar os administradores na construção de scripts para soluções dos problemas do cotidiano.

Os scripts foram criados utilizando a linguagem de script BASH, que vem por padrão na maioria dos Linux. Para os scripts funcionarem é importante que as ferramentas do LDAP estejam instaladas na maquina. Normalmente essas ferramentas estão no pacote ldap-utils. Além dos pacotes das ferramentas instaladas é necessário que o LDAP esteja instalado e configurado.

Para os scripts funcionarem é preciso criar a base LDAP e as unidades organizacionais. Vou colocar esses 2 ldif para deixar bem claro.

Com o LDAP instalado é preciso que seja incluída o domínio na base LDAP. Segue um exemplo do domínio root; essa é a primeira entrada para a base LDAP. 

dn: dc=dominio
objectClass: top
objectClass: dcObject
objectClass: organization
dc: dominio
o: descricao do dominio

Neste caso estamos criando duas entradas. A primeira é para os usuários e a segunda para os grupos que os usuários pertencem.

Depois de esclarecida essas informações, vamos para os scripts.

Os scripts que estarei apresentando são:

• add_user.sh – Utilizado para incluir usuário na base LDAP;
• delete_user.sh – Utilizado para excluir usuário na base LDAP;
• add_group.sh – Script utilizado para incluir grupo na base LDAP;
• delete_group.sh – Script para deletar grupos;
• add_user_group.sh – Script utilizado para incluir um usuário no grupo;
• alter_senha.sh – Script utilizado para alterar/definir as senhas dos usuários;

Juntamente com os scripts é necessário criar um arquivo com o nome config e dentro dele colocar as configurações da base para ser utilizadas por todos os scripts.

Segue o conteúdo do arquivo config. Altere com os dados da sua base LDAP.

suffix="dc=dominio"
people="ou=people",$suffix
group="ou=groups",$suffix
rootdn="cn=manager"
rootpw="senha"

O primeiro script (add_user.sh) é para incluir o usuário base LDAP.

#!/bin/bash

source config

uidnumber=`ldapsearch -h localhost -x -b $suffix -D $rootdn,$suffix -w $rootpw uidNumber | grep uidNumber | sort | cut -d : -f 2 | tail -n 1| sed s/\ //g | sed s/uidNumber//g`

if [ -z $uidnumber ]; then
   uidnumber="1000"
fi

nextuid=`expr $uidnumber + 1`

echo "Digite o nome:"
read cn

echo "Digite o sobrenome:"
read sn

echo "Digite o email:"
read email

uid=$1
(
echo "dn:uid=$uid,$people"
echo "objectClass: top"
echo "objectClass: person"
echo "objectClass: posixAccount"
echo "objectClass: inetOrgPerson"
echo "cn:$cn"
echo "sn: $sn"
echo "mail: $email"
echo "telephonenumber:11-11-1-11"
echo "uid: $uid"
echo "userPassword: x"
echo "homeDirectory: /home/$uid"
echo "loginShell: /dev/null"
echo "uidNumber: $nextuid"
echo "gidNumber: $nextuid"
)| ldapadd -x -D $rootdn,$suffix -w $rootpw

 

Sintaxe para executar o script.

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.

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.

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

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.

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.

Alguns dias não envio nenhuma documentação para o blog. Na sexta-feira dia 02 de outubro de 2009 nasceu a reponsável por isso.

Gostaria de compartilhar com vocês esse momento muito importante na minha vida que é o nascimento da minha filha.

Estou colocando algumas fotos dela para vocês conhecerem também. Ainda estou me acostumando com as noites  mau dormida.

Olhe a Julia dormindo no seu quarto, quando chegou em casa.

Mas logo estarei postando outros artigos.

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:

smb.conf - Arquivo de configuração do samba
named.conf - Arquivo principal do bind
dtux.org.zone - Zona principal criada pelo samba e adaptada
11.168.192.in-addr.arpa - Zona Reversa baseada na Zona Principal
krb5.conf - Arquivo de configuração do Keberos criado pelo samba
adminSamba4.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

Portanto, neste post, estarei apresentando alguns dados de avaliação sobre a satisfação do curso. O curso foi realizado em julho e agosto de 2009, com as aulas de interação nas segundas e quartas das 14h as 17h.

Trabalhamos com o número de 10 alunos por turma para possibilitar o máximo de aproveitamento dos alunos.

A seguir temos o resultado da avaliação.

 1 )  Minha Expectativa em relação ao curso foi alcançado?

 2) Qual seu grau de aprendizado?

 3) A Ferramenta utilizada superou suas expectativas?

 4) O Professor estava sempre disponível nos horários especificados.

 5) As dúvidas foram resolvidas a contento.

 6) Quanto ao horário de aula, para você foi?

 7) Você recomendaria este curso para alguém?

A seguir temos algumas frases (depoimento) dos participantes:

Estou satisfeito com o Curso,
Clodonil. Parabéns, a turma acredito que foi "boa" todos demostraram certo conhecimento na área, eu me ausentei por algumas, mas estou mesmo satisfeito
com que aprendi.

Emerson Langie dos Santos – Embrapa 

Foi revelado neste curso o verdadeiro núcleo de se trabalhar com REDES! A parti disto é possível fazer tudo! OpenLDAP

Claonilton Viera Silva Junior

Ótimo curso! Agregou muito em meus conhecimentos sobre administração de serviços em redes e integração dos mesmos. A metodologia do curso foi bem administratada pelo Clodonil.. Parabens! Recomendo o treinamento…

 Lutiano Silva – Analista de Redes e Segurança do PRODAP (Processamento de Dados do Estado do Amapá)

Clodonil é um ótimo professor e amigo!

Diego Pereira Grassato – Consultor em Redes Wireless 

Gostaria de agradecer ao Clodonil. Aprendi muito com o curso e com certeza meu curriculum só tende a melhorar. O contéudo, as ferramentas e o conhecimento do professor foi fundamental para o andamento pleno do Curso. Parabéns ao Clodonil pelo profissionalismo e sua competência.

Fabiano Gomes da Silva – USP

A próxima turma do curso de OpenLDAP vai começar em janeiro e teremos algumas novidades. A primeira delas é a utilização do software DIMDIM em 1 aula por semana. A outra novidade será a utilização de um servidor de IM durante o curso, assim o suporte por texto, video e audio será feita utilizando uma única ferramenta. Os servidores remotos irão continuar.

Em breve inscrições para nova turma

Nas versões anteriores do SAMBA, bastava criar um contêiner chamado [HOME] que o compartilhamento era criado. Mas agora com o SAMBA4 algumas coisas mudaram devido á proposta de integração com o Active Directory.

Vamos tomar como partida que o SAMBA4 está instalado, caso tenha dúvida como instalar, consulte o post  SAMBA4.

Primeira coisa que temos que criar é um compartilhamento para o HOME dos usuários. Para  isso vamos abrir o arquivo smb.conf e vamos acrescentar o seguinte compartilhamento.

[v01]
        path = /home/users
        read only = no

 Portanto dentro do diretório /home/users que ficaram "os HOMES".

O próximo passo é a criação do usuário. Podemos fazer isso de duas formas:

1.  Criando diretamente pelo AD. Essa forma de criação é interessante porque usa o AD diretamente, porém cria uma grande dor de cabeça. Como vamos mapear esses usuário no LINUX /UNIX ? Para tentar fazer esses mapeamentos, utilizar o libnss-ldap e editei o nsswitch.conf para buscar os usuários na base do LDAP do SAMBA4. Porém não funcionou corretamente devido a vários problemas de mapeamento de campos. Vou continuar tentando.

2.  A outra forma (na qual deu certo), basta criar o usuário no Linux com o comando useradd e configurar o AD.

 Para fazer isso primeiramente crie um usuário com o comando useradd.

       #useradd julia

 Agora precisamos criar esse usuário no SAMBA4. Para isso entre no diretório fonte do samba4, no meu caso ficou no /usr/local/src/samba4/source4, e execute o comando newuser.

       # ./setup/newuser julia

Feito esses passos, vamos no Active Directory. Lá deve estar aparecendo o usuário criado pelo newuser. Abra a propriedade desse usuário e encontre a aba perfil. Na área “Pasta base”, escolha a opção Conectar e defina a unidade que vai ser usando para mapear o home do usuário e defina o cominho passando o servidor e o compartilhamento, como mostra a figura1.

Figura 1 – Mapenado a unidade home do usuário

Feito isso o usuário deve estar autenticando em um cliente e mapeando a unidade de rede. Por questão de segurança você pode voltar no Linux e setar as permissões do diretório do usuário.

     # chown Julia:users /home/users/Julia
  # chmod 750 /home/users/Julia

 Pronto, temos o home do usuários.