Nethesis
NethServer 8: cosa controllare quando un’app non trova gli utenti LDAP
Host, porta, Base DN, credenziali e TLS devono essere coerenti. Una guida per capire dove cercare quando un’applicazione non vede gli utenti del dominio.
Prima domanda: dove si trova il dominio utenti?
In NethServer 8 utenti, password e gruppi sono organizzati in domini basati su LDAP. Il cluster può ospitare domini interni con schema Active Directory Samba oppure OpenLDAP RFC2307, ma può anche collegarsi a un servizio LDAP esterno. Questa distinzione viene prima di ogni prova: un’app installata nel cluster può ricevere i parametri tramite l’integrazione prevista, mentre un programma collocato su un altro server deve poter raggiungere un endpoint realmente esposto. Copiare host e porta da una configurazione diversa può quindi produrre un errore anche se utenti e password sono corretti.
Host, porta e Base DN svolgono compiti diversi
L’host indica quale server contattare; la porta identifica il servizio; il Base DN stabilisce da quale punto dell’albero LDAP cercare utenti e gruppi. La documentazione NethServer indica 389 come valore standard per LDAP e 636 per LDAPS, ma la scelta deve corrispondere al servizio configurato. Per alcuni collegamenti ad Active Directory possono servire le porte Global Catalog 3268 o 3269 quando l’applicazione non gestisce i riferimenti LDAP subordinati. Modificare più parametri insieme rende difficile capire quale fosse errato: è preferibile annotare i valori previsti e verificarli uno alla volta.
Il nome DNS conta soprattutto con TLS
Un indirizzo IP può risultare raggiungibile, ma non essere il nome per il quale è stato emesso il certificato. Con la verifica TLS attiva, NethServer 8 controlla che il certificato sia firmato da un’autorità attendibile e che il nome corrisponda all’host configurato. Anche i nodi del cluster richiedono un FQDN risolvibile verso un indirizzo instradabile; il DNS corretto è parte del funzionamento della cifratura, non soltanto una comodità. Disattivare la verifica per far sparire un errore nasconde il controllo d’identità del server e non dovrebbe diventare la soluzione definitiva.
Non tutti i provider espongono LDAP allo stesso modo
Il provider Samba AD interno espone le porte LDAP e LDAPS alle applicazioni esterne soltanto se è stato creato con l’opzione per cartelle condivise e autenticazione dei client Windows. Il provider OpenLDAP RFC2307 interno, invece, non pubblica una porta per programmi esterni: ascolta su una porta LDAP in chiaro accessibile ai servizi della rete del cluster, dove l’infrastruttura gestisce il collegamento. Per questo una guida generica trovata per un’altra installazione può essere inapplicabile. Prima di aprire firewall o inoltrare porte bisogna verificare il tipo di dominio e il percorso supportato.
Un esempio con un gestionale separato
Immaginiamo un gestionale su un server distinto che debba autenticare i dipendenti usando un dominio Samba AD di NethServer 8. Il responsabile verifica che il provider sia stato predisposto per l’accesso dei client, registra un nome DNS coerente, usa la porta sicura prevista, importa la catena di certificazione attendibile nell’applicazione e crea credenziali di bind con i soli permessi necessari. Imposta poi il Base DN corretto e prova prima una ricerca limitata a un utente di test. È uno scenario ipotetico: non descrive un intervento eseguito da System & Software e i campi effettivi dipendono dal gestionale.
Un ordine di diagnosi riduce i tentativi casuali
Conviene separare i controlli per livelli. Primo: il nome si risolve e l’host è raggiungibile dal server dell’applicazione? Secondo: la porta risponde ed è quella del protocollo scelto? Terzo: il certificato è valido per quel nome? Quarto: il bind DN viene accettato? Quinto: Base DN e filtro restituiscono l’utente previsto? Infine si verifica come l’applicazione traduce gruppi e attributi nei propri ruoli. I registri di NethServer e dell’applicazione aiutano a distinguere timeout, rifiuto TLS, credenziali errate e ricerca senza risultati, che non sono lo stesso problema.
Limiti e cautele
Un collegamento LDAP riuscito non assegna automaticamente i permessi corretti dentro l’applicazione e non garantisce continuità. Se il dominio esterno dispone di più provider, la documentazione richiede che siano raggiungibili da tutti i nodi del cluster; con alcune modalità di verifica TLS esistono inoltre limiti nel passaggio al provider alternativo. Versioni recenti di Microsoft Active Directory, incluso Windows Server 2025, applicano requisiti più rigorosi per firma e TLS: la guida NethServer raccomanda un certificato attendibile invece di disabilitare la firma LDAP, che ridurrebbe la sicurezza. Prima della produzione servono prova di accesso, revoca e comportamento durante un guasto.
Fonti e riferimenti
Fonti consultate il 31/10/2026.