Das Notes Forum
Domino 9 und frühere Versionen => Administration & Userprobleme => Thema gestartet von: Wirsing am 10.07.03 - 14:56:46
-
Hallo zusammen,
ich habe gehört, dass es eine Möglichkeit gibt, Datenbanken in Lotus Notes mit doppeltem Passwort zu schützen.
Soll heissen, dass erst zwei bestimme User ihr Kennwort eingeben müssen, damit die Datenbank geöffnet wird.
Dies wäre für uns interessant, da ja die Admins über den AdminClient auf dem Server in jede Datenbank einblick haben.
Meine Fragen:
* Kann man so etwas einfach verwirklichen?
* Welche Software ist nötig?
* Kann man dieses Prinzip auf den Server beschränken (Handling der Maildatenbanken auf den Clients normal, auf dem Server aber mit zwei Kennwörtern vor unbefugter Einsicht gesichert)?
Gruss
wirsing
-
Hi,
man kann Notes-IDs mit mehreren Passwörtern versehen. Das macht man normalerweise bei Certifier-IDs, um dort das 4-Augen-Prinzip anzuwenden.
Datenbanken kann man so nicht schützen.
Oftmals sollen Dokumente vor den Admins geschützt werden. In diesem Fall würde ich mit Lesenamensfeldern oder Codierungsschlüsseln arbeiten.
Andreas
-
Es gibt natürlich folgende Möglichkeit. Man kreiere eine anonyme ID, wie z.b.: Mailzugriff.ID. Diese wird mit vielen Kennwörtern versehen, z.b. so viele wie Admins vorhanden und jeder bekommt genau eines mitgeteilt. Ebenfalls wird angegeben wie viele Kennwörter notwendig sind ( 2 oder 3 aus vielen). Abschliessend erhält der Pseudo Admin Managerechte auf alle Mailfiles und der Rest (Adminzugriffe) fliegt raus. Das ganze geschieht im Administrator Client
-
@widmaier
wenn ich aber alle manager rauswerfe (also auch den Server) kann es doch sein, dass die Schablonen nicht mehr upgedated werden usw. oder liege ich da falsch?
-
Halt, halt, natürlich nur die Personen. Und den User würde ich unter R5 nur Designer geben. Designer ist wichtig, damit der OoO Agent funktioniert, aber der User die ACL nicht mehr verändern kann! Die Server bleiben natürlich mit den entsprechenden Rechten in der ACL
-
Und den User würde ich unter R5 nur Designer geben. Designer ist wichtig, damit der OoO Agent funktioniert, aber der User die ACL nicht mehr verändern kann!
Dann hast Du nur ein kleines Problem mit der Delegierung, dafür muss nämlich die ACL verändert werden.
Meff
-
Ein kleiner Lösungsvorschlag:
Wir haben das mal bei einem Kunden so gemacht:
Server haben Managerzugriff
User hat Managerzugriff
Sonst steht niemand drin, es sei den, der Anwender vergibt die entsprechenden Rechte (z.B. über die Kalenderdelegierung)
Wenn jetzt ein Problem bei dem Anwender entsteht, sodass die Hotline da reinschauen muss, haben wir ein Mail mit einem Aktionsbutton drin, welches an den Anwender versendet wird. Der Anwender klickt diesen Button und trägt dadurch den Abesender des Mails in die ACL mit Managerrechten ein. Nachdem die Arbeit getan wurde, schmeisst der Admin sich einfach aus der ACL wieder aus.
Der Hintergrund, warum niemand in der ACL steht ist: Der Betriebsrat
Meff
-
Dann kann aber der AdminClient auf dem Domino in alle Datenbanken reingucken.
Genau das möchte ich ja nicht.
Wenn der Serveragent trotzdem die Datenbanken aktualisieren kann, ist es ja ok.
-
Dann kann aber der AdminClient auf dem Domino in alle Datenbanken reingucken.
Genau das möchte ich ja nicht.
Wenn der Serveragent trotzdem die Datenbanken aktualisieren kann, ist es ja ok.
Das verstehe ich jetzt nicht so ganz. Auf welches Posting beziehst Du den diese Aussage?
Meff
-
auf das von widmaier.
Die ACL umzustellen wäre ja ok, aber ohne Managerrechte für den Server gehen doch sämtliche 'Nachtjobs' nicht mehr.
Die Haupsache sollte sein, dass die Admins nicht mehr so einfach in die Datenbanken linsen können.
Anderer Ansatz:
Hat es Auswirkungen, wenn man die Programmdateien für den AdminClient auf dem Domino-Server löscht?
-
@wirsing
1. In den Datenbanken nur Rechte für Server und dem Eigentümer.
Die Administratoren haben dann keinen Zugriff auf die Datenbank. Nur lokal über den Server.
2. Welche Programmdateien für den AdminClient auf dem Domino Server????
;D MOD
-
Noch einmal von vorne:
User --> Designer / Person
LocalDomainServer --> Manager / Servergruppe
Administrationsserver --> Manager / Server
fertig!
Zusätzlich eine Pseudo ID mit X(Anzahl Admins) Kennwörtern, wobei mindestens 2 eingegeben werden müssen. --> Manager / Person
-
@widmaier
Wenn der Anwender keinen Managerzugriff mehr hat, dann kann er auch keine Delegierung mehr vergeben.
@wirsing
Am besten ist es immer, dass überhaupt niemand Zugriff ausser dem Besitzer und den Servern hat. Spricht irgendetwas gegen die Lösung mit dem Mail, dass die Admins im Problemfall Zugriff erhalten?
Desweiteren die Frage, die schon MOD gestellt hat: Was für Programmdateien willst Du den auf dem Server löschen. Ich habe so das Gefühl, dass entweder Du so einige Probleme zusammen hier auf den Tisch schmeisst oder wir irgendetwas komplet falsch verstanden haben. Vielleicht erklärst Du uns einfach nochmals in ein paar einfachen Sätzen, was Du machen bzw. verhindern willst.
Meff
-
ALSO:
Auf unserem Dominoserver (unter W2k-Server) gibt es unter \Lotus\Domino\Data die Datei notes.exe. Dieser Mini-Notes-Client hat VOLLE Zugriffsrechte auf alle Datenbanken, die den Server als Manager eingetragen haben.
DIES möchte ich möglichst unterbinden und stattdessen möglichst Mehrfachkennwörter für die Anwendungs- und Maildatenbanken nutzen.
Ich habe bereits bemerkt, das Mehrfachkennwörter nicht für Datenbanken nutzbar sind.
Hintergrund:
Uns möchte jemand auf die Füsse tappen und behauptet, wir würden in den Maildatenbanken unserer User rumstöbern.
Deutlich genug?
-
Wo liegt Dein Problem?
1. Wie mehrfach beschrieben, einfach die ACL entsprechend anpassen
2. Um zu verhindern, dass Du lokal an die DB´s über den Server rankommst, einfach die ACL konsistent machen. Wenn die ACL anständig gepflegt ist, also die Server wirklich als Typ Server oder Servergruppe drinstehen, kommst Du nicht mehr dran, auch lokal nicht.
3. Grundsätzlich kannst Du die notes.exe oder die nlnotes.exe auf dem Server löschen, allerdings hast Du diesen Client eh nur auf W2K Rechnern, unter UNIX gibt es sowas nicht. Allerdings löschst Du damit nur die Exe und ansonsten keine weiteren Dateien, die zum Aufrufen des Clients notwendig sind.
Meff
-
Ein kleiner Lösungsvorschlag:
Wir haben das mal bei einem Kunden so gemacht:
Wenn jetzt ein Problem bei dem Anwender entsteht, sodass die Hotline da reinschauen muss, haben wir ein Mail mit einem Aktionsbutton drin, welches an den Anwender versendet wird. Der Anwender klickt diesen Button und trägt dadurch den Abesender des Mails in die ACL mit Managerrechten ein. Nachdem die Arbeit getan wurde, schmeisst der Admin sich einfach aus der ACL wieder aus.
@Meff
Ich bin schon ewig auf der Suche nach einer Möglichkeit, wie man in Mitarbeiter-ACL's bequem User mit Manager-Zugriff einfügen kann. Deine Schaltfläche hört sich da ziemlich gut an. Könntest Du uns evtl. das Script zur Verfügung stellen? :D
Gruß
Markus
-
Ich muss es zwar noch Suchen, aber sobald ich es habe, werde ich das Ding posten.
Meff
-
So, tschuldigung, hat etwas länger gedauert. Hier der Script:
Sub Click(Source As Button)
' ###############################################################
' # mit diesem Script wird UserName in die ACL als Manager eingetrage,#
' # mit dem Recht Dokumente#
' ###############################################################
Dim s As New notessession
Dim workspace As New NotesUIWorkspace
Dim db as NotesDatabase
Dim acl as NotesACL
Dim uidoc As NotesUIDocument
DIM person as NotesAclEntry
Dim UserName as String
Set uidoc = workspace.CurrentDocument
uidoc.EditMode = True
Call uidoc.fieldsettext("flag","1")
Call uidoc.save
UserName=s.UserName
Set db=s.currentdatabase
Set acl=db.acl
Set acl = db.ACL
Set Person = acl.GetEntry(UserName)
If ( Person Is Nothing ) Then
Set person=acl.createaclentry(UserName,ACLLEVEL_MANAGER)
Else
person.level= ACLLEVEL_MANAGER
End If
person.candeletedocuments=True ' falls er Dokumente
löschen darf
' person.usertype=ACLTYPE_Person ' nur bei Version 5
möglich!!!!!!!
acl.save
uidoc.EditMode = False
End Sub
Das ganze als Button in ein Mail und das war´s.
Meff
-
Ich werd das ganze mal Testen.
Schon mal vielen Dank für Deine Arbeit.
Gruß
Markus
-
Hallo,
wir handeln das so:
1. In der Regel gibt es ja keine Veranlassung mit der Server ID sich anzumelden.
2. Die Rechte braucht der Server
3. Zugriff auf Server am Server direkt - 4 Augen Prinzip
4. Dokumentation (Warum, Wieso, Weshalb) + Information an Abt.-Leiter
5. Wer diese Regeln bricht hat echt Ärger am Hals (Cheffe + Betriebsrat)
-
@Bubble
grundsätzlich richtig, dass Problem ist nur, dass nachzuvollziehen. Ich hatte es jetzt schon mehrmals, dass von Anwenderseite die Vermutung geäussert wurde, die Administratoren fummeln im Mail rum und wenn das dann noch von einem hohen Tier kommt, hast Du ziemlich versch....Daher ist es schon am besten, wenn man den Zugriff entsprechend beschränkt, kann Dir viel Ärger ersparen.
Meff
-
@Meff,
1. Du weißt selbst mit einer gewissen kriminellen Energie kommt man überall dran. :D
2. Meistens muß man ja in der Firma eine Datenschutzerklärung unterschreiben.
3. Liegt es mir fern Mail DBs anzuschauen - man hat ja sonst nichts zu tun
4. Sensible User (GFs) PGP
@Wirsing
Alles eine Frage Sicherheitsstrategie und der Kosten