Newsgroup: it.comp.os.linux.sys
Titolo: Qualcuno si intende di autenticazione Windows?

Non è OT, in quanto sto cercando di capire alcune bizzarrie
che sto verificando in un processo di integrazione tra Active
Directory e alcuni servizi basati su Linux.
Le bizzarie si sono manifestate quando ho provato a cambiare
delle password di dominio con modalità "non windows", ad esempio 
via ldap con un codice php scritto da un collega o via kpasswd
e quindi kerberos direttamente da shell.
Ciò che si verifica è che, dopo un cambio di password siffatto,
servizi che si interfaccino con l'AD via ldap/global catalog
o usando pam_winbind accettano sia la nuova password che la
password immediatamente precedente, quasi come se i "livelli"
ldap, ntlm e kerberos di AD non fossero esattamente in sync.
Mi rendo conto che l'esposizione non è il massimo della chiarezza
ma sono effettivamente un po' confuso.
Qualcuno ha esperienze analoghe in merito?

 ma sono effettivamente un po' confuso.
Ecco, appunto, prova a spiegarti meglio :^)
Il gioco da chi è pilotato, da un AD vero o da un Samba? E questi
cambi di password dove e come vengono fatti?
bye!

Il Thu, 19 Feb 2009 01:56:14 -0800, Hermooz scrisse:

E' un AD vero, windows 2003.
Come dicevo, il cambio password lo hanno fatto prima alcuni colleghi
con un'applicazione web che dava questi bizzarri risultati, poi l'ho
fatto anche io, usando sia kpasswd di krb5 che con "net rap password"
di samba.
Il cambio password funziona, nel senso che la nuova password mi autentica.
Ma continua a funzionare anche la vecchia.
Un esempio pratico: dopo un kpasswd, faccio un ldapsearch
ldapsearch  -h tc-ad.pippo.lan -x -D "cn=whiplash,ou=BU02,ou=Corp-Users,dc=pippo,dc=lan" -b "dc=pippo,dc=lan" -W
Enter LDAP Password:
e il binding va a buon fine sia con la vecchia che con la nuova password
se metto una pass a caso, non va il binding:
ldap_bind: Invalid credentials (49)
Idem se mi autentico via ssh con pam_winbind: l'ultima password e la penultima
funzionano indifferentemente.
L'unico che reagisce immediatamente al cambio è proprio kerberos: se
dopo un kpasswd faccio un kdestroy e di nuovo un kinit, devo necessariamente
utilizzare l'ultima password, per ottenere un ticket.
E' questo che mi fa pensare alla prima citata non sincronia, insomma.

 E' questo che mi fa pensare alla prima citata non sincronia, insomma.
Mmmmm... a me fa pensare al fatto che, IIRC, dentro AD ci sono DUE
password (quella in formato LM e quella in formato NT), e che per
compatibilità verso il basso non mi meraviglierei ne bastasse una per
autenticarsi (la modalità in cui è stato installato il dominio
sicuramente c'entra, ma ora non so dirti perchè). E' probabile che le
applicazioni di terze parti modifichino solo una delle due senza
tenere in sync l'altra.
guarda anche qui: 
http://wiki.samba.org/index.php/Samba_&_Active_Directory
questo passaggio mi sembra ricalchi molto bene quello che descrivi:
"password changes
it is possible to change your password using samba AD integration, but
not recommended. it results in a curious condition in that seemingly
two passwords become assigned to one username.
both the old, as well as the new password come into effect and are
accepted by linux as well as some windows systems utilizing AD as an
authentication mechanism (ex: altiris). Windows logon however only
accepts the new password assigned by the user.
the madness continues with windows' ability to "extinguish" silently
the old password... Once a linux user logs back into their windows
system with this new password (assigned in linux), the old password
automagically becomes null and void; no longer existing for use
anywhere. "
Forse nelle ML di samba puoi trovare qualche info in più.
Bye!

 passaggio mi sembra ricalchi molto bene quello che descrivi:
Grazie mille, utilissimo.
La vera follia è che cambiando le password via kerberos, via ldap
continua ad accettare anche la vecchia.
Bah: ora investigherò per capire se esiste un modo per tenere in sync
il tutto.

 il tutto.
IMVHO l'unico modo è usare la modalità nativa di windows per cambiare
la password...
bye!


i miei 2 cents; qual'è il livello di funzionalità del dominio AD?

 ldap, ntlm e kerberos di AD non fossero esattamente in sync.
Si comporta così anche dopo un reboot del client? In caso negativo,
potrebbe essere la client-side caching di LDAP.
Per la versione linux mi sfuggono i dettagli implementativi. Ma a
google non sfugge nulla.

 sicuramente c'entra, ma ora non so dirti perchè).
C'è l'opzione "compatibilità per pre-Windows 2000" che di fatto "attiva"
questo doppio campo.
Difatti quando si cambia password nel dominio che è in "modalità
compatibilità", e si mette una password "tanto" lunga, il sistema
avverte (per i limiti di LM) che non è possibile fare il login su
sistemi troppo vecchi (9x e similari) con la nuova password.
Enrico

 potrebbe essere la client-side caching di LDAP.
No, non è caching.
Verificato con tcpdump.

 i miei 2 cents; qual'è il livello di funzionalità del dominio AD?
"Questo dominio opera al massimo livello di funzionalità".
E' questo che intendevi?

 password...
Pare di no: anche cambiando la pass direttamente da Windows, via 
LDAP per circa un'oretta la strana sovrapposizione continua, mi dice
chi ha testato anche questa via.
Amazing Windows! :-)

 LDAP per circa un'oretta la strana sovrapposizione continua,
mmmmmmmmhhhhhh ... dai che è il caching del client ldap. Mi ricordo
una menata simile sui manuali di ldapux.
Io ricontrollerei l'output di tcpdump altre 25 volte.

 Io ricontrollerei l'output di tcpdump altre 25 volte.
comunque il client potrebbe tentare contemporaneamente la connessione
di rete e simultaneamente leggere la cache.
Cioè è molto teorico.... ma in questo caso compare tcpdump non aiuta.
Che esiste una cache lato client di ldap invece è vero.


non proprio. intendevo "windows 2003 nativo" o "windows 2003 interim" o
similari. hai controller di dominio 2000 o NT?

 o "windows 2003 interim" o similari. hai controller di dominio 2000 o NT?
No.

 tcpdump altre 25 volte.
Ho imparato a leggere parecchi anni fa.
Purtroppo.
81	5.297050	172.22.50.40	172.22.55.21	LDAP	bindRequest(1) "whip...@pippo.lan" simple 
82	5.301709	172.22.55.21	172.22.50.40	LDAP	bindResponse(1) success 
Feel free to try it, anyway.
Ti cambi la pass con kpasswd e poi fai un binding ldap al global catalog
con la vecchia password.
Potrai altresì verificare che, al contempo, se provi a richiedere un nuovo
ticket con kinit avrai bisogno della nuova password.

 Questo.
Hai diversi domain controller?
Una spiegazione potrebbe essere quella di ritardi nella replicazione del 
ldap che invece probabilmente non esistono per la parte kerberos.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 con la vecchia password.
mumble, mumble. Ho rimosso tutto e sono tornato all'utente locale
perché mi creava un grosso problema.... diverso dal tuo, e credo senza
soluzione.
Abbiamo la rete 802.1x, che usa la password di dominio per
l'autenticazione, e per come è impostato in Ubuntu mi crea una
situazione tale che non posso fare più login sulla macchina se
dimentico di reimpostare la password per 802.1x nel network-manager,
prima di fare logout.

 ldap che invece probabilmente non esistono per la parte kerberos.
Questa spiegazione (che è una cosa che avevo già pensato).... ma penso
che questa è una cosa risaputa e comunque l'accavallamento non è del
tutto giustificabile.
IMHO, il fatto che le password si accavallino per circa un'ora può
essere una sorta di strana feature, per dare il tempo a tutte le
applicazioni di sincronizzarsi. Ponendo il caso di una rete 802.1x,
con Linux avrei un'ora di tempo per continuare a fare login, e avrei
quindi la possibilità di cambiare la password nel network-manager....
altrimenti, come è successo a me (che ho riacceso il PC il giorno
dopo) non si puo' nemmeno fare login, perché non si riesce ad ottenere
nemmeno l'indirizzo IP.