Espacio de nombres distribuido: Zonas. Domain Name System (DNS) RR de tipo SOA (Start of Authority) Resource Record.

Transcripción

1 Domain Name System (DNS) Servicio de nombres de máquinas en Internet: nombre IP No es un serv. nombres general pero ilustrativo por escalabilidad Diseño genérico: aunque uso habitual nombre de máquinas Internet Inicios de Internet: fichero HOST que se actualizaba periódicamente Espacio de nombres de DNS jerárquico Nombre: secuencia de dominios ( directorios) de dcha. a izda. + es + upm + fi + datsi Dominio raíz:. Caminos absolutos (FQDN) terminan con. Dominios nivel superior (TLD) gtlds: genéricos (com, org,...) cctlds: por país ( qué pasa con el de Tuvalu?) De segundo nivel, de tercero,... Implementación más usada BIND Sistemas Distribuidos 1 Fernando Pérez Costoya Espacio de nombres distribuido: Zonas Zona DNS: partición del árbol global (zona dominio) Información recursos de un dominio y sus subdominios no delegados Delegación de dominios Un subdominio puede tener su propia zona Dominio padre incluye punto de montaje a esa zona subordinada Diseño habitual: delegar todos los subdominios Una zona para cada dominio (zona dominio) Incluso a veces a los mismos servidores que el dominio del que cuelgan Cada zona está replicada: 1 servidor maestro/primario y N (al menos 1) esclavos/secundarios Fiabilidad: mejor réplicas en distintas subredes Información contenida en una zona: Colección de Resource Records (RR) que describen sus recursos Sistemas Distribuidos 2 Fernando Pérez Costoya Resource Record Definición de un recurso: Nombre Tipo Clase TTL Datos Clase IN para Internet (otros HS, para Hesiod, y CH, para Chaos) NOTA: Nombre puede tener * a la izqda. (wildcard RR; no lo tratamos) Fichero de zona: Fichero de texto en primario define RRs de una zona: 1 RR/línea Aunque RRs se transmiten en binario Incluye RRs de recursos del dominio y de subdominios no delegados Sintaxis definida para facilitar introducción de datos en fichero de zona Macros, caracteres especiales, caminos relativos, omisión de campos,... Diversos tipos de RRs Nos centramos en SOA, A, AAAA, PTR, CNAME, MX, SRV, TXT y NS No tratamos los RRs relacionados con la extensión DNSSEC Proporciona autenticación e integridad en DNS Sistemas Distribuidos 3 Fernando Pérez Costoya RR de tipo SOA (Start of Authority) Comienzo de definición de una zona Ejemplo de definición en fichero de zona (wikipedia) example.com. IN SOA ns.example.com. username.example.com. ( ; serial number of this zone file 1d ; slave refresh (1 day) 2h ; slave retry time in case of a problem (2 hours) 4w ; slave expiration time (4 weeks) 1h ; maximum caching time in case of failed lookups (1 hour) ) Ejemplo de consulta: dig fi.upm.es. SOA fi.upm.es IN SOA chita.fi.upm.es. hostmaster.fi.upm.es Dominio; TTL; Clase Internet; Start Of Authority; S. maestro; responsable; nº serie (incrementar si cambio); Periodo de actualización de secundario; Tiempo de reintento de secundario antes actualización fallida; Tiempo de expiración de info. de secundario ante actualización fallida; TTL para cache negativa (tiempo en cache de consultas erróneas) Sistemas Distribuidos 4 Fernando Pérez Costoya RR de tipo A o AAAA Dirección de máquina: A (IPv4) y AAAA (IPv6) Ejemplo de definición en fichero de zona (wikipedia) A ; IPv4 address for example.com AAAA 2001:db8:10::1 ; IPv6 address for example.com Ejemplo de consulta: dig A IN A Múltiples recursos con mismo nombre (reparto de carga) IN A IN A IN A Hasta Nótese TTL bajo en RR para favorecer el reparto de carga Sistemas Distribuidos 5 Fernando Pérez Costoya RR de tipo PTR Traducción inversa dirección IP Nombre Gestionada también por DNS: mediante dominios especiales Para IPV4: in-addr.arpa. Traducir in-addr.arpa. Para IPV6: ip6.arpa. Traducir 2001:720:41c:40:12:100:4: c ip6.arpa. Ejemplos de consulta: dig in-addr.arpa. PTR in-addr.arpa IN PTR dig c ip6.arpa. PTR c ip6.arpa IN PTR galileo.ccupm.upm.es. Sistemas Distribuidos 6 Fernando Pérez Costoya

2 RR de tipo CNAME (Canonical NAME) Alias: Nuevo nombre para mismo recurso IN CNAME avellano.datsi.fi.upm.es. avellano.datsi.fi.upm.es IN A Frente a: IN A avellano.datsi.fi.upm.es IN A Más flexibilidad ante cambios pero ineficiencia por indirección Pueden encadenarse: IN CNAME elpais.es.edgesuite.net IN CNAME elpais.es.edgesuite.net. elpais.es.edgesuite.net IN CNAME a1749.g.akamai.net. a1749.g.akamai.net. 20 IN A a1749.g.akamai.net. 20 IN A Sistemas Distribuidos 7 Fernando Pérez Costoya RR de tipo MX Servidores de correo para dominio con orden de preferencia Formato: name TTL class MX priority target Ejemplo de consulta: dig upm.es. MX upm.es IN MX 10 relay.upm.es. upm.es IN MX 30 relay4.upm.es. upm.es IN MX 50 correo.upm.es. Número indica orden de preferencia: prioridad preferencia Remitente de correo debe contactar con servidor de menor nº Si caído con el siguiente, Sistemas Distribuidos 8 Fernando Pérez Costoya RR de tipo SRV Permite especificar qué máquinas dan un servicio en el dominio Formato: _service._proto.name TTL class SRV priority weight port target Permite especificar prioridades y reparto entre misma prioridad Ejemplo de wikipedia: _sip._tcp.example.com IN SRV bigbox.example.com. _sip._tcp.example.com IN SRV smallbox1.example.com. _sip._tcp.example.com IN SRV smallbox2.example.com. _sip._tcp.example.com IN SRV smallbox2.example.com. _sip._tcp.example.com IN SRV backupbox.example.com. Por qué se usan tan poco? Por qué no se usan para la Web? RR de tipo TXT Permite asociar texto con un nombre Una forma de añadir funcionalidad a DNS sin nuevos RRs Ejemplos de aplicación: Sender Policy Framework (SPF): Validar qué máquinas de un dominio pueden enviar correo NOTA: existe también un RR de tipo SPF Verificar la propiedad de un dominio para Google Ejemplo de consulta: dig fi.upm.es. TXT fi.upm.es IN TXT "v=spf1 ip4: /24 ip4: /24 ip4: all" fi.upm.es IN TXT "google-site-verification=rjt2yatvyyg4hepvhznk6lrxhnnlarzhanxhkfcsgu Sistemas Distribuidos 9 Fernando Pérez Costoya Sistemas Distribuidos 10 Fernando Pérez Costoya RR de tipo NS (Name Server) Primer uso: especificar servidores de nombres para un dominio Ejemplo: dig fi.upm.es. NS fi.upm.es IN NS chita.fi.upm.es. fi.upm.es IN NS zape.fi.upm.es. fi.upm.es IN NS tarzan.fi.upm.es. fi.upm.es IN NS galileo.ccupm.upm.es. fi.upm.es IN NS ns.fi.upm.es. Ejemplo: dig in-addr.arpa. NS in-addr.arpa IN NS in-addr.arpa IN NS in-addr.arpa IN NS in-addr.arpa IN NS in-addr.arpa IN NS zape.fi.upm.es. chita.fi.upm.es. galileo.ccupm.upm.es. tarzan.fi.upm.es. ns.fi.upm.es. Sistemas Distribuidos 11 Fernando Pérez Costoya RR de tipo NS para delegación Segundo uso: delegar subdominio a s.nombres (pto. montaje) Aparece como nombre del RR el del subdominio Lista subdominios delegados no se puede obtener mediante consulta Ejemplo: UPM delega administración de sus recursos DNS a FI: fichero de zona de upm.es. debe incluir: fi.upm.es IN NS chita.fi.upm.es. fi.upm.es IN NS zape.fi.upm.es. fi.upm.es IN NS tarzan.fi.upm.es. fi.upm.es IN NS galileo.ccupm.upm.es. fi.upm.es IN NS ns.fi.upm.es. fichero de zona de in-addr.arpa. debe incluir: in-addr.arpa IN NS zape.fi.upm.es in-addr.arpa IN NS chita.fi.upm.es in-addr.arpa IN NS galileo.ccupm.upm.es in-addr.arpa IN NS tarzan.fi.upm.es in-addr.arpa IN NS ns.fi.upm.es. Problema: delegación y CIDR (no lo tratamos) Sistemas Distribuidos 12 Fernando Pérez Costoya

3 Ejemplo hipotético Empresa con sede central y tres departamentos Un administrador gestiona sede central, dep1 y dep2 Dep3 con administrador propio (y servidor de correo propio) Detalles de servidores de nombres de cada dominio: Sede central de la empresa (emp.es.): 2 s. de nombres maestro en dominio (ns.emp.es.);esclavo externo (ns.isp.com.) Dep1 (dep1.emp.es.): subdominio no delegado Dep2 (dep2.emp.es.): subdominio delegado a mismos servidores Dep3 (dep3.emp.es.): 3 s. de nombres Maestro (ns1.dep3.emp.es.); esclavo interno (ns2) y externo (ns.isp.com.) Empresa tiene asignada red clase B central; dep1; dep2; dep3 Sólo está delegado subdominio de Sistemas Distribuidos 13 Fernando Pérez Costoya F. zona emp.es. (ns.emp.es.) emp.es. IN SOA ns.emp.es. emp.es IN NS ns.emp.es. ; servidor maestro del dominio emp.es IN NS ns.isp.com. ; servidor esclavo externo ; dep2 delegado a mismos servidores dep2.emp.es IN NS ns.emp.es. ; servidor maestro en el dominio padre dep2.emp.es IN NS ns.isp.com. ; servidor esclavo externo ; dep3 delegado a servidor maestro en el subdominio dep3.emp.es IN NS ns1.dep3.emp.es. ; servidor maestro en su propio subdominio dep3.emp.es IN NS ns2.dep3.emp.es. ; servidor esclavo en su propio subdominio dep3.emp.es IN NS ns.isp.com. ; servidor esclavo externo emp.es IN MX 10 mail1.emp.es. ; servidor de correo preferente para la empresa emp.es IN MX 20 mail2.emp.es. ; servidor de correo de reserva para la empresa dep1.emp.es IN MX 10 mail1.emp.es. ; servidor de correo preferente para dep1 dep1.emp.es IN MX 20 mail2.emp.es. ; servidor de correo de reserva para dep1 ; Máquinas en el dominio de la empresa ns.emp.es IN A mail1.emp.es IN A mail2.emp.es IN A IN A IN A ; RR de subdominio no delegado en misma zona ; Glue records para subdominio dep3 ns1.dep3.emp.es IN A ns2.dep3.emp.es IN A Sistemas Distribuidos 14 Fernando Pérez Costoya F. zona dep2.emp.es. (ns.emp.es.) dep2.emp.es. IN SOA ns.emp.es. dep2.emp.es IN NS ns.emp.es. ; servidor maestro del dominio (=padre) dep2.emp.es IN NS ns.isp.com. ; servidor esclavo externo ; Correo dep2.emp.es IN MX 10 mail1.emp.es. ; s. correo preferente para dep2 dep2.emp.es IN MX 20 mail2.emp.es. ; s. correo de reserva para dep2 ; Máquinas en el dominio de dep IN A backup.dep2.emp.es IN CNAME F. zona dep3.emp.es. (ns.dep3.emp.es.) dep3.emp.es. IN SOA ns1.dep3.emp.es. dep3.emp.es IN NS ns1.dep3.emp.es.; servidor maestro del dominio (!=padre) dep3.emp.es IN NS ns2.dep3.emp.es.; servidor esclavo en el propio dominio dep3.emp.es IN NS ns.isp.com. ; servidor esclavo externo ; Correo dep3.emp.es IN MX 10 mail.dep3.emp.es. ; s. correo preferente para dep3 dep3.emp.es IN MX 20 mail2.emp.es. ; s. correo de reserva para dep3 ; Máquinas en el dominio de dep3 ns1.dep3.emp.es IN A ns2.dep3.emp.es IN A mail.dep3.emp.es IN A IN A ; reparto de carga en servicio web IN A ; reparto de carga en servicio web Sistemas Distribuidos 15 Fernando Pérez Costoya Sistemas Distribuidos 16 Fernando Pérez Costoya F. zona (ns.emp.es.) in-addr.arpa. IN SOA ns.emp.es in-addr.arpa IN NS ns.emp.es in-addr.arpa IN NS ns.isp.com. ; dir. IP de dep3 delegadas a servidor maestro en el subdominio (no se necesitan glue records) in-addr.arpa IN NS ns1.dep3.emp.es in-addr.arpa IN NS ns2.dep3.emp.es in-addr.arpa IN NS ns.isp.com. ; Máquinas de sede central, dep1 y dep in-addr.arpa IN PTR ns.emp.es in-addr.arpa IN PTR mail1.emp.es in-addr.arpa IN PTR mail2.emp.es in-addr.arpa IN PTR in-addr.arpa IN PTR in-addr.arpa IN PTR F. zona (ns.dep3.emp.es.) in-addr.arpa. IN SOA ns1.dep3.emp.es in-addr.arpa IN NS ns1.dep3.emp.es in-addr.arpa IN NS ns2.dep3.emp.es in-addr.arpa IN NS ns.isp.com. ; Máquinas de dep in-addr.arpa IN PTR ns1.dep3.emp.es in-addr.arpa IN PTR ns2.dep3.emp.es in-addr.arpa IN PTR mail.dep3.emp.es in-addr.arpa IN PTR in-addr.arpa IN PTR Sistemas Distribuidos 17 Fernando Pérez Costoya Sistemas Distribuidos 18 Fernando Pérez Costoya

4 Glue records Posibles círculos viciosos en la traducción de nombres Si s. nombres de subdominio (Ssub) pertenece a subdominio En el ejemplo: ns1.dep3.emp.es. y ns2.dep3.emp.es. Para obtener IP de cualquier máq. subdominio contactar con Ssub IP de contactar con ns1.dep3.emp.es. Pero para hacerlo necesito IP de Ssub contactar con Ssub IP de ns1.dep3.emp.es.? contactar ns1.dep3.emp.es. Glue record (GR) RR de tipo A/AAAA que se incluye en un dominio ajeno Solución c. vicioso: padre debe incluir RR tipo A con dir. IP de Ssub Aumenta problemas de coherencia Cambios en IP de Ssub deben reflejarse también en dominio padre No necesario glue record para servidor externo o en dominio padre Siempre se puede obtener su traducción Sistemas Distribuidos 19 Fernando Pérez Costoya Ejercicio: delegaciones en UPM dig upm.es. SOA upm.es IN SOA einstein.ccupm.upm.es. hostmaster.upm.es dig etsia.upm.es. SOA etsia.upm.es IN SOA einstein.ccupm.upm.es. hostmaster.upm.es dig fi.upm.es. SOA fi.upm.es IN SOA chita.fi.upm.es. hostmaster.fi.upm.es dig datsi.fi.upm.es. SOA datsi.fi.upm.es IN SOA chita.fi.upm.es. hostmaster.fi.upm.es dig dlsiis.fi.upm.es. SOA No hay respuesta Analizar qué delegaciones existen dónde se necesitan glue records? Sistemas Distribuidos 20 Fernando Pérez Costoya Servidores de nombres raíces Hay 13 servidores de dominio raíz (.) replicados Desde a.root-servers.net hasta m.root-servers.net 13 porque esa información cabe en paquete UDP DNS usa UDP (53); y sólo TCP(53) cuando tamaño lo aconseja Problemas de escalabilidad? Detrás de cada uno hay múltiples servidores (uso de anycast) Incluyen NS y glue records de dominios de nivel 1º (TLDs) Aunque también gestionan algunos dominios de primer nivel arpa. Cada serv. DNS tiene dir. de servidores raíz (fichero root.servers) Se debe actualizar periódicamente Lista y localización: Sistemas Distribuidos 21 Fernando Pérez Costoya Servidores DNS Servidor gestiona (authoritative) N ( 0) zonas directas/inversas De algunas puede ser maestro de otras esclavo Servidor DNS puede tener doble rol (algo confuso): Proporciona acceso a sus zonas Puede actuar como cliente en navegación recursiva Servidor debe ofrecer navegación iterativa; recursiva opcional Si no ofrece recursiva (no caché) sólo acceso a sus zonas Recursiva (caché) por seguridad sólo peticiones de ciertas máquinas Ejemplos de diversos tipos de servidores de nombres: Servidor sólo caché (nonauthoritative), recursivo para clientes internos Sirve a clientes de una organización actuando de proxy Servidor authoritative y recursivo sólo para clientes internos Sirve a clientes de una organiz. y da acceso a sus zonas a todo el mundo Servidor authoritative no recursivo p.e. servidor raíz o de TLD Sistemas Distribuidos 22 Fernando Pérez Costoya Resolver Parte cliente de DNS: da servicio a aplicaciones en un nodo Implementado habitualmente como biblioteca ( en libc) Proporciona API para traducción directa e inversa: UNIX: gethostbyname/getaddrinfo y gethostbyaddr/getnameinfo Configurado con servidores de nombres a los que consulta Requiere también las direcciones IP de todos esos s. de nombres En UNIX: /etc/resolv.conf Esos servidores de nombres deben ser recursivos Resolver no sabe navegar Puede usar caché (las aplicaciones también) UNIX permite configurar mecanismo de traducción de hosts /etc/hosts, DNS, NIS, LDAP (/etc/nsswitch.conf) Sistemas Distribuidos 23 Fernando Pérez Costoya Resolución de consultas Servidor S recibe una consulta C de N: Compara con RRs de todas sus zonas y de su caché (si usa) Selecciona mejor encaje RR (RRX) que sea sufijo más largo de C Si encaje completo envía a N consuelta resuelta La marca como authoritative si no proviene de la caché Si varios RRs satisfacen consulta, se envía a N lista con todos Servidor rota la lista cada vez (Round-robin DNS) para reparto de carga Se incluye información adicional para agilizar la operación P.e. consulta MX puede retornar los RRs de tipo A de servidores de correo Si encaje no completo, RRX NSs de dominio por donde continuar En el peor caso, los NSs de servidores raíz Si op. recursiva: S envía consulta a uno de los NSs encontrados Si op. no recursiva: S envía a N los RRs de los NSs encontrados Si S conoce direcciones de NSs encontrados Si no recursiva: las incluye como info. adicional en mens. de respuesta a N Si recursiva: S las usa para contactar; sino tiene que obtenerlas Sistemas Distribuidos 24 Fernando Pérez Costoya

5 Ejemplos reales de traducción Operación de traducción directa: Operación de traducción inversa: Resolver tiene configurado como SN (3 opciones): SN1: ns.miempresa.com.; IP Zonas gestionadas: miempresa.com. y in-addr.arpa., SN2: einstein.ccupm.upm.es.; IP Zonas gestionadas: upm.es. y in-addr.arpa., SN3: zape.fi.upm.es.; IP Zonas gestionadas: fi.upm.es. y in-addr.arpa., Supuestos: traducción recursiva resolver-sn e iterativa desde SN cachés vacías Sistemas Distribuidos 25 Fernando Pérez Costoya Traducción directa usando SN1 Aplicación llama a gethostbyname( ) de resolver Resolver envía petición DNS de tipo A a dir. de SN1: SN1 mejor encaje:. elige un s. raíz: a.root-servers.net. ( ) a.root-servers.net. mejor encaje: es. envía a SN1 los NSs de es. Y sus glue records como información adicional SN1 elige a.nic.es. ( ) a.nic.es. mejor encaje: upm.es. envía a SN1 los NSs de upm.es. Y sus glue records como información adicional SN1 elige einstein.ccupm.upm.es. ( ) einstein.ccupm.upm.es. mejor encaje: fi.upm.es. envía a SN1 los NSs de fi.upm.es. y sus glue records SN1 elige zape.fi.upm.es. ( ) zape.fi.upm.es. Encaje completo: envía a SN1 el NS de tipo A SN1 se lo envía al resolver y éste retorna la IP a la aplicación Sistemas Distribuidos 26 Fernando Pérez Costoya Traducción directa usando SN2 y SN3 Aplicación llama a gethostbyname( ) de resolver Resolver envía petición DNS de tipo A a dir. de SN2: SN2 mejor encaje: fi.upm.es. elige zape.fi.upm.es. ( ) zape.fi.upm.es. encaje completo: envía a SN2 el NS de tipo A ( ) SN2 se lo envía al resolver y éste retorna la IP a la aplicación Aplicación llama a gethostbyname( ) de resolver: Resolver envía petición DNS de tipo A a dir. de SN3: SN3 encaje completo: ( ) SN3 se lo envía al resolver y éste retorna la IP a la aplicación Traducción inversa usando SN1 Aplicación llama a gethostbyaddr( ) de resolver Resolver envía PTR in-addr.arpa. a SN1: SN1 mejor encaje:. elige un s. raíz: a.root-servers.net. ( ) a.root-servers.net. mejor encaje: in-addr.arpa. envía a SN1 los NSs de in-addr.arpa. y sus glue records SN1 elige a.in-addr-servers.net. ( ) a.in-addr-servers.net. mejor encaje: 138.in-addr.arpa. envía a SN1 los NSs de 138.n-addr.arpa. (no sus glue records) SN1 elige r.arin.net. tiene que hacer la traducción directa completa No se muestra el detalle por ya conocido; Obtiene r.arin.net. mejor encaje: in-addr.arpa. envía a SN1 los NSs de 138.n-addr.arpa. (no sus glue records) Sistemas Distribuidos 27 Fernando Pérez Costoya Sistemas Distribuidos 28 Fernando Pérez Costoya Traducción inversa usando SN1 (cont.) SN1 elige einstein.ccupm.upm.es. necesita trad. directa completa No se muestra el detalle por ya conocido; Obtiene einstein.ccupm.upm.es. mejor encaje: in-addr.arpa. envía a SN1 los NSs de 138.n-addr.arpa. y sus glue records SN1 elige zape.fi.upm.es. ( ) zape.fi.upm.es. encaje completo: in-addr.arpa. envía a SN1 el NS de tipo PTR in-addr.arpa SN1 se lo envía al resolver y éste retorna nombre del host a la aplicación Traducción inversa usando SN2 y SN3 Aplicación llama a gethostbyaddr( ) de resolver Resolver envía PTR in-addr.arpa. a SN2: SN2 mejor encaje: in-addr.arpa. elige zape.fi.upm.es. zape.fi.upm.es. encaje completo: in-addr.arpa. envía a SN2 el NS de tipo PTR in-addr.arpa SN2 se lo envía al resolver y éste retorna nombre del host a la aplicación Aplicación llama a gethostbyaddr( ) de resolver Resolver envía PTR in-addr.arpa. a SN3: SN3 encaje completo: in-addr.arpa in-addr.arpa SN3 se lo envía al resolver y éste retorna nombre host a la aplicación Sistemas Distribuidos 29 Fernando Pérez Costoya Sistemas Distribuidos 30 Fernando Pérez Costoya

6 Mantenimiento de info. de zona Sincronización de esclavo Esclavo pide info. zona a maestro Periódicamente (tal como lo especifica SOA) O cuando maestro avisa de cambios (NOTIFY) Si cambio: transferencia zona completa (AXFR) o incremental (IXFR) Sólo se debe permitir transferencia de zona entre maestro y esclavos Actualización de DNS: Cambio en fichero zona, incrementa nº en SOA y aviso a maestro Dynamic DNS: Protocolo DNS incluye ops. para actualizar zona Añadir, modificar y borrar RR pero no crear nuevas zonas Mucho más flexible pero menos seguro Algunas aplicaciones: Permitir que máquinas mantengan mismo nombre en sistemas con DHCP Servidor elige cualquier puerto y usa SRV (requerido por Active Directory) Sistemas Distribuidos 31 Fernando Pérez Costoya Objetos y clases Entidad Objeto (entrada) en LDAP Orientado a objetos: Objeto Clase (atributo objectclass) Clase define conjunto de atributos del objeto Tipo del atributo obligatorio(ob) u optativo(op) valor único o múltiple Herencia: clases forman una jerarquía (top raíz de jerarquía) Clase derivada hereda atributos de superclases Tipos de clases: Abstracta (AB): no pueden definirse objetos de esa clase (p.e. top) Estructural (ES): Objeto Una y solo una clase estructural No puede cambiar la clase estructural de un objeto Auxiliar (AU): Objeto puede estar asociado a varias clases auxiliares Pueden añadirse dinámicamente: Facilitan extensión de objetos Superclase(ES)=ES AB; Superclase(AU)=AU AB Sistemas Distribuidos 32 Fernando Pérez Costoya Ejemplos de clases top: raíz; AB; ob: objectclass person: top; ES; ob: cn, sn; op: telephonenumber,... residentialperson: person; ES; ob: l; op: postaladdress,... organization: top; ES; ob: o; op: postaladdress,... organizationalunit: top; ES; ob: ou; op: postaladdress,... dcobject: top; AU; ob: dc (valor único) device: top; ES; ob: cn; op: serialnumber, o, ou, owner,... groupofnames: top; ES; ob: cn, member; op: o, ou,... alias: top; ES; ob: aliasedobjectname referral: top; ES; ob: ref Sistemas Distribuidos 33 Fernando Pérez Costoya Extracto de mi entrada en LDAP de FI Formato de texto LDIF (LDAP Data Interchange Format): protocolo LDAP es binario objectclass: estructural (top person organizationalperson ) objectclass: posixaccount auxiliar (top posixaccount) objectclass: fiemployee auxiliar (top irisperson fiperson fiemployee) objectclass: sambasamaccount auxiliar (top sambasamaccount ) cn: Fernando Perez Costoya cn: F. P. Costoya sn: Perez Costoya person organizationalperson telephonenumber: mail: fperez@fi.upm.es uid: fperez uidnumber:... posixaccount gidnumber:... irisuserstatus: Activo irisperson firelationship: pdi fiperson fiemployee fiteaching:... sambasid:... sambasamaccount Sistemas Distribuidos 34 Fernando Pérez Costoya Extracto de entrada FI en LDAP de FI objectclass: dcobject auxiliar (top dcobject) objectclass: organization estructural (top organization) objectclass: labeleduriobject auxiliar (top labeleduriobject) dc: fi atributo específico de dcobject o:: RmFjdWx0YWQgZGUgSW5mb3Jtw6F0aWNhIC0gVVBN postalcode: l: Boadilla del Monte st: Madrid labeleduri: atributo específico de labeleduriobject telephonenumber: Decodificación de base 64 o: Facultad de Informática UPM Sistemas Distribuidos 35 Fernando Pérez Costoya Modelo de nombres Entrada tiene un nombre: Relative Distinguished Name (RDN) 1 o más atributos de la entrada que la hacen única entre hermanos uid=fperez (ej. múltiples: cn=fernando Perez Costoya+dni= ) Jerarquía de nombres (Directory Information Tree, DIT) Nombre completo (path): Distinguished Name (DN) RDN de la entrada + DN del padre (separados por comas) dn: uid=fperez,ou=personal,dc=fi,dc=upm,dc=es No confundir con jerarquía de clases Similar a SF pero directorios también tienen información asociada Nombre del objeto raíz (sufijo o base): a discreción Convenio: a partir de dominio DNS usando clase auxiliar dcobject Dominio:fi.upm.es dn: dc=fi,dc=upm,dc=es Servidor LDAP gestiona 1 ó más DIT Servidor devuelve metainformación en objetos/atrib. operacionales DIT gestionados por el servidor, esquemas soportados,... Sistemas Distribuidos 36 Fernando Pérez Costoya

7 Extracto de rama del DIT del LDAP de FI dc: fi objectclass: dcobject objectclass: organization o:: RmFjdWx0YWQgZGUgSW5mb3Jtw6F0aWNhIC0gVVBN postalcode: l: Boadilla del Monte st: Madrid... objectclass: objectclass: posixaccount cn: Fernando Perez Costoya cn: F. P. Costoya sn: Perez Costoya telephonenumber: mail: roomnumber: 4201 departmentnumber: DATSI uid: fperez... dn: ou=personal,dc=fi,dc=upm,dc=es dn: dc=fi,dc=upm,dc=es ou: personal objectclass: organizationalunit dn: uid=fperez,ou=personal,dc=fi,dc=upm,dc=es Sistemas Distribuidos 37 Fernando Pérez Costoya Diseño del DIT No trivial: requiere experiencia Análisis previo de info. del SD y cómo evolucionará Diseño debería evitar que cambios previstos en info. modifiquen DIT Cambio debería afectar a atributos en vez de a estructura de DIT Mejor árbol poco profundo Ej.: empresa donde personal cambia de dpto. con frecuencia Diseño 1 1 organizationalunit/dpto. + 1 /persona Entrada de persona hija de entrada de su departamento Diseño 2 1 organizationalunit para todo el personal + 1 /persona 1 groupofnames/dpto. con 1 atributo member/persona Persona cambia de departamento: cambio atributos, no cambio DIT Aunque ciertas búsquedas pueden ralentizarse Sistemas Distribuidos 38 Fernando Pérez Costoya Diseño 1 Diseño 2 Empresa organization Empresa organization Dpto1 organizationalunit Dpto2 organizationalunit Dpto3 organizationalunit Personal organizationalunit Dpto1 groupofnames member: pers1 member: pers2 Dpto2 groupofnames member: pers3 Dpto3 groupofnames member: pers4 pers1 pers2 pers3 pers4 pers1 pers2 pers3 pers4 Sistemas Distribuidos 39 Fernando Pérez Costoya Sistemas Distribuidos 40 Fernando Pérez Costoya Operaciones de LDAP Bind/Unbind: conecta y autentica/desconecta Search: realiza una búsqueda basada en los parámetros: DN base de la búsqueda Ámbito: Sólo la entrada base, sólo hijos o todo el sub-árbol Filtro de búsqueda Atributos que se devuelven (además, si valores o sólo tipos) Si se siguen los alias o no durante la búsqueda Límite de tiempo y máximo nº de entradas retornadas Compare: comprueba si DN dado tiene un valor en atributo Add/Delete: Añade/Elimina la entrada del DN dado Modify: Modifica atributos (añade, elimina o cambia) de un DN Modify DN: Cambia DN de una entrada Renombra si sólo cambia RDN final; mueve en DIT en caso contrario Sistemas Distribuidos 41 Fernando Pérez Costoya Ejemplos de búsquedas (en triqui) Leer mi entrada ldapsearch -x -W -H ldaps://info.fi.upm.es -D 'uid=fperez,ou=personal,dc=fi,dc=upm,dc=es -b 'uid=fperez,ou=personal,dc=fi,dc=upm,dc=es' Nombre de profesores que comparten un despacho dado ldapsearch -x -W -H ldaps://info.fi.upm.es -D 'uid=fperez,ou=personal,dc=fi,dc=upm,dc=es' -b 'ou=personal,dc=fi,dc=upm,dc=es' '(roomnumber=4201)' cn sn Nº tel. de personal de nombre Fernando y no sean del DATSI ldapsearch -x -W -H ldaps://info.fi.upm.es -D 'uid=fperez,ou=personal,dc=fi,dc=upm,dc=es' -b 'ou=personal,dc=fi,dc=upm,dc=es' '(&(!(departmentnumber=datsi))(cn=*fernando*))' cn telephonenumber Nombre de secciones de la FI ldapsearch -x -W -H ldaps://info.fi.upm.es -D 'uid=fperez,ou=personal,dc=fi,dc=upm,dc=es' -b 'dc=fi,dc=upm,dc=es' -s one '(objectclass=organizationalunit)' ou Sistemas Distribuidos 42 Fernando Pérez Costoya

8 Ejercicio de DNS Considere un consorcio internacional (dominio DNS con.com.) formado por 2 empresas (emp1.con.com. y emp2.con.com.), cada una de las cuales está organizada en 2 sucursales (suc1.empx.con.com. y suc2.empx.con.com.) y éstas a su vez en 2 departamentos (dep1.sucy.empx.con.com. y dep2.sucy.empx.con.com.). Supóngase que los servidores de nombres de cada dominio son máquinas de ese dominio. Al servicio web del consorcio se accede a través de El servicio web realmente es proporcionado por varias máquinas incluidas en el dominio dep1.suc1.emp1.con.com., todas con el nombre web.dep1.suc1.emp1.con.com.. Además, el consorcio ha adquirido los dominios con.fr. y con.es. para permitir a los clientes de esos dos países el acceso al mismo servicio web mediante y respectivamente. 1. En cuántos dominios del consorcio será necesario incluir glue records? a. 7 b. 9 c. 15 d. 17 Un dominio necesita glue records para hacer referencia a los servidores de nombres de sus dominios hijos (siempre que éstos estén incluidos dentro de los los mismos, lo que suele ser habitual). Hay 7 dominios que tienen hijos (1 el del consorcio, 2 los de las empresas y 4 los de las sucursales) y, por tanto, los 7 requieren glue records. 2. En cuántos dominios del consorcio será necesario incluir registros de tipo CNAME para proporcionar el servicio de web descrito? a. 3 b. 1 c. 2 d. 4 Hacen falta 3 registros CNAME para que las tres URLs mediante las cuales se accede al servicio hagan referencia a las máquinas que proporcionan realmente el servicio (mostradas de forma simplificada): CNAME web.dep1.suc1.emp1.con.com. CNAME web.dep1.suc1.emp1.con.com. CNAME web.dep1.suc1.emp1.con.com. 3. Suponiendo todas las cachés de traducción vacías, un cliente solicita la traducción del nombre ftp.suc2.emp2.con.com.. Cuál de los siguientes servidores de nombres debería tener configurado el cliente como servidor DNS local para que fuera más eficiente la traducción? a. ns1.con.com. b. ns1.dep2.suc2.emp2.con.com. c. ns1.suc1.emp2.con.com. d. ns1.emp1.con.com. En cuanto a las búsquedas estando la caché vacía, hay que tener en cuenta que la única manera de evitar tener que buscar desde la raíz es que el servidor de nombres que tenemos configurado como DNS local sea del mismo dominio que el nombre a buscar o un antecesor del mismo: padre, abuelo (que es la respuesta correcta en esta pregunta), etc. Supongamos, por ejemplo, que buscamos ftp.suc2.emp2.con.com.. usando como DNS local el servidor de nombres de un dominio hijo ns1.dep2.suc2.emp2.con.com. Cuando realiza la comparación, este servidor DNS no incluye ninguna entrada que sea un sufijo completo del nombre a buscar. Por tanto, tiene que empezar por el dominio raíz. 4. En los diversos dominios del consorcio hay parejas de RR relacionadas entre sí. Para cuál de las siguientes sería más razonable especificar un TTL más bajo? a. 2 registros A que asocian el mismo nombre a distinta IP. b. 2 registros A que asocian distintos nombres a la misma IP. c. un registro A y un CNAME que le hace referencia. d. un registro A y un MX que le hace referencia. Especificar que un mismo nombre tienes varias IPs (varias máquinas) se hace habitualmente para lograr un reparto de carga entre dichas máquinas. Es conveniente en ese caso poner un TTL bajo (como en el ejemplo de Google en la primera transparencia de DNS) para que un cliente no vaya siempre a la misma máquina debido a la información que hay en las cachés. 5. El administrador DNS del consorcio se plantea usar un registro SRV para definir un nuevo servicio ya que permite ocultar al cliente diversos parámetros del servicio. Cuál de los siguientes parámetros del servicio no queda oculto para el cliente? a. el protocolo TCP o UDP. b. el puerto de servicio. c. cómo se reparten las máquinas especificadas las peticiones. d. qué máquinas entran a dar servicio en caso de caídas de otras máquinas. Un registro SRV permite especificar qué máquinas, y por qué puertos, se proporciona un determinado servicio, pudiendo definirse tanto la prioridad de las máquinas como el reparto de carga entre las mismas. El cliente que consulta debe definir de qué servicio se trata (nivel de aplicación) y qué protocolo de transporte quiere usar (TCP UDP). Por tanto, este último aspecto (TCP UDP) no es transparente. 6. Suponga que en una empresa (dominio emp.com) se crean dos nuevos departamentos (dominios dep1.emp.com y dep2.emp.com), tal que el primero tendrá su propio servicio DNS mientras que el segundo será gestionado por el servicio general de la empresa. Para qué departamento puede ser necesario incluir glue records en el servicio general de la empresa? a. Sólo para el primero. b. Sólo para el segundo. c. Para ninguno. d. Para ambos. Sólo se pueden necesitar glue records en el dominio de la empresa para el primer departamento. En caso de que alguno de los servidores de nombres del dominio del primer departamento esté incluido en el propio dominio, que es lo habitual, deberá incluirse un glue record (un RR de tipo A con la traducción de dicho servidor de nombres) por cada uno de ellos. 7. Suponga que en una empresa organizada en tres niveles (empresa, sucursales y departamentos) existen direcciones de correo en el nivel de empresa (usu@emp.com) y en el de sucursal (usu@suc3.emp.com), pero no en el de departamento. Sin embargo, las dos máquinas que sirven el correo para toda la organización pertenecen a un determinado departamento (m1.dep1.suc1.emp.com y m2.dep1.suc1.emp.com). Cuántos registros MX deberán incluirse en ese departamento? a. 0 b. 2 c. 4 d. 6 Los registros MX hay que incluirlos en el dominio que corresponde al destino del correo. Dado que el departamento no va serlo, no habrá que incluir ningún RR de este tipo en ese dominio, aunque las máquinas especificadas para recibir el correo sí estén incluidas en ese dominio. 8. En una empresa, actualmente, se usa una única máquina para los servicios de ftp, backup y web. A medio plazo, se mantendrá esta asignación de una sola máquina, aunque durante ese periodo puede cambiar la máquina (nueva IP). A largo plazo, cuando se consiga una segunda máquina, ésta se dedicará en exclusiva al servicio web. Qué disposición de RR (simplificados) minimizará el impacto de los cambios (menos RR añadidos, eliminados o modificados) tanto a medio como a largo plazo? a. web CNAME ftp; ftp CNAME backup; backup A IP

9 b. ftp CNAME web; web CNAME backup; backup A IP c. backup CNAME ftp; ftp CNAME web; web A IP d. backup CNAME web; web CNAME ftp; ftp A IP El resultado que se pretende obtener es: web A IP2; ftp CNAME backup; backup A IP o, de forma equivalente, web A IP2; backup CNAME ftp; ftp A IP. Analicemos cuántas operaciones se necesitan para cada opción: 1. Habría que eliminar el primer CNAME e incorporar un RR de tipo A que asociará al servidor web la dirección de la nueva máquina. Total: 2 operaciones. 2. Habría que eliminar los dos primeros CNAME, incorporar un RR de tipo A que asociará al servidor web la dirección de la nueva máquina, y un CNAME que haga corresponder el servidor ftp y el de backup. Total: 4 operaciones. 3. Habría que eliminar el segundo CNAME y el RR de tipo A e incorporar un RR de tipo A que asociará al servidor web la dirección de la nueva máquina y otro que vinculará el servidor ftp con la dirección IP de la máquina original. Total: 4 operaciones. 4. Habría que eliminar los dos primeros CNAME, incorporar un RR de tipo A que asociará al servidor web la dirección de la nueva máquina, y un CNAME que haga corresponder el servidor backup y el de ftp. Total: 4 operaciones. 9. Para dar un determinado servicio se van a usar 3 máquinas. La primera dará servicio por el puerto y sólo lo hará cuando las otras dos estén caídas. La segunda máquina recibirá la mitad de las peticiones y usará el puerto La tercera ofrecerá servicio por los puertos y 33333, una cuarta parte del total por cada uno. Cuántos registros SRV serán necesarios para ese configuración? a. 4 b. 2 c. 3 d. 5 A continuación, se muestran, de forma simplificada, los cuatro RRs de tipo SRV requeridos: _serv._tcp.ej.com. SRV m1 _serv._tcp.ej.com. SRV m2 _serv._tcp.ej.com. SRV m3 _serv._tcp.ej.com. SRV m3 10. Cuando en Windows se activa el servicio Active Directory en una máquina, ésta selecciona un puerto libre para dar servicio LDAP y se configura automáticamente sin intervención del administrador. Qué mecanismo de DNS permite este modo de operación? a. Dynamic DNS b. NOTIFY c. IXFR d. Round-robin DNS Ese mecanismo requiere poder añadir nuevos RR a un dominio sin necesidad de editar el fichero de zona correspondiente. Esa extensión del DNS se conoce como Dynamic DNS. Por otro lado, la operación NOTIFY sireve para que un maestro notifique a un esclavo que se ha modificado una zona y la operación IXFR permite que el esclavo pueda solicitar el volcado, de manera incremental, de los datos de una zona. Por último, bajo el término Round-robin DNS se hace referencia a que un servidor DNS, cuando retorna la lista de RRs que satisfacen una consulta, va rotando el orden de los elementos en la lista para favorecer de esta forma el reparto de carga. 11. Considere una empresa organizada en tres niveles DNS (empresa, sucursales y departamentos) con servidores autónomos en cada nivel. Suponga que un cliente tiene configurado como servidor DNS el correspondiente a una determinada sucursal (ns1.suc1.emp.com) y que están activos todos los servidores de la empresa pero no hay en este instante ningún tipo de comunicación con el resto de Internet. Suponiendo vacías todas las posibles caches de traducción, de cuántos de estos dominios (emp.com, dep2.suc1.emp.com, suc2.emp.com y dep1.suc2.emp.com) podría el cliente, manteniendo su configuración actual, obtener traducción de los nombres de máquinas incluidas en el mismo?: a. 1 b. 2 c. 3 d. 4 Sólo se podrían obtener traducciones de los recursos que pertenecen al dominio gestionado por ese servidor (suc1.emp.com.) o sudominios del mismo. Por tanto, de los cuatro dominios propuestos en el enunciado, sólo podría accederse a recursos del dominio dep2.suc1.emp.com al ser hijo del dominio gestionado por el servidor de nombres que tiene configurado el cliente. Ejercicio de LDAP Se plantea diseñar el servicio LDAP para una empresa (dominio DNS emp.com.) organizada en sucursales (dominio DNS sucx.emp.com. para la sucursal X), que están a su vez estructuradas en departamentos (dominio DNS depy.sucx.emp.com. para el departamento Y de la sucursal X). Por las características de la empresa se conoce a priori que los empleados de esta empresa nunca van a cambiar de departamento ni de sucursal. Por otro lado, en el día a día de la empresa se va a necesitar muy frecuentemente información de todos los empleados de la empresa que pertenezcan a la categoría de supervisores (un porcentaje muy pequeño dentro del total), con independencia de la sucursal y el departamento al que estén vinculados, siendo, además, relativamente habitual que un empleado adquiera la categoría de supervisor e igualmente que la pierda. 1. Qué clases estructurales usaría para las sucursales (Suc), los departamentos (Dep) y los empleados en la categoría de supervisores (Sup)? a. Suc: organizationalunit; Dep: organizationalunit; Sup: groupofnames. b. Suc: groupofnames; Dep: organizationalunit; Sup: organizationalunit. c. Suc: organizationalunit; Dep: groupofnames; Sup: organizationalunit. d. Suc: organizationalunit; Dep: groupofnames; Sup: groupofnames. Como no se esperan cambios de personal entre departamentos ni sucursales, usamos OU para ambas. Para los supervisores, donde va a haber más dinamismo, utilizamos groupofnames. 2. Suponiendo que sólo hemos incluido la clase dcobject en el objeto que representa la empresa y en los correspondientes a los departamentos, cómo sería el DN del departamento Y de la sucursal X? a. dc=depy,ou="sucursal X",dc=emp,dc=com b. dc=depy,dc=sucx,dc=emp,dc=com c. ou="departamento Y",ou="sucursal X",dc=emp,dc=com d. ou="departamento Y",dc=sucX,dc=emp,dc=com Dado que sólo hay dcobject en el nivel de empresa y de departamento, el DN usaría para la sucursal el OU. 3. Qué operación de LDAP se usaría para cambiar a un empleado de departamento dentro de la misma sucursal y cuál para hacer que un empleado obtuviera la categoría de supervisor, respectivamente? a. Modify DN y Modify. b. Modify y Modify DN. c. Modify DN en ambos casos. d. Modify en ambos casos. Dado que los departamentos están representados por OU y los supervisores por GroupOfNames, el primer cambio requiere un Modify DN mientras que para el segundo es suficiente un Modify. 4. Considere que se necesitan realizar las siguientes búsquedas: (1) todos los datos de un determinado departamento de una determinada sucursal; (2) todos los datos del departamento de la empresa que tiene un determinado número de teléfono; (3) todos los datos del departamento de una determinada sucursal que tiene un cierto número de teléfono. Qué ámbito se especificaría (base, one o el valor por defecto) en cada una de las tres operaciones si se pretende minimizar el número de nodos afectados por la misma? a. (1) base; (2) por defecto; (3) one;

10 b. (1) one; (2) base; (3) por defecto; c. (1) por defecto; (2) one; (3) base; d. (1) base; (2) por defecto; (3) por defecto; Búsqueda (1): accede directamente a un nodo (base) Búsqueda (2): tiene que recorrer todos los departamentos de todas las sucursales de la empresa (por defecto: búsqueda en todo el subárbol) Búsqueda (3): es suficiente con buscar en todos los departamentos de una determinada sucursal (one). 5. Qué es falso con respecto al RDN de un objeto? a. Sólo puede corresponder con atributos de la clase estructural del objeto. b. Debe ser único entre objetos hermanos. c. Puede estar formado por múltiples atributos del objeto. d. Es el componente final del DN del objeto. El RDN de un objeto es la parte final (el último componente) del DN que hace referencia a dicho objeto y tiene que ser único entre todos los objetos hijos del mismo objeto padre. El valor del RDN se corresponde con uno o más atributos del objeto que le hacen único entre sus hermanos pudiendo corresponer a atributos de la clase estructural pero también de las clases auxiliares a las que esté asociado el objeto. Así, por ejemplo, es habitual que el objeto que representa una organización use como RDN el atributo dc. 6. Un esquema donde los nodos de los empleados de la empresa cuelguen de nodos que representan equipos de trabajo (pequeña agrupación de empleados del mismo departamento que trabajan juntos) en vez de nodos de departamentos, qué implica? a. Un árbol más profundo y, por tanto, más sensible a los cambios en la empresa. b. Un árbol más profundo y, por tanto, menos sensible a los cambios en la empresa. c. Un árbol menos profundo y, por tanto, más sensible a los cambios en la empresa. d. Un árbol menos profundo y, por tanto, menos sensible a los cambios en la empresa. Es un árbol más profundo ya que implica un nivel más (equipos de trabajo que cuelgan de departamentos) lo que trae como consecuencia que sea más sensible a los cambios en la organización de la empresa. 7. En el nodo correspondiente a cada departamento de una empresa, cuelgan los nodos de empleados e impresoras asociados a ese departamento. Qué características tendrá una operación de búsqueda que obtiene todos los datos de los empleados de un departamento dado? a. ámbito one; con filtro de búsqueda b. ámbito one; sin filtro de búsqueda c. ámbito base; con filtro de búsqueda d. ámbito base; sin filtro de búsqueda En cuanto al ámbito, hay que recorrer todos los nodos de un departamento, por lo que debe ser de tipo one. Con respecto al filtro, es necesario puesto que se pretende seleccionar sólo aquellos nodos que correspondan a empleados (se podría, por ejemplo, establecer un filtro basado en objectclass). 8. La empresa E1 organiza sus departamentos como OUs asociando el personal a los mismos. La empresa E2 usa un único OU para colgar todo el personal y groupofnames para implementar los departamentos. Qué ámbito mínimo requeriría en cada empresa una operación de búsqueda que obtenga el número de teléfono de todos sus empleados? a. E1 default; E2 one b. E1 one; E2 one c. E1 one; E2 default d. E1 default; E2 default departamentos, por lo que requiere en ámbito de tipo default. La segunda, sin embargo, tiene que recorrer todos los nodos que cuelgan de personal por lo que le basta con usar un ámbito de tipo one. 9. En una empresa que usa un único OU para colgar todo el personal y groupofnames para implementar los departamentos, cuántas de las siguientes operaciones requerirán el uso de la operación Modify: alta de un empleado en la empresa, baja de un empleado y cambio de departamento? a. 3 b. 0 c. 1 d. 2 Analicemos cada una de las operaciones: alta: requiere una operación de Add para incorporar el nodo y un Modify para añadir el nodo al departamento correspondiente. baja: requiere un Modify para quitar el empleado del departamento y un Delete para eliminar el nodo de la empresa. cambio de departamento: requiere un Modify para quitar el empleado del departamento previo y otro para incorporarlo al nuevo. Por tanto, las tres requieren un Modify. 10. En una empresa que organiza sus departamentos como OUs asociando el personal a los mismos, cuántas de las siguientes operaciones requerirán el uso de la operación Modify DN: alta de un empleado en la empresa, baja de un empleado y cambio de departamento? a. 1 b. 3 c. 0 d. 2 Analicemos cada una de las operaciones: alta: requiere una operación de Add para incorporarlo a la empresa. baja: requiere una operación Delete para eliminar el nodo de la empresa. cambio de departamento: requiere una operación Modify DN para realizar el cambio de departamento, puesto que hay que mover el nodo en el árbol. Por tanto, sólo la última requiere un Modify DN. 11. En una empresa los empleados no cambian prácticamente nunca de departamento, pero un empleado puede pertenecer a varios departamentos. Cómo podría implementarse este requisito? a. Usando un único OU para todo el personal y un groupofnames por cada departamento. b. Usando un OU para cada departamento y colgando al empleado de los departamentos correspondientes. c. En LDAP no se pueden crear ese tipo de relaciones. d. Usando un OU para cada departamento con sus empleados asociados y un único groupofnames sólo para todos los empleados que pertenecen a varios departamentos. LDAP gestiona un espacio de nombres organizado en un árbol. Por tanto, no es posible que un nodo (en este caso, un empleado) cuelgue de varios nodos padre (que serían departamentos, en el caso que nos ocupa). Una posible solución sería colgar todos los empleados de un nodo de tipo OU que representa a todo el personal e implementar cada departamento como un groupofnames, tal que en el campo member se hace referencia a cada empleado de ese departamento, permitiendo así que un empleado pueda pertenecer a varios departamentos. La primera empresa tiene que recorrer todos los nodos correspondientes a empleados que cuelgan de todos los