Newsgroup: it.comp.os.linux.sys
Titolo: LDAP

Ciao a tutti,
dovrei fare autenticare una macchina con sopra PFsense verso active 
directory. Non ho seguito la cosa fino ad ora, ma mi è stato detto che la 
via più seguita consiste nell'installare LDAP su una terza macchina e 
metterlo in sync con active directory. Innanzitutto: è vero?
Non ho esperienza di LDAP: qualcuno ha già fatto qualcosa del genere e ha 
voglia di darmi qualche dritta o qualche quida online per configurare LDAP 
su una Debian Squeeze in modo che sia sincronizzato con active directory e 
autentichi gli utenti di una macchina con PFsense (ed eventualmente altre)?
Ciao e grazie,
  Void


http://www.miamammausalinux.org/2011/02/openldap-migrazione-dalla-configurazione-classica-alla-nuova-cnconfig/
vedi se fa al caso tuo.

 altre)?
Non so nulla di PFsense né di active directory. Però in questo periodo 
smanetto con ldap/kerberos. E in quanto a guide questo tipo sa il fatto suo:
http://www.rjsystems.nl/en/2100.php
Preparati al bagno di sangue con ldap :P
Nicola.
-- 
chi va pian va san e va lontan

 ha scritto:

Anche io avevo avuto una sparata "simile" alla tua :-)
In realtà non puoi metterlo semplicemente in sync, perché metterlo in
sync equivale ad usare una copia identica. A quel punto tanto vale
usare l'originale.
Pertanto mi volevo inventare di utilizzare un proxy LDAP, che in
maniera trasparente, facesse delle redirect per gli attributi posix o
per quelle cose che possono mancare su Active Directory. 
Tieni comunque presente che Windows Server 2003 R2 (ripeto: R2) leggo
che dovrebbe avere le carte in regola per fare da LDAP per autenticare
le macchine UNIX.
Se ti trovassi invece con un server con versione più vecchia, allora
dovresti utilizzare i "Microsoft Services for Unix".
In definitiva, puoi usare tranquillamente AD come LDAP.
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"

 In definitiva, puoi usare tranquillamente AD come LDAP.
Concordo e confermo: io l'ho fatto diverse volte per macchine Linux e a 
parte un po' di smanettamenti iniziali, non ho mai avuto grossi problemi, 
senza usare nessun proxy LDAP
-- 
"Never underestimate the bandwidth of a station wagon full of tapes
hurtling down the highway" - Andrew S. Tanenbaum
http://blog.mainardi.me
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"

 metterlo in sync con active directory. Innanzitutto: è vero?
Non c'è bisogno.

 Preparati al bagno di sangue con ldap :P
Piu` che altro, il bagno di sangue e` quasi previsto per il fatto che 
OpenLDAP ha cambiato totalmente la struttura di configurazione, passando 
da un bellissimo file di configurazione ad un orribilissimo albero LDAP 
dedicato (in teoria non sarebbe male, se non fosse che non ci sono 
strumenti piu` o meno grafici che permettono di modificarlo). 
L'alternativa sarebbe utilizzare 389ds o OpenDS/OpenDJ, ma tutti e due 
richiedono risorse non indifferenti (e.g. OpenDS/OpenDJ e` completamente 
in Java) o conoscenze non banali (389ds non viene distribuito per Debian, 
bisogna compilarselo)
Enrico

 
ne approfitto per segnalare la presenza di un file tanto caruccio per
coloro che usano sudo:
/usr/share/doc/sudo-ldap/schema.ActiveDirectory.gz
Come si aggiunge uno schema su AD non lo so... però pare che si possa
fare.


Il giorno Sat, 5 Mar 2011 11:34:38 +0000 (UTC)
Enrico 'Henryx' Bianchi <enrico....@gmail.com_INVALID_> ha scritto:

389ds non mi dispiace, però:
389ds= iplanet, Netscape Directory Server, Sun DS 
389ds è un carrozzone degli anni '90 che nessuno riesce più a
manutenere.
In Sun c'è stato un bagno di sangue per portare il backend da ldbm a
sleepycat (BDB), e per aggiungere la possibilità di usare 4 master
piuttosto che 2.
Dopo di che, il progetto è stato abbandonato in favore di OpenDS.
Altra opinione:
guarda che OpenDS, nonostante sia un software scritto in java, in
realtà usa pochissime risorse. In termini di CPU sicuramente meno di
qualsiasi software analogo scritti in python e siamo ai livelli di un
software in C. In termini di RAM probabilmente è *leggermente* più
esoso. Ma parliamoci chiaro: che problema è la RAM nei server di oggi?
E da un'altra parte java ti consente di impostare un initial heap size e
anche un maximum heap size, e ti consente di monitorare i processi con
jconsole (ed in remoto con JMX) cosa che con i software in C ti sogni.
p.s.: OpenDS si tira su e si configura per l'autenticazione Unix/Linux
in 15 minuti. Oggi ho configurato sudo over ldap. Visto che era la
prima volta che lo facevo ho dovuto perdere un po' di tempo. Ho
scoperto dopo un po' di tempo che lo schema da aggiungere poteva essere
copiato dal 389ds, e più che altro lato client ho perso altro tempo per
capire come andava configurato.
Unico piccolo neo di OpenDS: la GUI non fa tutto e certe modifiche
devono essere fatte da linea di comando con il comando dsconfig.
Ma le guide di Sun - credimi - sono anni luce avanti rispetto a
qualsiasi documentazione disponibile per i software GPL e qualsiasi
cosa tu voglia fare troverai sempre documentazione dettagliatissima...
e non forum fuorvianti.


 strumenti piu` o meno grafici che permettono di modificarlo).
Quoto al cento per cento.


 in 15 minuti.
Si, lo so, probabilmente sostituiro` l'OpenLDAP che ho in ufficio proprio 
con OpenDJ, che e` un fork di OpenDS e che ti consiglio di usare in 
quanto non e` chiaro il destino del server Sun
Enrico

 On Sat, 05 Mar 2011 19:13:23 +0000, Max_Adamo wrote:

ti ho dato dopo retta aver letto il tuo messaggio ed aver scoperto che
mentre OpenDJ è arrivato alla versione 2.4 (rilasciata due giorni fa)
OpenDS è fermo alla 2.2 rilasciata non si da quando.
In pratica Oracle ha già un suo sistema di ID Management, e il
confronto tra quello di Sun e quello di Oracle non è impari come quello
tra mysql e Oracle dbms.
Per cui Oracle difficilmente manterrà in piedi due sistemi che hanno lo
stesso identico target. Uno dei due dovrà sicuramente morire. 


Grazie a tutti per le risposte, ci sto meditando... Void :-)