Notes Webaccess "härten"?

[schroederk]

Hallo,

bisher bin ich davon ausgegangen, dass nur die DWA7-Schablone den Webaccess ermöglicht und die Standard-Mail-Schablone Mail7 eben nicht.
Demzufolge sind die Restriktionen was Passwörter etc betrifft nicht gerade sehr stark. Bei einigen Notes-Accounts handelt es sich um Wechsel-Arbeitsplätze wie Azubis oder Produktion. Die haben leider nur sehr leichte Kennwörter.
Die DWA7-User haben ausreichend starke Kennwörter, die für Webaccess geeignet sind.

Lange Rede kurzer Sinn... Kann ich mit Notes-Boardmitteln ausschließlich DWA7-User für Webaccess zulassen und alle anderen aussperren?

Derzeit fällt mir lediglich ein, die Mail7-Schablone zu verwuschteln und die Web-Views zu deaktivieren.

Wäre mir sehr lieb, wenn es hier eine saubere Lösung gäbe. 

[Christopher]

Hm gute Frage evtl. wäre die sauberste Lösung für die Webuser einen sepperaten Server zu betreiben. Auf dem anderen Server wird der HTTP Task deaktiviert. Was anderes fällt mir da jetzt nicht ein.

[m3]

Du möchtest also nicht den Server "härten", sondern eigentlich den Zugriff über das Web auf eine bestimmte Gruppe, unabhängig von der Datenbank beschränken?

IMHO wird das mit Bordmitteln nicht gehen.

Du könntest IMHO:
a) die Benutzername/Passwort Anmeldung deaktivieren und den berechtigten ein Internet-Zertifikat zur Anmeldung geben (Handling?)
b) ein DSAPI schreiben, das nur die Anmeldung von Benutzern, die in einer Gruppe sind, zulässt

[hallo.dirk]

Wenn Du Geld ausgeben möchtest kannst Du den Server z.B. mit SecureDomino härten...


mehr Infos hier:
http://timetoact.de/ttacms.nsf/id/SecDomEN

Das wird aber nicht billig......

[schroederk]

Ich hatte "härten" geschrieben, da ich die Funktion Webzugriff für Mail7 entfernen wollte. Somit eine Funktion, die nicht notwendig ist. 

Das Entfernen der Kennwörter ist leider nicht möglich, da sonst kein Sametime möglich ist.
(Ist ja imho dummerweise dasselbe Kennwort)

Das Anschaffen und Betreiben eines zusätzlichen Notes-Servers ist wohl die sauberste Lösung, obwohl ich wohl die Mail-DBs der User lediglich zu diesem Server replizieren würde.
Ich fand die Lösung nur mit Kanonen nach Spatzen schiessen, wenn es eine Notes-eigene Lösung gegeben hätte. (Ist ja auch nicht gerade billig: Kosten für Server, Serverlizenz ...)

Die SecureDomino-Software klingt recht vielversprechend, allerdings ist mit Geld ausgeben erstmal ungünstig. Vielleicht kann ich es bei der Investplanung 2008 berücksichtigen lassen.

Hatte gehofft, es gibt irgendwo ein Access-Filter, wer (User / Schablone) darf und wer nicht.

[pinodriver]

Hi schroederk, sofern nur DWA-User per Browser auf genau diesen Server zugreifen sollen, kannst du bei allen anderen den Zugriff über die "erweiterte ACL" "Max. Internet-Namens-  und Kennwortzugriff" steuern. Alle die nicht auf Ihre (Mail-)Datenbanken zugreifen dürfen bekommen den Eintrag "no access".
Über einen Vhost und der Redirect-DB für DWA kannst du den Zugriff über eine Gruppe steuern.
Hoffe ich habe mich nicht zu umständlich/schwierig ausgedrückt

[m3]

Hi schrederk, sofern nur DWA-User per Browser auf genau diesen Server zugreifen sollen, kannst du bei allen anderen den Zugriff über die "erweiterte ACL" "Max. Internet-Namens-  und Kennwortzugriff" steuern. Alle die nicht auf Ihre (Mail-)Datenbanken zugreifen dürfen bekommen den Eintrag "no access".

WOW. Geschickt. 
Daran hätt ich gar nicht gedacht.

Über einen Vhost und der Redirect-DB für DWA kannst du den Zugriff über eine Gruppe steuern.

Da kann ich dir leider nicht folgen. Etwas ausführlicher?

[pinodriver]

Über einen Vhost und der Redirect-DB für DWA kannst du den Zugriff über eine Gruppe steuern.

Da kann ich dir leider nicht folgen. Etwas ausführlicher?

Auf deinem Mailserver richtest du einen virtuellen Server ein. Es wird aus dem Template "dwaredirect" (iwaredir.ntf) die Redirect-DB für DWA erstellt und in dem virtuellem Server als Einstiegspunkt hinterlegt. In der DB wird eine ACL-Gruppe als "leser" eingetragen. Nur authorisierte Benutzer können nun das Script ausführen lassen, welches den Pfad zur Mail-DB aus dem Adressbuch ausliest und den URL umschreibt. Nicht-authorisierte bekommen einen Hinweis. Die DB ist nicht für die Sicherheit sondern für die Anwenderfreundlichkeit geschrieben worden. Die DBen müssen über die erweiterte ACL gesichert werden.

[m3]

Auf deinem Mailserver richtest du einen virtuellen Server ein. Es wird aus dem Template "dwaredirect" (iwaredir.ntf) die Redirect-DB für DWA erstellt und in dem virtuellem Server als Einstiegspunkt hinterlegt. In der DB wird eine ACL-Gruppe als "leser" eingetragen. Nur authorisierte Benutzer können nun das Script ausführen lassen, welches den Pfad zur Mail-DB aus dem Adressbuch ausliest und den URL umschreibt. Nicht-authorisierte bekommen einen Hinweis. Die DB ist nicht für die Sicherheit sondern für die Anwenderfreundlichkeit geschrieben worden. Die DBen müssen über die erweiterte ACL gesichert werden.

Ah, OK. Also nur für die bessere "Optik".

[schroederk]

sofern nur DWA-User per Browser auf genau diesen Server zugreifen sollen, kannst du bei allen anderen den Zugriff über die "erweiterte ACL" "Max. Internet-Namens-  und Kennwortzugriff" steuern. Alle die nicht auf Ihre (Mail-)Datenbanken zugreifen dürfen bekommen den Eintrag "no access".

Das hört sich ja sehr gut an...   
Und das hat keinen Einfluss auf den Notes-Client-Funktionalitäten bzw. auf Sametime, lediglich Webaccess?
Wenn nicht, dann wäre das meine Lösung! 

[pinodriver]

Notes: Auf Notes hat es keine Einflüsse, da es sich hier um http und nicht nrpc requests handelt.
Sametime: Sametime hat ja sozusagen nichts mit Mail zu tun. Sofern du nicht mit einem Browser auf die Mail-DBen zugreifst (ausgenommen natürlich die DWA-Postfächer) hat es keine Einflüsse.