Jean~ I cannot seem to figure this out for my life ... (Let's hope it doesn't kill me! Ha ha ha.)
I know you are a busy man, but if you could point me in the right direction I would greatly appreciate it. Let me break down the summary of the issue. -- No other services are running on the server except for SOGo. Nothing aside from my config has been modified. -- User changes password, and password is immediately updated in the LDAP database as well as the Kerberos database. User can authenticate immediately to any Kerberos services as well as LDAP services using the new password. -- After closing "Preferences" window, about 70-80% of the time, clicking anywhere brings up the login page. -- If the login page does not show when clicking on any other SOGo link, all is well. -- If the login page does show, most of the time the user will still be unable to log on, even if the user goes to another computer and tries a new session. The only way I can describe the behavior here is that if the "usual" URL after a successful login is https://sogo.paravis.net/SOGo/so/lpeter...@mydomain.com/Mail/view, the URL after an unsuccessful login is simply https://sogo.paravis.net/SOGo/so/lpeterson. -- User must wait an undefined period of time, after which everything works again with the new password. I am going to try rebuilding a new server for testing purposes, but I can confirm that all LDAP and Kerberos authentication is working great. The password changes perfectly through SOGo. It seems though that SOGo has something cached in its memory that is not being renewed when the password changes. Or maybe it is receiving a response from the LDAP server that makes it confused. Which debug information should I focus my efforts on? Or how would you suggest troubleshooting? I am truly baffled. Thank you so much Jean. ~Laz On Thursday, November 21, 2013 06:45 AM PST, Jean Raby <jr...@inverse.ca> wrote: On 13-11-21 6:45 AM, Jean Raby wrote: > On 13-11-21 12:09 AM, Laz C. Peterson wrote: >> Yikes. >> >> Then if it shouldn’t matter, I’m sure there’s something else going on here. > I'll test it. But why are you running with a 10 seconds cache expiration? > that's > really low. > I think you're running with passwordpolicy enable in sogo, but the passowrdpolicy overlay is not enabled in openldap. Just disable password policy in your sogo user source and it will work properly. Also, you didn't provide your config file, it would have saved us time and trouble if you had... (finally, unless you have a good reason to set the cache cleanup interval so low, you're probably better off keeping it at its default value) -- users@sogo.nu https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists
