Update 1.8.001 auf 1.8.004 - LDAP Problem

moe 2013-03-15 11:04:09 UTC #1

Hallo,

ich habe gestern nach längerer Zeit (weil alles recht rund lief) von der
Version
1.8.001 auf die Version 1.8.004 (Daily Snapshot) upgedatet.

Bei uns läuft die Auth für die Benutzerkonten und den IMAP-Server, der von
eGW genutzt wird über einen LDAP.

Seite dem Update ist der LDAP tierisch beschäftigt … bis zu 100% CPU
Auslastung.
Das bremst natürlich den Server entsprechend aus.

Gab es bei diesem Versionssprung irgendeine Änderung, die dafür
verantwirtlich sein könnte.

Vielen Dank!

Moe

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-03-15 11:47:44 UTC #2

Nun habe ich mal den LDAP-Server auf Debug-Level 1 gesetzt und gesehen,
dass bei JEDEM Klick auf eine Mail oder einen IMAP Ordner usw.
enorm viele Anfragen an den LDAP gehen. u.a. werden alle Gruppen in denen
der User sich befindet abgefragt. Das ist m.E. total unnötig und führt
zu hoher Last.

Gibt es eine Ansatzpunkt wie ich da wieder in den Griff bekomme ohne auf
die alte Version zu müssen?

Moe

Hallo,

ich habe gestern nach längerer Zeit (weil alles recht rund lief) von der
Version
1.8.001 auf die Version 1.8.004 (Daily Snapshot) upgedatet.

Bei uns läuft die Auth für die Benutzerkonten und den IMAP-Server, der von
eGW genutzt wird über einen LDAP.

Seite dem Update ist der LDAP tierisch beschäftigt … bis zu 100% CPU
Auslastung.
Das bremst natürlich den Server entsprechend aus.

Gab es bei diesem Versionssprung irgendeine Änderung, die dafür
verantwirtlich sein könnte.

Vielen Dank!

Moe

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

ASTA 2013-03-17 12:05:11 UTC #3

Nun habe ich mal den LDAP-Server auf Debug-Level 1 gesetzt und gesehen,
dass bei JEDEM Klick auf eine Mail oder einen IMAP Ordner usw.
enorm viele Anfragen an den LDAP gehen. u.a. werden alle Gruppen in denen
der User sich befindet abgefragt. Das ist m.E. total unnötig und führt
zu hoher Last.

Gibt es eine Ansatzpunkt wie ich da wieder in den Griff bekomme ohne auf
die alte Version zu müssen?

Moe

Hallo Moe,

ich glaube Du kannst auf Deinem LDAP-Server die Art des bind bestimmen
(je nach Version), ob die Verbindung persistent sein soll, etc.

Ich kann mich auch dunkel daran erinnern, so etwas mal in der
e-Groupware gesehen zu haben, aber ich finde es gerade nicht.

Grüße
Ivan

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-03-17 18:39:01 UTC #4

Hallo Moe,

ich glaube Du kannst auf Deinem LDAP-Server die Art des bind bestimmen
(je nach Version), ob die Verbindung persistent sein soll, etc.

Ich kann mich auch dunkel daran erinnern, so etwas mal in der
e-Groupware gesehen zu haben, aber ich finde es gerade nicht.

Grüße
Ivan

Hallo Ivan,

danke für Deine Antwort. Leider bringt die mich nicht wirklich weiter.
Vielleicht weiß jemand anderes noch was er meint…

Der Kern der Sache scheint aber zu sein, dass bei JEDEM Klick
auf eine Mail alle Gruppen (bei uns ca. 70) mehrfach vom LDAP
abefragt werden. Das kann ja nicht sinn der Sache sein.

Ideen?

Gruß Moe

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-03-18 16:03:21 UTC #5

Hat sonst wirklich niemand einen Ansatzpunkt oder das gleiche Problem
beobachtet? Es müsste doch auch andere betreffen, die LDAP als
Backend für die Userkonten benutzen?
Vielleicht tritt das Problem bei kleineren Umgebungen nicht so stark zu
Tage wenn es z.B. nicht so viele User / Gruppen gibt?
Bei uns sind es ca. 280 User in 70 Gruppen.

Bin für jeden Hinweis dankbar.

Moe

Hallo Moe,

ich glaube Du kannst auf Deinem LDAP-Server die Art des bind bestimmen
(je nach Version), ob die Verbindung persistent sein soll, etc.

Ich kann mich auch dunkel daran erinnern, so etwas mal in der
e-Groupware gesehen zu haben, aber ich finde es gerade nicht.

Grüße
Ivan

Hallo Ivan,

danke für Deine Antwort. Leider bringt die mich nicht wirklich weiter.
Vielleicht weiß jemand anderes noch was er meint…

Der Kern der Sache scheint aber zu sein, dass bei JEDEM Klick
auf eine Mail alle Gruppen (bei uns ca. 70) mehrfach vom LDAP
abefragt werden. Das kann ja nicht sinn der Sache sein.

Ideen?

Gruß Moe

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Mario_Moder 2013-03-18 19:29:57 UTC #6

Hat sonst wirklich niemand einen Ansatzpunkt oder das gleiche Problem
beobachtet? Es müsste doch auch andere betreffen, die LDAP als
Backend für die Userkonten benutzen?
Vielleicht tritt das Problem bei kleineren Umgebungen nicht so stark zu
Tage wenn es z.B. nicht so viele User / Gruppen gibt?
Bei uns sind es ca. 280 User in 70 Gruppen.

Hi Moe

Wir hatten mal ein ähnliches Problem (bei ca. 1000 Usern und 100 Gruppen),
zumindest meine ich mich daran zu erinnern, dass ich mich auch über die vielen
LDAP-Abfragen gewundert habe, die den LDAP-Server (und Apache) auf halbwegs
aktueller HP-Proliant-Hardware ganz schön in Schwitzen gebracht hat. Ein
Kollege der Systemadministration hat das Problem damit in den Griff bekommen,
auf bestimmte LDAP-Datenbank-Strukturen Indizes zu setzen:

olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: uid eq

Seitdem haben wir keine Performance-Probleme mehr mit den LDAP-Zugriffen.

Grüße

Mario

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-03-19 06:50:56 UTC #7

Hi Moe

Wir hatten mal ein ähnliches Problem (bei ca. 1000 Usern und 100 Gruppen),
zumindest meine ich mich daran zu erinnern, dass ich mich auch über die vielen
LDAP-Abfragen gewundert habe, die den LDAP-Server (und Apache) auf halbwegs
aktueller HP-Proliant-Hardware ganz schön in Schwitzen gebracht hat. Ein
Kollege der Systemadministration hat das Problem damit in den Griff bekommen,
auf bestimmte LDAP-Datenbank-Strukturen Indizes zu setzen:

olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: uid eq

Seitdem haben wir keine Performance-Probleme mehr mit den LDAP-Zugriffen.

Grüße

Mario

Hallo Mario,

danke für Deine Antwort. Ich habe die Indizies überprüft. Die waren
gesetzt. Ich habe den Index trotzdem nochmal neu aufbauen lassen.
Leider ohne merkliche Besserung.

Gibt es weitere Ansatzepunkte?

Wie schon erwähnt war die Performance in der Version 1.8.001 (vom
18.9.2010) deutlich besser als in der aktuellen 1.8.004.

Ich denke dort wurden Änderungen am Code durchgeführt, die dazu führen.

Würde mich über Hinweise freuen.
vielen Dank!

Moe

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

TorstenL 2013-03-29 16:24:59 UTC #8

Der Kern der Sache scheint aber zu sein, dass bei JEDEM Klick
auf eine Mail alle Gruppen (bei uns ca. 70) mehrfach vom LDAP
abefragt werden. Das kann ja nicht sinn der Sache sein.

Ideen?
kanns Du es etwas genauer “beschreiben”.? (Bsp.)
Erste Grundregel ist “messen”.

Wie sieht die Systemauslastung der beteiligten Server aus?
70 Anfragen p. Klick scheinen mir recht viel.
Wenn der ldapserver jede Anfrage in 0.01s beantwortet,
dann sind es zusammen 0,7s und damit schon im Grenzbereich.
Wenn von 1000 angemeldeten Nutzern 10% gerade Klick machen, summiert es
sich auf 7s.
Wenn der ldapserver auch noch andere Dienste versorgen muss kann es zum
GAU kommen.
Ob der Ldapserver noch mitkommt kann man im logfile erkennen, wenn man
sich die An/Abmeldungen ansieht.
Gelegentl. Ueberlagerungen sind i.O., da auch Subqueries moegl.

Anbei mal eine Anleitung einer moeglichen,systematischen Herantastung.

1. Ueberwachung der Auslastung der Systeme
  (sar,cacti,vmstat,ps,top)
1. Test ldapd conn
  slapd.conf:loglevel 256
  ldaplog=/var/log/syslog
  cat $ldaplog | egrep “ACCEPT|close” | awk ‘{print $3,$6,$8}’ | more
- Fall1
  06:57:09 conn=1879410 ACCEPT
  06:57:09 conn=1879410 closed
  06:57:09 conn=1879411 ACCEPT
  06:57:09 conn=1879411 closed
  06:57:09 conn=1879412 ACCEPT
  06:57:09 conn=1879412 closed
  -> i.O.
- Fall2
  15:56:49 conn=51321 ACCEPT
  15:58:54 conn=51322 ACCEPT
  15:59:12 conn=51323 ACCEPT
  15:59:32 conn=51323 closed
  15:59:32 conn=51321 closed
  15:59:32 conn=51322 closed
  -> diese Kiste hat gleich mehrere Probleme
  (…ist ne andere Baustelle…)
1. Test ldapd idx
  May 29 14:02:49 v3 slapd[22598]: <= bdb_equality_candidates:
  (uniqueMember) not indexed
  -> reindex noetig
1. test ldapd R/s
  ze="06:57:0"
  cat $ldaplog | egrep “ACCEPT” | grep “$ze” | wc -l
Bsp:
06:57:0 -> 90 -> 90/10s
06:57:09 -> 52 -> 50/s
06:57:08 -> 0 -> 0/s
-> dieser Server (2x2,2GHz,8xPV) schafft min. 50R/s (max 100)

Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel’s independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-04-02 05:29:39 UTC #9

Hallo Thorsten,

Vielen Dank für die ausführliche Antwort

Ueberwachung der Auslastung der Systeme
(sar,cacti,vmstat,ps,top)
Es ist so, dass beim betrachten mit top der slapd (bei 10-15
angemeldeten Usern)
schon fast dauerhaft bei 100% steht. Gelegentlich geht die auslastung
kurzzeitig runter.

Test ldapd conn
slapd.conf:loglevel 256
ldaplog=/var/log/syslog
cat $ldaplog | egrep “ACCEPT|close” | awk ‘{print $3,$6,$8}’ | more

Fall1
06:57:09 conn=1879410 ACCEPT
06:57:09 conn=1879410 closed
06:57:09 conn=1879411 ACCEPT
06:57:09 conn=1879411 closed
06:57:09 conn=1879412 ACCEPT
06:57:09 conn=1879412 closed
-> i.O.

Fall2
15:56:49 conn=51321 ACCEPT
15:58:54 conn=51322 ACCEPT
15:59:12 conn=51323 ACCEPT
15:59:32 conn=51323 closed
15:59:32 conn=51321 closed
15:59:32 conn=51322 closed
-> diese Kiste hat gleich mehrere Probleme
(…ist ne andere Baustelle…)
Das habe ich mal getestet und es scheint i.d.T. so zu sein, dass hier
der Fall2
auftritt. Kann das die Ursache sein? Ich verstehe allerdings nicht wo das
Problem liegt wenn die Verbindungen nicht in der Reihenfolge geschlossen
werden wie sie auch geöffnet wurden.

Die Indizies sind korrekt gesetzt. Fehler diesbgzl. kann ich im Log
nicht erkennen.

Die Performanceprobleme tauchen auch nur in Verbindung mit dem IMAP-Client
von eGroupware auf. Die Authentifizierung von eGW über LDAP läuft in
normaler
Geschwindigtkeit.
Bei uns läuft ein Cyrus IMAP, der via sasld gegen den LDAP authentifiziert.
Jetzt möchte man meinen, dass dies ein Problem zwischen den beiden ist, aber
mit anderen IMAP-Clients läuft es performant.

Weitere Ideen und Hinweise sind sehr Willkommen.

Moe

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-04-02 14:11:47 UTC #10

Ich konnte das Problem lösen.
Es scheint mit den Blowfish-Passwörtern zu tun zu haben.

Wenn diese verwendet werden geht die CPU-LAST des Slapd bei Verwendung des
egw-Imap-clients extrem hoch.

Ich habe nun umgestellt auf SSHA und alle User aufgefordert ihre
Passwörter zu ändern.
Nun geht die Serverlast langsam nach unten.

Nach der PW-Änderung bei den einzelnen Usern geht es sofort spürbar
schneller.

Moe

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Ralf_Becker_Stylite 2013-04-02 14:28:31 UTC #11

Ich konnte das Problem lösen.
Es scheint mit den Blowfish-Passwörtern zu tun zu haben.

Wenn diese verwendet werden geht die CPU-LAST des Slapd bei Verwendung des
egw-Imap-clients extrem hoch.

Ich habe nun umgestellt auf SSHA und alle User aufgefordert ihre
Passwörter zu ändern.
Nun geht die Serverlast langsam nach unten.

Nach der PW-Änderung bei den einzelnen Usern geht es sofort spürbar
schneller.

Wir verwenden aktuell crypt Passwörter mit sha256 Hash und den Default
5000 Runden, die sind erheblich sicherer als ssha aber noch nicht ganz
so cpu intensiv with Blowfish.

Die Umstellung kannst Du auch automatisch machen, in dem Passwort
Migration im Setup Konfiguration eingestellt wird. Dann genügt ein
normales Anmelden an der EGroupware um den Hash in einem anderen
Verfahren zu speichern.

Allg. gilt heute allerdings, je cpu intensive ein Algorithmus ist, um so
sicherer ist er.

Ralf

Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-04-03 05:08:38 UTC #12

Wir verwenden aktuell crypt Passwörter mit sha256 Hash und den Default
5000 Runden, die sind erheblich sicherer als ssha aber noch nicht ganz
so cpu intensiv with Blowfish.

Die Umstellung kannst Du auch automatisch machen, in dem Passwort
Migration im Setup Konfiguration eingestellt wird. Dann genügt ein
normales Anmelden an der EGroupware um den Hash in einem anderen
Verfahren zu speichern.

Allg. gilt heute allerdings, je cpu intensive ein Algorithmus ist, um so
sicherer ist er.

Ralf

Hallo Ralf,

danke für den Tip mit der Passwortmigration. Das wusste ich nicht.

Moe

Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-04-03 05:21:03 UTC #13

Wir verwenden aktuell crypt Passwörter mit sha256 Hash und den Default
5000 Runden, die sind erheblich sicherer als ssha aber noch nicht ganz
so cpu intensiv with Blowfish.

Die Umstellung kannst Du auch automatisch machen, in dem Passwort
Migration im Setup Konfiguration eingestellt wird. Dann genügt ein
normales Anmelden an der EGroupware um den Hash in einem anderen
Verfahren zu speichern.

Allg. gilt heute allerdings, je cpu intensive ein Algorithmus ist, um so
sicherer ist er.

Ralf
Hallo Ralf,

danke für den Tip mit der Passwortmigration. Das wusste ich nicht.

Moe

Jetzt habe ich nochmal geschaut und nur in den Setup-Einstellungen eine
Zeile
gefunden, die heisst "Erlaubte Migrationstypen (Komma separiert):"
Reicht es aus in dieser Zeile z.B. crypt anzugeben, um die Passwörter zu
migrieren oder
ist da noch etwas anderes einzustellen?

Moe

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Ralf_Becker_Stylite 2013-04-03 07:13:25 UTC #14

Wir verwenden aktuell crypt Passwörter mit sha256 Hash und den Default
5000 Runden, die sind erheblich sicherer als ssha aber noch nicht ganz
so cpu intensiv with Blowfish.

Die Umstellung kannst Du auch automatisch machen, in dem Passwort
Migration im Setup Konfiguration eingestellt wird. Dann genügt ein
normales Anmelden an der EGroupware um den Hash in einem anderen
Verfahren zu speichern.

Allg. gilt heute allerdings, je cpu intensive ein Algorithmus ist, um so
sicherer ist er.

Ralf
Hallo Ralf,

danke für den Tip mit der Passwortmigration. Das wusste ich nicht.

Moe

Jetzt habe ich nochmal geschaut und nur in den Setup-Einstellungen eine
Zeile
gefunden, die heisst "Erlaubte Migrationstypen (Komma separiert):"
Reicht es aus in dieser Zeile z.B. crypt anzugeben, um die Passwörter zu
migrieren oder
ist da noch etwas anderes einzustellen?

Du stellst das Ziel der Migration zB. sha512_crypt als “SQL oder LDAP
Verschlüsselungstyp” ein und alle alten Typen die Du noch in DB oder
LDAP hast komma-separiert bei “erlaubten Migrationstypen”.

Ralf

Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-04-03 07:28:50 UTC #15

Du stellst das Ziel der Migration zB. sha512_crypt als “SQL oder LDAP
Verschlüsselungstyp” ein und alle alten Typen die Du noch in DB oder
LDAP hast komma-separiert bei “erlaubten Migrationstypen”.

Ralf

Vielen Dank für die Erklärung, dass sollte das passen.
Ein Frage habe ich allerdings noch:
nachdem ich die Prüfung auf sichere Passwörter (also die
Komplexitätsprüfung) im Setup aktiviert habe,
wird das korrekt geprüft wenn die User ihr Passwört ändern.
Allerdings habe ich im code gesehen, dass auch eine Prüfung stattfinden
sollte ohne das der User
das Passwörter ändert (also schon beim einloggen). Das scheint hier aber
nicht zu passieren.
Muss dafür noch etwas aktiviert werden?

Moe

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Ralf_Becker_Stylite 2013-04-03 09:10:35 UTC #16

Du stellst das Ziel der Migration zB. sha512_crypt als “SQL oder LDAP
Verschlüsselungstyp” ein und alle alten Typen die Du noch in DB oder
LDAP hast komma-separiert bei “erlaubten Migrationstypen”.

Ralf

Vielen Dank für die Erklärung, dass sollte das passen.
Ein Frage habe ich allerdings noch:
nachdem ich die Prüfung auf sichere Passwörter (also die
Komplexitätsprüfung) im Setup aktiviert habe,
wird das korrekt geprüft wenn die User ihr Passwört ändern.
Allerdings habe ich im code gesehen, dass auch eine Prüfung stattfinden
sollte ohne das der User
das Passwörter ändert (also schon beim einloggen). Das scheint hier aber
nicht zu passieren.

Hab’ kurz mit Klaus gesprochen, der das implementiert hat: beim Login
gibt es keine Komplexitätsprüfung, die findet nur bei Passwortänderungen
statt. Was es beim Login optional gibt, ist die Prüfung wie alt das
Passwort ist und daraus dann der Zwang das Passwort zu ändern (muss aber
aktiviert werden).

Wenn Du da noch mehr Unterstützung brauchst, solltest Du ein
Supportbudget bei uns eröffnen.

Ralf

Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

moe 2013-04-03 11:19:07 UTC #17

Hab’ kurz mit Klaus gesprochen, der das implementiert hat: beim Login
gibt es keine Komplexitätsprüfung, die findet nur bei Passwortänderungen
statt. Was es beim Login optional gibt, ist die Prüfung wie alt das
Passwort ist und daraus dann der Zwang das Passwort zu ändern (muss aber
aktiviert werden).

Wenn Du da noch mehr Unterstützung brauchst, solltest Du ein
Supportbudget bei uns eröffnen.

Ralf
In der login.php gibt es in Zeile 345 einen “Check for save passwd”.
Ich hatte den code beim überfliegen so verstanden, dass bei sicheren
Passwörtern schon
beim Login gecheckt wird ob diese die Komplexitätsanforderungen
erfüllen und falls nicht,
der User genötigt wird sein Passwort zu ändern bevor er sich einloggen kann.

Moe

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Leithoff_Klaus 2013-04-03 14:04:08 UTC #18

Hmm, in der Theorie hast Du recht.
Wenn das im Setup aktiviert ist UND im ADMIN eine stärke eingestellt ist, dann sollte das zum passwort ändern dialog schicken.
Das tut hier nicht, weil der acl check nicht auf changepassword sondern auf NOT nopasswordchange gehen müsste, oder eben die userdata[changepassword]
Ich fixe das morgen.

kl@stylite.de
Stylite AG
[ open style of IT ]
Morschheimer Strasse 15
67292 Kirchheimbolanden
fon 06352 . 70629-0
fax 06352 . 70629-30
www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

moe 2013-04-04 05:46:44 UTC #19

Hmm, in der Theorie hast Du recht.
Wenn das im Setup aktiviert ist UND im ADMIN eine stärke eingestellt ist, dann sollte das zum passwort ändern dialog schicken.
Das tut hier nicht, weil der acl check nicht auf changepassword sondern auf NOT nopasswordchange gehen müsste, oder eben die userdata[changepassword]
Ich fixe das morgen.

Super, Vielen Dank für die Info!

Gruß Moe

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Leithoff_Klaus 2013-04-04 11:55:37 UTC #20

rev 42158 für 1.8

kl@stylite.de
Stylite AG
[ open style of IT ]
Morschheimer Strasse 15
67292 Kirchheimbolanden
fon 06352 . 70629-0
fax 06352 . 70629-30
www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany