Kerberos+LDAP+NFSv4
Kerberos
Kerberos é un protocolo de autenticación que permite a ordenadores nunha rede insegura identificarse mutuamente de xeito seguro. Tanto os clientes coma o servidor verificarán a identidade un do outro. Kerberos básase en criptografía de chave simétrica e precisa dun terceiro de confianza, ainda que existen extensións que permiten o uso de criptografía de chave asimétrica. Kerberos establece tamén unha duración das autorizacións, de xeito que únicamente é necesario autenticarse unha vez ata que caduque a concesión.
O funcionamento de Kerberos emprega 2 entidades (servidores), o Servidor de Autenticación (SA) e o Servidor de Tickets de Acceso (TGS) co obxecto de asegurar o acceso a un servicio ofrecido por un Proveedor de Servizo (SS) como NFS. Estes dous servidores forman parte do servidor kerberos, que atenderá as solicitudes mediante o seguinte intercambio de mensaxes:
- O usuario introduce no cliente o seu usuario e contrasinal
- O cliente transforma o contrasinal con cifrado de un so sentido, creando a chave segreda do cliente.
- O cliente envía unha mensaxe en claro ao SA solicitando servicio para o usuario identificado.
- O SA verifica que o usuario está na súa base de datos obtendo a súa contrasinal da BBDD e xerando a chave segreda do cliente que cotexará coa recibida. Si coinciden se crearán dúas mensaxes que se envían ao cliente:
- Mensaxe A
- O SA Crea unha mensaxe cifrada coa chave segreda do cliente, chamada Client/TGS Session Key.
- Mensaxe B
- O SA obteń o contrasinal do TGS da BBDD e xenera con ela unha mensaxe cifrada que conten: ID de cliente, dirección IP do cliente, periodo de validez do ticket, e o Client/TGS Session Key. Esta mensaxe é o Ticket Granting Ticket (TGT).
- O cliente descifra a Client/TGS Session Key da Mensaxe A, que se utilizará para a comunicación co TGS.
- Cando o cliente precise un servicio, necesitará solicitarllo ao TGS mediante as seguintes mensaxes:
- Mensaxe C
- Composta polo TGT e a ID do servicio solicitado.
- Mensaxe D
- Cifrado coa Client/TGS Session Key obtida da Mensaxe A e composta polo ID de cliente e unha marca de tempo, chamada Autenticador.
- O TGS descifra o TGT da Mensaxe C obtendo a Client/TGS Session Key necesaria para descifrar a Mensaxe D (Autenticador) e obtendo así o ID de cliente e a marca de tempo
- O TGS con esta información crea unha mensaxe composta pola ID de cliente,IP do cliente,Periodo de validez e a Client/Server Session Key xenerada para a comunicación. Esta mensaxe se cifra coa Chave Segreda do Servizo e se chama Client-To-Server Ticket (Mensaxe E). Tamén se crea outra mensaxe composta pola Client/Server Session Key cifrada coa Client/TGS Session Key (Mensaxe F). Se envían estas dúas mensaxes ao cliente
- Unha vez recibidas estas mensaxes, o cliente poderá autenticarse para acceder ao servizo enviando ao Proveedor do Servizo (SS) a Mensaxe E, e unha nova mensaxe cifrada coa Client/Server Session Key obtida da Mensaxe F que terá o ID do cliente e unha Marca de Tempo.
- O proveedor de servizo (SS) descifrará a Mensaxe E coas súa chave sergreda obtendo así a Client/Server Session Key que lle permitirá descifrar a Mensaxe F e crear unha mensaxe de autorización de acceso ao servizo (Mensaxe H) composta pola marca de tempo obtida da Mensaxe F+1 e cifrada coa Client/Server Session Key.
- O cliente descifra a mensaxe de autorización e confirma a corrección da marca de tempo. Si é correcto, poderá empezar a utilizar o servizo.
Instalación de Kerberos
En Linux existen dúas versións de Kerberos: Heimdall e MIT. Utilizaremos MIT.
Os tickets kerberos teñen periodos de validez establecidos, polo que resulta importante a sincronización dos distintos ordenadores da rede. Para manter a sincronización podemos facer uso de ntp ou do paquete ntpdate, que combinado con cron nos permitirá manter o tempo en sincronía en todos os ordenadores da rede. Se recomenda a versión 5 de Kerberos, xa que a versión 4 ten diversas vulnerabilidades e debilidades no cifrado. E tamén necesario que todos os equipos que utilicen Kerberos sexan resoltos de modo axeitado, tanto de modo directo como inverso, polo que e convinte un servidor DNS, e incluso engadir ao /etc/hosts os servidores e clientes implicados para asegurar o posible fallo do DNS.
Kerberos soporta replicación a múltiples servidores, recomendándose o uso de polo menos dous, un maestro que será o servidor Primario (PDC) e outro Secundario que estará dispoñible para cubrir posibles fallos do maestro (BDC). Os clientes Kerberos utilizarán o servidor secundario automáticamente no caso de fallo do primario.
Instalaremos o servidor Kerberos:
- Instalación do software:
apt-get install krb5-kdc krb5-admin-server
Durante a instalación se solicitará:
- O nome do dominio Kerberos (Realm), que normalmente será o noso dominio en maiúsculas: IESRODEIRA.COM
- Os servidores Kerberos para o dominio, que serán en primeiro lugar o PDC, e logo o BDC: krbldap-pdc.iesrodeira.com krbldap-bdc.iesrodeira.com
- O nome do servidor administrativo (PDC): krbldap-pdc.iesrodeira.com
- Debemos modificar /etc/krb5.conf para incluir a información do noso dominio kerberos na sección [domain-realm] e un apartado para configurar os log de kerberos
mkdir /var/log/kerberos chmod 750 /var/log/kerberos
[domain-realm]
.iesrodeira.com = IESRODEIRA.COM
iesrodeira.com = IESRODEIRA.COM
[logging]
kdc=FILE:/var/log/kerberos/krb5kdc.log
admin_server=FILE:/var/log/kerberos/kadmin.log
default=FILE:/var/log/kerberos/krb5lib.log
- A continuación creamos a base de datos para Kerberos, para o que necesitará recolectar información aleatoria (tardará un pouco) e solicitarnos unha password que será imprescindible para o decodificado da base de datos:
krb5_newrealm service krb5-admin-server restart && service krb5-kdc restart
- Xa podemos empezar a engadir servidores e usuarios a base de datos Kerberos (principals) mediante a utilidade kadmin.local. Os principals Kerberos teñen a forma SPEC@REALMKERBEROS (no noso caso SPEC@IESRODEIRA.COM), donde SPEC normalmente ten a forma de usuario/rol ou servizo/hostname (por exemplo, root/admin, ou nfs/nfs.iesrodeira.com). Estas SPEC se poden utilizar logo no ficheiro /etc/krb5kdc/kadm5.acl para establecer ACLS especificando permisos.
- As password para os principals poden organizarse mediante políticas (policies) que forzan distintos graos de fortaleza (-minlength, -minclasses, -maxlife, -minlife, -maxfailure, -failurecountinterval, -lockoutduration), creando primeiro as políticas como por exemplo:
add_policy -minlength 8 -minclasses 1 user add_policy -minlength 8 -minclasses 3 admin
- Para posteriormente crear o principal cunha política determiñada:
addprinc -policy user root/admin
- Ou cambiar de política un principal existente:
modprinc -policy admin root/admin
- Polo tanto, creamos as políticas e un principal para poder acceder a configuración Kerberos dende calqueira equipo cliente:
add_policy -minlength 6 -minclasses 1 user add_policy -minlength 8 -minclasses 2 admin addprinc -policy admin root/admin
- E editaremos /etc/krb5kdc/kadm5.acl, especificando */admin *, indicando que todos os usuarios co rol admin teñen todos os privilexios de administración. A partir deste momento poderemos administrar o servicio Kerberos dende calqueira cliente coa utilidade kadmin, crear tickets coa utilidade kinit, examinalos (klist) e eliminalos (kdestroy).
- [domain_realm] conten o mapeo ao dominio correcto
- default_realm ten o valor correcto
- o realm está definido na sección [realms]
Podemos comprobar o correcto funcionamento creando un ticket para o principal creado, listando o ticket (TGT) e destruíndolo:
kinit -p root/admin klist kdestroy
- Creamos un principal no PDC para o servidor PDC mediante a utilidade kadmin cunha chave aleatoria, xa que unha máquina non pode introducir unha chave, e creamos o ficheiro local para as chaves.
addprinc -randkey host/krbldap-pdc.iesrodeira.com ktadd host/krbldap-pdc.iesrodeira.com
Unha boa idea sería crear o ficheiro /etc/logrotate.d/krb5-kdc cun contido similar a este:
/var/log/kerberos/krb5lib.log /var/log/kerberos/kadmin.log /var/log/kerberos/krb5lib.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
postrotate
/etc/init.d/krb5-kdc restart > /dev/null
/etc/init.d/krb5-admin-server restart > /dev/null
endscript
}
Tamén sería unha boa práctica alterar a vida dos tickets:
~# kadmin.local Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin.local: modprinc -maxlife "1 day" -maxrenewlife "90 day" krbtgt/IESRODEIRA.COM@IESRODEIRA.COM Principal "krbtgt/IESRODEIRA.COM@IESRODEIRA.COM" modified. kadmin.local: q
e modificando o ficheiro /etc/krb5kdc/kdc.conf para reflexar os cambios cambiando as liñas:
max_life = 1d 0h 0m 0s max_renewable_life = 90d 0h 0m 0s
Servidor Slave (BDC)
- Debemos instalar o paquete krb5-user e contestar ás preguntas:
apt-get install krb5-user
- Creamos un principal no PDC para o servidor esclavo mediante a utilidade kadmin cunha chave aleatoria, xa que unha máquina non pode introducir unha chave, e creamos o ficheiro local para as chaves.
addprinc -randkey host/krbldap-bdc.iesrodeira.com ktadd host/krbldap-bdc.iesrodeira.com
- Instalamos a parte servidor. Necesitaremos xinetd para configurar o servicio de propagación kpropd.
apt-get install krb5-kdc xinetd
- Engadimos o servizo kpropd a xinetd creando o ficheiro /etc/xinetd.d/krb_prop e poñendo:
service krb_prop
{
disable = no
socket_type = stream
protocol = tcp
user = root
wait = no
server = /usr/sbin/kpropd
}
- Inciamos o servizo xinetd
service xinetd restart
- Configuramos a propagación da base de datos Kerberos do primario ao secundario
- Creamos o ficheiro cos controladores Kerberos do noso reino en /etc/krb5kdc/kpropd.acl nos dous controladores. O contido será o seguinte:
host/krbldap-pdc.iesrodeira.com@IESRODEIRA.COM host/krbldap-bdc.iesrodeira.com@IESRODEIRA.COM
- No controlador primario creamos un backup da base de datos Kerberos e a enviamos ao controlador secundario
kdb5_util dump /var/lib/krb5kdc/slave_datatrans kprop krbldap-bdc.iesrodeira.com
- De volta no controlador secundario creamos un ficheiro cunha copia da chave mestra Kerberos:
kdb5_util stash
- Xa podemos iniciar o servizo co comando service krb5-kdc start
A propagación das modificacións da base de datos Kerberos no controlador primario non se propagan ao secundario de xeito automático, polo que é aconsellable crear un script que se encarge da migración de xeito periódico mediante a utilidade cron. Crearemos o ficheiro /etc/cron.hourly/krb5-prop co seguinte contido:
#!/bin/sh
slavekdcs=krbldap-bdc.iesrodeira.com
/usr/sbin/kdb5_util dump /var/lib/krb5kdc/slave_datatrans
error=$?
if [ $error -ne 0 ]; then
echo "Kerberos database dump failed"
echo "with exit code $error. Exciting."
exit 1
fi
for kdc in $slavekdcs; do
/usr/sbin/kprop $kdc > /dev/null
error=$?
if [ $error -ne 0 ]; then
echo "Propagation of database to host $kdc"
echo "failed with exit code $error."
fi
done
exit 0
LDAP
LDAP (LightWeight Directory Access Protocol) é un protocolo de acceso a bases de datos de directorio (Servicios de Directorio) que implementa un subconxunto do estándar X.500. Os servicios de directorio caracterízanse por ser sistemas con moitos accesos de lectura e moi poucas insercións e actualizacións, polo tanto están optimizadas para consultas rápidas.
Este tipo de bases de datos poden almacenar e organizar, por exemplo, a información sobre usuarios dunha rede e os recursos da mesma.LDAP xunto con Kerberos forma o núcleo do sistema de Active Directory de Microsoft Windows, e de moitas outras implementacións como Novell eDirectory ou o RedHat Directory Service.
As bases de datos LDAP teñen forma de árbore, dandolle ao administrador a posibilidade de crear as distintas ramas (DIT, Directory Information Tree), especificando en primeiro lugar a raíz da árbore, que normalmente é o dominio da organización, como pode ser dc=iesrodeira, dc=com (dc é unha abreviatura de Domain Component).
Back in the mid 1980s, before the Internet and its TCP/IP protocol suite became popular, two standards organizations, the ITU-T (then known as the CCITT) and the ISO, were busy developing their own standards for network communications. They had already produced the OSI Transport service, which was an advance in network communications, and also X.400; a collection of data communication standards for what was basically an e-mail service. However, more standards needed to be defined before any of this could be used as part of a global communications system.
The two organizations were looking for solutions. The ITU-T was hoping to develop a white pages service that would return either people's phone numbers or X.400 O/R addresses, while the ISO mostly wanted a name server service for OSI applications. Not wanting to duplicate each other's efforts, they decided to pool their resources. Together they produced a set of networking standards in 1988, called X.500, for what was described as a directory service.
X.500 is an elaborate collection of protocols, specifications and definitions centered around the concept of a single, distributed, replicated, global Directory Information Tree (DIT), capable of storing all kinds of information that would be accessible via the Directory Access Protocol (DAP). The whole system would take off as soon as organizations everywhere started to publish their own directory information, or subsets thereof, in the global DIT. Unfortunately, this never happened, perhaps because most organizations considered their own directory information to be too valuable, or too confidential, to be made available to the world at large in the form of an X.500 directory sub-tree.
However, the concept of a private DIT, and a DAP with which to access it, was regarded as worthy enough in its own right. It just needed to be simplified somewhat. To this end, the Lightweight Directory Access Protocol (LDAP) was defined in 1993 (RFC-1487), giving clients access to an X.500-based DIT via TCP/IP without incurring the costly resource requirements associated with the X.500 DAP. The third and current version of LDAP was published in 1997 (RFC-2251), with a technical specification (RFC-3377) following in 2002.
First released 1998, OpenLDAP is the popular open source implementation of LDAP. With it, anyone can create their own DIT and, unfettered by vendor limitations, decide for themselves what to use it for. All kinds of information can be stored in it − anything from host configuration data to names and addresses − and accessed from anywhere using the many different LDAP-compatible applications.
A DIT is a hierarchically organized collection of entries, each identified by a Distinguished Name (DN); a unique, comma-separated list of components that provide the path to an entry, or object, from the top of the tree. For example, the DN of the root of a DIT for Example Corp. could be dc=example,dc=com, while the DN of someone employed there might be cn=JoeSmith,ou=People,dc=example,dc=com. The Relative Distinguished Name (RDN) of this entry is cn=JoeSmith. Notice how each DN consists of multiple key=value pairs. The keys in these example DNs stand for Common Name (cn), Organizational Unit (ou) and Domain Component (dc).
All LDAP entries are typed, meaning that each DN belongs to an objectClass that identifies the type of information it represents. In turn, each entry consists of multiple attributes that also consist of key=value pairs, each of which is defined by a certain attributeType. These objectClasses and attributeTypes are defined in schema files. This allows an LDAP administrator to decide which schema files to include, based on the needs of the applications that will be using the DIT.
As distintas entradas na árbore LDAP se representan habitualmente en formato LDIF (LDAP Data Interchange Format) que indican o nome (dn) da nova entrada e os seus atributos.
Realizaremos unha instalación de OpenLDAP para almacenar a base de datos dos usuarios do sistema e dos servicios Kerberos, e configuraremos os clientes do modo apropiado.
Instalación de OpenLDAP
1.- Instalamos OpenLDAP
apt-get install slapd ldap-utils
2.-Configuramos de modo apropiado o ficheiro /etc/ldap/ldap.conf
BASE dc=iesrodeira,dc=com
URI ldap://krbldap-pdc.iesrodeira.com ldap://krbldap-bdc.iesrodeira.com
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
3.- A configuración inicial por defecto do esquema LDAP é a seguinte:
root@krbldap-pdc:~/LDAP_configs# slapcat
dn: dc=iesrodeira,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: iesrodeira.com
dc: iesrodeira
structuralObjectClass: organization
entryUUID: 8cfe1ca6-cadc-1032-8ccb-2d2a52bafa1f
creatorsName: cn=admin,dc=iesrodeira,dc=com
createTimestamp: 20131016182851Z
entryCSN: 20131016182851.761222Z#000000#000#000000
modifiersName: cn=admin,dc=iesrodeira,dc=com
modifyTimestamp: 20131016182851Z
dn: cn=admin,dc=iesrodeira,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9ekxHT0c5bXpjWnAvRkFrUVRkc0IweVVHejczZFVHbU0=
structuralObjectClass: organizationalRole
entryUUID: 8d29617c-cadc-1032-8ccc-2d2a52bafa1f
creatorsName: cn=admin,dc=iesrodeira,dc=com
createTimestamp: 20131016182852Z
entryCSN: 20131016182852.044793Z#000000#000#000000
modifiersName: cn=admin,dc=iesrodeira,dc=com
modifyTimestamp: 20131016182852Z
- E os esquemas instalados:
root@krbldap-pdc:~/LDAP_configs# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcBackend={0}hdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}hdb,cn=config
- Activaremos un modo que nos deixe máis información nos logs, e creamos varios índices para mellorar as velocidades de busca. Creamos o seguinte ficheiro inicializa.ldif
# 1.
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats
# 2.1.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uid eq
-
# 2.2.
add: olcDbIndex
olcDbIndex: cn eq
-
# 2.3.
add: olcDbIndex
olcDbIndex: ou eq
-
# 2.4.
add: olcDbIndex
olcDbIndex: dc eq
- e o cargamos no esquema LDAP coa orde:
ldapmodify -QY EXTERNAL -H ldapi:/// -f inicializa.ldif
- Podemos verificar os cambios executando:
ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))"
4.- Replicación no BDC
- A replicación se realiza co módulo Syncrepl. Syncrepl permite que os cambios se envíen seguindo un modelo proveedor-consumidor. O proveedor enviará os cambios do directorio LDAP aos consumidores. Instalaremos o servidor secundario:
apt-get install slapd ldap-utils
- e configuramos de modo apropiado o ficheiro /etc/ldap/ldap.conf
BASE dc=iesrodeira,dc=com
URI ldap://krbldap-bdc.iesrodeira.com ldap://krbldap-pdc.iesrodeira.com
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
- En primeiro lugar será necesario crear no servidor primario (productor)un obxecto de tipo organizationalRole no servidor primario (productor) para representar o secundario (consumidor). Crearemos un ficheiro consumer_role.ldif co seguinte contido:
dn: cn=krbldap-bdc,dc=iesrodeira,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: krbldap-bdc
description: LDAP replicator
userPassword: {SSHA}2jOUxdjQthjBS5Ot3/YlAo+IHJ1nbACi