Archive for the tag 'LDAP'

Scripts em BASH para administração do LDAP

clodonil March 26th, 2010

 Um dos pontos mais complexos em administrar a base LDAP é encontrar ferramentas que auxiliam no gerenciamento da base. Algumas ferramentas, tais como phpldapadmin e outras com o nome de ldapbrowser realmente contribuem nesse processo.

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

Após a inclusão da base é necessário criar as unidades organizacionais. Dentro dessas unidades que vamos criar os usuários e os grupos. A título de exemplo para a execução do script, crie as unidades organizacionais pessoas (ou=pessoas) e grupos (ou=grupos).
A seguir estão as duas unidades organizacionais.
 
dn: ou=pessoas,dc=dominio
objectClass: organizationalUnit
ou: pessoas
 
dn: ou=groups,dc=dominio
objectClass: organizationalUnit
ou: groups
 

 

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.

# user_add.sh julia
 
O primeiro parâmetro é o uid do usuário. Como exemplo de possibilidade, coloquei a inclusão dos dados: Nome, SobreNome e Email. Outros campos podem ser incluídos também. O mais importante nesse script é o gerenciamento do uidNumber que não podem ser repetidos.
 
O segundo script (del_user.sh) é para apagar os usuários da base LDAP.
 
#!/bin/bash
 
source config
 
cn=$1
echo $LDAPDN
(
echo "uid=$cn,$people"
)| ldapdelete -x -D $rootdn,$suffix -w $rootpw
 
Sintaxe:
 
# del_user.sh julia
 
O próximo script (add_group.sh) é um exemplo de como criar grupos na base LDAP. Esses grupos são criados dentro da unidade organizacional group.
 
#!/bin/bash
 
source config
 
gidnumber=`ldapsearch -h localhost -x -b $group -D $rootdn,$suffix -w $rootpw gidNumber | grep gidNumber: | sort | cut -d : -f 2 | tail -n 1| sed s/\ //g`
nextgid=`expr $gidnumber + 1`
 
uid=$1
(
echo "dn:cn=$uid,$group"
echo "objectClass: posixGroup"
echo "cn: $uid"
echo "gidNumber: $nextgid"
)| ldapadd -x -D $rootdn,$suffix -w $rootpw
 
A sintaxe para executar script.
 
# add_group.sh cpd
 
Para complementa o gerenciamento do grupo, o próximo script (delete_group.sh) é para apagar os grupos criados.
 
#!/bin/bash
 
source config
 
cn=$1
echo $LDAPDN
(
echo "cn=$cn,$group"
)| ldapdelete -x -D $rootdn,$suffix -w $rootpw
 
Para finalizar essa parte de gerenciamento de usuário e de grupo, no próximo script (add_user_group.sh)  é para adicionar o usuário no grupo.
 
#!/bin/bash
 
source config
 
cn=$1
uid=$2
LDAPDN=`ldapsearch -h localhost -x -b $group -D $rootdn,$suffix -w $rootpw "(cn=$cn)"|grep dn`
(
echo "$LDAPDN"
echo "changetype: modify"
echo "add: memberUid"
echo "memberUid: $uid"
)| ldapmodify -x -D $rootdn,$suffix -w $rootpw
 
Sintaxe:
 
# add_user_group.sh grupo usuario
 
E para finalizar temos o último script que altera a senha do usuário.
#!/bin/bash
 
source config
 
cn=$1
 
echo "Digite a senha:"
read -s pass
 
senha=`slappasswd -c crypt -s $pass`
 
LDAPDN=`ldapsearch -h localhost -x -b $people -D $rootdn,$suffix -w $rootpw "(cn=$cn)"|grep dn`
(
echo "$LDAPDN"
echo "changetype: modify"
echo "replace: userPassword"
echo "userPassword: $senha"
)| ldapmodify -x -D $rootdn,$suffix -w $rootpw
 
Dessa forma temos alguns scripts que auxiliam no gerenciamento da base LDAP. O maior legado é a possibilidade da criação de outros scripts para facilitar a vida dos administradores.

Alta Disponibilidade de servidor LDAP (OpenLDAP)

clodonil January 14th, 2010

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.

Pure-ftp integrando com o LDAP (GOsa)

clodonil October 28th, 2009

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.

Next »