Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/carlamndz/InventarioITU/llms.txt

Use this file to discover all available pages before exploring further.

OpenLDAP provides centralized authentication for InventarioITU, acting as the single source of truth for user identities across all lab environments at ITU Mendoza. It runs as the ldap-service container and listens on port 389, allowing the inventario-web Node.js application to validate credentials at login time. Every user who accesses the inventory system — whether a lab administrator or teaching staff — must have a valid entry in the OpenLDAP directory.

​
Deploy the OpenLDAP Container

The recommended way to run OpenLDAP for InventarioITU is with the osixia/openldap image. The following command bootstraps the server with the ITU Mendoza organization and the itu.edu.ar domain: 
docker run -d \
  --name ldap-service \
  -p 389:389 \
  -e LDAP_ORGANISATION="ITU Mendoza" \
  -e LDAP_DOMAIN="itu.edu.ar" \
  -e LDAP_ADMIN_PASSWORD="admin_password" \
  osixia/openldap:1.5.0
Replace admin_password with a strong, randomly generated secret before deploying to any shared or production environment. Store it in a Kubernetes Secret or a secrets manager — never hard-code it in a Dockerfile or commit it to version control.
Once the container is running you can confirm it is healthy with: 
docker ps --filter name=ldap-service

​
Directory Information Tree (DIT)

InventarioITU organizes LDAP entries under two organizational units: ou=usuarios for individual user accounts and ou=grupos for role-based groups. This structure maps directly to the access levels enforced by the web application. 
dc=itu,dc=edu,dc=ar
├── ou=usuarios
│   ├── uid=admin
│   └── uid=jdoe
└── ou=grupos
    ├── cn=administradores
    └── cn=docentes
Members of cn=administradores have full read/write access to inventory records, while members of cn=docentes can view equipment assignments but cannot modify them. Create both OUs before adding any user entries.
When you add your LDAP configuration to the ldap/ directory, you can save LDIF files there and apply them with ldapadd after the container is running. The example snippets in this guide can be saved directly into ldap/ as a starting point.

​
Add a User Account

User entries follow the inetOrgPerson and posixAccount object classes. Save the snippet below as jdoe.ldif and apply it with ldapadd: 
dn: uid=jdoe,ou=usuarios,dc=itu,dc=edu,dc=ar
objectClass: inetOrgPerson
objectClass: posixAccount
uid: jdoe
cn: Juan Doe
sn: Doe
mail: jdoe@itu.edu.ar
userPassword: {SSHA}hashedpassword
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/jdoe
Apply the entry against the running container: 
ldapadd -x \
  -H ldap://localhost:389 \
  -D "cn=admin,dc=itu,dc=edu,dc=ar" \
  -w admin_password \
  -f jdoe.ldif
Generate a proper {SSHA} password hash before setting userPassword: 
docker exec ldap-service slappasswd -s "the_users_password"

​
Connect inventario-web to LDAP

The Node.js application reads its LDAP configuration exclusively from environment variables. Set the following variables in your Docker Compose file, Kubernetes Secret, or .env file before starting inventario-web:
VariableExample ValuePurpose
LDAP_URLldap://ldap-service:389Connection URL for the LDAP server
LDAP_BASE_DNdc=itu,dc=edu,dc=arRoot of the directory tree
LDAP_BIND_DNcn=admin,dc=itu,dc=edu,dc=arService account used for bind operations
LDAP_BIND_PASSWORDadmin_passwordPassword for the service account
LDAP_USER_SEARCH_BASEou=usuarios,dc=itu,dc=edu,dc=arSubtree searched when validating a login
When deploying on Kubernetes, store LDAP_BIND_PASSWORD in a Secret and inject it as an environment variable rather than placing it directly in the Deployment manifest: 
env:
  - name: LDAP_BIND_PASSWORD
    valueFrom:
      secretKeyRef:
        name: ldap-credentials
        key: bind-password

​
Test the LDAP Connection

After the container is running and users have been added, verify connectivity and entry retrieval with ldapsearch: 
ldapsearch -x -H ldap://localhost:389 \
  -D "cn=admin,dc=itu,dc=edu,dc=ar" \
  -w admin_password \
  -b "ou=usuarios,dc=itu,dc=edu,dc=ar" "(uid=jdoe)"
A successful response returns the full attribute set for uid=jdoe. If you receive ldap_bind: Invalid credentials (49), double-check the admin password. If you receive No such object (32), the ou=usuarios organizational unit has not been created yet. From within the Kubernetes cluster, run the same search through the web pod to confirm internal DNS resolution: 
kubectl exec -it <web-pod> -- \
  ldapsearch -x -H ldap://ldap-service:389 \
    -D "cn=admin,dc=itu,dc=edu,dc=ar" \
    -w admin_password \
    -b "ou=usuarios,dc=itu,dc=edu,dc=ar" "(uid=jdoe)"
Plain LDAP (port 389) transmits credentials in clear text and is acceptable only in isolated local or development environments. For any deployment accessible over a network, configure LDAPS (LDAP over TLS) on port 636 using a valid certificate. The osixia/openldap image supports TLS via the LDAP_TLS_* environment variables.

Build docs developers (and LLMs) love

Get started for freeTalk to us