Il sistema di gestione delle rubriche in domino è piuttosto complesso dato che deve soddisfare svariate esigenze:
- permettere il lookup dei nomi per l'indirizzamento di posta
- permettere il lookup dei nomi per le autenticazioni e/o autorizzazioni su diversi protocolli; notes, http, ldap, etc.
Fondamenti sulla Domino Directory
Domino usa per ogni dominio Domino obbligatoriamente una Domino Directory (chimata anche NAB=Notes address book o names.nsf). All'interno di questo database sono registrati utenti e server del dominio. Questa rubrica viene automaticamente replicata su tutti i server del domino per i motivi sopra elencati.
Caricando il task LDAP con il comando "load ldap" in automatico viene pubblicata la rubrica names.nsf sul protocollo LDAP(il quale può essere letto da un client LDAP di posta come ad esempio outlook).
La DD (Domino Directory) è stata generata dal modello pubnames.nsf e questo modello è utilizzabile per creare altre Directory secondarie.
A cosa server una Directory secondaria?
In genere una directory secondaria puo essere utilizzata per:
- creare ex novo contatti per uso aziendale (fornitori clienti, etc..) come spedizione posta e registrazione di informazioni.
- creare ex novo contatti (nome utente e password internet) per utilizzo applicativo. Ad esempio per permettere l'accesso ad applicazioni web sviluppate su domino.
- Pubblicare la Domino Directory di un'altro Dominio. Ad esempio se avessi due aziende che utilizzano entrambe domino (R4.6.x; R5.x; R6.x) ma che sono nate come entità separate, posso decidere di replicare la domino directory da una azienda all'altra per permettere lo scambio di posta mediante protocollo nativo NRPC e non più tramite SMTP(è necessaria una procedura di cross certificazione per permettere al domino A di scambiare dati con il Dominio B).
In caso di creaziono ex novo avete a dispozione due modelli:
pubnames.ntf | Di interfaccia poco "User Friendly" è decisamente il modello più funzionale che permette sia il lookup degli indirizzi per spedizione posta che l'autentica sui protocolli HTTP; SMTP;POP3;IMAP;LDAP |
pernames.ntf | Con interfaccia per l'uso da parte degli utenti finali può essere utilizzata solo per la spedizione della posta ma non per l'autentica sui protocolli sopra citati (a meno di modifiche di disegno). |
Come posso pubblicare una rubrica secondaria?
Per permettere agli utenti notes di visualizzare ed interrogare anche rubriche secondarie per l'indirizzamento posta e/o per l'autenticazione sui protocolli HTTP; SMTP;POP3;IMAP;LDAP sono necessarie queste operazioni:
1. Creare sul domino server (o posizionare se esiste già) una rubrica generata dai modelli pernames.ntf o pubnames.ntf
2. Creare il database Directory Assistance (dal modello DA50.ntf)
3. Configurare il server perchè utilizzi il Directory Assistance appena creato
4. Pubblicare all'interno del DA (Directory Assistance) il database creato al punto 1.
A cosa server la Directory Assistance?
La Directory Assistance è un database che si preoccupa di gestire come pubblicare rubriche secondarie e che tipo di utilizzo è permesso. Ad esempio è possibile definire chi può utilizzare le rubriche secondarie; se queste debbano essere utilizzate per autenticazioni sui protocolli come HTTP, POP, etc... e se si vuole permettere ad utenti Domino di interrogare un LDAP server esterno (Ad esempio Active Directory o qualsiasi LDAP standard v3).
Di fatto non esiste limite al numero di rubriche che si possono pubblicare nel DA, ma esistono dei limiti funzionali. Ad esmepio l'autentica di componenti in gruppi definiti su una rubrica secondaria è possibile solo per una rubrica secondaria. Questa limitazione però può essere superata se viene implementato anche l'Extended Directory Catalog.
Utilizzo di Directory Catalogs
In domino è possibile implementare due tipologie di Directory Catalog:
Condensed Directoy catalog | Questo database che viene
genearato dal modello Dircat.ntf ha lo scopo di aggregare 2 o più directory
(in genere la names.nsf + altre directory create dai modelli pernames.ntf
o pubnames.ntf) filtrando i campi da aggregare. Questo permette di avere
un databse che mediamente pesa 1/10 dei database sorgenti e utilizzarlo
per due scopi:
|
Extended Directory catalog | Questo database viene generato dal modello pubnames.ntf ed esegue come il "Condensed Directoy catalog" una aggregazione di documenti filtrando solo una serie di dati. La differenza rispetto al condensed è che può essere utilizzato per la gestione delle autentiche sui protocolli e soprattutto per le autentiche su gruppi di utenti residenti su diverse rubriche secondarie. Inoltre migliora notevolmente le performance per l'indirizzamento di posta su grandi volumi. |
Le argomentazioni di questo documento valgono sia per la R5 (a partire dalla R5.0.5)che per la R6 con alcune eccezioni sulle autenticazioni per quanto riguarda i gruppi sulle rubriche secondarie Della R5. Ossia sulla R5 i gruppi di utenti per le autentiche devono essere per forza nella Domino Directory (names.nsf) non funzionano su rubriche secondarie.
In aggiunta per il funzionamento di autentica su rubriche secondarie sulla R5 (per protocolli internet) è obbligatorio aggiungere nel notes.ini questo parametro:
INET_Authenticate_with_Secondary=1
Visibilità delle rubriche
Qunado una rubrica secondaria viene pubblicata nel Directory Assistance tutti gli utenti del server riusciranno ad eseguire il lookup degli indirizzi contentuti in questa rubrica anche se a livello ACL questi utenti non abbiano diritti di accesso. Il motivo è dovuto dalla funzione lookup che di fatto baipassa la ACL.
Una maniera per evitare che utenti in rubrica secondaria vengono "visualizzati" per l'indirizzamento posta (type-ahead) da utenti che non devono essere autorizzati è di controlloare gli accessi a livello dei campi lettore. Nelle directory sono già presenti questi campi, è necessario interventire per aggiungere dei ruoli (ma sulla R6 ho riscontrato diversi problemi...) per la visibilità oppure definire direttamente nel campo lettore i gruppi di utenti autorizzati.
9 Commenti:
ciao
Nel client notes se vai nella rubrica personale, quindi vai sul bottone More - Preferences lo trovi....
la funzione nella R 8.5.2 è diventata:
Do not automatically add:
sotto decidi gli elementi da non inserire nei recent contacts
1] comprendere le rubriche di Domino
Creato il 22/05/2009 16.19.59 da Claudio
disabilita: "do not automatically add names to the recent contacts...."
sono interessata a tale funzione ma purtroppo non so dove trovarla
grazie
cordiali saluti
lucia sacco
correzzione.... disabilita: "do not automatically add names to the recent contacts...."
vai nella rubrica personale locale sotto MORE - preferences e disabilita: Enable Synchronize Contacts....."
credo potrebbe essere inerente, e quindi posto...
Con Notes 8 quando apro un nuovo messaggio in arrivo, il mittente viene immediatamente aggiunto nella rubrica personale. C'è un modo per disabilitare questa funzione?
ti pregherei di postare la domanda nel forum... CMQ... permettimi il dubbio... perchè replicare la rubrica locale su server?.... Normalmente nessun utente è autorizzato a creare repliche (nuovi database) su server altrimenti sarebbe un delirio. Nel Documento del server sotto security basta mettere il nome persona nel campo: Create new replicas:
Salve a tutti,
siccome l'argomento mi sembra inerente, vorrei chiedere perchè un utente domino 6.5 con l'apposito Notes non riesce a creare una replica della propria Personal Address Book su una cartella del server (cartella PABS dentro a lotus\Domino\Data).
Mi restituisce il messaggio: utente non autorizzato a eseguire questa operazione.
Su un altro utente me lo fa senza battere ciglio.
FATALITA' l'utente a cui non funziona è il big-boss della situazione...
premetto che:
-NON sono un esperto di IBM, AT ALL.
-la cartella ha i permessi NTFS Full Control per quell'utente.
-L'utente è manager di se stesso e del suo file mail.
-Ho provato ad impostare le ACL di domino di quella directory per essere sicuro che quella persona AVESSE accesso.
ciao Stefano,
dunque, l'ho "RISOLTO" inserndo un campo reader nella form dei contatti dove all'interno metto il gruppo di persone. Purtroppo avevo letto nel KnoeledgeBase di IBM(e verificato) che il ruolo inserito nel campo reader sulla R6 (ma pare che anche sulla R7 non sia stato risolto)non funziona (intendo per il type-ahead)
Sarei molto interessato a sapere che tipo di problemi hai incontrato nell'utilizzare i ruoli per gestire la visibilità dei contatti in rubrica secondaria nella release 6 (ultime righe del tuo intervento). Nel frattempo hai trovato altre soluzioni.
Ciao e grazie