ID-Vault // SelfService Passwort Reset

[typeOneg]

Gott zum Gruße,

schon mal vorab sorry, das wird eine längere Geschichte ;-)

Wir haben im Unternehmen vor einger Zeit Notes-Shared-Login (NSL) eingeführt und stehen jetzt vor der Migration von XP hin zu Windows 7. Diese Neuinstallation der Rechner bewirkt natürlich, dass das NSL auf den Clients nicht mehr funktioniert. Jetzt gibt's zwar von der IBM eine Doku, was bei solchen OS-Migrationen zu tun ist, leider kommt es einem Glücksspiel gleich, ob das klappt oder nicht.

Meine Überlegung ist jetzt folgende:

- Notes-Passwort des Users wird zurückgesetzt (vom 1st Level support)
- PC wird migriert
- lokale User.id wird nach der W7-Migration gelöscht
- beim Start vom Notes wird User.id wieder aus dem ID-Vault downgeloadet und Notes verlangt das Passwort
- Anmeldung im Notes und irgendwann mal (wenn man das nur wüsste) wird über die Policy wieder NSL aktiv

Das klappt auch soweit. Ich suche jetzt nur eine elegante Möglichkeit für meine 1st-Level-Leute, im Vorfeld die Notes-Passwörter der User zurückzusetzen, damit nicht nach der Migration herumprobiert werden muß, weil man das Kennwort, dass der User VOR der Einführung von NSL hatte, nicht mehr weiß.

Ideal wäre die pwdresetsample.nsf-DB, wo über eine Webpage das Passwort resettet werden kann. Dazu muß man allerdings wieder das HTTP-Passwort wissen. Wissen die 1st-Leveler natürlich nicht (immer). Lt. Domino-Wiki kann man die HTTP-Auth. auch abschalten. Dh, es ist nur der Username und das neue Passwort einzugeben. Das wäre perfekt.

Problem: es ist nirgends dokumentiert, wie/wo man das konfiguriert. Der Sample-Agent hilft mir auch nicht weiter. Kann mir da wer von Euch weiterhelfen?

Bin für jeden Tipp dankbar und vielen Dank für's Lesen :-)

lg
Hans

Achja: Domino-Server 9.0 HF75 auf Win2008 R2

[m3]

Warum so kompliziert mit der pwdresetsample.nsf-DB? Geht doch einfacher mit einem simplen Agent, der ueber das DD looped:

Call notesSession.ResetUserPassword( servername, username, password[, downloadcount ] )

This method is only supported on the server. If you needed to invoke this method from the Notes Client, use RunOnServer method to invoke another agent containing method ResetUserPassword.

This method is only supported in agents.

The signer of the agent has to be an authorized password resetter, as does the server or servers on which the agent runs. To designated password resetters use Administration client tools "Create Id Vault" or "Manage Id Vault." For more information, see Domino Administrator Help. In addition the agent signer has to have rights to run agents specified in the Programmability Section of the Security section in Domino Directory.

P.S.: Policies (wie die fuer NSL) werden beim ersten Zugriff auf den Home Server aktualisiert.

[typeOneg]

aha....hatte ich dann nur einen Denkfehler?

D.h., wenn ich den SampleAgent in der pwdresetsample.nsf so

Call Session.ResetUserPassword("", "", "test")

automatisch laufen lasse, wird bei allen Usern am Server, wo der Agent läuft, als Notes-Kennwort "test" gesetzt?

Ad Policies: werden die nicht jedesmal abgefragt? Wie kann ich eine neuerliche Umsetzung denn pushen? Geht das nur über eine Änderung in der Policy (also über ein "Neu abspeichern")?

[ascabg]

Hallo,

Wird wahrscheinlich nicht funktionieren, da der Servername und auch der Username angegeben werden muessen.



Andreas

[Tweeks]

Die einfachste Möglichkeit eine Policy zu pushen ist, die Policy-Dokumente aus der lokalen names.nsf zu löschen und den Client einmal neu zu starten.
Dann MUSS der Client sich ja die Einstellungen neu vom Server holen.

MfG
Matthias

[typeOneg]

Die einfachste Möglichkeit eine Policy zu pushen ist, die Policy-Dokumente aus der lokalen names.nsf zu löschen und den Client einmal neu zu starten.
Dann MUSS der Client sich ja die Einstellungen neu vom Server holen.

MfG
Matthias

Ja, wobei selbst dann die Policies nicht immer greifen. Könnte man das Löschen der Policy-Dox in der lokalen names.nsf in einen Button verpacken, den man den Usern per Mail schickt? Bin mehr der Admin als der Developer :-)

[ascabg]

Hallo,

Klar kannst Du das.



Andreas

[m3]

aha....hatte ich dann nur einen Denkfehler?

D.h., wenn ich den SampleAgent in der pwdresetsample.nsf so

Call Session.ResetUserPassword("", "", "test")

automatisch laufen lasse, wird bei allen Usern am Server, wo der Agent läuft, als Notes-Kennwort "test" gesetzt?

Wie Andreas schon meinte, das wird so nicht klappen. Hol Dir einen Dev dazu, fuer den sollte das trivial sein ...

[m3]

Und weil ich es gerade gefunden habe:

How do policies get pulled and applied on the client?
When the client authenticates with the users home server, it sends over a hashed value that indicates what policy information it thinks it has stored locally.  The server calculates a similar hashed value for what it thinks the client should have.  If those values do not match, then the server tells the client that it need to refresh it's policies.  At this point, the client launches the dynamic configuration process, Dyncfg.exe, passing it flags on the command line that tell it to pull policies.  Dyncfg uses the NAMEGetPolicy API, which asks the server to calculate the effective policy for the user, and then stores the effective policies locally in the clients NAMES.NSF database.  You can see your locally cached policy documents by opening the hidden $Policies view (via Ctrl-Shift View\Go To).  After pulling and applying the policies to the client, Dyncfg stores off the new hashed value that it got from the server, to be sent back to the server during the next authentication, which starts this whole process over again.

So what info is encoded in this hashed value?  Previous to R8.5 and dynamic policies, it was simply the last modified time of the $Policies view in the server's NAB.  With the introduction of dynamic policies, the hash was expanded to include any group or user names that caused a policy to be assigned to the user, as well as the last modified time of the $Policies view.  So, if any policy info changes on the server, or the user is assigned to any new groups that cause a policy to be assigned to them, then the hash will change which will trigger the client to pull new policies.  Note that on the Domino server, we rely on the Update task to update the views in the NAB once per minute.  If this doesn't happen, then the $Policies view won't get updated, the code won't know anything has changed, and no policy changes will get pulled to the client.  This is a very common cause of policy problems on test machines.

How to I force the client to pull policies?
Part of the hashed value is the last modified time of the $Policies view in the Domino Directory on the server.  So modifying any policy or policy settings document (e.g., simple edit and save) and updating the $Policies view should cause the client to re-pull policies when it next authenticates with the server.  To make that happen, you can disconnect the client by hitting Ctrl-F5 and then reconnect to the server in any way (e.g., open any database on that server).  There have been some bugs where this process breaks down and policies do not get pulled.  We've fixed them as we've found them, the most recent fixes going into R8.5 (as of 7/1/2008).

http://www-10.lotus.com/ldd/dominowiki.nsf/dx/domino-policies-faq

[typeOneg]

werd' mal mit unserem businesspartner quatschen :-)

[Ralf_M_Petter]

@Martin!

Vielen Dank für den Link. Das sieht wirklich nach einer plausiblen Erklärung für seltsame Phänomene bei den Policys aus.

Grüße

Ralf

[m3]

werd' mal mit unserem businesspartner quatschen :-)

Lass den Rainer lieb gruessen

[XOverPoint]

Tip : http://petterralf.blogspot.de/2013/08/force-notes-client-to-refresh-policies.html