Diferencia entre revisiones de «OpenLDAP»
Línea 193: | Línea 193: | ||
== Control de Acceso == | == Control de Acceso == | ||
La política por defecto es dejar leer a todos y reservar al root todos los derechos. | La política por defecto es dejar leer a todos y reservar al [[root]] todos los derechos. | ||
El acceso a las entradas de LDAP se controla mediante el atributo olcAccess. La forma general de configurar olcAccess es: | El acceso a las entradas de LDAP se controla mediante el atributo olcAccess. La forma general de configurar olcAccess es: | ||
Línea 229: | Línea 229: | ||
Este indica a todos los objetos del árbol. | Este indica a todos los objetos del árbol. | ||
Otra opción es poner dn.base, one, subtree, o children. Esto selecciona la rama del aŕbol al cual queremos aplicar la regla. Así, ''base'' indica que se aplica sólo al DN indicado. ''one'' indica las entradas cuyo padre sea el sufijo indicado. ''subtree'' hace referencia a todas las entradas a partir del sufijo y ''children'' es igual que subtree pero sin contar el propio sufijo. | Otra opción es poner dn.base, one, subtree, o children. Esto selecciona la rama del aŕbol al cual queremos aplicar la regla. Así, ''base'' indica que se aplica sólo al DN indicado. ''one'' indica las entradas cuyo padre sea el sufijo indicado. ''subtree'' hace referencia a todas las entradas a partir del sufijo y ''children'' es igual que subtree pero sin contar el propio sufijo. | ||
Ejemplo: | |||
0: o=suffix | 0: o=suffix | ||
Línea 237: | Línea 239: | ||
5: uid=hyc,ou=people,o=suffix | 5: uid=hyc,ou=people,o=suffix | ||
entonces: | |||
dn.base="ou=people,o=suffix" | dn.base="ou=people,o=suffix" coincide con 2; | ||
dn.one="ou=people,o=suffix" | dn.one="ou=people,o=suffix" coincide con 3, and 5; | ||
dn.subtree="ou=people,o=suffix" | dn.subtree="ou=people,o=suffix" coincide con 2, 3, 4, and 5; and | ||
dn.children="ou=people,o=suffix" match 3, 4, and 5. | dn.children="ou=people,o=suffix" match 3, 4, and 5. |
Revisión del 11:50 12 sep 2012
OpenLDAP es una de las implementaciones del servicio de LDAP más populares en el mundo Linux.
Se trata de software libre y multiplataforma.
OpenLDAP tiene tres componentes principales:
- slapd - Es el demonio que espera peticiones.
- Bibliotecas para implementar el protocolo
- Programas clientes: ldapsearch, ldapadd, ldapdelete...
Opciones de configuración
La opción más simple es la de un servicio local, ya sea en una LAN o en un ordenador individual. Un servidor proporciona el servicio a uno o más clientes.
La siguiente opción, es la que se usa para añadir nuestro servidor a un servicio de directorio más amplio. Puede que administrado por otros.
Como se puede ver, si el servidor local no es capaz de resolver la petición, le indica al cliente que la pida a un servidor superior.
La tercera opción es la de crear duplicados del servicio de directorio.
En esta opción, el servidor maestro crea duplicados en otros servidores.
Referencia: http://www.openldap.org/doc/admin24/config.html
Backend
El servidor OpenLDAP tiene un sección frontal para controlar conexiones y el protocolo LDAP y una base de datos en segundo plano o backend que se dedica a guardar los datos.
Puesto que tiene una arquitectura modular, se pueden usar múltiples backends para ofrecer el servicio.
OpenLDAP permite por defecto 16 backends distintos. Estos se pueden clasificar en tres categorías:
- De almacenamiento de datos
- Proxy backends, que actuan como puertas de enlace con otros sistemas de almacenamiento.
- Dinámicos, los que generan los datos en el momento.
Un servidor LDAP puede dar, simultáneamente, acceso a múltiples bases de datos. En las nuevas versiones de LDAP hay como mínimo dos:
- config para la configuración
- /var/lib/ldap que es el backend de la base de datos. Suele estar en hdb
Configuración
A partir de OpenLDAP 2.3, la configuración se vuelve dinámica. Esto quiere decir que permite modificaciones con el servidor en marcha. Además, la propia configuración se almacena como un directorio LDAP y se puede administrar con las órdenes comunes del servidor.
Puesto que la configuración también es como un directorio LDAP, tiene su DIT. Es el siguiente:
El primer nodo es cn=config y tiene los ajustes de configuración global. En las otras entradas están los demás ajustes:
- cn=module Carga dinámica de módulos.
- cn=schema Contiene el schema del sistema.
- Los objetos hijos de cn=schema contienen los schemas del usuario añadidos más tarde.
- La configuración del Backend y de la base de datos, otras configuraciones de la base de datos se pueden colocar como hijos de esta. olcDatabase es el parámetro que se usa para configurar la base de datos.
Veamos el LDIF de una configuración estándar.
# global configuration settings dn: cn=config objectClass: olcGlobal cn: config <global config settings>
# schema definitions dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema <system schema>
dn: cn={X}core,cn=schema,cn=config objectClass: olcSchemaConfig cn: {X}core <core schema>
# additional user-specified schema ...
# backend definitions dn: olcBackend=<typeA>,cn=config objectClass: olcBackendConfig olcBackend: <typeA> <backend-specific settings>
# database definitions dn: olcDatabase={X}<typeA>,cn=config objectClass: olcDatabaseConfig olcDatabase: {X}<typeA> <database-specific settings>
# subsequent definitions and settings ...
la X indica un número. LDAP no mantiene un orden en sus entradas. Si es necesario este orden se puede forzar con esos números.
Las directivas de configuración en detalle se pueden ver en: http://www.openldap.org/doc/admin24/slapdconf2.html#Configuration%20Directives
Ejemplo de configuración
(Al final de cada fragmento de LDIF hay una línea en blanco para indicar el final de una entrada)
dn: cn=config objectClass: olcGlobal cn: config olcReferral: ldap://root.openldap.org
Este es el LDIF del nodo raíz. Las tres primeras líneas indican que es el nodo raíz. El atributo olcReferral indica dónde debe preguntar el cliente en caso de que el servidor no pueda responder su petición.
# internal schema dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema
Aquí está el schema interno del sistema. No es necesario indicar nada más porque los schemas principales están en el própio código de slapd
# include the core schema include: file:///usr/local/etc/openldap/schema/core.ldif
Este include hace referencia al esquema core.
# global database parameters dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend olcAccess: to * by * read
Aquí llega la configuración de la base de datos. La última línea es control de acceso global que permite a todos leer.
# set a rootpw for the config database so we can bind. # deny access to everyone else. dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy olcAccess: to * by * none
Se define con olcRootPW la contraseña del superusuario de la base de datos. La siguiente línea niega el acceso a todos menos al superusuario.
# BDB definition for example.com dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: "dc=example,dc=com" olcDbDirectory: /usr/local/var/openldap-data olcRootDN: "cn=Manager,dc=example,dc=com" olcRootPW: secret olcDbIndex: uid pres,eq olcDbIndex: cn,sn,uid pres,eq,approx,sub olcDbIndex: objectClass eq olcAccess: to attrs=userPassword by self write by anonymous auth by dn.base="cn=Admin,dc=example,dc=com" write by * none olcAccess: to * by self write by dn.base="cn=Admin,dc=example,dc=com" write by * read
En esta parte se define un backend para example.com. Primero se especifica el sufijo para consultas y el directorio donde se guardará. A continuación se indica quien es el superusuario de esa base de datos. las siguientes líneas indican el control de acceso para esta base de datos. Para todas las entradas, el atributo userPassword puede ser escrito por la propia entrada o el administrador. Se puede usar para autentificar, pero de otra forma no es legible. Todos los demás atributos pueden ser leidos por todos y modificados por la entrada o el adminstrador.
Instalación
Instalación en Ubuntu: https://help.ubuntu.com/12.04/serverguide/openldap-server.html
slapd
Se trata del demonio, multiplataforma, encargado de hacer de servidor LDAP. Como características tiene:
- Implementa el protocolo LDAPv3, que puede funcionar sobre IPv4 o IPv6
- Permite autenticación simple y una capa de seguridad. Para conseguirlo usa SASL.
- Soporta TLS para un transporte seguro de los datos. Puede trabajar con OpenSSL.
- Tiene control de acceso a través de ACL o por parámetros de la red.
- Soporta Unicode
- Permite elegir entre múltiples backends.
- Puede servir múltiples bases de datos en una sola instalación.
- Permite el uso de módulos para dotarlo de más características.
- Usa threads, lo cual le permite un mayor rendimiento.
- Puede usarse para ser replicado, replicar o actuar como proxy caché.
- Se puede configurar dinámicamente.
Control de Acceso
La política por defecto es dejar leer a todos y reservar al root todos los derechos.
El acceso a las entradas de LDAP se controla mediante el atributo olcAccess. La forma general de configurar olcAccess es:
olcAccess: <access directive> <access directive> ::= to <what> [by <who> [<access>] [<control>] ]+ <what> ::= * | [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>] [filter=<ldapfilter>] [attrs=<attrlist>] <basic-style> ::= regex | exact <scope-style> ::= base | one | subtree | children <attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist> <attr> ::= <attrname> | entry | children <who> ::= * | [anonymous | users | self | dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>] [dnattr=<attrname>] [group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>] [peername[.<basic-style>]=<regex>] [sockname[.<basic-style>]=<regex>] [domain[.<basic-style>]=<regex>] [sockurl[.<basic-style>]=<regex>] [set=<setspec>] [aci=<attrname>] <access> ::= [self]{<level>|<priv>} <level> ::= none | disclose | auth | compare | search | read | write | manage <priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+ <control> ::= [stop | continue | break]
El <what> indica qué entradas se verán afectadas por esta regla de acceso. <who> indica a quién se le aplica esta regla. <access> define los permisos aplicados. Esto se verá con más detalle y mediante ejemplos a continuación.
El <what> puede representarse como una expresión regular o un DN, por ejemplo:
to *
Este indica a todos los objetos del árbol. Otra opción es poner dn.base, one, subtree, o children. Esto selecciona la rama del aŕbol al cual queremos aplicar la regla. Así, base indica que se aplica sólo al DN indicado. one indica las entradas cuyo padre sea el sufijo indicado. subtree hace referencia a todas las entradas a partir del sufijo y children es igual que subtree pero sin contar el propio sufijo.
Ejemplo:
0: o=suffix 1: cn=Manager,o=suffix 2: ou=people,o=suffix 3: uid=kdz,ou=people,o=suffix 4: cn=addresses,uid=kdz,ou=people,o=suffix 5: uid=hyc,ou=people,o=suffix
entonces:
dn.base="ou=people,o=suffix" coincide con 2; dn.one="ou=people,o=suffix" coincide con 3, and 5; dn.subtree="ou=people,o=suffix" coincide con 2, 3, 4, and 5; and dn.children="ou=people,o=suffix" match 3, 4, and 5.