Newsgroup: it.comp.os.linux.sys
Titolo: NTLM Squid - Samba - Winbindd

Ciao a tutti...
Avete esperienze nella configurazione di squid(3) con autenticazione
degli utenti su AD via samba(4) e winbind?
Winbind sembrerebbe funzionare...
wbinfo -t
checking the trust secret via RPC calls succeeded
wbinfo -u
restituisce l' elenco utenti in AD
ma se interpello direttamente l' helper:
/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
dominio+utente password
mi restituisce perennemente:
BH NTLMSSP query invalid
in smb.conf ho settato il "winbind separator = +" ma nulla, l' helper
continua a darmi picche...
L' unico helper al momento funzionante sembrerebbe essere --helper-
protocol=squid-2.5-basic
Che altro provare a fare?

 Che altro provare a fare?
Da quanto si può immaginare consultando nella sfera di cristallo le
informazioni intenzionalmente omesse, parrebbe che tu non abbia fatto il
join al dominio in modalità ADS.
Gli step da eseguire sono:
a) configurare smb.conf con security ads e tutti i parametri al posto giusto.
b) configurare ntp per sincronizzare l'ora con il domain controller AD
c) configurare kerberos correttamente per il realm di AD
d) fare il join al dominio
e) riavviare winbind
f) configurare nsswitch
g) configurare squid con ntlm.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 Che altro provare a fare?
Oltre a verificare gli step consigliati da Zip mi permetto anche di suggerirti 
di verificare la versione di NTLM accettata dal dominio AD.
Nel mio caso ho dovuto fare una modifica ai server di dominio per accettare 
anche la versione di NTLM vecchia altrimenti l'autenticatore continuava a darmi 
errore. C'è documentazione su google a riguardo.
Rizio
-- 
Si vis pacem para bellum

 g) configurare squid con ntlm.
/etc/squid3/squid.conf
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-
ntlmssp --require-membership-of=
BITNET.AD
\"Internet Users"
auth_param ntlm children 5
auth_param ntlm keep_alive on
auth_param basic program /usr/bin/ntlm_auth --helper-
protocol=squid-2.5-basic --require-membership-of=
BITNET.AD
\"Internet
Users"
auth_param basic children 5
auth_param basic realm Squid proxy
Tralasciando per il momento la configurazione di squid:
/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
bitnet.ad
+administrator <password>
[2010/11/11 00:06:03,  1] utils/ntlm_auth.c:
802(manage_squid_ntlmssp_request)
BH NTLMSSP query invalid
dove <password> è la stessa utilizzata con successo al punto D.
----
cat /var/log/samba/log.winbindd
[2010/11/11 00:01:32,  1] winbindd/idmap.c:
438(idmap_init_passdb_domain)
  Could not init passdb idmap domain
[2010/11/11 00:01:32,  0] winbindd/idmap.c:
201(smb_register_idmap_alloc)
  idmap_alloc module tdb already registered!
[2010/11/11 00:01:32,  0] winbindd/idmap.c:149(smb_register_idmap)
  Idmap module passdb already registered!
[2010/11/11 00:01:32,  0] winbindd/idmap.c:149(smb_register_idmap)
  Idmap module nss already registered!
[2010/11/11 00:01:32,  0] winbindd/idmap.c:
201(smb_register_idmap_alloc)
  idmap_alloc module tdb already registered!
[2010/11/11 00:01:32,  0] winbindd/idmap.c:149(smb_register_idmap)
  Idmap module passdb already registered!
[2010/11/11 00:01:32,  0] winbindd/idmap.c:149(smb_register_idmap)
  Idmap module nss already registered!
Non so più dove sbattere la testa...

 Ecco la situazione ...
Ma ti dispiace raccontare un po' quel che hai?
Distribuzione Linux? Versione di Samba? Versione di Windows? Eventuali group
policy non di default?
Non è la massima aspirazione di un sistemista dover cavare le informazioni
con la pinza...


 policy non di default?
Lato windows:  windows 2003 standard fresco di installazione senza gpo
in virtualbox.
- Ho creato un gruppo "Internet Users" all' interno del quale è
presente l' utente "administrator"
Lato linux: ubuntu 10.04  in virtualbox
- Samba Version 4.0.0alpha9-GIT-9733816
- Winbindd Version 3.4.7
- Squid Version 2.7.STABLE7 (Ho provato subito con Squid3 ora son
passato alla 2.7)

/usr/bin/ntlm_auth --username=administrator
<password>
OK
funziona...sembra essere un problema di helper...
Un altra strada potrebbe essere quella di ottenere l' autenticazione
SSO dei client windows attraverso l' uso di LDAP su squid?

 SSO dei client windows attraverso l' uso di LDAP su squid?
Puoi autenticare ma non in modo trasparente.


> Puoi autenticare ma non in modo trasparente.
e questo è un problema.
Ma in merito all' uso dell' helper squid-2.5-ntlmssp hai qualche
esperienza nell' uso?

 esperienza nell' uso?
Lo uso regolarmente su qualche decina di server, in produzione con Debian
Lenny, Debian Squeeze, Centos 5 (usando samba3x al posto di samba).
Non ho mai usato e mai userei Samba 4 *alfa* per una qualsiasi cosa che non
sia mero test, e certamente non ci perderei più di un paio d'ore nel tentare
di farlo funzionare.


 di farlo funzionare.
Capito il concetto... ma alivello di configurazione dei file che ho
allegato noti delle imprecisioni?

 allegato noti delle imprecisioni?
Non mi pareva ma non ho tempo adesso di rileggerli
Faccio prima ad allegarti i miei:
*** smb.conf ***
[global]
   workgroup = DOMINIO
   netbios name = PROXY
   realm = dominio.msft
   server string = PROXY
   dns proxy = no
   interfaces = eth0
   bind interfaces only = yes
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = ads
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   domain master = no
   idmap uid = 10000-20000
   idmap gid = 10000-20000
   template shell = /bin/false
   winbind enum groups = yes
   winbind enum users = yes
   winbind cache time = 10
   winbind use default domain = Yes
   winbind nested groups = Yes
*** krb5.conf ***
[libdefaults]
	default_realm = dominio.msft
	clockskew = 300
	dns_lookup_kdc = true
	kdc_timesync = true
	allow_weak_crypto = true
	krb4_config = /etc/krb.conf
	krb4_realms = /etc/krb.realms
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
	v4_instance_resolve = false
	v4_name_convert = {
		host = {
			rcmd = host
			ftp = ftp
		}
		plain = {
			something = something-else
		}
	}
	fcc-mit-ticketflags = true
[realms]
	DOMINIO.MSFT = {
		kdc = srvdc1.dominio.msft
		kdc = srvdc2.dominio.msft
		kdc = srvdc3.dominio.msft
		master_kdc = srvdc1.dominio.msft
		admin_server = srvdc1.dominio.msft
		default_domain = dominio.msft
	}
[domain_realm]
	.dominio.msft = DOMINIO.MSFT
	dominio.msft = DOMINIO.MSFT
[login]
	krb4_convert = true
	krb4_get_tickets = false
*** squid.conf ***
[CUT]
auth_param ntlm program /usr/bin/ntlm_auth
--helper-protocol=squid-2.5-ntlmssp --domain=DOMINIO
--require-membership-of=DOMINIO+HTTPUsers  --diagnostic -d 5
auth_param ntlm children 20
auth_param ntlm keep_alive on
auth_param basic program /usr/bin/ntlm_auth
--helper-protocol=squid-2.5-basic --domain=DOMINIO
--require-membership-of=DOMINIO+HTTPUsers  --diagnostic -d 5
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
acl autenticati proxy_auth REQUIRED
http_access allow autenticati
[CUT]
Forse il tuo problema è nel required membership. Prova a toglierlo e vedere
se l'auth funziona.


rifatto il tutto su una debian lenny e funziona... qualcosa mi lascia
pensare che samba4 non sia ancora pronto per questo mestiere...
Ora mi sorge un altro dubbio:
se avessi diversi gruppi in AD ai quali applicare diverse ACL come
potrei gestirle?


Non puoi farlo direttamente. Devi crearti un redirector di squid che dato il
nome utente cosě come rilevato da ntlm_auth interroghi l'AD e stabilisca
l'appartenenza di quell'utente ad un determinato gruppo ed in base a quello
poi prenda delle decisioni.
Non č difficile, ma č comunque una lavorata.
Alternativamente come metodo spartano puoi crearti dei "gruppi" in squid
usando le acl
acl gruppo1 proxy_auth "/etc/squid/gruppo1"
acl gruppo2 proxy_auth "/etc/squid/gruppo2"
...
I file /etc/squid/gruppo{1,2,...} puoi rigenerarli periodicamente (
p.es
.
ogni ora) usando uno script che interroghi il dominio (
p.es
. tramite
winbind) e metta in ciascun file, un utente per riga, i membri dei gruppi
omologhi su AD.
Meno flessibile dell'altro sistema ma piů semplice.
Puoi anche fare un'external ACL, ma a quel punto io preferisco il redirector.


> Puoi anche fare un'external ACL, ma a quel punto io preferisco il redirector.
Ho provato l' external wbinfo_group in questa maniera e sembra
funzionare...
acl autorizzati url_regex "/etc/squid/autorizzati.txt"
acl INET_LIBER external wbinfo_group SQ-Completo
acl INET_AUTOR external wbinfo_group SQ-Limitato
http_access allow INET_LIBER
http_access allow INET_AUTOR autorizzati
http_access deny all
Può essere una soluzione valida in produzione?

 Può essere una soluzione valida in produzione?
Assolutamente sì.
