I started memcached in debug mode and I logged dump attached above. It was catched after iddle > SOGoCacheCleanupInterval

LDAP user record:

dn: cn=u00001,o=bingo,dc=mydomain,dc=local
objectClass: top
objectClass: person
objectClass: knkPerson
cn: u00001
o: bingo
mail: bogdan@bingo.mydomain.com.pl
uid: u00001-bingo
knkMailQuota: 8192
userPassword: {SSHA}cutted
displayName: Boguslaw Juza
givenName: Boguslaw
sn: Juza

From SOGo config file:

CNFieldName = displayName;
UIDFieldName = uid;
bindFields = ( mail };
id = bingo;
filter = "(o='bingo' AND NOT knkDisable='*')";

The SOGoEnableDomainBasedUID flag is set to NO in my config file. If I change it to YES, session works correctly. But SOGo adds domain name to UID and to e-mail, so it creates bogdan@bingo.mydomain.com.pl@bingo.mydomain.com.pl.

I have unique uids in all domains and I do not want to use domain-based UIDs.
But while SOGo is recreating memcached entries, it forces it. In memcached debug log these enteries appears:

<31 set bogdan@bingo.mydomain.com.pl@bingo.mydomain.com.pl+attributes 0 10 4

31 STORED

I reproduced the issue here.

Here's the simplest config to reproduce the bug:

<pre>
domains = {
acme.com = {
SOGoMailDomain = acme.com;
SOGoUserSources = (
{
CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = uid;
baseDN = "ou=acme,dc=example,dc=com";
bindDN = "cn=admin,dc=example,dc=com";
bindPassword = sogo;
bindFields = (mail);
canAuthenticate = YES;
displayName = "Acme Shared Addresses";
hostname = "ldap://127.0.0.1:3389/";
id = acme_directory;
isAddressBook = YES;
type = ldap;
},
);
};
</pre>

Sample user ldap entry:
<pre>
dn: uid=acme1,ou=acme,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
cn: Acme One
sn: One
givenName: Acme
homePhone: +1 (123) 456-7890
l: Vladivostok
mail: acme1@acme.com
telephoneNumber: +1 (120) 987-6543
uid: acme1
userPassword:: e1NTSEF9K1IxWUlCZTJaaEVCa084MkJRUWhsdDgyZHc4S1RGWkZlUjJDQXc9P
Q==
</pre>

• Shutdown memcached
• try to login as acme1@acme.com... it won't work, you'll be redirected to the login page infinitely

It seems to happen only if bindfields contains (mail).

This should be fixed in the next nightly build: https://github.com/inverse-inc/sogo/commit/eec8c07d4f061a2006bd7ec9967a2b1c92e7618b

Note that the data returned by the UIDFieldName attribute (uid in the example above) MUST still be unique across the entire SOGo installation.

So, a setup like this will NOT work:
<pre>
dn: uid=jdoe,ou=acme,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
cn: John Doe
sn: Doe
givenName: John
mail: john@acme.com
telephoneNumber: +1 (120) 987-6543
uid: jdoe
userPassword: patate

dn: uid=jdoe,ou=coyote,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
cn: Jack Doe
sn: Doe
givenName: John
mail: jack@coyote.com
telephoneNumber: +1 (120) 987-6543
uid: jdoe
userPassword: patate
</pre>

Even if the complete DN is different, since both users shares the same 'uid' value, sogo will consider this as being the same user (they will end up using the same database tables behind the scenes...)
Keep this in ming when designing your ldap server, make sure to assign a unique uid value to each user.

This patch fixes this issue and session is now preserved after longer idle time. Thanks! :)

I have UIDs created by scheme CN-OU, so they are unique across the entire SOGo.