Re: [SOGo] Can't Login after Install/Configuration of New Instance
Hello Ron Scott-Adams Am 2014-03-02 04:49, schrieb Ron Scott-Adams: On Feb 28, 2014, at 1:20 AM, Ron Scott-Adams r...@tohuw.net wrote: Ah, now I’ve gotten somewhere. I added an MX entry and flipped the domain so I can test logging in via IMAP. That worked fine, as did SMTP. So my only auth problem is with the SOGo web interface and any DAV logins. So, we’re dealing with my SOGo Apache conf now, yeah? ... I don't think it has to do with your apache config at all. On Feb 28, 2014, at 12:11 AM, Ron Scott-Adams r...@tohuw.net wrote: The LDAP search returns results fine. The difference in our ACLs is nominal, to my understanding. tohuw@joab:~$ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b uid=tohuw,ou=users,dc=tohuw,dc=net -D uid=sogo,ou=Services,dc=tohuw,dc=net ... You use ldapi here. Could you try with the same URL as used in your sogo.conf please? Kind regards, Christian Mack -- Christian Mack Abteilung Basisdienste KIM IT-Services Universität Konstanz smime.p7s Description: S/MIME Cryptographic Signature
Re: [SOGo] Can't Login after Install/Configuration of New Instance
If someone can take a look at this, that would be great. I lost a bit of this
thread inadvertently, but for anyone interested in the backlog, it’s at
https://lists.inverse.ca/sogo/arc/users/2014-02/msg00378.html. I’m pasting the
most relevant trail below, **with a relevant revision based on my very latest
conf**. I have at this point moved DNS and services to this server. Everything
in Postfix/Dovecot works fine. Anything SOGo seems to not work, including
logging in to the web interface, and any of the DAV services.
I have noticed if I visit the URL https://tohuw.net/SOGo/dav/tohuw/, I get
object not found: tohuw”, but I can’t remember if that’s expected behavior or
not.
Let me know what else I can provide. Thanks in advance.
—
Ah, now I’ve gotten somewhere. I added an MX entry and flipped the domain so I
can test logging in via IMAP. That worked fine, as did SMTP. So my only auth
problem is with the SOGo web interface and any DAV logins. So, we’re dealing
with my SOGo Apache conf now, yeah?
tohuw@joab:~$ sudo cat /etc/apache2/conf.d/SOGo.conf
Alias /SOGo.woa/WebServerResources/ \
/usr/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo/WebServerResources/ \
/usr/lib/GNUstep/SOGo/WebServerResources/
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
/usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2
Directory /usr/lib/GNUstep/SOGo/
AllowOverride None
Order deny,allow
Allow from all
# Explicitly allow caching of static content to avoid browser specific
behavior.
# A resource's URL MUST change in order to have the client load the new
version.
IfModule expires_module
ExpiresActive On
ExpiresDefault access plus 1 year
/IfModule
/Directory
LocationMatch
^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*\.(jpg|png|gif|css|js)
SetHandler default-handler
/LocationMatch
## Uncomment the following to enable proxy-side authentication, you will then
## need to set the SOGoTrustProxyAuthentication SOGo user default to YES and
## adjust the x-webobjects-remote-user proxy header in the Proxy section
## below.
#Location /SOGo
# AuthType XXX
# Require valid-user
# SetEnv proxy-nokeepalive 1
# Allow from all
#/Location
ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On
# When using CAS, you should uncomment this and install cas-proxy-validate.py
# in /usr/lib/cgi-bin to reduce server overloading
#
# ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
# Proxy http://localhost/app/cas-proxy-validate.py
# Order deny,allow
# Allow from your-cas-host-addr
# /Proxy
ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0
Proxy http://127.0.0.1:2/SOGo
## adjust the following to your configuration
RequestHeader set x-webobjects-server-port 443
RequestHeader set x-webobjects-server-name tohuw.net
RequestHeader set x-webobjects-server-url https://tohuw.net;
## When using proxy-side autentication, you need to uncomment and
## adjust the following line:
# RequestHeader set x-webobjects-remote-user %{REMOTE_USER}e
RequestHeader set x-webobjects-server-protocol HTTP/1.0
AddDefaultCharset UTF-8
Order allow,deny
Allow from all
/Proxy
# Create a rule to allow the url to be all lower-case
RewriteEngine On
RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
Redirect permanent /webmail https://tohuw.net/SOGo
# CardDav (Mac) Support
NameVirtualHost 0.0.0.0:8843
VirtualHost 0.0.0.0:8843
ServerName tohuw.net
SSLEngine On
SSLCertificateFile /etc/ssl/certs/tohuw_net.crt
SSLCertificateKeyFile /etc/ssl/private/tohuw_net.key
SSLCertificateChainFile /etc/ssl/certs/tohuw_net.ca-bundle
ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On
ProxyPassInterpolateEnv On
ProxyPass /principals http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass /SOGo/dav/ http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass / http://127.0.0.1:2/SOGo/dav/ interpolate
Proxy http://127.0.0.1:2
RequestHeader set x-webobjects-server-port 8843
RequestHeader set x-webobjects-server-name tohuw.net:8843
RequestHeader set x-webobjects-server-url https://tohuw.net:8843;
RequestHeader set x-webobjects-server-protocol HTTP/1.0
RequestHeader set x-webobjects-remote-host 127.0.0.1
AddDefaultCharset UTF-8
Order allow,deny
Allow from all
/Proxy
/VirtualHost
On Feb 28, 2014, at 12:11 AM, Ron Scott-Adams r...@tohuw.net wrote:
Hi Christian. Thanks again for your assistance. What you say about the database
makes sense, and is rather what I expected.
The LDAP search returns results fine. The difference in our ACLs is nominal, to
my understanding.
tohuw@joab:~$ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b
uid=tohuw,ou=users,dc=tohuw,dc=net -D uid=sogo,ou=Services,dc=tohuw,dc=net
dn: uid=tohuw,ou=Users,dc=tohuw,dc=net
objectClass: inetOrgPerson
objectClass: posixAccount
Re: [SOGo] Can't Login after Install/Configuration of New Instance
Any ideas? I’m running out of ideas here. Let me know if I can provide any
other details.
On Feb 28, 2014, at 1:20 AM, Ron Scott-Adams r...@tohuw.net wrote:
Ah, now I’ve gotten somewhere. I added an MX entry and flipped the domain so
I can test logging in via IMAP. That worked fine, as did SMTP. So my only
auth problem is with the SOGo web interface and any DAV logins. So, we’re
dealing with my SOGo Apache conf now, yeah?
tohuw@joab:~$ sudo cat /etc/apache2/conf.d/SOGo.conf
Alias /SOGo.woa/WebServerResources/ \
/usr/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo/WebServerResources/ \
/usr/lib/GNUstep/SOGo/WebServerResources/
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
/usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2
Directory /usr/lib/GNUstep/SOGo/
AllowOverride None
Order deny,allow
Allow from all
# Explicitly allow caching of static content to avoid browser specific
behavior.
# A resource's URL MUST change in order to have the client load the new
version.
IfModule expires_module
ExpiresActive On
ExpiresDefault access plus 1 year
/IfModule
/Directory
LocationMatch
^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*\.(jpg|png|gif|css|js)
SetHandler default-handler
/LocationMatch
## Uncomment the following to enable proxy-side authentication, you will then
## need to set the SOGoTrustProxyAuthentication SOGo user default to YES and
## adjust the x-webobjects-remote-user proxy header in the Proxy section
## below.
#Location /SOGo
# AuthType XXX
# Require valid-user
# SetEnv proxy-nokeepalive 1
# Allow from all
#/Location
ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On
# When using CAS, you should uncomment this and install cas-proxy-validate.py
# in /usr/lib/cgi-bin to reduce server overloading
#
# ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
# Proxy http://localhost/app/cas-proxy-validate.py
# Order deny,allow
# Allow from your-cas-host-addr
# /Proxy
ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0
Proxy http://127.0.0.1:2/SOGo
## adjust the following to your configuration
RequestHeader set x-webobjects-server-port 443
RequestHeader set x-webobjects-server-name joab.tohuw.net
RequestHeader set x-webobjects-server-url https://joab.tohuw.net;
## When using proxy-side autentication, you need to uncomment and
## adjust the following line:
# RequestHeader set x-webobjects-remote-user %{REMOTE_USER}e
RequestHeader set x-webobjects-server-protocol HTTP/1.0
AddDefaultCharset UTF-8
Order allow,deny
Allow from all
/Proxy
# Create a rule to allow the url to be all lower-case
RewriteEngine On
RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
Redirect permanent /webmail https://tohuw.net/SOGo
# CardDav (Mac) Support
NameVirtualHost 0.0.0.0:8843
VirtualHost 0.0.0.0:8843
ServerName tohuw.net
SSLEngine On
SSLCertificateFile /etc/ssl/certs/tohuw_net.crt
SSLCertificateKeyFile /etc/ssl/private/tohuw_net.key
SSLCertificateChainFile /etc/ssl/certs/tohuw_net.ca-bundle
ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On
ProxyPassInterpolateEnv On
ProxyPass /principals http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass /SOGo/dav/ http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass / http://127.0.0.1:2/SOGo/dav/ interpolate
Proxy http://127.0.0.1:2
RequestHeader set x-webobjects-server-port 8843
RequestHeader set x-webobjects-server-name joab.tohuw.net:8843
RequestHeader set x-webobjects-server-url
https://joab.tohuw.net:8843;
RequestHeader set x-webobjects-server-protocol HTTP/1.0
RequestHeader set x-webobjects-remote-host 127.0.0.1
AddDefaultCharset UTF-8
Order allow,deny
Allow from all
/Proxy
/VirtualHost
On Feb 28, 2014, at 12:11 AM, Ron Scott-Adams r...@tohuw.net wrote:
Hi Christian. Thanks again for your assistance. What you say about the
database makes sense, and is rather what I expected.
The LDAP search returns results fine. The difference in our ACLs is nominal,
to my understanding.
tohuw@joab:~$ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b
uid=tohuw,ou=users,dc=tohuw,dc=net -D uid=sogo,ou=Services,dc=tohuw,dc=net
dn: uid=tohuw,ou=Users,dc=tohuw,dc=net
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: tohuw
sn: Scott-Adams
givenName: Ron
cn: Ron Scott-Adams
gecos: Ron Scott-Adams
loginShell: /bin/bash
homeDirectory: /home/tohuw
uidNumber: 1000
gidNumber: 1000
mail: r...@joab.tohuw.net
On Feb 27, 2014, at 4:17 AM, Christian Mack christian.m...@uni-konstanz.de
wrote:
Hello Ron Scott-Adams
Am 2014-02-26 03:11, schrieb Ron Scott-Adams:
It’s also worth mentioning that my postgres
Re: [SOGo] Can't Login after Install/Configuration of New Instance
Ah, now I’ve gotten somewhere. I added an MX entry and flipped the domain so I
can test logging in via IMAP. That worked fine, as did SMTP. So my only auth
problem is with the SOGo web interface and any DAV logins. So, we’re dealing
with my SOGo Apache conf now, yeah?
tohuw@joab:~$ sudo cat /etc/apache2/conf.d/SOGo.conf
Alias /SOGo.woa/WebServerResources/ \
/usr/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo/WebServerResources/ \
/usr/lib/GNUstep/SOGo/WebServerResources/
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
/usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2
Directory /usr/lib/GNUstep/SOGo/
AllowOverride None
Order deny,allow
Allow from all
# Explicitly allow caching of static content to avoid browser specific
behavior.
# A resource's URL MUST change in order to have the client load the new
version.
IfModule expires_module
ExpiresActive On
ExpiresDefault access plus 1 year
/IfModule
/Directory
LocationMatch
^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*\.(jpg|png|gif|css|js)
SetHandler default-handler
/LocationMatch
## Uncomment the following to enable proxy-side authentication, you will then
## need to set the SOGoTrustProxyAuthentication SOGo user default to YES and
## adjust the x-webobjects-remote-user proxy header in the Proxy section
## below.
#Location /SOGo
# AuthType XXX
# Require valid-user
# SetEnv proxy-nokeepalive 1
# Allow from all
#/Location
ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On
# When using CAS, you should uncomment this and install cas-proxy-validate.py
# in /usr/lib/cgi-bin to reduce server overloading
#
# ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
# Proxy http://localhost/app/cas-proxy-validate.py
# Order deny,allow
# Allow from your-cas-host-addr
# /Proxy
ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0
Proxy http://127.0.0.1:2/SOGo
## adjust the following to your configuration
RequestHeader set x-webobjects-server-port 443
RequestHeader set x-webobjects-server-name joab.tohuw.net
RequestHeader set x-webobjects-server-url https://joab.tohuw.net;
## When using proxy-side autentication, you need to uncomment and
## adjust the following line:
# RequestHeader set x-webobjects-remote-user %{REMOTE_USER}e
RequestHeader set x-webobjects-server-protocol HTTP/1.0
AddDefaultCharset UTF-8
Order allow,deny
Allow from all
/Proxy
# Create a rule to allow the url to be all lower-case
RewriteEngine On
RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
Redirect permanent /webmail https://tohuw.net/SOGo
# CardDav (Mac) Support
NameVirtualHost 0.0.0.0:8843
VirtualHost 0.0.0.0:8843
ServerName tohuw.net
SSLEngine On
SSLCertificateFile /etc/ssl/certs/tohuw_net.crt
SSLCertificateKeyFile /etc/ssl/private/tohuw_net.key
SSLCertificateChainFile /etc/ssl/certs/tohuw_net.ca-bundle
ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On
ProxyPassInterpolateEnv On
ProxyPass /principals http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass /SOGo/dav/ http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass / http://127.0.0.1:2/SOGo/dav/ interpolate
Proxy http://127.0.0.1:2
RequestHeader set x-webobjects-server-port 8843
RequestHeader set x-webobjects-server-name joab.tohuw.net:8843
RequestHeader set x-webobjects-server-url
https://joab.tohuw.net:8843;
RequestHeader set x-webobjects-server-protocol HTTP/1.0
RequestHeader set x-webobjects-remote-host 127.0.0.1
AddDefaultCharset UTF-8
Order allow,deny
Allow from all
/Proxy
/VirtualHost
On Feb 28, 2014, at 12:11 AM, Ron Scott-Adams r...@tohuw.net wrote:
Hi Christian. Thanks again for your assistance. What you say about the
database makes sense, and is rather what I expected.
The LDAP search returns results fine. The difference in our ACLs is nominal,
to my understanding.
tohuw@joab:~$ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b
uid=tohuw,ou=users,dc=tohuw,dc=net -D uid=sogo,ou=Services,dc=tohuw,dc=net
dn: uid=tohuw,ou=Users,dc=tohuw,dc=net
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: tohuw
sn: Scott-Adams
givenName: Ron
cn: Ron Scott-Adams
gecos: Ron Scott-Adams
loginShell: /bin/bash
homeDirectory: /home/tohuw
uidNumber: 1000
gidNumber: 1000
mail: r...@joab.tohuw.net
On Feb 27, 2014, at 4:17 AM, Christian Mack christian.m...@uni-konstanz.de
wrote:
Hello Ron Scott-Adams
Am 2014-02-26 03:11, schrieb Ron Scott-Adams:
It’s also worth mentioning that my postgres database is empty, though
the base schema seems to be present:
sogo=# \d
List of relations
Schema | Name | Type | Owner
+--+--+---
public | sogo_folder_info
Re: [SOGo] Can't Login after Install/Configuration of New Instance
Hello Ron Scott-Adams
Am 2014-02-26 03:11, schrieb Ron Scott-Adams:
It’s also worth mentioning that my postgres database is empty, though
the base schema seems to be present:
sogo=# \d
List of relations
Schema | Name | Type | Owner
+--+--+---
public | sogo_folder_info | table| sogo
public | sogo_folder_info_c_folder_id_seq | sequence | sogo
public | sogo_sessions_folder | table| sogo
public | sogo_user_profile| table| sogo
(4 rows)
Is that normal due to no user having ever successfully logged in, or is
something else wrong that may be contributing to my login issue?
Yes, that is normal.
All other information and tables are created on the fly, when logging in
the first time.
Also, I should mention I also tested logging in as the SOGo ldap user
via ldapwhoami, and it succeeded.
ldapwhoami only shows, that your account exists, and the password is
correct.
It doesn't show which privileges you have in the LDAP tree.
Lastly, everything else in the stack seems to work:
Postfix/Dovecot/Sieve channel a message correctly when testing via
Telnet. It’s non-trivial to test too far beyond that, though, and
obviously, this is a login issue specific to SOGo. I’m sure there’s
something simple I’m not considering, but what?
On Feb 25, 2014, at 6:21 PM, Ron Scott-Adams r...@tohuw.net
mailto:r...@tohuw.net wrote:
After adding the LDAP clause to my conf and restarting SOGo, I get no
further information in sogo.log. For the record, the ACL entry for the
SOGo LDAP user follows. It’s identical to the permissions in my
functional SOGo implementation, and the DIT is structured the same.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to dn.subtree=ou=Users,dc=tohuw,dc=net by
dn=uid=sogo,ou=Services,dc=tohuw,dc=net write
*
cut
In my openLDAP olcAccess is in
dn: olcDatabase={-1}frontend,cn=config
But I am not sure, this is your problem.
Could you try an ldapsearch with the
dn=uid=sogo,ou=Services,dc=tohuw,dc=net user?
Please search for another users entrys.
Kind regards,
Christian Mack
--
Christian Mack
Abteilung Basisdienste
KIM IT-Services
Universität Konstanz
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [SOGo] Can't Login after Install/Configuration of New Instance
Hello Ron Scott-Adams Am 2014-02-25 03:53, schrieb Ron Scott-Adams: I'm building a new SOGo install very similar to a current, working one. I'm experiencing an issue with logging in. There is a single auth source (ldap). The error is: SOGoRootPage Login for user 'username' might not have worked - password policy: 65535 grace: -1 expire: -1 bound: 0 What can I do to elicit more information? cut Your config looks OK. I guess your user doesn't have the privileges needed on your LDAP. In order to get more debugging information for your LDAP access, add the following to your config: LDAPDebugEnabled = YES; Kind regards, Christian Mack -- Christian Mack Abteilung Basisdienste KIM Universität Konstanz -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Can't Login after Install/Configuration of New Instance
Hello Christian, thanks for the reply.
After adding the LDAP clause to my conf and restarting SOGo, I get no further
information in sogo.log. For the record, the ACL entry for the SOGo LDAP user
follows. It’s identical to the permissions in my functional SOGo
implementation, and the DIT is structured the same.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to dn.subtree=ou=Users,dc=tohuw,dc=net by
dn=uid=sogo,ou=Services,dc=tohuw,dc=net write
Ron Scott-Adams
r...@tohuw.net
“We are stuck with technology when what we really want is just stuff that
works.” (Douglas Adams)
On Feb 25, 2014, at 5:58 AM, Christian Mack christian.m...@uni-konstanz.de
wrote:
Hello Ron Scott-Adams
Am 2014-02-25 03:53, schrieb Ron Scott-Adams:
I'm building a new SOGo install very similar to a current, working one.
I'm experiencing an issue with logging in. There is a single auth source
(ldap). The error is: SOGoRootPage Login for user 'username' might not
have worked - password policy: 65535 grace: -1 expire: -1 bound: 0
What can I do to elicit more information?
cut
Your config looks OK.
I guess your user doesn't have the privileges needed on your LDAP.
In order to get more debugging information for your LDAP access, add the
following to your config:
LDAPDebugEnabled = YES;
Kind regards,
Christian Mack
--
Christian Mack
Abteilung Basisdienste
KIM
Universität Konstanz
--
users@sogo.nu
https://inverse.ca/sogo/lists
--
users@sogo.nu
https://inverse.ca/sogo/lists
Re: [SOGo] Can't Login after Install/Configuration of New Instance
It’s also worth mentioning that my postgres database is empty, though the base
schema seems to be present:
sogo=# \d
List of relations
Schema | Name | Type | Owner
+--+--+---
public | sogo_folder_info | table| sogo
public | sogo_folder_info_c_folder_id_seq | sequence | sogo
public | sogo_sessions_folder | table| sogo
public | sogo_user_profile| table| sogo
(4 rows)
Is that normal due to no user having ever successfully logged in, or is
something else wrong that may be contributing to my login issue?
Also, I should mention I also tested logging in as the SOGo ldap user via
ldapwhoami, and it succeeded.
Lastly, everything else in the stack seems to work: Postfix/Dovecot/Sieve
channel a message correctly when testing via Telnet. It’s non-trivial to test
too far beyond that, though, and obviously, this is a login issue specific to
SOGo. I’m sure there’s something simple I’m not considering, but what?
On Feb 25, 2014, at 6:21 PM, Ron Scott-Adams r...@tohuw.net wrote:
Hello Christian, thanks for the reply.
After adding the LDAP clause to my conf and restarting SOGo, I get no further
information in sogo.log. For the record, the ACL entry for the SOGo LDAP user
follows. It’s identical to the permissions in my functional SOGo
implementation, and the DIT is structured the same.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to dn.subtree=ou=Users,dc=tohuw,dc=net by
dn=uid=sogo,ou=Services,dc=tohuw,dc=net write
Ron Scott-Adams
r...@tohuw.net
“We are stuck with technology when what we really want is just stuff that
works.” (Douglas Adams)
On Feb 25, 2014, at 5:58 AM, Christian Mack christian.m...@uni-konstanz.de
wrote:
Hello Ron Scott-Adams
Am 2014-02-25 03:53, schrieb Ron Scott-Adams:
I'm building a new SOGo install very similar to a current, working one.
I'm experiencing an issue with logging in. There is a single auth source
(ldap). The error is: SOGoRootPage Login for user 'username' might not
have worked - password policy: 65535 grace: -1 expire: -1 bound: 0
What can I do to elicit more information?
cut
Your config looks OK.
I guess your user doesn't have the privileges needed on your LDAP.
In order to get more debugging information for your LDAP access, add the
following to your config:
LDAPDebugEnabled = YES;
Kind regards,
Christian Mack
--
Christian Mack
Abteilung Basisdienste
KIM
Universität Konstanz
--
users@sogo.nu
https://inverse.ca/sogo/lists
--
users@sogo.nu
https://inverse.ca/sogo/lists
[SOGo] Can't Login after Install/Configuration of New Instance
I'm building a new SOGo install very similar to a current, working one. I'm
experiencing an issue with logging in. There is a single auth source (ldap).
The error is: SOGoRootPage Login for user 'username' might not have worked -
password policy: 65535 grace: -1 expire: -1 bound: 0 What can I do to
elicit more information?
The configuration is not different between the two servers that I can tell,
except those parts necessary due to the server being different. I have ensured
the necessary entries exist in LDAP, and everything else seems correct.
ldapwhoami authenticates the user fine.
My sogo.conf follows. If I can provide anything else, please let me know.
{
SOGoProfileURL = postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile;
OCSFolderInfoURL =
postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info;
OCSSessionsFolderURL =
postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder;
OCSEMailAlarmsFolderURL =
postgresql://sogo:sogo@localhost:5432/sogo/sogo_alarms_folder;
SOGoSMTPServer = 127.0.0.1;
SOGoMailDomain = tohuw.net;
SOGoMailingMechanism = smtp;
SOGoForceExternalLoginWithEmail = NO;
SOGoMailSpoolPath = /var/spool/sogo;
SOGoIMAPServer = localhost;
NGImap4ConnectionStringSeparator = /;
SOGoDraftsFolderName = Drafts;
SOGoSentFolderName = Sent;
SOGoTrashFolderName = Trash;
SOGoIMAPAclConformsToIMAPExt = YES;
SOGoMailAuxiliaryUserAccountsEnabled = YES;
SOGoDefaultCalendar = personal;
SOGoHideSystemEmail = YES;
SOGoSieveServer = sieve://127.0.0.1:4190;
SOGoSieveScriptsEnabled = YES;
SOGoVacationEnabled = YES;
SOGoForwardEnabled = YES;
SOGoSieveServer = sieve://127.0.0.1:4190;
SOGoAppointmentSendEMailNotifications = YES;
SOGoACLsSendEMailNotifications = YES;
SOGoEnableEmailAlarms = YES;
SOGoUserSources = (
{
type = ldap;
CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = uid;
baseDN = ou=Users,dc=tohuw,dc=net;
bindDN = uid=sogo,ou=Services,dc=tohuw,dc=net;
bindPassword = [redacted];
canAuthenticate = YES;
displayName = Shared Addresses;
hostname = ldap://127.0.0.1:389;
id = public;
isAddressBook = YES;
}
);
SOGoPasswordChangeEnabled = YES;
SOGoPageTitle = Webmail;
SOGoLanguage = English;
SOGoTimeZone = America/New_York;
}
Ron Scott-Adams
r...@tohuw.net
“We are stuck with technology when what we really want is just stuff that
works.” (Douglas Adams)
--
users@sogo.nu
https://inverse.ca/sogo/lists
