Confieso que lo había olvidado, como dice el maestro Sinner:  LINUX es LINUX es LINUX es LINUX. Tanto tiempo escuchándolo en el trabajo, en la calle, en la red, incluso en Blogdrake alguna vez: “mandriva es para el escritorio”,”en un server instala Debian/CentOS/Fedora“,”mandriva es para  niñas”…  y un largo etc de muletillas.
No me lo trago, mandriva me ha dado estupendos resultados como servidor últimamente en el trabajo.

El primer caso: un piloto para el montaje de un PDC con OpenLdap + Samba, antes de montarlo a “mano” me pidieron evaluar el ahora llamado 389-ds y Mandriva Directory Server.  Evidentemente son versiones en continuo desarrollo, “embriones” para los productos de pago incluidos en Red Hat o en Mandriva Enterprise y no voy a negar que dan problemas. MDS vence por goleada, un producto serio, bien enfocado ( en mi opinión claro) usando herramientas ya conocidas y con una filosofía que va de la mano de la forma tradicional de montar un PDC con OpenLDAP+ SAMBA. 389-ds es todo lo contrario, van un poco “a su aire” por ser los herederos de antiguo NDS,  abandonan smbldaptools por unas nuevas “fdstools”, la integración con samba y postfix casi es “demoníaca” , todo esto con la versión estable para fedora 11 , si nos vamos a la versión testing simplemente no funciona.

El segundo caso (ZAPE): Los pc’s de escritorio son cada vez  más baratos, más potentes y con más almacenamiento que muchos servidores “relativamente modernos” .  Una tarde me llaman del “otro trabajo”: – Oye Bersuit, que me sobra un equipo, me he equivocado con el pedido ¿ Que podemos hacer con él ?. Unas horas después estaba instalando Mandriva 2009 a un clónico con “nosecuantos” núcleos, varios gigas de RAM y 500 Gb de disco duro.  El servidor de almacenamiento/backup (ZIPI) con tropecientos gigas, raid 5 “chupi guay” va hasta el cuello y los discos valen una pasta. Con 100€ para comprar otro disco de respaldo ya tenemos un servidor de backup secundario.

Mandriva 2009 + samba + winbind autenticándose contra el AD corporativo, almacena el repositorio de software, que liberó bastante espacio en el servidor primario,  almacena las copias antiguas de los servidores , las imágenes del pc de algún usuario, la segunda copia de los documentos “importantes” y las unidades para que los lusers guarden sus documentos que no quieren perder cuando llega “la cizalla” . Todas las noches poquito a poquito hace un rsync al segundo disco ( una controladora raid se salia del presupuesto), pero aún hay más …

OpenFire como servidor de IM interno autenticado también contra el AD, los usuarios al principio eran reticentes: ¡Bersuit yo quiero mi msn!, ahora ya no pueden vivir sin él.

Ayer mismo me lleve la última sorpresa, que motiva esta entrada, instalando nagios para monitorizar los servicios dentro de la red interna:

urpmi nagios nagios-www

Y ya, listo para hacer login en la consola web de nagios, ¡si hasta me había generado automáticamente un usuario y password ! listos que son estos chicos de mandriva si señor.

Como conclusión: Linux es Linux es Linux es Linux, instala mandriva en tus servidores. Sí, es cierto, no hay que perder el norte, hay distribuciones “enterprise” que hacen las cosas muy bien, hay sitios donde entra una distribución de Linux suavemente y no es necesario “partirse” la cara para meter tu distro preferida, pero no dejen a mandriva a un lado por ser una “distro de escritorio”.

Bisa install LDAP dan sudah lancar berjalan, akan tetapi diinginkan menghapus seluruh data LDAP dan akan dilakukan inisialisasi data dari awal kembali.

Langkahnya yaitu :

1. Matikan service LDAP
   

   #service ldap stop

2. Hapus database LDAPumunya database berada di /var/lib/ldap
   

   # rm * -f

3. Lakukan konfigurasi awal LDAP kembali

Bisa install LDAP dan sudah lancar berjalan, akan tetapi diinginkan menghapus seluruh data LDAP dan akan dilakukan inisialisasi data dari awal kembali.

Langkahnya yaitu :

1. Matikan service LDAP
   

   #service ldap stop

2. Hapus database LDAPumunya database berada di /var/lib/ldap
   

   # rm * -f

3. Lakukan konfigurasi awal LDAP kembali

LDAP atau Lightweight Directory Access Protocol adalah protokol aplikasi untuk melakukan query dan perubahan layanan direktori melalui TCP/IP. Sedangkan direktori disini yang dimaksud adalah sekumpulan obyek yang memiliki atribut yang secara logika maupun hirarki terorganisasi dengan baik. Sebagai contoh adalah direktori telpon yang berisi nama (orang maupun perusahaan) dikelompokkan secara alpabetis, dimana setiap nama memiliki alamat, no telpon dan lain-lain.

Pemanfaatan lain LDAP ini biasanya dipakai untuk melaukan layanan otentifikasi, terkait dengan permasalahan keamanan seperti jaringan komputer, sistem informasi, dll.

Cara instalasi di CENTOS yaitu :

1. Jalankan terminal
2. install openldap

#yum install openldap openldap-client openldap-server

3. Konfigurasi ldapserver,
Buat LDAP root user password

#slappasswd
New password: —> misalnya masukkan 123456 sebagai password
Re-enter new password:
{SSHA}+7NhMdrO/CU1ToxihSPH74/NpQNBMh5h

4. Ubah setup slapd.conf, yang BOLD yang saya ubah

#vi /etc/openldap/slapd.conf#

# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema

# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org

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

# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la

# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running “make slapd.pem”, and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# pastikan dahulu letak folder file berikut, gunakan perintah #find / -name ‘ca-bundle.crt’

TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
TLSCertificateFile /etc/pki/tls/certs/slapd.pem
TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem

# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base=”” by * read
# access to dn.base=”cn=Subschema” by * read
# access to *
# by self write
# by users read
# by anonymous auth

access to * by * read

# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., “access to * by * read”)
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# ldbm and/or bdb database definitions
#######################################################################

database bdb
suffix “dc=arifrohman,dc=com”
rootdn “cn=admin,dc=arifrohman,dc=com”
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw 123456
rootpw {SSHA}+7NhMdrO/CU1ToxihSPH74/NpQNBMh5h

# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
loglevel 256
lastmod on
schemacheck on
cachesize 100000

# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub

# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com@EXAMPLE.COM

5. Copy file konfigurasi database LDAP

# cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

6. Jalankan LDAP server

# service ldap start

7. setup LDAP agar otomatis start saat Centos booting

# chkconfig –level 235 ldap on

8. Inisialisasi LDAP root

# vi ldap_root.ldif

isikan dengan data berikut :

dn: dc=arifrohman,dc=com
dc: arifrohman
description: LDAP Admin
objectClass: dcObject
objectClass: organizationalUnit
ou: rootobject
dn: ou=People, dc=arifrohman,dc=com
ou: People
description: Users of UII
objectClass: organizationalUnit

tambahkan data ke servel ldap, dengan perintah berikut :

# ldapadd -x -D “cn=Manager,dc=arifrohman,dc=com” -W -f ldap_root.ldif

9. install web server untuk manajemen ldap server

# yum install httpd php-mbstring php-ldap

10. Download phpldapadmin dari website http://phpldapadmin.sourceforge.net/download.php, cari versi yang terakhir

#wget http://internode.dl.sourceforge.net/sourceforge/phpldapadmin/phpldapadmin-1.1.0.5.zip

11. install phpldapadmin sebagai halaman utama dari webserver di /var/www/html

#unzip phpldapadmin-1.1.0.5.zip -d /var/www/
#cp /var/www/phpldapadmin-1.1.0 /var/www/html -R

12. konfigurasi phpLDAPadmin

#cp /var/www/htm/config.php.example /var/www/html/config/config.php
#vi /var/www/html/config/config.php

lakukan editing bagian server agar terhubung ke server ldap:

/*********************************************/
/* Define your LDAP servers in this section */
/*********************************************/

$i=0;
$ldapservers = new LDAPServers;

/* A convenient name that will appear in the tree viewer and throughout
phpLDAPadmin to identify this LDAP server to users. */
$ldapservers->SetValue($i,’server’,’name’,’UII LDAP Server’);

/* Examples:
‘ldap.example.com’,
‘ldaps://ldap.example.com/’,
‘ldapi://%2fusr%local%2fvar%2frun%2fldapi’
(Unix socket at /usr/local/var/run/ldap) */
$ldapservers->SetValue($i,’server’,’host’,’127.0.0.1′);

/* The port your LDAP server listens on (no quotes). 389 is standard. */
$ldapservers->SetValue($i,’server’,’port’,’389′);

/* Array of base DNs of your LDAP server. Leave this blank to have phpLDAPadmin
auto-detect it for you. */
// $ldapservers->SetValue($i,’server’,’base’,array(”));

/* Four options for auth_type:
1. ‘cookie’: you will login via a web form, and a client-side cookie will
store your login dn and password.
2. ’session’: same as cookie but your login dn and password are stored on the
web server in a persistent session variable.
3. ‘http’: same as session but your login dn and password are retrieved via
HTTP authentication.
4. ‘config’: specify your login dn and password here in this config file. No
login will be required to use phpLDAPadmin for this server.

Choose wisely to protect your authentication information appropriately for
your situation. If you choose ‘cookie’, your cookie contents will be
encrypted using blowfish and the secret your specify above as
session['blowfish']. */
$ldapservers->SetValue($i,’server’,’auth_type’,’cookie’);

/* The DN of the user for phpLDAPadmin to bind with. For anonymous binds or
‘cookie’ or ’session’ auth_types, LEAVE THE LOGIN_DN AND LOGIN_PASS BLANK. If
you specify a login_attr in conjunction with a cookie or session auth_type,
then you can also specify the login_dn/login_pass here for searching the
directory for users (ie, if your LDAP server does not allow anonymous binds. */
$ldapservers->SetValue($i,’login’,’dn’,’cn=Manager,dc=uii,dc=ac,dc=id’);
# $ldapservers->SetValue($i,’login’,’dn’,’cn=Manager,dc=example,dc=com’);

/* Your LDAP password. If you specified an empty login_dn above, this MUST also
be blank. */
$ldapservers->SetValue($i,’login’,’pass’,”);
# $ldapservers->SetValue($i,’login’,’pass’,’secret’);

/* Use TLS (Transport Layer Security) to connect to the LDAP server. */
$ldapservers->SetValue($i,’server’,’tls’,false);

13. Tes dengan browser

Você ainda utiliza autenticação individual para cada serviço ? Seus usuários já estão cansados de memorizar tantas senhas ?

Realmente tudo isso simplesmente não pode existir em ambientes organizados, empresas com mais de 50 funcionários já não podem mais se dar ao luxo de fazerem as coisas “‘de qualquer jeito”. Utilizando-se um ambiente com autenticação centralizada todos saem ganhando, tanto os Administradores de Rede, Programadores ou os próprios usuários, todos usufruem das facilidades de um serviço de Autenticação Centralizada.

Daí entra em campo o OpenLDAP, um serviço de Diretórios OpenSource baseado no protocolo LDAP que usa o modelo X.500, utilizado principalmente para autenticação centralizada de serviços. Onde um Diretório é uma estrutura de armazenamento organizado de forma hirárquica, que facilita o armazenamento e busca por informações.

Apesar de se parecer bastante com o conceito de um Banco de Dados, uma Base LDAP não é recomendada para situações onde há grande volume de escrita, e sim quando é necessário um grande volume de consultas a informações como logins, que é onde o OPENLDAP se destaca por sua velocidade e compatibilidade com centenas de aplicações. Permitindo assim um ambiente homogêneo de autenticação e consulta de informações simples.

Instalando o OpenLDAP :

Debian-like :

$ apt-get install slapd ldap-utils libnss-ldap libpam-ldap

OBS. : Durante a instalação do libnss-ldap serão efetuadas algumas perguntas, mas basicamente a maioria você irá deixar como padrão, as únicas coisas que mudam são o endereço do ldap ( 127.0.0.1 ) e o caminho da Base ( dc=base,dc=com,dc=br ).

Red-hat-like :

$ yum install openldap openldap-servers openldap-servers-overlays

Criando uma Senha para o Administrador da Base :

$ ldappasswd -h {MD5}

Será gerada uma senha em MD5 como essa : “{MD5}W6whSnp02Fl3rPMXH3wijw==”  copie o resultado e cole-o no campo rootpw.

Arquivo de Configurações de Exemplo :

OBS. : Esse arquivo deve ser seguido apenas como exemplo, e alterado de acordo com as necessidades do ambiente a ser implementado, principalmente em produção. Tomando em considerações questões como volume de informações armazenadas e a segurança de acesso.
slapd.conf :

# Versão de Protocolo para consultas ao LDAP – Não recomendado por ser antigo e inseguro
#allow bind_v2

# Schemas / Altere os caminhos para os REDHAT like.
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema

# Arquivos de controle dos processos
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

# Módulos
# No Fedora/RedHat você deve comentar
# as duas linhas abaixo
modulepath /usr/lib/ldap
moduleload back_hdb

# Controle de acesso
# acesso à estrutura básica do Diretório
access to dn.exact=”"
by * read

# Apenas o próprio usuário pode ver/alterar a senha
access to attrs=userPassword
by self write
by anonymous auth
by * none

# Libera consulta a todos os outros dados de nossa base
access to *
by * read

# Definição do nível de log
loglevel 0

# Base de dados
backend hdb
database hdb

# Estrutura do diretório e administrador
suffix “dc=base,dc=com,dc=br”
rootdn “cn=root,dc=base,dc=com,dc=br”
# A senha a seguir é um exemplo e deve ser substituída pela sua saída do comando slappasswd -h {MD5}
rootpw {MD5}W6whSnp02Fl3rPMXH3wijw==

# Local de armazenamento dos dados
directory /var/lib/ldap

# Índices de pesquisa
index objectClass eq
index cn,sn,mail eq,sub,approx
index uid eq,sub

Populando a base :
Salve o conteúdo abaixo em um arquivo chamado ldap-base.ldif ( ldif é o formato de texto utilizado pelo Openldap para lidar com inclusões, alterações e remoções de uma base ldap via linha de comando. )

ldap-base.ldif :

dn: dc=base,dc=com,dc=br
dc: base
objectClass: top
objectClass: domain

dn: ou=Pessoas,dc=base,dc=com,dc=br
ou: Pessoas
objectClass: top
objectClass: organizationalUnit

dn: ou=Grupos,dc=base,dc=com,dc=br
ou: Grupos
objectClass: top
objectClass: organizationalUnit

dn: ou=Computadores,dc=base,dc=com,dc=br
ou: Computadores
objectClass: top
objectClass: organizationalUnit

dn: cn=suporte,ou=Pessoas,dc=base,dc=com,dc=br
objectClass: top
objectClass: person
cn: nssuser
sn: Usuario de Suporte para testes

Incluindo os dados na base :

$ ldapadd -f ldap-base.ldif -x -D “cn=root,dc=base,dc=com,dc=br” -W

Pronto! Caso nenhum erro ocorra sua base está populada e funcional, caso contrário, pare o serviço do ldap e remova todos os arquivos do diretório /var/lib/ldap e comece tudo novamente.

Autenticando-se ao LDAP :

RedHat like :
rode o comando “setup” na linha de comando, escolha a opção Autenticação, e depois marque as opções  ldap na primeira coluna e  MD5, Ldap e Autenticação Local é Suficiente, depois avance e digite o endereço de sua base ( no caso local ) “127.0.0.1” e a base “dc=base,dc=com,dc=br” e depois avance novamente e saia da caixa do Setup.

Debian Like :

$ apt-get install libpam-ldap libnss-ldap nss-updatedb

Crie um arquivo chamado “auth_ldap“  com o conteúdo abaixo e salve-o no diretório “/etc/auth-client-config/profile.d“  :

[auth_ldap]
nss_passwd=passwd: compat ldap
nss_group=group: compat ldap
nss_shadow=shadow: compat ldap
nss_netgroup=netgroup: nis
pam_auth=auth       required     pam_env.so
auth       sufficient   pam_unix.so likeauth nullok
auth       required   pam_mount.so use_first_pass
auth       sufficient   pam_ldap.so use_first_pass
auth       required     pam_deny.so
pam_account=account    sufficient   pam_unix.so
account    sufficient   pam_ldap.so
account    required     pam_deny.so
pam_password=password   required     pam_unix.so nullok obscure min=4 max=8 md
password   sufficient   pam_ldap.so use_first_pass
pam_session=session    required     pam_limits.so
session    required     pam_mkhomedir.so skel=/etc/skel/
session    required     pam_unix.so
session    optional     pam_ldap.so
session    optional     pam_mount.so

Agora execute o seguinte comando para efetuar as alterações no sistema para que o mesmo comece a se autenticar via ldap :

$ auth-client-config -a -p auth_ldap

Testando se as informações estão sendo armazenadas na base ldap :

$ ldapsearch -x

O retorno do comando acima deve ser semelhante ao visto abaixo :

dn: dc=base,dc=com,dc=br

objectClass: top

dn: ou=Pessoas,dc=base,dc=com,dc=br
objectClass: top
objectClass: organizationalunit
ou: Pessoas

dn: ou=Grupos,dc=base,dc=com,dc=br

objectClass: top

objectClass: organizationalunit

ou: Grupos

dn: ou=Computadores,dc=base,dc=com,dc=br
objectClass: top
objectClass: organizationalunit
ou: Computadores

dn: uid=suporte,ou=Pessoas,dc=base,dc=com,dc=br

objectClass: person

objectClass: top

objectClass: organizationalPerson

ou: Accounting

ou: Pessoas

sn: Suporte

Ferramentas Recomendadas :

• Apache Directory Studio – Excelente ferramenta desktop multiplataforma feita em java e baseada no Eclipse para Gerenciamento de Bases LDAP.

• GOSA – Ferramenta de Gerenciamento de Bases LDAP via Web.

Outros Serviços de Diretórios Semelhantes :

• Fedora Directory Server
• Centos Directory Server
• RedHat Directory Server
• Apache Directory Server

Pronto ! Agora temos uma base ldap rodando e esperando apenas ser organizada como devido e populada. Em próximos artigos irei citar integrações como Serviços como Samba, Squid, etc.

Espero que tenha sido de ajuda para aqueles que possam estar quebrando a cabeça como eu estava a alguns anos atrás heheh.

GRRAS – An apex center for promotion and development of Linux operating system operating for imparting education on Linux, open source and open source-based value-added applications. We are the partner of Rajasthan Knowledge Corporation limited. We strive to spread awareness in people about computer with this program and promote IT in every area in Rajasthan.

GRRAS has been training the corporate houses and students Linux technologies like RHCE, RHCSS, System & network administration, SELINUX, Firewall security, Shell Scripting. For a very long time we have been engaged in offering foremost Linux related training courses which is tremendously lucrative for the IT organizations & Students involved in Software Development, System & Network Administration, SELinux & Firewall security.

contact detail–

219, Himmat Nagar,Behind Kiran Sweets,
Gopalpura Turn, Tonk Road, Jaipur(Raj.)
Tel: +91-141-3136868, +91- 9887789124, +91-9352767438
Email: info@grras.com
RHCE Certification

Red Hat Certified Security Specialist (RHCSS) is a security certification that proves advanced skills in using Red Hat Enterprise Linux, SELinux, and Red Hat Directory Server to meet the security requirements of today’s enterprise environment.

join GRRAS institute for Red Hat Certified Security Specialist (RHCSS) and Red Hat Certified Engineer (RHCE).

* GRRAS is the only institute in jaipur(India) which has first network and security specialists.
* It’s an admiration to be a part of an institute which has best Linux professionals.
* All the GRRAS faculties are technocrats and have much experience of Linux teaching.
* GRRAS provides doubt solving sessions which tend to effective training.
* We became the renowned leader and did set the benchmark for the IT market in training of Linux since the very beginning of our foundation.
* We empower our Linux trainees with unique core competencies for exploiting the untouched jobs in Linux field.

Administering Linux 2.6.x (particularly Red Hat). Installation, initial configuration, using the bash command shell, managing files, managing software, and granting rights to users. DNS, FTP, Apache, send mail, Samba, and other services are covered with live training and full dedication.

Advantage of the COURSE

The Linux Networking & System Administration course provides knowledge and skills for Linux- and/or UNIX- systems administrators who want to build proficiency at configuring common network services and security administration using Linux. This course is updated for building skills on Linux Administration.

you can contact for Red Hat Certified Security Specialist (RHCSS) and Red Hat Certified Engineer (RHCE) batches.

contact detail–
219, Himmat Nagar,Behind Kiran Sweets,
Gopalpura Turn, Tonk Road, Jaipur(Raj.)
Tel: +91-141-3136868, +91- 9887789124, +91-9352767438
Email: info@grras.com

Website Source

We were originally using Apple OS X Server as our LDAP store for our Alfresco instance.

Apple’s OS X Server uses OpenLDAP but adds custom schema for many things including users and groups.  As a result we ended up using the description LDAP attribute for Alfresco’s ldap.synchronisation.groupIdAttributeName.

We’ve since migrated to a generic OpenLDAP server (with a bit of our own custom schema) so we’re now able to use the more common and unchanging cn attribute for the group id.

When we change ldap.synchronisation.groupIdAttributeName in ldap-synchronisation.properties Alfresco imports the new groups properly but group permissions on spaces will retain the old group name so we need to change those to use the new cn attribute.

What we did was to create a temporary table in the Alfresco database, import the mapping of the cn attribute to the description attribute, then run a query to replace the old authorities with the new.

The following assumes Alfresco version 3.x.

Create the Temp Table

Import the LDAP Group Data

We used phpLDAPAdmin to export our groups subtree as CSV with only the cn and description attributes, then imported that file into the t_ldap_groups table just created.

Replace the Old Authorities

I’m by no means an SQL expert but the query below does the following:

• Strips GROUP_ from the current stored group long name
• Searches the temporary LDAP table for that group long name and corresponding group short name
• Updates the alf_authority.authority field with GROUP_group short name

In Alfresco 2.x the authority is stored directly in the alf_access_control_entry table as well so the update statement would be a bit more complicated.

Drop the Temp Table

DROP TABLE t_ldap_groups;

So far we haven’t had any adverse effects on our development server doing things this way but if anyone has a better method or potential issues with this one let us know.

The Big Picture

Nos vamos acercando al entorno deseado. Tenemos Liferay y Alfresco autenticando con OpenLDAP. Es hora de añadir el Single Sign On (SSO), utilizando una solución desarrollada por la universidad de Yale: Central Authentication System (CAS).

1. Deberemos configurar un “LDAP Authentication Handler”
2. Deberemos configurar el servidor para SSL.
3. Deberemos configurar los clientes para que confíen en el certificado del servidor generado en el punto (2) -esto es necesario porque vamos a trabajar con certificados de prueba (self-signed)

Configuración de CAS y LDAP

CAS User Manual

Paso 1.1

El primer paso que indica el manual es añadir la siguiente dependencia a pom.xml

<dependency>
     <groupId>${project.groupId}</groupId>
     <artifactId>cas-server-support-ldap</artifactId>
     <version>${project.version}</version>
</dependency>

Sé que tiene que ver con Maven, pero dado que Maven lo asocio a la construcción, no sé cuál es la razón de añadir esta declaración. Si algún alma caritativa puede aportar algo de luz mediante un comentario Dios se lo pagará con muchos hijos -o mujeres u hombres-

Mi pompom, mi pom.xml lo tengo en: C:\desarrollo\java\install\tomcat-5.5\webapps\cas-server-webapp-3.3.3\META-INF\maven\org.jasig.cas\cas-server-webapp\pom.xml

Paso 1.2

Añadir los beans al archivo: C:\desarrollo\java\install\tomcat-5.5\webapps\cas-server-webapp-3.3.3\WEB-INF\deployerConfigContext.xml

NOTA: Mi servidor es gammu y openLDAP está corriendo en el puerto 389.

1.2.1 Configuración del bean id=”contextSource”

En el bean con id contextSource debemos indicar:
Las URL del servidor LDAP. En mi caso ldap://gammu:389
El DN del usuario con el que conectaremos con LDAP. En mi caso cn=admin,dc=uniovi,dc=es
La contraseña de este usuario. En mi caso secret -contraseña por defecto en OpenLDAP y Apache DS-

 1.2.2 Configuración del bean id=”authenticationManager”

En la propiedad authenticationHandlers define una lista de manejadores. Debemos eliminar o comentar el SimpleTestUsernamePasswordAuthenticationHandler y sustituirlo por el FastBindLdapAuthenticationHandler -en mi caso-.

1.2.3 Propiedades del FastBindLdapAuthenticationHandler

Simplemente tenemos que configurar la propiedad filter. Esta propiedad define cómo buscar usuarios en el árbol LDAP. En mi caso utilizo el UID, en otros casos puede ser necesario comprobar por el CN. En mi caso: uid=%u,ou=people,dc=uniovi,dc=es

————————————- deployerConfigContext.xml —————————————————-

<beans xmlns=”http://www.springframework.org/schema/beans“
       xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance“
       xmlns:p=”http://www.springframework.org/schema/p“
       xsi:schemaLocation=”http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd“>
 
 <!– FER_BEGIN –>
 <bean id=”contextSource”>
  <property name=”pooled” value=”true”/>
  <property name=”urls”>
   <list>
    <value>ldap://gammu:389</value>
   </list>
  </property>
  <property name=”userDn” value=”cn=admin,dc=uniovi,dc=es”/>
  <property name=”password” value=”secret”/>
  <property name=”baseEnvironmentProperties”>
   <map>
    <entry>
     <key>
      <value>java.naming.security.authentication</value>
     </key>
     <value>simple</value>
    </entry>
   </map>
  </property>
 </bean>  
 <!– FER_END –>
…

<bean id=”authenticationManager”
  class=”org.jasig.cas.authentication.AuthenticationManagerImpl”>
…
<property name=”authenticationHandlers”>
   <list>
      <bean class=”org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler”  p:httpClient-ref=”httpClient” />
    <!– FER_BEGIN
    <bean
     class=”org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler” />
    FER_END –>  
    <bean class=”org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler”>
       <property name=”filter” value=”uid=%u,ou=people,dc=uniovi,dc=es” />
       <property name=”contextSource” ref=”contextSource” />
    </bean>    
   </list>
  </property>
</bean>
…

</beans>

Paso 2.1

Me adelanto un poco, pero prefiero comentar aquí un error que veréis cuando configuréis Alfresco para CAS. Si no hemos definido un certificado de servidor para nuestro Tomcat_CAS Alfresco nos mostrará un mensaje tal como:

edu.yale.its.tp.cas.client.CASAuthenticationException: Unable to validate ProxyTicketValidator [[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null] [edu.yale.its.tp.cas.client.ServiceTicketValidator casValidateUrl=[https://localhost:8444/cas-server-webapp-3.3.3/serviceValidate] ticket=[ST-10-46fBuOkjqiPZUoCrUVc6-cas] service=[http%3A%2F%2Flocalhost%3A9090%2Falfresco%2Ffaces%2Fjsp%2Fdashboards%2Fcontainer.jsp] renew=false]]]

Para evitarlo tenemos que configurar Tomcat para SSL -ver el post de configuración de Tomcat con SSL- y añadir el certificado a la lista de certificados de confianza de la JRE.

Si tanto Alfresco como Liferay los tenéis en un mismo servidor, utilizad la misma JRE para ambos y no tendréis problemas de confianza. En el caso de tenerlos separados tenéis que importar el certificado a cada JRE -dado que me refiero siempre a certificados de prueba, no de VeriSign-.

Añadir una trusted certificate entry se puede hacer con la herramienta keytool o usando un pequeño programa Java muy sencillo.InstallCert

Dado que estamos trabajando contiuamente con LDAP en Windows, voy a incluir algunas direcciones con software de interés. Principalmente dónde encontrar una versión de OpenLDAP compilada para Windows.

• Servidor OpenLDAP para Windows: Userbooster OpenLDAP for Windows version 2.4.11
• Servidor LDAP de Apache: Apache Directory
• Cliente LDAP: Apache Directory Studio
• Cliente LDAP: Softerra LDAP Browser
• Manual OpenLDAP: OpenLDAP Admin Guide

Let’s get to work with CentOS5 now that we have set up the yum repositories and are able to install all the software we need. As a short reminder our requirements listing again. So let’s continue from last time…

Our requirements are the following:

• nagios for monitoring of
  • disk space
  • system load
  • service availability
  • …
• openLDAP (v3 only and TLS only)
• SMTP with Sender Authentication over TLS only
• IMAPs (only, and only over TLS)
• a webmail interface for easy access from anywhere – also TLS only

Since I know Postfix best I decided to go with it, also Dovecot is a nice (and fast) IMAP server (as I learned on the way). User Information for the mail users should come from LDAP – that also makes it easy to set up some password changing webform (did I mention: TLS only).

But first the basic setup. This is where the problems started:

• no nagios in the official repositories – rpmforge has them
  • it seems Dag Wieers is an official package maintainer taking part in this repo so it seems trustworthy according to some Google research
• postfix seems to be in the CentOsPlus repository

Let’s see, yum is the package manager and seems to work quite well, no sign of RPM-dependency hell any more.

O.K. – so much for a basic running service. Of course that doesn’t do that much that is useful for us. Let’s first configure slapd and a basic LDAP tree. The config of slapd is rather simple, we don’t really have any users except one so we don’t exactly need any groups. Why bother with LDAP then? Well, once you get used to having LDAP and a nice GUI tool is actually a lot easier more convenient to deal with than with the good unix passwords. Note: I recommend to NEVER EVER put system users required to start daemons/applications in LDAP, don’t even think about it!

Now here comes the slapd.conf:

# egrep -v '^ *#|^$' /etc/openldap/slapd.conf
include        /etc/openldap/schema/core.schema
include        /etc/openldap/schema/cosine.schema
include        /etc/openldap/schema/inetorgperson.schema
include        /etc/openldap/schema/nis.schema
include        /etc/openldap/schema/misc.schema
pidfile        /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args
TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
TLSCertificateFile /etc/pki/tls/certs/slapd.pem
TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
 by self write
 by users read
 by anonymous auth
database    bdb
suffix        "dc=example,dc=org"
rootdn        "cn=System Maintenance Account,ou=System,dc=example,dc=org"
rootpw changeme
directory    /var/lib/ldap
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

And this is our LDIF (already with the user we want to use for mailing):

dn: dc=example,dc=org
objectClass: dcObject
objectClass: top
objectClass: organization
dc: dc=example,dc=org
o: Example Corp.

dn: ou=People,dc=example,dc=org
objectClass: organizationalUnit
objectClass: top
ou: People

dn: cn=Alice  Squarepants,ou=People,dc=example,dc=org
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: inetLocalMailRecipient
cn: Alice  Squarepants
mail: asquarepants@example.org
mailLocalAddress: alice@example.org
sn: Doe
userPassword: changeme

dn: ou=System,dc=example,dc=org
objectClass: organizationalUnit
objectClass: top
ou: System

dn: cn=System Maintenance Account,ou=System,dc=example,dc=org
objectClass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
cn: System Maintenance Account
userPassword: changeme

dn: cn=postfix,ou=System,dc=example,dc=org
objectClass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
cn: postfix
userPassword: changeme

dn: cn=dovecot,ou=System,dc=example,dc=org
objectClass: organizationalRole
objectClass: top
objectClass: simpleSecurityObject
cn: dovecot
userPassword: changeme

dn: cn=Bob,ou=People,dc=example,dc=org
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: inetLocalMailRecipient
cn: Bob  Squarepants
mail: bob@example.org
sn: Bob Squarepants
userPassword: changeme

dn: cn=Postmaster,ou=People,dc=example,dc=org
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
objectClass: inetLocalMailRecipient
cn: Postmaster
mail: postmaster@example.org
mailLocalAddress: hostmaster@example.org
mailLocalAddress: abuse@example.org
sn: Postmaster
userPassword: changeme

Let’s see now what we have.

• Non-System users ready to use in LDAP – check
• Aliases that can be used easily – check
• a container for “real people” vs. a container for “role objects” – check
• Hopefully no typos since I made some modifications like changing the passwors (of course) the Root DSE and some DNs

Next time we’ll see how to configure Dovecot to use this information and automagically create the correct mailbox with the information provided from our LDAP tree.

Extracting ldif data is not enough when you have to import them into some other data source. The most simple solution is to convert ldif to some delimited file format ( CSV or TSV ) that is more supported from existing tools and software.  The best online resource I was able to find is this one. Sadly python is not contemplated among programming languages used by my customer. So I had to write something myself in C++. I chosed TSV over CSV because distinguished names contain commas and surrounding them with double quotes (“) is sometimes not so well digested by some software. The usage is simple:

Ldif2Tsv <ldif file> <tsv file> <attribute1> <attribute2> <attribute 3> … <attribute n>

You just type the name of the compiled program followed by the input file, the ouput file and an arbitrary list of attributes that you would like to have in the tsv output. You  can copy and paste the code below or download the whole thing here.

#include <iostream>
#include <fstream>
#include <string>
#include <map>
#include <vector>

using namespace std;

string& trim(string &str)
{
    int i,j,start,end;

    //ltrim
    for (i=0; (str[i]!=0 && str[i]<=32); )
        i++;
    start=i;

    //rtrim
    for(i=0,j=0; str[i]!=0; i++)
        j = ((str[i]<=32)? j+1 : 0);
    end=i-j;
    str = str.substr(start,end-start);
    return str;
}

int main(int argc, char* argv[])
{
 std::map<std::string,std::string> entry;
 const char* SEPARATOR="\t";
 
 if(argc< 4)
 {
  cout<<"Usage Ldif2Tsv <ldif file> <tsv file> <attribute1> <attribute2> <attribute 3> ... <attribute n>"<<endl;
  return 0;
 }
 
 ifstream ifile; 
 ofstream ofile;;

 ifile.open(argv[1]);
 if(ifile.is_open()!=true)
 {
  cout<<"Cannot open inputfile "<<argv[1]<<endl;
  return 0;
 }

 ofile.open(argv[2]);
 if(ofile.is_open()!=true)
 {
  cout<<"Cannot open outputfile "<<argv[2]<<endl;
  return 0;
 }

 vector<string> attributes;
 for(int i=3;i<argc;i++)
 {
  attributes.push_back(argv[i]);
 }

 for(size_t i=0;i<attributes.size()-1;i++)
 {
  ofile<<attributes[i]<<SEPARATOR;
 }
 ofile<<attributes[attributes.size()-1]<<endl;

 std::string line;
 std::string prevvalue="";
 std::string prevattribute="";
 
 std::string value="";
 std::string attribute="";

 int coloncount=0;
 bool firstline=true;

 while(!ifile.eof())
 {
  //We have a new (attribute:value) pair, keep track of the previous one
  if(coloncount==2)
  {    
    entry[prevattribute]=prevvalue;
    prevattribute=attribute;
    prevvalue=value;
    coloncount=1;
  }

  getline(ifile,line);

  //Empty line: end of the old entry and beginning of a new one. Keep track of the
  //last attribute in the entry and write down the tsv row for this entry
  if(line.length()==0)
  {
   entry[prevattribute]=prevvalue;
   for(size_t i=0;i<attributes.size()-1;i++)
   {
    ofile<<entry[attributes[i]]<<SEPARATOR;
    
   }
   ofile<<entry[attributes[attributes.size()-1]]<<endl;

   prevvalue="";
   prevattribute="";
   firstline=true;
   coloncount=0;
   continue;
  }

  
  string::size_type colonfound =line.find_first_of(":");
  if(colonfound==string::npos)
  {
   //We are on a broken line. Accumulate the value
    prevvalue=prevvalue.append(trim(line));
    continue;
  }

  attribute=line.substr(0,colonfound);
  attribute=trim(attribute);
  value=line.substr(colonfound+1,line.length()-colonfound-1);
  value=trim(value);
  coloncount++;
  if(firstline==true)
  {
   prevattribute=attribute;
   prevvalue=value;
   firstline=false;
  }

 }
 return 0;
}

I often have to work on data coming from ldap sources. Indeed I also developed some customs openldap backends that aggregate identity information in peculiar ways to satisfy the needs of one of our clients. A few days ago I was asked to make a complete dump of an Ldap tree because there was the need to import most of the data in a database.

If you have administrator privileges the easiest way to do so consists of three steps:

• Disable logging. In the slapd.conf configuration file set the loglevel directive to 0. Even if this is not recommended it will boost the speed of your dump considerably. Obviously every  conscientious administrator will restore the old value after the dump is finished.
• Set the sizelimit directive to unlimited. This will allow to retrieve all of the ldap tree with a single query. As usual restore the previous sizelimit when you are done with the dump.
• Finally dump the whole directory in LDIF format with a single ldapsearch: ldapsearch -h <ldapserverhostname> -b “dc=sampleRoot” -s sub -L objectClass=* >dumpfile.ldif

LDIF is a textual format that is very handy to parse and to process. The format is made by a sequence of lines where each one represents an attribute of a given entry.  A new entry is separated by the previous one by a blank line, and each line has both the name of the attribute and its value separated by a colon.

On the internet is easy to find many free libraries written in various programming languages that are able to deal with LDIF.  However these libraries are usually very picky about the format and not so forgiving when the file contains small errors. One recurring problem I found while dumping data as described above is to have a newline just in the middle of the attribute value,like this:

dn: cn=john,ou=officeUs,o=
    Usa,dc=sample
attribute1=value
....

I have written a small c++ program that I would like to share that repairs these type of defects. It takes two arguments : the file to repair and the output path for the repaired file. It is written in standard c++ and should compile on any available c++ compiler. The source code is licensed under The Code Project Open License (CPOL) . You may also download it from here.

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

string& trim(string &str)
{
    int i,j,start,end;

    //ltrim
    for (i=0; (str[i]!=0 && str[i]<=32); )
        i++;
    start=i;

    //rtrim
    for(i=0,j=0; str[i]!=0; i++)
        j = ((str[i]<=32)? j+1 : 0);
    end=i-j;
    str = str.substr(start,end-start);
    return str;
}

int main(int argc, char* argv[])
{
 
 if(argc!= 3)
 {
  cout<<"Usage ldifclean inputfile outputfile"<<endl;
  return 0;
 }
 
 ifstream ifile; 
 ofstream ofile;;

 ifile.open(argv[1]);
 if(ifile.is_open()!=true)
 {
  cout<<"Cannot open inputfile "<<argv[1]<<endl;
  return 0;
 }

 ofile.open(argv[2]);
 if(ofile.is_open()!=true)
 {
  cout<<"Cannot open outputfile "<<argv[2]<<endl;
  return 0;
 }
 
 std::string line;
 std::string prevvalue="";
 std::string prevattribute="";
 
 std::string value="";
 std::string attribute="";

 int coloncount=0;
 bool firstline=true;

 while(!ifile.eof())
 {
  //We have a new (attribute:value) pair, write down the previous one
  if(coloncount==2)
  {    
    ofile<<prevattribute<<":"<<prevvalue<<endl;
    prevattribute=attribute;
    prevvalue=value;
    coloncount=1;
  }

  getline(ifile,line);

  //Empty line: end of the old entry and beginning of a new one
  if(line.length()==0)
  {
   ofile<<prevattribute<<":"<<prevvalue<<endl;  
   ofile<<endl;
   prevvalue="";
   prevattribute="";
   firstline=true;
   coloncount=0;
   continue;
  }

  
  string::size_type colonfound =line.find_first_of(":");
  if(colonfound==string::npos)
  {
   //We are on a broken line. Accumulate the value
    prevvalue=prevvalue.append(trim(line));
    continue;
  }

  attribute=line.substr(0,colonfound);
  value=line.substr(colonfound+1,line.length()-colonfound-1);
  coloncount++;
  if(firstline==true)
  {
   prevattribute=attribute;
   prevvalue=value;
   firstline=false;
  }

 }
 return 0;
}

¿Qué es el Directorio LDAP?

LDAP (“Lightweight Directory Acces Protocol”, en español Protocolo Ligero de Acceso a Directorios) es un protocolo de tipo cliente-servidor para acceder a un servicio de directorio.

Se usó inicialmente como un Front-end o interfaz final para x.500, pero también puede usarse con servidores de directorio únicos y con otros tipos de servidores de directorio como OpenLDAP.

Cada item (entrada) en el directorio LDAP describe un objeto (por ejemplo: una persona, un recurso de red, una organización) y tiene un único identificador llamado Nombre Distinguido (DN, Distingued Name). La entrada consiste de una colección de atributos (por ejemplo una persona podría tener apellido, organización, e-mail). Para encontrar las entradas hay que navegar a través del Arbol de Información de Directorio (DIT, Directory Information Tree). En la raíz del árbol se encuentra El Mundo, el cual esta subdividido en el siguiente nivel en paises, y en el siguiente en organizaciones. Dentro de las organizaciones se alamcenan información de gente, recursos, etc.

La mayoría de la información disponible hoy vía LDAP es sobre personas y organizaciones, pero en LDAP también se puede almacenar información sobre otras entidades (o objetos) como recursos de red, aplicaciones…

El servicio LDAP se utiliza principalmente para buscar información de personas (dirección, número de teléfono, e-mail, etc.). Los campos básicos para realizar la búsqueda son: el nombre de la persona y el nombre de la organización a la que pertenece la persona (y departamento dentro de la organización).

http://www.um.es/atica/ldap/

http://mundopc.net/articulos/servicio-de-directorio-openldap/

Deixo un enlace a unha ferramenta que nos pode axudar a elaborar un listado de críterios que se deberian ter en conta a hora de securizar un directorio. Para elo faise uso dunha ferramenta de sw libre chamada  OCIL Interpreter.

Ben, o mellor e que te informes por ti mesmo dado que na web hai moita documentación.

- OpenLdap BSA-

/etc/openldap/slapd.conf

access to *
by dn="cn=Manager,dc=linux,dc=com" write
by self write
by * read

~/.ldaprc

base    dc=linux,dc=com
binddn  cn=Manager,dc=linux,dc=com
host    localhost

# ldapsearch -x "cn=abc"

1. Turn Alfresco OpenLDAP logging on, http://nix.theism.de/turn-alfresco-ldap-logging-on/

Empezamos la segunda parte donde lo dejamos, daremos un vistazo al fichero insane.ldif para hacernos una idea de lo que contiene  nuestro directorio-árbol.  Vamos con la raíz:

# insanecrew.info
dn: dc=insanecrew,dc=info
dc: insanecrew
objectClass: domain
objectClass: domainRelatedObject
associatedDomain: insanecrew.info

Inmediatamente después los dos primeros contenedores donde colocaremos a los usuarios y a los grupos.

# People, insanecrew.info
dn: ou=People,dc=insanecrew,dc=info
ou: People
objectClass: organizationalUnit

# Group, insanecrew.info
dn: ou=Group,dc=insanecrew,dc=info
ou: Group
objectClass: organizationalUnit
description: Container for user accounts

Ahora llega la primera sorpresa, mandriva crea dos unidades organizativas como contenedores de los usuarios y los grupos de los sistemas y servicios que usaran nuestro directorio como fuente para autenticarse.

# System Accounts, insanecrew.info
dn: ou=System Accounts,dc=insanecrew,dc=info
ou: System Accounts
objectClass: organizationalUnit
description: Container for System and Services privileged accounts

# System Groups, insanecrew.info
dn: ou=System Groups,dc=insanecrew,dc=info
ou: System Groups
objectClass: organizationalUnit
description: Container for System and Services privileged groups

Seguimos con otra vuelta de tuerca

# Hosts, insanecrew.info
dn: ou=Hosts,dc=insanecrew,dc=info
ou: Hosts
objectClass: organizationalUnit
description: Container for Samba machine accounts

# Idmap, insanecrew.info
dn: ou=Idmap,dc=insanecrew,dc=info
ou: Idmap
objectClass: organizationalUnit
description: Container for Samba Winbind ID mappings

# Address Book, insanecrew.info
dn: ou=Address Book,dc=insanecrew,dc=info
ou: Address Book
objectClass: organizationalUnit
description: Container for global address book entries

Tenemos una unidad organizativa que contendrá a los host de nuestra red. Seguimos complicando la cosa. otro contenedor para el mapeo de  uids y gid s para integrar samba y winbind con nuestro directorio,  ( en próximos capítulos suplantaremos a cualquier AD).
La última Unidad Organizativa de esta tanda es un contenedor llamado libreta de direcciones ¿Nos dará soporte mandriva para enchufar nuestros clientes de correo al directorio? Pues eso parece.

# sudoers, insanecrew.info
dn: ou=sudoers,dc=insanecrew,dc=info
ou: sudoers
objectClass: organizationalUnit
description: Container for sudo related entries

# dhcp, insanecrew.info
dn: ou=dhcp,dc=insanecrew,dc=info
ou: dhcp
objectClass: organizationalUnit
description: Container for DHCP related entries

# dns, insanecrew.info
dn: ou=dns,dc=insanecrew,dc=info
ou: dns
objectClass: organizationalUnit
description: Container for DNS related entries

Las últimas versiones del paquete sudo permiten enchufarlo contra un directorio  para tener un control más exhaustivo de quién, como y cuando usa sudo en nuestros sistemas. Los servicios de infraestructura basados en GNU/Linux también  se integran con nuestro directorio, DHCP y  DNS. Sí, otra vez como el AD.

# Password Policies, insanecrew.info
dn: ou=Password Policies,dc=insanecrew,dc=info
ou: Password Policies
objectClass: organizationalUnit
description: Container for OpenLDAP password policies

# default, Password Policies, insanecrew.info
dn: cn=default,ou=Password Policies,dc=insanecrew,dc=info
cn: default
objectClass: pwdPolicy
objectClass: namedObject
pwdAttribute: userPassword

# KDEConfig, insanecrew.info
dn: ou=KDEConfig,dc=insanecrew,dc=info
ou: KDEConfig
objectClass: organizationalUnit
description: Container for KDE configuration profiles

# default, KDEConfig, insanecrew.info
dn: ou=default,ou=KDEConfig,dc=insanecrew,dc=info
ou: default
objectClass: organizationalUnit
description: Default KDE configuration for all users

Casi estamos acabando, ¡no sufran!  Los dos primeros contenedores contendrán la política de Password de nuestra empresa. Las dos últimas  Unidades Organizativas son para la configuración del escritorio kde de los puestos de nuestra red. ¡ Quién tuviera KDE en los escritos de usuario!

De un tirón los DN (Distinguished Name) de los usuarios para administrar los servicios en nuestra corporación.

# Account Admin, System Accounts, insanecrew.info
dn: uid=Account Admin,ou=System Accounts,dc=insanecrew,dc=info
uid: Account Admin
objectClass: account
objectClass: simpleSecurityObject
description: Account used to administer all users, groups, machines and genera
l accounts

# nssldap, System Accounts, insanecrew.info
dn: uid=nssldap,ou=System Accounts,dc=insanecrew,dc=info
uid: nssldap
objectClass: account
objectClass: simpleSecurityObject
description: Unprivileged account which can be used by nss_ldap for when anony
mous searches are disabled

# MTA Admin, System Accounts, insanecrew.info
dn: uid=MTA Admin,ou=System Accounts,dc=insanecrew,dc=info
uid: MTA Admin
objectClass: account
objectClass: simpleSecurityObject
description: Account used to administer email related attributes

# XXXX Admin, System Accounts, insanecrew.info
dn: uid=XXXX Admin,ou=System Accounts,dc=insanecrew,dc=info
uid: XXXX Admin
objectClass: account
objectClass: simpleSecurityObject
description: Account used to administer XXXX attributes

Sustituya XXXX por lectores y escritores en DHCP yDNS, SUDO, Libreta de direcciones, kde config..  (Si coloco el ldif entero esto se convertirá en eterno). A continuación tenemos los grupos ( groupOfNames) donde incluir a todos los administradores de los servicios antes nombrados, siguiendo la siguiente estructura

# XXXX Admins, System Groups, insanecrew.info
dn: cn=XXXX Admins,ou=System Groups,dc=insanecrew,dc=info
cn: XXXX Admins
objectClass: groupOfNames
description: Members can administer ou=XXXX entries and attributes
owner: uid=XXXX Admin,ou=System Accounts,dc=insanecrew,dc=info
member: uid=XXXX Admin,ou=System Accounts,dc=insanecrew,dc=info

¡Ya era hora! Menudo lío, nos queda claro, que esto no es un directorio de “chichinabo” como dicen en mi pueblo. mandriva nos coloca a competir directemante en funcionalidad con el  “otro” directorio.
Así que para el siguiente capitulo necesitaremos algo de ayuda:

• La documentación oficial de proyecto en el wiki de mandriva
• La instalación de la consola de administración de mandriva, para manejar todo esto.
• Documentación sobre la integración de DNS , sudo y DHCP con OpenLdap