General discussion on installation and configuration of SOGo

Text archives Help

Re: [SOGo] Can't Login after Install/Configuration of New Instance

Chronological Thread 
  • From: Ron Scott-Adams < >
  • To:
  • Subject: Re: [SOGo] Can't Login after Install/Configuration of New Instance
  • Date: Fri, 28 Feb 2014 01:20:00 -0500

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/ \
Alias /SOGo/WebServerResources/ \
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \

<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"

<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*\.(jpg|png|gif|css|js)">
  SetHandler default-handler

## 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

ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On

# When using CAS, you should uncomment this and install
# in /usr/lib/cgi-bin to reduce server overloading
#   Order deny,allow
#   Allow from your-cas-host-addr
# </Proxy>

ProxyPass /SOGo retry=0

## adjust the following to your configuration
  RequestHeader set "x-webobjects-server-port" "443"
  RequestHeader set "x-webobjects-server-name" ""
  RequestHeader set "x-webobjects-server-url" ""

## 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

# 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

# CardDav (Mac) Support
    SSLEngine On
    SSLCertificateFile /etc/ssl/certs/tohuw_net.crt
    SSLCertificateKeyFile /etc/ssl/private/tohuw_net.key
    SSLCertificateChainFile /etc/ssl/certs/

    ProxyRequests Off
    SetEnv proxy-nokeepalive 1
    ProxyPreserveHost On

    ProxyPassInterpolateEnv On
    ProxyPass /principals interpolate
    ProxyPass /SOGo/dav/ interpolate
    ProxyPass / interpolate

        RequestHeader set "x-webobjects-server-port" "8843"
        RequestHeader set "x-webobjects-server-name" ""
        RequestHeader set "x-webobjects-server-url" ""
        RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
        RequestHeader set "x-webobjects-remote-host" ""
        AddDefaultCharset UTF-8
        Order allow,deny
        Allow from all

On Feb 28, 2014, at 12:11 AM, Ron Scott-Adams < > 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

On Feb 27, 2014, at 4:17 AM, Christian Mack < > 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                 | 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
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 <
<mailto: >> 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

Archive powered by MHonArc 2.6.18.

Top of page