lockout ID

[luna]

hallo,

ich hab schon hier gesucht, aber unter "lockout" nix gefunden.

bei uns geht die post ab. da gehen oft user von einer sekunde auf die andre, die duerfen dann ab sofort nirgends mehr zugriff haben. frueher hab ich die dann sofort geloescht, dann gingen die vor gericht, und standen ein paar tage spaeter wieder hier.

ich hab nun im nab heute das erste mal die funktion "lockout ID" benutzt. kenne mich da aber leider ueberhaupt nicht aus.

heisst das jetzt wirklich, definitiv und 100%ig, dass der user mit dem notes client nicht mehr an seine mail files kann? kann ich mich da drauf verlassen?

und koennte ich dann bei bedarf den user wieder hinlassen? wenn ja wie?

vielen dank fuer jede meinung,
gruss,
daniela

[eknori]

Also ich gehe da wie folgt vor:

den Eintrag im NAB kopiere ich in ein "temporäres Adressbuch" (Gestaltung des NAB).
Dann lösche ich den User im Nab mit Hilfe des Adminclient. Hier hast du ja auch die Option den User in eine sog. DenyAccess Group einzutragen. Diese Gruppe muss natürlich auch im Serverdokument eingetragen sein.

Der User  ist dann , nachdem der Adminp gelaufen ist aus allen gruppen ACL etc gelöscht.

Die Maildatei lösche ich nicht; ( erstens mache ich eine Kopie auf CD, zweitens bekommte der Vorgesetzte den Zugriff ) Nach 3 Monaten lösche ich dann auch die MailDB.

Selbst wenn der User seine ID mitnimmt, kommt er durch die Deny Access Group nicht mehr ins System.
Sollte er dann wider Erwarten doch wieder auftauchen, kopiere ich das gesicherte Personendokument wieder zurück ins NAB. Dann noch den User aus der DenyAccess herauslöschen und schon ist er wieder am Draht.

Das System funktioniert bei uns sehr zuverlässig; wir haben eine sehr hohe Fluktuation. durch viele Leiharbeiter, die teilweise 4-5 mal pro Jahr für Projekt bei uns sind.

Ulrich

[luna]

hallo ulrich,

vielen dank fuer deine ausfuehrungen. ich hab an die deny access gruppe gar nicht mehr gedacht.

es ist so, dass der user grad das haus verlassen musste, jedoch ich nicht weiss, ob er morgen wieder kommt. eigentlich sollte er nie wieder kommen.

ich mach das jetzt aehnlich wie du beschrieben hast. danke fuer deinen tip.

aber trotzdem wuerde mich interessieren, was dieses lockout ID genau macht und wie man es wieder wegbekommt (nun neugierig).  

gruss,
daniela

[eknori]

Bich ich blind; wo finde ich das ??

[Fis]

Hallo Ulrich,

ich hab dazu auch mal ein paar Fragen, Bei uns klappt das nicht das der User dann aus allen ACL´r raus getragen wird, und wie kann ich den User in die Deny Access bekommen ohne in das Adressbuch zu springen und mit copy and Paste zu arbeiten


Gruß Rodan

[luna]

natuerlich bist du nicht blind !!!

ich geh ins nab auf den user
dann im menu: actions / set password fields
dort dann: check password: lockout ID

gruss,
daniela

[eknori]

Hallo Rodan,

erst einmal musst du dir eine solche gruppe unter Server - Gruppen ohne Zugriff im NAB erstellen.

Wenn du jetzt einen Benutzer im NAB über die AKTION Person löschen löscht ( nicht einfach nur markieren und dann Entf !! ) öffnet sich ein Dialog, in dem du unter anderem die Option "In Gruppe eintragen" hast; hier wählst du dann die DenyAccess Group aus.

Im Serverdokument muss die Gruppe im Feld "Kein Serverzugriff" im Abschnitt Sicherheit eingetragen werden.

In das NAB habe ich mir einen Agenten eingebaut, der über eine einfache Aktion ( In Datenbank kopieren) den Personeneintrag in das temp NAB kopiert.

eknori

[eknori]

AHHHH, Danke Daniela. Muss mal sehen, was der Adminp da macht. Ich vermute mal, der schiebt den User in die DenyAccess Group. Werde das mal testen

[andi_g]

Hi Leute,

hier die Aufklärung über die Funktion Lockout ID!

Dies ist eine klasse Funktion von Notes (die schnellste Funktion User aus dem System zu verbannen). Mit den Access Deny Gruppen wäre ich vorsichtig. Diese Gruppe muss dann in alle Datenbanken mit "kein Zugriff" stehen. Sonst ist sie wirkungslos. Die Funktion Lockout ID ist genau für die beschriebene Situation gedacht.

ABER! Vorher bedarf es noch ein paar Konfigurationsschritte:
Die betroffenen Server (von denen der User ausgeschlossen werden soll) sind folgendermaßen zu konfigurieren:
Im Serverdokument muss die Option "Check Passwords on Notes IDs" (Passwort auf Notes IDs überprüfen) aktiviert werden (Security - Security Settings)!

Alle User bei denen im Personendokument die Option Lockout ID aktiviert ist, haben keinen Zugriff auf diese konfigurierten Server. Der Server verweigert jede Authentifizierung mit diesen Usern. Wird die Option Lockout ID deaktiviert ist alles wieder beim alten.

alles klar??

Diese Funktion kann ich nur empfehlen!!!!!!

mfg
andi

[Fis]

Wir richten in allen Templates die Gruppe Deny Access ein, das reicht aus.

[luna]

hallo andi,

vielen dank fuer diese ausfuehrung. dann ist das also genau richtig fuer mich. die settings check ich gleich noch.

dass die gruppe "deny access group" in jeder datenbank als gruppe mit no access angelegt werden muss, das hab ich nicht gewusst. hoer ich heute zum ersten mal. reicht es denn nicht, wenn default auf no access steht? wahrscheinlich nicht, oder?

und, wie deaktiviere ich den lockout dann wieder? ich finde da nix.

gruss,
daniela

[andi_g]

hi daniela,

indem du im Personendokument die Option Administration - Check password: Don't check Password oder Check Password einstellst. Dann sind die User wieder berechtigt sich mit dem Server zu authentifizieren. In dem du sie in die Access Deny Group mit aufnimmst sind sie ja noch im System!!! Dabei muss man aufpassen!!! Mit der Option Lockout ID schließt du sie allerdings wirklich aus dem System aus (Wenn du die nötige Konfiguration vorgenommen hast)

alles klar daniela??
noch Fragen?? Dann schieß los!!

mfg
andi

[Fis]

Nee default reicht nicht aus, die Gruppe muß in allen DB´s rein aber du kannst die Deny-Access spapeln, das heißt die Gruppe Deny Access group2 in die erste mit rein nehmen

[luna]

@fis:
danke, ich werd gleich in jede datenbank die denyaccessgruppe und no access mit aufnehmen. und auch in die schablonen als default. vielen dank dafuer. ich wusste das nicht !

@andi:
auch dir vielen dank, ich hab das jetzt verstanden. meine settings sind schon so, wie du es beschrieben hattest. es muesste also funzen.

ich werde die lockout IT funktion nutzen, das geht am schnellsten und macht am wenigsten arbeit erstmal und auch dann, wenn der user doch wiederkommt.

ich mach das immer so:
wenn der user 4 wochen weg ist, dann loesch ich alles (personendokument und mail DB), dann trag ich ihn auch in die deny access group ein. das reicht dann aber auch so.

vielen dank euch allen fuer eure hilfe "hamma wieder was glernt!"

gruss,
daniela

[Fis]

Schreibst du dir das immer auf wer gegangen ist und wer nicht? Ich könnte das nicht überblicken.


Gruß Rodan

[luna]

hey rodan,

tja, dafuer hab ich die ToDo's im lotus notes. den mach ich mir immer fuer 4 wochen nach austritt. sonst wuesst ich das auch nimmer.

ausserdem muss ich fuer jeden user sofort nach austritt einen agent schreiben, der eine mail an den absender schickt, wo er seine mails in zukunft hinschicken soll. also hab ich auf dem workspace in einem tab sowieso die user alle als bookmark drauf.

und ausserdem hab ich insgesamt nur 200 user, da geht das noch. obwohl die fluktution hier so gross ist wie bei einem grossen.

gruss,
dani

[luna]

Nee default reicht nicht aus, die Gruppe muß in allen DB´s rein aber du kannst die Deny-Access spapeln, das heißt die Gruppe Deny Access group2 in die erste mit rein nehmen

default no access / user type: unspecified?

[Fis]

jepp

[andi_g]

jawohl der default user ist immer unspecified. Es könnte ja beispielsweise auch irgend ein Server oder ähnliches auf die DB zugreifen.

[eknori]

Ich habe es gerade nochmal getestet.

Ist ein user in der DenyAccess Group eingetragen, kann er nicht mehr auf den Server zugreifen. Er kommt also nicht an die Datenbanken heran, obwohl die Datenbanken selber diese Gruppe nicht in der ACL haben.

LockID funktioniert auch klasse und ich werde es für meine Leiharbeiter einsetzen, von denen ich weiss, dass sie in ein paar Monaten wiederkommen.

Schaeidet ein User aber permanent aus, nützt mir LockID aber nix, da er

a) adressierbar ist und
b) als Leiche im NAB bis zum St. Nimmerleinstag herumgammeln würde.