El primer pas consisteix a preparar l’entorn amb dues instàncies d’Ubuntu, assignant-ne una al rol de servidor i la restant al de client. Posteriorment, s’haurà d’establir una xarxa NAT comuna per tal que ambdós sistemes estiguin correctament interconnectats.
Un cop el sistema estigui operatiu, el següent pas és configurar una adreça IP estàtica de manera permanent.
Seguidament, executarem l’ordre ping per verificar que hi hagi connectivitat entre ambdós equips.
Després d’establir l’adreça IP fixa, procedirem a modificar el nom de l’host (hostname) per identificar l’equip a la xarxa.
A continuació, cal editar el fitxer /etc/hosts. En primer lloc, substituirem el nom antic vinculat a l’adreça de retorn (loopback) pel nou hostname configurat. Tot seguit, afegirem una entrada addicional que vinculi la IP estàtica amb el nom complet del domini (FQDN) i el nom curt de la màquina, seguint l’estructura que es mostra a la imatge.
Després de validar les modificacions en els fitxers de configuració, procedirem a actualitzar els repositoris mitjançant l’ordre apt update. Aquest pas és indispensable per garantir la descàrrega i instal·lació correcta del següent paquet.
Durant el procés d’instal·lació, serà necessari establir una contrasenya de seguretat. Un cop el servei estigui operatiu al servidor, abans d’aplicar qualsevol modificació, executarem l’ordre slapcat per obtenir una visió detallada de la configuració base del sistema.
Mitjançant l’execució de dpkg-reconfigure, podrem personalitzar els paràmetres de l’LDAP segons les nostres necessitats específiques. A continuació, es detallen els valors que aplicarem per a aquesta configuració:
Amb el servei base ja establert segons els nostres requeriments, procedirem a incorporar l’estructura d’Unitats Organitzatives (UO), usuaris i grups. Aquests elements es troben emmagatzemats a l’arxiu arxius.zip, de manera que el primer pas serà descomprimir-ne el contingut.
Cal adaptar els fitxers uo.ldif, usu.ldif i grup.ldif a la nostra infraestructura. Per fer-ho, editarem cadascun d’aquests arxius per assegurar-nos que les referències al domini coincideixen amb el que hem configurat prèviament.
Un cop editats els fitxers, procedirem a la seva importació al directori LDAP. Per fer-ho, utilitzarem l’eina de línia de comandes per carregar les estructures definides en els arxius LDIF.
Per finalitzar, executarem novament l’ordre slapcat amb l’objectiu de verificar que tota l’estructura d’usuaris i grups s’ha integrat correctament en la base de dades del directori.
Amb aquests passos, la configuració de l’entorn del servidor ha quedat finalitzada i optimitzada segons els requeriments establerts.
De la mateixa manera que hem fet amb el servidor, caldrà establir una adreça IP estàtica a la màquina client. Posteriorment, validarem la connectivitat entre ambdós equips mitjançant una prova de ping per assegurar-nos que la comunicació és estable.
En el client també és necessari instal·lar paquets relacionats amb l’LDAP, tot i que el programari difereix de l’utilitzat al servidor, ja que en aquest cas l’objectiu és l’autenticació i no la gestió del directori.
Un cop finalitzada la instal·lació, s’executarà automàticament l’assistent de configuració del client LDAP. Els paràmetres que hem definit per a aquest entorn es detallen a continuació:
En cas de detectar algun error o si cal realitzar ajustos posteriors, podem tornar a llançar l’assistent mitjançant l’ordre dpkg-reconfigure ldap-auth-config. Això ens permetrà revisar i corregir qualsevol paràmetre de l’autenticació.
Cal incorporar els paràmetres ldap i compat a l’inici de les directives de configuració. D’aquesta manera, el sistema prioritzarà la consulta al directori LDAP per realitzar l’autenticació abans de buscar en els fitxers locals.
Finalment, cal incorporar l’última línia que es mostra en el fitxer de configuració per completar la integració del sistema.
Dins d’aquest fitxer de configuració, cal localitzar el paràmetre use_authtok i suprimir-lo de totes les línies on estigui present.
Afegim el greeter.
Un cop finalitzada la configuració, per validar que la connexió amb el servidor s’ha establert correctament, realitzarem una consulta d’un dels usuaris creats prèviament mitjançant els fitxers .ldif. Aquesta comprovació ens permetrà confirmar que el client pot resoldre usuaris que no existeixen localment.
Comprovem que podem entrar.
El següent pas consisteix a comprovar l’inici de sessió gràfic. Per fer-ho, seleccionarem l’opció d’entrar amb un usuari nou, n’indicarem el nom (usuari alu1) i n’introduirem la contrasenya corresponent per verificar que el perfil es carrega sense incidències.
Comprovació final:
En aquest punt, la infraestructura de xarxa i el servei de directori estan plenament desplegats. El servidor gestiona les peticions d’autenticació correctament i el client respon de manera transparent, permetent l’accés tant per terminal com per entorn gràfic.
Un servidor Samba permet la compartició de recursos en xarxa, com ara fitxers i impressores, en entorns multiplataforma (Linux i Windows). L’autenticació es gestiona a nivell d’usuari i ofereix la flexibilitat d’utilitzar tant una base de dades d’usuaris pròpia de Samba com una integració centralitzada mitjançant LDAP.”
Instalem Samba
Primerament, procedirem a la creació del directori que volem compartir i n’ajustarem els permisos i la propietat. Definirem l’usuari i el grup corresponents per garantir que només els membres autoritzats tinguin accés al recurs compartit.
Per a la gestió dels accessos, procedirem a donar d’alta tres nous usuaris i un grup de seguretat. Posteriorment, vincularem aquests comptes al grup per tal de centralitzar els permisos del recurs compartit en una única unitat.
Procedirem a establir les credencials d’accés per als nous usuaris. Aquest pas és indispensable per garantir que es puguin validar correctament en iniciar la sessió des del client.
Procedirem a l’edició del fitxer smb.conf per afegir-hi la declaració del recurs compartit. Això inclou configurar els paràmetres necessaris perquè el directori sigui visible i accessible des de la xarxa per als clients autoritzats.
Per tal que els canvis realitzats en el fitxer de configuració s’apliquin correctamente, caldrà reiniciar el servei de Samba. Això permetrà que el sistema carregui la nova definició del recurs compartit.”
Abans de procedir amb la connexió al recurs, cal verificar la connectivitat de xarxa entre el client i el servidor. Per fer-ho, utilitzarem l’eina ping per assegurar-nos que ambdues màquines es comuniquen correctament.
Instalem smbclient.
Procedirem a validar l’accés al recurs compartit mitjançant el protocol SMB. Des de l’entorn gràfic, utilitzarem l’opció de connexió a servidors indicant la ruta corresponent (smb://[IP_DEL_SERVIDOR]/[NOM_RECURS]) per establir el vincle.
Hem realitzat una prova d’accés com a usuari anònim i hem comprovat que és possible crear carpetes satisfactòriament. Aquest èxit es deu a la configuració dels permisos a nivell de sistema de fitxers i a les directives del recurs en Samba, que permeten l’escriptura a usuaris no autenticats.
Hem validat l’accés nominal amb el compte de l’usuari naim. Les proves d’escriptura i lectura han estat satisfactòries, fet que confirma que les directives de seguretat aplicades al recurs compartit i els permisos del sistema de fitxers estan correctament sincronitzats.
Per comprovar el control d’accés, hem iniciat sessió com a eros. El resultat de la prova ha estat satisfactori: l’usuari pot llistar els fitxers, però en intentar crear un nou directori, el servidor Samba retorna un error de permís denegat, complint amb la configuració establerta.
Per concloure les proves de seguretat, hem intentat accedir amb l’usuari edgar. En aquest cas, el sistema ha denegat l’accés al recurs compartit, confirmant que els usuaris que no pertanyen al grup autoritzat no poden ni tan sols llistar el contingut del directori.
Durant la prova amb l’usuari no autoritzat, hem observat que el sistema no retorna un error explícit de denegació, sinó que sol·licita cíclicament les credencials. Aquest comportament és el mètode estàndard del protocol per indicar que l’usuari no té privilegis d’accés al recurs sol·licitat.
Iniciem la integració de LDAP creant un recurs compartit de zero. Configurem un nou directori al sistema i assignem els permisos d’usuari i grup necessaris per garantir una base neta abans de la vinculació.
Preparem un fitxer .ldif per definir l’estructura de dades a LDAP. Hi especifiquem la creació d’un nou grup i els seus usuaris associats, seguint l’esquema d’atributs necessari per a la integració amb Samba.
Executem la comanda ldapadd per carregar les definicions del fitxer LDIF al servidor. Amb això, l’estructura de grups i usuaris queda integrada i operativa dins del directori LDAP.
Modifiquem el fitxer smb.conf per establir el backend de passatges a ldapsam. Afegim els paràmetres de connexió al directori i definim el nou recurs compartit, permetent que Samba sincronitzi les contrasenyes i gestioni els accessos mitjançant l’esquema de LDAP.
Afegim l’esquema de Samba al servidor LDAP. Aquest pas és imprescindible perquè el directori entengui i accepti els nous camps de dades que Samba necessita per gestionar els usuaris i les seves contrasenyes.
Reiniciem el slapd (LDAP) i smbd (Samba) per aplicar els canvis en la configuració i carregar el nou esquema. Aquest pas assegura que ambdós serveis sincronitzin correctament la base de dades d’usuaris actualitzada
Utilitzem la comanda smbpasswd -w per emmagatzemar la contrasenya de l’administrador de LDAP dins de la base de dades secreta de Samba. Això permet que el servei smbd tingui els permisos necessaris per realitzar canvis i consultes al directori slapd
Ara ja podrem afegir les contrasenyes als usuaris.
Passem a la fase de proves des del client. Verifiquem que el nou recurs és visible i que podem iniciar sessió amb els usuaris i contrasenyes que hem configurat prèviament al directori.
Malgrat no visualitzar errors de sintaxi, la connexió falla en l’intent de validació. Això és degut al fet que el fitxer smb.conf no té habilitat l’accés per a convidats o usuaris anònims, obligant el sistema a rebutjar qualsevol intent de connexió que no estigui explícitament autenticat.
L’usuari Eros aconsegueix autenticar-se correctament, però l’accés està limitat a mode lectura. Això indica que, tot i que l’autenticació amb LDAP funciona, el recurs compartit a smb.conf o els permisos del sistema de fitxers no tenen habilitada l’opció write list o els permisos d’escriptura per a aquest usuari.
Comprovem que l’usuari Eros no pot eliminar el directori de Ian. Això confirma que els permisos de sistema (filesystem permissions) estan correctament configurats, impedint que un usuari amb permisos d’escriptura pugui interferir o esborrar la propietat d’altres membres del grup.
Validem l’accés amb l’usuari Ian, confirmant que disposa de permisos de lectura, escriptura i execució (rwx). A diferència d’altres perfils, aquest usuari pot gestionar el cicle de vida complet dels seus fitxers i carpetes dins del recurs compartit.
L’usuari Razvan no pot accedir al recurs a causa de les restriccions imposades a la configuració de Samba. Tot i estar al directori LDAP, la manca de permisos explícits al fitxer smb.conf provoca que el servidor el tracti com un usuari no autoritzat, igual que passa amb les connexions anònimes.”
Totes les configuracions i instal·lacions descrites a continuació es duran a terme a nivell de servidor. És primordial que la màquina central disposi de l’entorn Java per poder executar les eines de gestió del directori.
L’administració del directori es realitzarà mitjançant un entorn gràfic especialitzat. Entre les opcions disponibles, farem servir Apache Directory Studio, una eina basada en Eclipse que ens permetrà gestionar els objectes, atributs i esquemes de l’LDAP d’una manera més visual i intuïtiva.
Com a requisit previ per a l’execució de l’Apache Directory Studio, és necessari instal·lar l’entorn de l’JRE (Java Runtime Environment) al sistema. Sense aquesta dependència, l’eina d’administració no podria iniciar-se correctament.
Un cop l’entorn Java està operatiu, procedirem a obtenir el paquet d’instal·lació de l’Apache Directory Studio des del seu lloc web oficial. Seleccionarem la versió compatible amb la nostra arquitectura de sistema per garantir una integració òptima.
El descomprimim.
Per tal de mantenir l’ordre en el sistema de fitxers, desplaçarem el directori descomprimit a la ruta /opt/. Aquesta ubicació és la idònia per instal·lar paquets de programari que no formen part de la distribució oficial del sistema operatiu.
Procedirem a modificar els atributs del fitxer executable mitjançant l’ordre chmod. En atorgar el bit d’execució, habilitarem l’accés al programa des de la línia de comandes o des de l’entorn de l’escriptori.
Abans d’executar l’aplicació, és necessari realitzar un ajust en el fitxer de configuració .ini per resoldre una incompatibilitat de versions. Atès que l’ADS està preconfigurat per treballar amb Java 11 i el nostre sistema disposa de la versió 17 (LTS), caldrà especificar la ruta correcta de la nostra màquina virtual (JVM).
Executem l’aplicació.
Amb l’aplicació ja operativa, el següent pas consisteix a establir una nova connexió LDAP. En aquest procés, configurarem els paràmetres de xarxa i les credencials d’administrador per poder interactuar directament amb el servei de directori des de la interfície gràfica.
En la finestra de configuració, assignarem un nom identificatiu a la connexió per facilitar-ne la gestió i especificarem l’adreça IP del nostre servidor. Aquests paràmetres permetran a l’aplicació localitzar el servei LDAP dins la xarxa.
En la següent fase del configurador, procedirem a l’autenticació del sistema. Introduirem les credencials d’administrador configurades prèviament, especificant el Bind DN (compost pel cn i el dc corresponents) i la contrasenya per tal d’obtenir permisos de gestió sobre el directori.
Com a pas de control, verificarem l’autenticació per assegurar-nos que el Bind DN i la contrasenya han estat introduïts correctament. Un cop validat el punt d’accés, finalitzarem el procés, moment en el qual l’arbre de directori es farà visible a la interfície de l’ADS.
Un cop establerta la connexió, ens dirigirem al panell ‘LDAP Browser’ situat a la part esquerra de la interfície. Des d’aquí, ja podrem visualitzar la jerarquia del nostre servidor LDAP i confirmar que l’estructura base del domini s’ha carregat correctament.
A continuació, procedirem a la creació d’un nou usuari en el directori per verificar el cicle complet de gestió. Un cop donat d’alta, realitzarem una prova d’inici de sessió des del client per demostrar que l’autenticació centralitzada i l’accés als recursos funcionen segons el previst.
Iniciarem el procés d’alta d’objectes mitjançant el menú contextual del domini. En triar ‘New Entry’, podrem escollir entre crear una Unitat Organitzativa (OU) per estructurar el directori o definir directament nous usuaris i grups sota la jerarquia del domini.
El crearem de 0.
El següent pas consisteix a triar l’esquema de l’objecte. Mitjançant la interfície de selecció, afegirem la classe d’objecte organizationalUnit. Aquesta acció ens permetrà establir una nova Unitat Organitzativa, proporcionant un marc jeràrquic on posteriorment integrarem els comptes d’usuari.
Dins del selector d’atributs, cercarem el terme ou (Organizational Unit) per definir la classe d’objecte. Un cop seleccionada, li assignarem un nom identificatiu (com ara ‘Usuaris’ o ‘Grups’), establint així la base jeràrquica on s’allotjaran els futurs registres.ç
Ara que ja tenim la nova UO creada, creem un usuari.
Procedirem a afegir les Object Classes requerides per a la interoperabilitat del compte. Mitjançant inetOrgPerson definim l’entrada com un objecte de persona estàndard, i amb l’extensió posixAccount habilitem els paràmetres de nivell de sistema (com el UID, GID i el directori Home) que permetran l’inici de sessió en el client.
Al RDN li ficarem uid i li afegim el nom que volem.
Per tal de definir les credencials d’accés, haurem d’incorporar un nou atribut a l’entrada de l’usuari. Mitjançant el menú contextual (clic dret) i l’opció ‘New Attribute’, seleccionarem l’atribut userPassword, el qual ens permetrà assignar una contrasenya segura per a l’autenticació.
Busquem userPassword.
Un cop seleccionat l’atribut userPassword, procedirem a l’assignació de la clau. L’assistent de l’Apache Directory Studio ens permet, a més, escollir un mètode de hashing (com ara SSHA o SHA). Aquesta pràctica garanteix que, en cas d’un accés no autoritzat a la base de dades LDAP, les credencials dels usuaris romanguin protegides.
Haurém d’afegir també l’informació que ens sortia en roig.
Ara podem veure que ja tenim l’usuari creat.
Un cop configurat l’usuari al servidor, ens dirigirem a l’estació de treball client per verificar l’autenticació. A la pantalla d’inici, seleccionarem l’opció de canviar d’usuari i farem clic sobre ‘No està a la llista?’. Això ens permetrà introduir manualment el nom d’usuari emmagatzemat al directori LDAP.
Afegim també la contrasenya i ja ens crearà l’usuari.
Ara ja podem veure a la terminal si està tot correcte.
L’afegim.
Ara el podem buscar.
L’afegim.
Afegim i confirmem.
Hi han 2 grups, informatica i administracio.
No fiquem accents ja que no apareixerà el valor correctament.
Hi han 3 usuaris, xavier, enric, sergi i manu.
Durant el procés de configuració, observarem que certs atributs no poden ser eliminats a causa de les restriccions de l’esquema. Concretament, la classe d’objecte posixGroup requereix obligatòriament l’atribut gidNumber per complir amb l’estàndard POSIX, garantint així que el sistema operatiu pugui identificar el grup correctament.
Hi han 3 UOs.
En intentar suprimir la Unitat Organitzativa (UO), el sistema ens retornarà un error de restricció, ja que no es pot eliminar un node que conté objectes dependents. Per procedir, caldrà realitzar un esborrat en cascada manual: primer eliminarem els comptes d’usuari allotjats en el seu interior i, un cop el directori estigui buit, podrem eliminar la UO definitivament.
Ara ja no ens apareix ni l’usuari ni el grup.
Els passos anteriors s’hem va peta la terminal i no me surtia el resultat.
Administració té la gid 1002.
Només està l’usuari Sergi.
No hi ha cap en aquest uidNumber.
En executar la consulta, observem que el resultat és buit. Això es deu al fet que cap entrada compleix simultàniament els criteris establerts: d’una banda, l’usuari modificat al punt anterior ja no coincideix amb el filtre de cognom (ha passat de ‘Reus’ a ‘Pallares’) i, de l’altra, els registres restants queden exclosos en tenir un uidNumber inferior al llindar de 1003.
El gidNumber de informàtica és 1001.
Ens apareix 3 en total, 2 del grup informàtica i 1 que el seu cognom és Pallares.