(mere) argomento complicato.... capisco la volontà di togliersi il problema password, ma credo che il tuo ragionamento possa funzionare in condizione di utilizzare delle smartcard.. le id su file-server ... io non le considero al sicuro (soprattutto se non hanno una password di protezione)...
Devi inoltre considerare che in caso di trafugamento di ID..... non è così immediato rendersene conto..... quindi la password resta la bariera più importante (niente vieta agli utenti di farsi copie e via dicendo...). Quindi c'è una differenza sostanziale tra il zero password e l'SSO..... SSO viene gestito e non preclude alla ID di avere una propia sicurezza.... Infatti SSO funzionerà se la persona utilizzerà il proprio PC, e noi non ci dobbiamo proteggere tanto dal fatto che qualcuno prenda il pc di un nostro utente ... anche, ma la condizione più pericolosa e più "invisibile" è la sottrazione della ID.
Non per ultimo verresti meno ad una normativa di legge Italiana... che non solo pretende password ma anche con una lughezza minima, etc....
spero di esserti stato di aiuto....
(Antelope) [QUOTE]
Premessa: riguardo la sicurezza, sono paranoico.:gun:
[/QUOTE]
Anche io, abbastanza.. :-)
[QUOTE]
Una soluzione del genere, mi sembra un incubo.. lasciare gli ID senza password, mi sembra una grave violazione della sicurezza.
[/QUOTE]
Ma perchè? Gli ID sono accessibili solo se l'utente si autentica sul dominio, o comunque sul file server dove sono memorizzati. Compromettere quella password potrebbe significare problemi molto più gravi di quelli che potrebbero venire dalla compromissione della posta elettronica: è chiaro che deve essere già ben gestita in partenza. Da dove potrebbe venire esattamente il rischio di una <<grave violazione della sicurezza>>?
Il meccanismo che ho proposto mi sembra molto simile al signon senza password tramite ssh su un sistema unix/linux, a partire da un altro sistema dove mi sono già autenticato (si basa tutto sul proteggere tramite la prima password una chiave privata).
[QUOTE]
Potresti fare in un modo diverso: sincronizzare la password notes con la password del dominio (ed hai un minimo di sicurezza :)) e poi gestisci gli utenti come "roaming users". Lasci le informazioni degli utenti (names, desktop, etc) sul server e quando si loggano gli utenti, viene trasferito tutto su client degli stessi....
[/QUOTE]
Già fatto, cioè utilizzo il servizio di single signon. Il punto è che 1) la procedura del rinnovo password di Notes è afflitta dai soliti problemi di interazione con l'utente mal progettata che affliggono tante parti dell'ambiente e 2) idem con patate, gli utenti roaming funzionano ma è tutto "ostile" all'utente finale. NB: non voglio parlare di questo ora, cioè delle problematiche della scarsa qualità dell'interfaccia utente di Notes (che secondo me esistono eccome), voglio sapere se la mia idea iniziale è praticabile e dove stanno esattamente le debolezze.
(Giuseppe) meeting via chat? un'ottima idea!
ps:
tempo fa mi pare si fosse già tentata una cosa tipo chat di dominopoint o ricordo male?
(Giuseppe) ok, ci provo, facendo riferimento al mio post precedete
- lascia perdere @failure e @success, per il web non sono molto utili :-)
ErrMsg inizializzato a stringa vuota ""
per ogni campo (es, campo cognome), il codice di validazione è del tipo:
@if(cognome<>"";"";ErrMsg:=ErrMsg:"errore Cognome obbligatorio")
ovvero, se supero la validazione non faccio nulla, altrimenti aggiungo l'errore in ErrMsg
alla fine, il campo $$return deve essere valorizzato in funzione del contenuto di ErrMsg.
spero che questo ti aiuti a chiarire, altrimenti, se questo genere di cose è di interesse comune posso provare a scrivere un post per dominopoint.it che descriva la tecnica allegando un database di esempio
(GianClaudio) Premessa: riguardo la sicurezza, sono paranoico.:gun:
Una soluzione del genere, mi sembra un incubo.. lasciare gli ID senza password, mi sembra una grave violazione della sicurezza.
Potresti fare in un modo diverso: sincronizzare la password notes con la password del dominio (ed hai un minimo di sicurezza :)) e poi gestisci gli utenti come "roaming users". Lasci le informazioni degli utenti (names, desktop, etc) sul server e quando si loggano gli utenti, viene trasferito tutto su client degli stessi....
(Antelope) Mi chiedevo se era possibile gestire gli utenti con dei file user.id privi di password.. per favore ditemi se quanto segue ha un senso o se sto sbagliando clamorosamente qualcosa :-)
1) nei Security Settings del documento server, seleziono:
- Compare Notes public keys against those stored in Directory = YES
- Allow anonymous Notes connections = NO
- Check passwords on Notes IDs = DISABLED
2) registro gli utenti con user.id con password facoltativa
3) memorizzo gli user.id esclusivamente su un file server, p.es. nelle home directory degli utenti, che sono accessibili solo dopo autenticazione su un dominio Windows o quant'altro
In questo modo un utente potrà accedere a Notes solo dopo essersi autenticato sul dominio, perchè altrimenti l'user.id è inaccessibile.
Possono esserci delle situazioni che compromettono il livello di sicurezza, ma non mi sembrano peggio di quelle che possono accadere nella normale gestione di una password:
- l'utente (ma ci vuole un utente evoluto) copia l'user.id p.es. sul proprio PC, che non è altrettanto sicuro di un file server. Questo potrebbe equivalere a "scrivere la password da qualche parte", e non può succedere per caso.
- l'utente invia il proprio user.id ad un altro utente. Questo equivale a "rivelare la password ad un altro".
Nel caso di compromissione di un user.id, non resterebbe che ri-registrare l'utente. Ciò equivale a "cambiare la password". L'opzione "compare notes public keys.." del documento server dovrebbe garantire che l'user.id compromesso sia inutilizzabile.
La scadenza pianificata dell'user.id e successiva ricertificazione è equivalente alla scadenza pianificata della password.
Per chi non lo avesse capito, sto cercando di capire se è possibile eliminare la gestione delle password di Notes senza naturalmente compromettere la sicurezza del sistema. Commenti? :-)
(DanteS) RINNOVO LA MIA RICHIESTA DI HELP!!!....la risposta di Giuseppe mi ha dato il LA per fare qualcosa...ma credo di non essere riuscito a capire perfettamente il suggerimento...tanto da essermi incasinato a palla!!!!!!
(alessandrobl) Fantastico!!
Grazie per l'aiuto ragazzi!!
Ciao e a presto!
(mr.hot) Grazie
buona serata
ciao
Franco
(mere) certamente, l'amministrazione di server è indipendente dalla piattaforma, ossia il client di amministrazione è installabile solo su PC Win e amministra allo stesso modo (graficamente) server domino su qualsiasi piattaforma..
Inoltre è anche presente una interfaccia grafica Web di amministrazione...
(mr.hot) Carissimi,
mi sapreste dire cortesemente se l'amministrazione di Domino (ver. 5 e ver. 6.5) su sistemi operativi SUN e LINUX viene effettuata con interfaccia grafica ?
Grazie in anticipo
ciao, Franco
(GianClaudio) oppure ancora meglio e soluzione piu' pulita, utilizzi la directory assistance per creare una rubrica fornitori e su questa registri le persone esterne a cui vuoi dare accesso via HTTP.
Non ti "sporchi" la rubrica principale e ne puoi dare la gestione di questa rubrica ai tuoi utenti, in modo tale che loro si gesticono chi deve accedere al database in questione...
(GianClaudio) ma secondo me se hai creato una policy per l'archiviazione in locale, i tuoi utenti devono selezionare i documenti e poi fare "action/archive/archive selected documents".
Se la policy e' in locale, hai quel messaggio di errore....
Facci sapere
(GianClaudio) Per limitare la possibilita di archiviare, devi dare una occhiata alla policies. Vai alla rubrica indirizzi (names.nsf) e controlla quello che hai sotto : configuration/polices/settings.
Le policies posso essere applicate sia a livello di organizzazione che a livello personale.
Inoltre se guardi il documento persona, nel tab "administration" puoi vedere se l'utente ha delle policy assegnate direttamente.
(mere) su template R5 devi per fare un agent che esegue il forward... ma così facendo non otterai mai il risultato che hai con le rule della R6 e R7....
(GianClaudio) scusa del ritardo nella risposta... era un vecchio database che avevo trovato parecchio tempo fa e che mi ricordo aver utilizzato, ma ad essere sincero, non ricordo la versione...:-( forse era con la versione 5 (a giudicare dal tempo) ... magari prova ad installare su un client al volo la versione 5 e magari non ti da errore...
(michele.lp) Come non detto...la risposta automatica funziona ma il forward no...nel senso che il forward l'avevo impostato sul documento persona...dal db di posta dell'utente non posso creare una regola di forward perchè utilizzano il template 5...
(Giuseppe) le cose sono un po' più complicate di così :-(
i folder privati al primo uso, possono essere istanziati via lotuscript con
notesDatabase.GetView( viewName$ ) per il backend e
notesUIDatabase.OpenView( viewName$ [, key$] [, newinstance] ) per il frontend
tuttavia, i folder privati al primo uso presentano alcune problematiche che vanno affrontate:
- il primo utilizzo deve forzatamente essere nel frontend, quindi, per ogni utente dell'applicativo, il folder non può essere utilizzato nel backend se prima non è stato istanziato almeno una volta nel frontend
- in caso di aggiornamento del template che comporti modifiche al modello del folder privato al primo uso, i vecchi folder di ogni utente dovranno essere cancellati perchè sia possibile ricrearli con le nuove impostazioni.
(michele.lp) grazie mille...funziona...(non avevo dubbi :-) )
(mere) non esiste una funzione ad hoc per quello che vuoi fare... ma dato se hai impostato una regola di inoltro dal database di posta del utente, potresti usare il seguente articolo per creare appunto una rispsota automatica ad ogni messaggio ricevuto nel database (partendo dal presupposto che ogni messaggio ricevuto è stato poi inoltrato)
http://www.dominopoint.it/Dominopoint/dominopoint_blog.nsf/dx/autreply.htm
questo sistema è utile se usi la rule inoltra dal db di posta del utente... se usi l'inoltro diretto dal documento persona allora non hai modo per intercettare la cosa e rispondere..
(michele.lp) Ciao a tutti, avrei bisogno di una dritta....devo impostare, per alcuni utenti, il forward. E fin qui tutto ok, già fatto...però devo far inviare all'indirizzo del mittente un messaggio tipo "Il messaggio è stato girato al seguente indirizzo mmm@nnn.com. ecc ecc". Come fare da server ad impostare il tutto?
Grazie
(mere) si... se prima li registri nella tua Domino directory (names del server) e gli dai gli accessi al database in questione..
(gabrielesh) Noi ci siamo scritti un piccolo pop3 retriever in java che funziona lato Domino come database .nsf.
Il tutto funziona interamente su domino senza software esterni come un agent schedulabile, con il solo protocollo POP3.
Non abbiamo implementato il protocollo IMAP.
Se vuoi te lo spedisco, free.
(gabrielesh) per esempio aprendola
(gabrielesh) Puoi modificare il form Memo, la sub postSave lanciando una tua routine.
Hai diverse possibilità per archiviare la posta nello stesso db o in un altro, avendo a disposizione il doc appena salvato.
(alessandrobl) Grazie Mere, ma possono creare documenti anche gli utenti che non sono della mia ditta? Questo perche l'ufficio tecnico che scambia DWG da 25 mb "colloquia" con un fornitore che non ha un account nel server..
Grazie per l'aiuto e la pazienza!
(alessandrobl) Grazie Mere, ma possono creare documenti anche gli utenti che non sono della mia ditta? Questo perche l'ufficio tecnico che scambia DWG da 25 mb "colloquia" con un fornitore che non ha un account nel server..
Grazie per l'aiuto e la pazienza!
(mere) bhè fondamentalmente qualsiasi template della R6 è utilizzabile via web.... potresti usare il discussion o Doc Library.... in entrambe creando un documento puoi allegare qualsiasi cosa come se fosse una mail...
(mere) Sei sicuro di avere configurato la policy perchè il client esegua l'archiviazione in locale della posta e non su server???... in genere quel errore avviene quando esistono delle impostazioni di archiviazione che richiedono che il processo di archiviazione venga eseguito da server con il compact -a
Se nella policy hai attivato Proibisci criteri personali, prova a disabilitarlo e andare nei setting del archiviazione dal client a verificare i parametri di archiviazione....
ciao
(ssadsv) Risolto con l'aggiornamento alla versione sucessiva di Domino (6.5.4), probabilmente c'era qualche file corrotto e con l'aggiornamento si sono ripristinati.
Ciao a Tutti.