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

Reply via email to