[gelöst] Fragen zu Richtlinien und dem Internet Kennwort

[lime]

Hallo,

Das erste Problem betrifft explizite Richtlinien: wie kann es sein, dass Richtlinien ewig brauchen bis sie angewendet werden (z.B braucht es bis sich das Notes Kennwort/Internet Kennwort synchronisiert oft mehrere Tage??), gibt es da eine Möglichkeit die Zeitspanne zu definieren wann eine Richtlinie wirksam wird, bzw. wann sollte eine Richtlinie spätestens wirksam werden?
Bzw. gibt es einen Befehl und/oder eine Option wie ich eine Richtlinie manuell gleich anwenden kann?

Zweites Problem: wenn man das Internet Kennwort bei uns im Webmail als User ändert, kann man mit beiden (!) Kennwörtern - alt und neu - ins Webmail einsteigen, dann nach einiger Zeit nur noch mit dem alten Kennwort = Lotus Notes Kennwort (das Internet Kennwort setzt sich praktisch von alleine wieder auf das Lotus Notes Kennwort zurück).
Wie kann das sein, es sollte sich doch nur das Internet Kennwort abgleichen wenn das Notes Kennwort geändert wurde (bei uns in einer organisationsbezogenen Richtlinie definiert) und sich nicht einfach wieder zurücksetzen obwohl das Notes Kennwort gar nicht geändert wurde, oder (??)

Die dritte Frage: wenn ich auf einen User mehrere explizite Richtlinien wirken habe, in einer Richtlinie davon eingestellt habe, dass die Kontaktsynchonisation im Replikator eingeschalten wird und in einer anderen expliziten Richtlinie die auch für den User gilt, diese Einstellung nicht gesetzt habe, sollte es doch egal sein, welche Priorität die Richtlinie A hat, diese Einstellung mit den Kontakten sollte dann so oder so gesetzt werden, richtig oder falsch?

Danke, Liebe Grüße
Verena

[Micha B]

zu 2. http://www.ibm.com/support/docview.wss?uid=swg21084375

[lime]

okay, danke, jetzt verstehe ich zwar warum beide eine Zeit lange gleichzeitig gültig sind, aber nicht warum nach einiger Zeit wieder das ALTE (=ursprüngliches Kennwort=Notes Kennwort) gültig wird und das neue "verschwindet"

[stoeps]

zu 3)
Du meinst dynamische Richtlinien, oder?
Hast du in der Policy in der der Wert nicht gesetzt wird die Option "don't apply" angehakt?

zu 1)
Kennwortsynchronistation ist ein Job des Adminp und ich würde da mal mit der Suche nach der Verzögerung beginnen.
https://www-304.ibm.com/support/docview.wss?uid=swg27010355

[lime]

zu 3)
Du meinst dynamische Richtlinien, oder?
Hast du in der Policy in der der Wert nicht gesetzt wird die Option "don't apply" angehakt?

Also die Richtlinie ist als explizite erstellt worden, scheint unter "Richtlinien" unter "Explicit Policies" auf und unter Dynamische Richtlinien scheint sie genauso auf (ist sie somit beides?)
Du meinst unter "How to apply this setting" -> "Don´t set value"? Nein, der Wert ist nicht gesetzt. Muss man das machen? Reicht es nicht, wenn man die Einstellung nicht definiert, dass sie auch nicht angewendet wird (und somit die Einstellung von der anderen Richtlinie zieht?)?

zu 1)
Kennwortsynchronistation ist ein Job des Adminp und ich würde da mal mit der Suche nach der Verzögerung beginnen.
https://www-304.ibm.com/support/docview.wss?uid=swg27010355

ok danke.
Aber dadurch bin ich auf das Problem zu Punkt 2 gekommen (dass sich das Internet Kennwort wieder zurücksetzt) -> ich glaube das hat etwas mit unserem alten Problem zu tun das nie gelöst wurde.....-> die Leute die das Internetkennwort ändern wollen haben diesen Eintrag verursacht:
Change HTTP Password in Domino Directory: Zeit/Benutzer/Title: Administrationsanforderungen Path: admin4.nsf, Error: Document is not signed  - wir haben das Problem damals nicht mal mit dem Support von IBM lösen können, aber so gut kennen wir uns leider auch nicht aus

[stoeps]

Du meinst unter "How to apply this setting" -> "Don´t set value"? Nein, der Wert ist nicht gesetzt. Muss man das machen? Reicht es nicht, wenn man die Einstellung nicht definiert, dass sie auch nicht angewendet wird (und somit die Einstellung von der anderen Richtlinie zieht?)?

Ja den mein ich und ja du mußt ihn setzen, sonst setzt dir eine höherwertige Policy den Wert zurück. Ich hab mir angewöhnt, neue Setting-Docs erstmal über die Schaltfläche "How to apply" - "Don't set ... für alle Felder auszuschalten und dann nur explizit die einzelnen Felder die ich setzen möchte auf die jeweilige Option ändern.

Was hast du denn für eine Clientversion? Es gab grad in Zusammenhang mit ID Vault ein paar Bugs mit dem Internetkennwort sync. Wobei diese unsigned Meldung schon komisch ist.

[lime]

okay danke, ich probiers mal (ist ziemlich umständlich :/)

Clientversionen gemischt, von 8.5 über 8.5.1 div. FPs bis 8.5.2 FP2

[stoeps]

Umständlich? Mag sein, aber damit kann man wenigstens sicher sein, was am Client ankommt.

Client 8.5? Mit ID Vault? Da wundert mich dein Sync Problem der Kennwörter nicht!

http://www-10.lotus.com/ldd/nd85forum.nsf/7570d1446ddf4cf085256bff00489f8d/c8cfc91b82c72cf1852576500021bac2?OpenDocument

[lime]

das Problem tritt aber genauso bei den neuen Clients auf....

Hat jemand vielleicht noch eine Idee zu Problem 2:

-> wenn man das Internet Kennwort bei uns im Webmail als User ändert, kann man mit beiden (!) Kennwörtern - alt und neu - ins Webmail einsteigen, dann nach einiger Zeit nur noch mit dem alten Kennwort = Lotus Notes Kennwort (das Internet Kennwort setzt sich praktisch von alleine wieder auf das Lotus Notes Kennwort zurück).

Im Moment kann deswegen kein Benutzer sein eigenes Internetkennwort ändern, weil es nach einiger Zeit immer wieder auf das Standardkennwort zurücksetzt....

Lg, Verena

[stoeps]

http://www.ipi.org/help/help8_admin.nsf/b3266a3c17f9bb7085256b870069c0a9/c61725cd208896a3852572fa004e57a7?OpenDocument
http://www.kalechi.com/doc/notesini.nsf/85255a87005060c585255a850068ca6f/1a6190d461d83987c1256e9e00442406!OpenDocument

Also dass nur noch das alte Kenneort geht, versteh ich nicht. Aber schau dir mal das Caching an.

[lime]

Die Lösung der Frage 2 (http Kennwort als User im Webmail ändern nicht permanent möglich - Kennwort setzt sich immer wieder auf den alten Stand zurück) ist:
Falls ein Server im Feld "User name" im Personendokument des Domain Admins eingetragen ist, diesen herauslöschen.