Forum IT Tranquillo

Buongiorno,
Ieri abbiamo aggiornato il nostro server (licenza enterprise) alla versione 2.7.19598. Il server utilizza Debian 13 Trixie (anch'esso aggiornato ieri; in precedenza utilizzavamo Debian 11 e poi Debian 12).
A seguito di questa transizione, si è verificato un cambiamento nel comportamento relativo al self-service; il sistema di autenticazione che utilizzavamo non è più funzionante.
Questo è in qualche modo correlato a questo argomento: viewtopic.php?t=4581 che non avevamo proseguito.
All'epoca, per i Mac che stavamo implementando, abbiamo infine deciso di non integrarli nella nostra directory AD (che non offriva alcun vantaggio pratico) e, per abilitare il self-service, abbiamo configurato tutti gli agenti (Windows e macOS) con:
service_auth_type=waptserver-ldap
use_kerberos = False

Con questa configurazione, all'apertura dell'area self-service, il sistema self-service richiedeva nome utente e password, che venivano poi verificati dal server tramite Active Directory (samba-ad). Nel complesso, questa soluzione ha funzionato bene per noi.
Il server WAPT è correttamente autenticato con AD; sono stato in grado di richiedere un ticket Kerberos e quindi autenticarmi con esso (tramite "curl -v --negotiate -u: https://si-wapt-01.ad.xxx.fr/api/v3/login_kerberos -k" senza preoccupazioni: Dopo l'aggiornamento di versione, con la stessa configurazione (waptserver-ldap e senza Kerberos), sui computer Windows riscontriamo il seguente errore: Su Mac: Mantenendo waptserver-ldap e abilitando Kerberos, non si verificano più errori sul lato Windows, ma i pacchetti non sono visibili.
E si è verificato un errore sul lato Mac: Abbiamo provato altre combinazioni (system, waptagent-ldap) senza successo e l'unica che sembra ripristinare il lato Windows sarebbe quella di inserirlo in filetoken, lì troviamo il contenuto previsto nel self-service, ma sul Mac continuiamo a non vedere nulla, come credo già dallo scorso marzo.

Insomma, sono un po' perso e non so più dove cercare, e ci ritroviamo con poco meno di venti Mac che non riescono ad aprire il sistema di self-service da ieri.

Avete idea di quale possa essere la causa e come risolverla?

MODIFICA: Informazione importante, ma il test "testing-ldap-connectivity.sh" è OK: MODIFICA 2: Ho una prima spiegazione; il mio sistema self-service utilizza "nomi di gruppo" abbreviati e non nomi completigroupname@ad.xxx.fr".
Aggiungendo un gruppo di questo tipo nella configurazione di waptserver-ldap+kerberos, sul lato Windows vedo i pacchetti arrivare nel self-service.
Ma sul Mac continua a comparire un errore...

AGGIORNAMENTO 3: Un'altra informazione potenzialmente interessante, ma sul lato Mac, l'autenticazione Kerberos sembra funzionare correttamente:

Ho fatto qualche progresso; devi usare il nome Kerberos in lettere maiuscole: yoann.montocket@AD.XXX.FR a livello di kinit, e usa un file temporaneo per memorizzare il token ed esporta il percorso del token:
kinit -c FILE:/tmp/krb5cc_$(id -u) yoann.montocket@AD.XXX.FR
esporta KRB5CCNAME=FILE:/tmp/krb5cc_$(id -u)

quindi avviare manualmente nello stesso terminale:
/Applicazioni/WAPT/WAPT\ Self-service.app/Contenuti/MacOS/waptself

A quel punto, l'area self-service si è aperta correttamente con i pacchi previsti. Ma non c'era nessun pulsante per gestire i pacchi! Chiaramente, sarà estremamente difficile industrializzare questi passaggi per i colleghi... Hai per caso un'idea migliore?

Ciao Yoann,

riguardo al bug di visualizzazione nell'interfaccia self-service, lo abbiamo riprodotto e lo stiamo risolvendo (il problema è dovuto a una differenza di comportamento tra Mac con processori Intel e Mac con processori ARM).

Per quanto riguarda il problema di autenticazione/recupero del gruppo nel self-service, venerdì è stata rilasciata una patch nella nightly build per risolvere alcuni problemi. Verificherò con i miei colleghi se risolve anche il problema dei computer non appartenenti al dominio che utilizzano l'autenticazione con nome utente e password di dominio.

Detto questo, personalmente consiglio di aggiungere macOS al dominio (funziona bene ultimamente, anche se non è sempre stato così ). Questo garantisce in particolare la rotazione delle password.

Stiamo eseguendo un'ultima serie di test e rilasceremo un aggiornamento a breve.

Cordiali saluti,

Denis

Ciao Denis,
il problema nel nostro caso con i Mac è che il nostro dominio non è accessibile ai computer quando effettuano l'accesso, ma solo tramite una VPN che si attiva solo una volta aperta la sessione.
Di conseguenza, la rotazione delle password non funziona, tra le altre cose.
Abbiamo dovuto implementare un sistema MDM su questi computer specificamente per gestire la rotazione delle password e distribuire policy come farebbe Active Directory su un computer Windows (ma non su un Mac).
Quindi non abbiamo visto alcun motivo per continuare a cercare di integrarli in Active Directory...
Avevamo un esempio di un Mac integrato nel nostro Active Directory; la password dell'account veniva ancora riconosciuta e accettata sul Mac nonostante una modifica in Active Directory, anche diverse settimane dopo la modifica, e nonostante la VPN fosse connessa (dopo l'accesso).
In breve, siamo aperti a una soluzione. Come ultima risorsa, abbiamo creato una soluzione alternativa che consente di aggiornare un token Kerberos localmente prima di avviare il self-service. L'abbiamo impacchettata e distribuita tramite Wapt e sembra funzionare come soluzione di ripiego temporanea.