View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001762SOGoBackend Generalpublic2012-04-09 16:002012-05-31 13:12
Reporterchrroessner Assigned Toludovic  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Product Version1.3.14 
Target Version1.3.16Fixed in Version1.3.16 
Summary0001762: bindAsCurrentUser issue in LDAP
Description

I enabled "bindAsCurrentUser" in the SOGoUserSources. Doing this breaks all users calendars and address books. To be precise: One user can do everything and for all other users, SOGo uses a wrong DN to bind to LDAP.

In my case, I have two users, croessner and eroessner.

The DN for croessner is:
uid=de10000,ou=people,ou=it,dc=roessner-net,dc=de

The DN for eroessner is:
uid=de10008,ou=people,ou=it,dc=roessner-net,dc=de

If croessner can use his calendar and address book, eroessner only receives errors and soho.log shows 404 errors. I digger deeper into this and traced my LDAP servers for this. It shows that for user eroessner, a wrong DN is used to bind:

Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 fd=37 ACCEPT from IP=[2a01:4f8:131:1081:88:198:80:229]:53774 (IP=[::]:389)
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=0 STARTTLS
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=0 RESULT oid= err=0 text=
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 fd=37 TLS established tls_ssf=128 ssf=128
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=1 BIND dn="uid=de10000,ou=people,ou=it,dc=roessner-net,dc=de" method=128
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=1 BIND dn="uid=de10000,ou=people,ou=it,dc=roessner-net,dc=de" mech=SIMPLE ssf=0
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=1 RESULT tag=97 err=0 text=
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=2 SRCH base="ou=it,dc=roessner-net,dc=de" scope=2 deref=0 filter="(|(uniqueIdentifier=eroessner)(mail=eroessner)(cn=eroessner))"
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=2 SRCH attr=*
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text=
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 op=3 UNBIND
Apr 9 12:10:12 roessner1 slapd[7641]: conn=15961 fd=37 closed

You can see that SOGo tries to use the de10000 entry, which normally is owned by croesner to query for eroessner information. And that mud fail, because the LDAP ACLs do not allow binding as user A and looking for attributes from user B.

A temporary workaround is to disable bindAsCurrentUser. But with this, I also can not allow a user to change his or her password over the web interface, as the proxy user only does have read access to the LDAP servers.

Additional Information

sogod SOGoUserSources '(
{
CNFieldName = cn;
IMAPLoginFieldName = mail;
KindFieldName = Kind;
MailFieldNames = (
mail
);
MultipleBookingsFieldName = Multiplebookings;
UIDFieldName = uniqueIdentifier;
baseDN = "ou=it,dc=roessner-net,dc=de";
bindAsCurrentUser = NO;
bindDN = "cn=proxyuser,dc=roessner-net,dc=de";
bindFields = (
mail,
cn,
uniqueIdentifier
);
bindPassword = *****;
canAuthenticate = YES;
displayName = "Gemeinsame Adressen";
encryption = STARTTLS;
hostname = "ldap0.roessner-net.de db.roessner-net.de";
id = LDAP;
isAddressBook = YES;
port = 389;
scope = SUB;
type = ldap;
}
)'

TagsNo tags attached.

Activities

chrroessner

chrroessner

2012-04-10 07:34

reporter   ~0003699

I just saw, this issue has a side effect to the administration tab in the web interface as well. While with the setting bindAsCurrentUser=YES you can not see any calendars or address books from users, all works well, if the option is disabled.
chrroessner

chrroessner

2012-04-10 17:28

reporter   ~0003713

Here is a sample LDIF file of user de10000:

dn: uid=de10000,ou=people,ou=it,dc=roessner-net,dc=de
objectClass: amavisAccount
objectClass: top
objectClass: rnsMSDovecotAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: rnsMSPostfixAccount
objectClass: extensibleObject
objectClass: calEntry
cn:: Q2hyaXN0aWFuIFLDtsOfbmVy
sn:: UsO2w59uZXI=
amavisLocal: TRUE
amavisSpamKillLevel: 2.4
amavisSpamTag2Level: 2.4
facsimileTelephoneNumber: +49 641 33053909
givenName: Christian
homePhone: +49 641 5879091
l:: R2llw59lbg==
labeledURI: http://www.roessner-network-solutions.com/
mail: c@roessner-network-solutions.com
mobile: +49 01234 56789
o:: UsO2w59uZXItTmV0d29yay1Tb2x1dGlvbnM=
ou: Administration
postalCode: 12345
rnsMSDeliverToAddress: de10000@srvint.net
rnsMSDovecotUser: de10000@srvint.net
rnsMSEnableDovecot: TRUE
rnsMSEnablePostfix: TRUE
rnsMSMailboxHome: /var/mail/virtual/de10000
rnsMSQuota: 5242880
rnsMSRecipientAddress: c@g33k5.de
rnsMSRecipientAddress: c@roessner-network-solutions.com
rnsMSRecipientAddress: christian@roessner-net.com
rnsMSRecipientAddress: de10000@srvint.net
rnsMSRecipientAddress: info@roessner-net.com
st: Some State
street: Some street
uid: de10000
uniqueIdentifier: croessner
userPassword: {SSHA}****

And here are some ACLs, so you can see, why the bug came up:

access to attrs=userPassword,shadowLastChange
by self write
by dn.exact="cn=proxyuser,dc=roessner-net,dc=de" read
by dn.exact="cn=replicator,dc=roessner-net,dc=de" read
by dn.exact="cn=mail,ou=people,ou=it,dc=roessner-net,dc=de" read
by anonymous auth
by * none

access to dn.sub="ou=it,dc=roessner-net,dc=de"
attrs=entry,children,@inetOrgPerson,@calEntry,@calendarResource
by users read
by * break

access to dn.sub="ou=it,dc=roessner-net,dc=de"
attrs=entry,children,@rnsMSPostfixAccount,@rnsMSDovecotAccount,@amavisAccount,givenName,sn
by dn.exact="cn=mail,ou=people,ou=it,dc=roessner-net,dc=de" read
by * break

access to
by dn.exact="cn=proxyuser,dc=roessner-net,dc=de" read
by dn.exact="cn=replicator,dc=roessner-net,dc=de" read
by self read
by none

So even for the address book lookups to work, SOGo must use the proxy user and not the bindAsCurrentUser.

So two problems with the same source. Do you need more information?

2012-04-16 07:36

 

sogo.log.gz (5,552 bytes)
chrroessner

chrroessner

2012-04-16 07:37

reporter   ~0003741

The log file I added is from the day, where I reported this issue. You can see the ping pong between users.
chrroessner

chrroessner

2012-05-15 19:48

reporter   ~0003910

I tested "bindAsCurrentUser = YES;" on SOGo-2.0.0 (2.0.0.20120515-1). Same result
jraby

jraby

2012-05-15 21:51

viewer   ~0003912

Could you reproduce this issue and provide the logs excerpts from both ldap and sogo?
chrroessner

chrroessner

2012-05-16 08:45

reporter   ~0003914

Last edited: 2012-05-16 08:46

1st person: The user that has successful connect:

sogo.log:
127.0.0.1 - - [16/May/2012:10:31:59 GMT] "PROPFIND /SOGo/dav/croessner/Contacts/personal/ HTTP/1.1" 207 416/181 0.032 - - 460K
95.223.188.147 - - [16/May/2012:10:31:59 GMT] "PROPFIND /SOGo/dav/croessner/Calendar/ HTTP/1.1" 207 1558/1925 0.103 8706 82% 1M

ldap.log:
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 fd=42 ACCEPT from IP=[2a01:4f8:131:1081:88:198:80:229]:40298 (IP=[::]:389)
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=0 EXT oid=1.3.6.1.4.1.1466.20037
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=0 STARTTLS
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=0 RESULT oid= err=0 text=
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 fd=42 TLS established tls_ssf=128 ssf=128
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=1 BIND dn="cn=proxyuser,dc=roessner-net,dc=de" method=128
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=1 BIND dn="cn=proxyuser,dc=roessner-net,dc=de" mech=SIMPLE ssf=0
May 16 10:31:59 roessner1 slapd[3134]: conn=13523 fd=41 TLS established tls_ssf=128 ssf=128
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=1 RESULT tag=97 err=0 text=
May 16 10:31:59 roessner1 slapd[3134]: conn=13523 op=1 BIND dn="cn=proxyuser,dc=roessner-net,dc=de" method=128
May 16 10:31:59 roessner1 slapd[3134]: conn=13523 op=1 BIND dn="cn=proxyuser,dc=roessner-net,dc=de" mech=SIMPLE ssf=0
May 16 10:31:59 roessner1 slapd[3134]: conn=13523 op=1 RESULT tag=97 err=0 text=
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=2 SRCH base="ou=it,dc=roessner-net,dc=de" scope=2 deref=0 filter="(|(mail=croessner)(cn=croessner)(uniqueIdentifier=croessner))"
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=2 SRCH attr=dn
May 16 10:31:59 roessner1 slapd[3134]: conn=13524 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
May 16 10:31:59 roessner1 slapd[3134]: conn=13521 op=1 BIND dn="uid=de10000,ou=people,ou=it,dc=roessner-net,dc=de" method=128
May 16 10:31:59 roessner1 slapd[3134]: conn=13523 op=2 SRCH base="ou=it,dc=roessner-net,dc=de" scope=2 deref=0 filter="(|(mail=croessner)(cn=croessner)(uniqueIdentifier=croessner))"
May 16 10:31:59 roessner1 slapd[3134]: conn=13521 op=1 BIND dn="uid=de10000,ou=people,ou=it,dc=roessner-net,dc=de" mech=SIMPLE ssf=0
May 16 10:31:59 roessner1 slapd[3134]: conn=13523 op=2 SRCH attr=dn
May 16 10:31:59 roessner1 slapd[3134]: conn=13521 op=1 RESULT tag=97 err=0 text=
May 16 10:31:59 roessner1 slapd[3134]: conn=13523 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=

Now, while this user seems to work perfectly, the other user has bad luck, because SOGo now uses the first users stuff to access the LDAP server, which must fail because of the correct LDAP ACLs!

2nd person:

sogo.log:
127.0.0.1 - - [16/May/2012:10:36:20 GMT] "PROPFIND /SOGo/dav/eroessner/Contacts/personal/ HTTP/1.1" 404 57/181 0.045 - - 0
217.227.86.161 - - [16/May/2012:10:36:20 GMT] "PROPFIND /SOGo/dav/eroessner/Calendar/ HTTP/1.1" 404 42/1925 0.123 - - 0

ldap.log:
May 16 10:36:20 roessner1 slapd[3134]: conn=13529 op=1 BIND dn="uid=de10000,ou=people,ou=it,dc=roessner-net,dc=de" method=128
May 16 10:36:20 roessner1 slapd[3134]: conn=13529 op=1 BIND dn="uid=de10000,ou=people,ou=it,dc=roessner-net,dc=de" mech=SIMPLE ssf=0
May 16 10:36:20 roessner1 slapd[3134]: conn=13529 op=1 RESULT tag=97 err=0 text=
May 16 10:36:20 roessner1 slapd[3134]: conn=13529 op=2 SRCH base="ou=it,dc=roessner-net,dc=de" scope=2 deref=0 filter="(|(uniqueIdentifier=eroessner)(mail=eroessner)(cn=eroessner))"

You now can clearly see the problem: In the second ldap.log you see that SOGo binds with the de10000 uid which belongs to croessner, but it should have bound with uid=de10008!

Also, if you can fix that bug, please keep in mind that the global address book must always be bound with the cn=proxyuser and not one of the regular users. A regular user always should only have success to its own LDAP object and not to any other objects in the DIT.
chrroessner

chrroessner

2012-05-22 19:33

reporter   ~0003957

New additional information:

If I activate bindAsCurrentUser, then all clients seem to work perfectly. All get 2xx codes in the sogo.log file. But in the moment, where the first user does a write action, say adding a new event to a calendar, all other users are broken in that moment.

Do you need any further information? I do not know, what else I can deliver to you :)
chrroessner

chrroessner

2012-05-23 10:09

reporter   ~0003965

Problem solved. Dumping all data, purging all sql tables and fully restoring all data fixed that issue.

Issue History

Date Modified Username Field Change
2012-04-09 16:00 chrroessner New Issue
2012-04-10 07:34 chrroessner Note Added: 0003699
2012-04-10 17:28 chrroessner Note Added: 0003713
2012-04-16 07:36 chrroessner File Added: sogo.log.gz
2012-04-16 07:37 chrroessner Note Added: 0003741
2012-05-15 19:48 chrroessner Note Added: 0003910
2012-05-15 21:51 jraby Note Added: 0003912
2012-05-16 08:45 chrroessner Note Added: 0003914
2012-05-16 08:46 chrroessner Note Edited: 0003914
2012-05-22 19:33 chrroessner Note Added: 0003957
2012-05-22 20:15 ludovic Target Version => 1.3.16
2012-05-23 10:09 chrroessner Note Added: 0003965
2012-05-31 13:12 ludovic Status new => resolved
2012-05-31 13:12 ludovic Fixed in Version => 1.3.16
2012-05-31 13:12 ludovic Resolution open => no change required
2012-05-31 13:12 ludovic Assigned To => ludovic
2012-05-31 13:12 ludovic Status resolved => closed