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 <[email protected]> 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:20000/SOGo retry=0 > > <Proxy http://127.0.0.1:20000/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:20000/SOGo/dav/ interpolate > ProxyPass /SOGo/dav/ http://127.0.0.1:20000/SOGo/dav/ interpolate > ProxyPass / http://127.0.0.1:20000/SOGo/dav/ interpolate > > <Proxy http://127.0.0.1:20000> > 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 <[email protected]> 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: [email protected] >> >> On Feb 27, 2014, at 4:17 AM, Christian Mack <[email protected]> >> 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 >>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 >>> >> > -- [email protected] https://inverse.ca/sogo/lists
