Password reset bei Web-Usern

[Flachmann]

Hi,

wir haben einige wenige "reine Web-User", die Personendokumente im DD haben, aber keine Notes ID im ID Vault.

Ich überlege wie man hier eine Kennwortänderung sinnvoll ermöglichen kann, da es immer wieder vorkommt, dass die User ihr Kennwort vergessen. db.nsf?ChangePassword geht nur, wenn die User ihr Kennwort (noch) kennen.

NotesSession.ResetUserPassword() funktioniert lt. Doku nur mit IDs im ID Vault, passt demnach auch nicht.

Ich habe jetzt versucht über einen Agent das HTTPPassword im Personendokument zu setzen (zuvor verschlüsselt). Das funktioniert, aber jetzt besteht das Problem, dass die Änderung über einen sehr langen Zeitraum nicht zieht. Ich nehme an, dass die HTTP Task den PW-Cache nicht aktualisiert.

Habt Ihr eine ähnliche Situation? Gibt es einen eleganten Lösungsweg?

[Erik Schwalb]

Warum haben diese "reinen Web-User" keine Notes IDs? Spricht etwas dagegen diese als "ganz normale Domino User" (d.h. mit Notes ID im ID Vault) anzulegen?

[MaVo]

Was verstehst Du unter einem "reinen Web-User"?

Das funktioniert, aber jetzt besteht das Problem, dass die Änderung über einen sehr langen Zeitraum nicht zieht. Ich nehme an, dass die HTTP Task den PW-Cache nicht aktualisiert.

Kennst Du den notes.ini Eintrag HTTP_PWD_CHANGE_HOURS?

[Flachmann]

Was verstehst Du unter einem "reinen Web-User"?

Einen User, der keinen Notes-Client-Zugang hat oder braucht, sondern rein über HTTP zugreift. Der hat auch keine Mailbox. Solch ein User hat einen Personeneintrag (und ist damit Lizenzpflichtig) mit Kennwort, wird aber nie eine ID-Datei verwenden. Alles was dieser User sieht ist quasi die Web-Anwendung (Notes oder XPages).

Warum haben diese "reinen Web-User" keine Notes IDs? Spricht etwas dagegen diese als "ganz normale Domino User" (d.h. mit Notes ID im ID Vault) anzulegen?

Jetzt wo Du's erwähnst spricht eigentlich nichts dagegen. Man könnte die ID anlegen, auch wenn sie nie benötigt wird. Bislang hatte ich es als logisch erachtet, bei solchen Usern gar keine ID zu erzeugen.

Das schaue ich mir mal an. Klingt sinnvoll.
Danke Euch! 

[Erik Schwalb]

FYI - Je nachdem, um welchen use case es sich handelt, kann es sogar sinnvoll sein, "Web-only User" als "vollständige" Domino User anzulegen.

• Wenn das "externe " User sind, die nicht zur eigenen Firma gehören, kannst Du sie anhand einer separaten Zulassungshierarchie leicht von den internen Usern unterscheiden...und das DLAU Tool erkennt diese Accounts dann auch korrekt als "extern".
• Wenn es interne User sind und Du ihnen irgendwann mal Zugriff auf Anwendungen per Nomad Web geben möchtest...dann brauchen sie ohnehin eine Notes ID.

[Flachmann]

FYI - Je nachdem, um welchen use case es sich handelt, kann es sogar sinnvoll sein, "Web-only User" als "vollständige" Domino User anzulegen.

• Wenn das "externe " User sind, die nicht zur eigenen Firma gehören, kannst Du sie anhand einer separaten Zulassungshierarchie leicht von den internen Usern unterscheiden...und das DLAU Tool erkennt diese Accounts dann auch korrekt als "extern".
• Wenn es interne User sind und Du ihnen irgendwann mal Zugriff auf Anwendungen per Nomad Web geben möchtest...dann brauchen sie ohnehin eine Notes ID.

Genau, es sind Externe, die eine eigene "Hierarchie" haben, darum gut zu erkennen sind. Das ist auch praktisch, wenn man ACL-Zugriffe auf Hierarchieebene vergeben möchte. Da solche User von Hand angelegt sind, brauchte man auch keinen Certifier, Hauptsache er unterscheidet sich von anderen Usern. Wg. DLAU habe ich das noch nie analysiert, sondern einfach laufen lassen. 

Für Nomad wäre eine ID zwangsläufig notwendig, klar!

Ich habe schon einen neuen Certifier erstellt und registriere die User in den nächsten Tagen. Vorher muss ich halt die "händischen" Personeneinträge raus löschen. Blöde ist halt die zusätzliche Kommunikation, weil ja ein neues Kennwort vergeben werden muss.

Aber das ergibt Sinn und passt besser in die Domino-Welt. Ich hatte unser altes Vorgehen nie in Frage gestellt. 

[MaVo]

Ich habe schon einen neuen Certifier erstellt und registriere die User in den nächsten Tagen. Vorher muss ich halt die "händischen" Personeneinträge raus löschen. Blöde ist halt die zusätzliche Kommunikation, weil ja ein neues Kennwort vergeben werden muss.

Schau Dir mal den Blogpost "SnTT - TOTP Needs an ID file in the ID Vault to Work, What if some are Missing?" von Keith Brooks an, der stand auch mal vor der Herausforderung.

But what do you do about people who solely use webmail/iNotes?

How do you get their IDs into the ID Vault?

[Flachmann]

Schau Dir mal den Blogpost "SnTT - TOTP Needs an ID file in the ID Vault to Work, What if some are Missing?" von Keith Brooks an, der stand auch mal vor der Herausforderung.

Super, danke. Das hilft ungemein. Gut, dass ich noch nicht viel weiter war! 

[Flachmann]

Schau Dir mal den Blogpost "SnTT - TOTP Needs an ID file in the ID Vault to Work, What if some are Missing?" von Keith Brooks an, der stand auch mal vor der Herausforderung.

Bin jetzt fertig (waren ja nicht viele). Die User sind jetzt alle im ID Vault.   Die Personendokumente haben jetzt alle ein Notes-Zertifikat und sehen optisch gut aus. Entsprechende "Recertify Person in Domino Directory"-Requests in der admin4.nsf sind vorhanden und wurden abgearbeitet. Torsten (Tode) hat den Prozess ja hier ganz gut beschrieben: https://atnotes.de/index.php?topic=62002.0. Und anders als bei ihm habe ich für alle die passenden Rezertifizierungsanforderungen.

Im Log steht:
... Certifying Username/CERT
... CA Process (O=CERT): Certificate Request processed.

Allerdings sind in der admin4.nsf unter 'Certification Authority Requests/Cerificate Requests' noch alle Requests im Status "Issued by Certification Authority". Und die müssten ja eigentlich abgearbeitet sein, oder?

Im Log finde ich dann auch:
... Error processing certificate created by /CERT for Username/CERT: Your certificate has not yet been signed by the Certificate Authority.  Try again later.

Der Certifier sollte gut sein. tell CA status liefert:
...     2. O=CERT
...         Certifier Type: Notes
...         Active: Yes
...         ICL DB Path: icl\icl_1234.nsf

Irgendeine Idee?