ldap groups and ptloader
Dear list, I use saslauthd to auth against ldap (bind auth) and I am trying to use ptloader to fetch group information from LDAP so that group based ACL's can be used for shared folders. The ldap auth works fine, but the group information gets screwed up somewhere. With tcpdump I see my directory server sending the correct group information to ptloader, but ptloader seems to interpret this information wrong. If I look with ptdump each user is listed with the correct number of groups he is member of, but the group name is wrong. Instead of the group name (cn attribute) it shows some random attribute such as another group member (a value of the memberUid attribute), or top ( a value of the objectclass attribute ). Sometimes, the group name is correct. I am running cyrus 2.2.13, on debian lenny amd64, compiled from the debian lenny source package to include ptloader support ( the default debian binary package does not include ptloader support ). /etc/imapd.conf: auth_mech: pts unix_group_enable: no ptloader_sock: /var/run/cyrus/socket/ptsock ldap_base: ou=people,dc=example,dc=org ldap_filter: (uid=%U) ldap_version: 3 ldap_sasl: 0 ldap_size_limit: 100 ldap_group_base: ou=groups,dc=example,dc=org ldap_group_scope: sub ldap_group_filter: cn=%u ldap_member_scope: sub ldap_member_base: ou=groups,dc=example,dc=org # ldap_member_method: attribute # ldap_member_attribute: memberUid ldap_member_method: filter ldap_member_filter: memberUid=%U ldap_uri: ldap://netinfo.example.org/ pts_module: ldap My group information is in ou=groups,dc=example,dc=org. My groups are posixGroup with the uid's of the members listed in the memberUid attribute, the group name is listed in the cn attribute: dn: cn=domainusers,ou=groups,dc=example,dc=org gidNumber: 513 description: Netbios Domain Users sambaSID: S-1-5-21---513 sambaGroupType: 2 displayName: Domain Users cn: domainusers memberUid: anja memberUid: someuid1 ... memberUid: someuid20 objectClass: top objectClass: posixGroup objectClass: sambaGroupMapping this is a typical user entry: dn: cn=Anja Smith,ou=people,dc=example,dc=org objectClass: inetOrgPerson objectClass: sambaSamAccount objectClass: posixAccount objectClass: top objectClass: shadowAccount givenName: Anja sn: Smith cn: Anja Smith uid: anja uidNumber: 2018 sambaSID: S-1-5-21- sambaLMPassword: sambaNTPassword: loginShell: /bin/bash gidNumber: 513 sambaPrimaryGroupSID: S-1-5-21- homeDirectory: /home/anja sambaAcctFlags: [UX] userPassword: mail: a...@example.org mail: anja.sm...@example.org sambaPwdCanChange: 0 sambaPwdMustChange: 2147483647 shadowMax: 9 The man pages are somewhat sparse on details on how the parameters are interpreted and how they will get the ldap information interpreted. I tried serveral variations on the configuration file without any success. Any tips on how to fix this ? Kind regards, Jos Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldap groups and ptloader
Jos De Graeve wrote: JDG I use saslauthd to auth against ldap (bind auth) and I am trying JDG to use ptloader to fetch group information from LDAP so that group JDG based ACL's can be used for shared folders. We have several similar systems in production. JDG If I look with ptdump each user is listed with the correct number JDG of groups he is member of, but the group name is wrong. Instead JDG of the group name (cn attribute) it shows some random attribute JDG such as another group member (a value of the memberUid attribute), JDG or top ( a value of the objectclass attribute ). Sometimes, the JDG group name is correct. JDG I am running cyrus 2.2.13, on debian lenny amd64 auth_mech: pts unix_group_enable: no ptloader_sock: /var/run/cyrus/socket/ptsock ldap_base: ou=people,dc=example,dc=org ldap_filter: (uid=%U) ldap_version: 3 ldap_sasl: 0 ldap_size_limit: 100 ldap_group_base: ou=groups,dc=example,dc=org ldap_group_scope: sub ldap_group_filter: cn=%u ldap_member_scope: sub ldap_member_base: ou=groups,dc=example,dc=org # ldap_member_method: attribute # ldap_member_attribute: memberUid ldap_member_method: filter ldap_member_filter: memberUid=%U ldap_uri: ldap://netinfo.example.org/ pts_module: ldap JDG My groups are posixGroup with the uid's of the members listed JDG in the memberUid attribute, the group name is listed in the cn JDG attribute: If you add ldap_member_attribute: cn to your config, it should work. Certainly something very similar works on our Lenny/amd64 2.3.14++ builds: auth_mech: pts pts_module: ldap ptscache_timeout: 60 ptloader_sock: /srv/imap/var/run/cyrus/socket/ptsock ldap_uri: ldapi:///var/run/ldapi \ ldaps://ldap3.this-site.client.com \ ldaps://ldap2.this-site.client.com \ ldaps://ldap4.this-site.client.com \ ldaps://ldap1.this-site.client.com ldap_tls_cacert_file: /etc/ssl/certs/client-ca.pem ldap_tls_check_peer:yes ldap_base: dc=client,dc=com ldap_group_base:dc=client,dc=com ldap_member_base: dc=client,dc=com ldap_sasl: no ldap_bind_dn: cn=this-cyrus,ou=agents,dc=client,dc=com ldap_password: verylongrandomstring ldap_filter: (|((objectclass=gosaMailAccount)(gosaMailServer=imap.client.com)(uid=%u))((objectclass=simpleSecurityObject)(cn=%u)(|(cn=cyrus)(cn=spamteach ldap_group_filter: ((objectclass=posixGroup)(cn=%u)) ldap_member_method: filter ldap_member_filter: ((objectclass=posixGroup)(memberUid=%u)) ldap_member_attribute: cn # size limit determines the max number of groups a user may be # in before authentication fails ldap_size_limit:1024 ldap_external_ids: mupdate.client.com fe1.client.com \ fe2.client.com feN.client.com \ be1.client.com be2.client.com \ beN.client.com JDG The man pages are somewhat sparse on details on how the JDG parameters are interpreted and how they will get the ldap JDG information interpreted. I tried serveral variations on JDG the configuration file without any success. Yes. It would be nice when someone has time to make the configuration of pts_ldap more similar to other things likely to be using the same data (eg pam/nss/samba as well as saslauthd). Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldap groups and ptloader
Hi Duncan, JDG My groups are posixGroup with the uid's of the members listed JDG in the memberUid attribute, the group name is listed in the cn JDG attribute: If you add ldap_member_attribute: cn to your config, it should work. Certainly something very similar works on our Lenny/amd64 2.3.14++ builds: Yep, that fixed it! Thanks :D Jos Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
cyrus replication and RENAME problem
Hi list, we have a cyrus murder cluster with two frontends,two backends and two replication servers, all running cyrus version 2.3.14. Each backend has two partitions. The two backends are replicated to the replication servers using the cyrus replication mechanism (sync_client -r). The replication servers have an identical partition scheme. Now to our problem: When I move a mailbox from one partition to the other partition on the same backend without changing the name of this mailbox (example command in cyradm: 'rename user.testa user.testa raid1'), nothing happens on the replication server but the mailbox is successfully moved on the backend. But when I also change the name of the mailbox while moving it (example: 'rename user.testa user.testb raid1') the replication works file and the mailbox on the replication server also changes the name and the partition. I haven't found anything in this mailing list about a possible solution to this problem, maybe it is an unknown bug or maybe a 'feature'? Can anyone help me? Renaming forth and back is a way, but not a really good solution to this problem. Regards, Markus attachment: rebensburg.vcf smime.p7s Description: S/MIME Cryptographic Signature Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
imapd, TLS and CRLs
I have been working on deploying an imap server using EXTERNAL+TLS
authentication. Everything is working fine and then I discover that
there is no support CRLs in imapd; from my point of view this is a Bad
Thing(tm).
I searched the mailing list and found a discussion of this in 2005/02
with the final word being (I'll paraphrase) sounds interesting, patches
welcome.
All right, the attached implements CRL checking via a 'tls_crl' option
in imapd.conf. Just point it at a PEM encoded CRL file. The file can
contain multiple CRLs if you have more than one CA you care about.
What it doesn't do is:
- implement crl_path
- implement CRL checking in the TLS client code
It also suffers from the fact that this code is ran at initialisation
time. When the CRL expires you need to get a fresh CRL, you need to
restart imapd; but this is the same behavior as Apache httpd and sendmail.
-stacy
--- imap/tls.c.orig 2008-11-14 15:24:38.0 -0700
+++ imap/tls.c 2010-05-27 08:32:39.0 -0600
@@ -308,6 +308,9 @@
case X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD:
syslog(LOG_NOTICE, cert has expired);
break;
+ case X509_V_ERR_CERT_REVOKED:
+ syslog(LOG_NOTICE, cert has been revoked);
+ break;
}
return (ok);
@@ -629,10 +632,15 @@
const char *cipher_list;
const char *CApath;
const char *CAfile;
+const char *CAcrl;
const char *s_cert_file;
const char *s_key_file;
intrequirecert;
inttimeout;
+ BIO *crl_file;
+ X509_CRL *crl;
+ X509_STORE *store;
+
if (tls_serverengine)
return (0); /* already running */
@@ -719,6 +727,7 @@
CAfile = config_getstring(IMAPOPT_TLS_CA_FILE);
CApath = config_getstring(IMAPOPT_TLS_CA_PATH);
+ CAcrl = config_getstring(IMAPOPT_TLS_CRL);
if ((!SSL_CTX_load_verify_locations(s_ctx, CAfile, CApath)) ||
(!SSL_CTX_set_default_verify_paths(s_ctx))) {
@@ -760,6 +769,25 @@
SSL_CTX_set_client_CA_list(s_ctx, SSL_load_client_CA_file(CAfile));
}
}
+ if(CAcrl != NULL) {
+ store = SSL_CTX_get_cert_store(s_ctx);
+ if((crl_file = BIO_new(BIO_s_file_internal())) != NULL) {
+ if (BIO_read_filename(crl_file, CAcrl) = 0) {
+ while((crl = PEM_read_bio_X509_CRL(crl_file,
NULL, NULL, NULL))) {
+ X509_STORE_add_crl(store, crl);
+ X509_CRL_free(crl);
+ }
+ X509_STORE_set_flags(store,
X509_V_FLAG_CRL_CHECK|X509_V_FLAG_CRL_CHECK_ALL);
+ } else {
+ syslog(LOG_ERR, TLS server engine: Can't load
CRL.);
+ /* should we bail? */
+ }
+
+ BIO_free(crl_file);
+ } else {
+ syslog(LOG_ERR, TLS server engine: Can't load CRL.
BIO_new failed.);
+ }
+ }
tls_serverengine = 1;
return (0);
--- lib/imapopts.c.orig 2009-12-21 06:17:55.0 -0700
+++ lib/imapopts.c 2010-05-27 07:18:26.0 -0600
@@ -736,6 +736,9 @@
{ IMAPOPT_TLS_CA_PATH, tls_ca_path, 0, OPT_STRING,
{(void *)(NULL)},
{ { NULL, IMAP_ENUM_ZERO } } },
+ { IMAPOPT_TLS_CRL, tls_crl, 0, OPT_STRING,
+{(void *)(NULL)},
+{ { NULL, IMAP_ENUM_ZERO } } },
{ IMAPOPT_TLSCACHE_DB, tlscache_db, 0, OPT_STRINGLIST,
{(void*)(berkeley-nosync)},
{ { berkeley , IMAP_ENUM_ZERO },
--- lib/imapopts.h.orig 2009-12-21 06:17:55.0 -0700
+++ lib/imapopts.h 2010-05-27 07:14:52.0 -0600
@@ -219,6 +219,7 @@
IMAPOPT_TIMEOUT,
IMAPOPT_TLS_CA_FILE,
IMAPOPT_TLS_CA_PATH,
+ IMAPOPT_TLS_CRL,
IMAPOPT_TLSCACHE_DB,
IMAPOPT_TLS_CERT_FILE,
IMAPOPT_TLS_CIPHER_LIST,
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: imapd, TLS and CRLs
Can you submit this to the Cyrus Bugzilla, please. :wes On 27 May 2010, at 13:04, Stacy Millions wrote: I have been working on deploying an imap server using EXTERNAL+TLS authentication. Everything is working fine and then I discover that there is no support CRLs in imapd; from my point of view this is a Bad Thing(tm). I searched the mailing list and found a discussion of this in 2005/02 with the final word being (I'll paraphrase) sounds interesting, patches welcome. All right, the attached implements CRL checking via a 'tls_crl' option in imapd.conf. Just point it at a PEM encoded CRL file. The file can contain multiple CRLs if you have more than one CA you care about. What it doesn't do is: - implement crl_path - implement CRL checking in the TLS client code It also suffers from the fact that this code is ran at initialisation time. When the CRL expires you need to get a fresh CRL, you need to restart imapd; but this is the same behavior as Apache httpd and sendmail. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldap groups and ptloader
On 27 May 2010, at 06:38, Duncan Gibb wrote: Yes. It would be nice when someone has time to make the configuration of pts_ldap more similar to other things likely to be using the same data (eg pam/nss/samba as well as saslauthd). Comments on: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3221 are welcome! :wes Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
unsubscribe
Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Experiment to test TCP keepalive for pop3d proxies
Ever since I can remember, our Cyrus installation had a problem with
pop3d processes accumulating on the murder front end server. This
didn't happen with imapd processes or with pop3d on the back end. A
couple of weeks ago, I counted 423 pop3d processes on the front end
but only 37 on the back end. Some of them were months old. All had
an established TCP connection from a client. Here's a typical stack
trace:
# pstack 12708
12708: pop3d -s
feb1a5c5 read (0, 817faf0, b)
fec2dfaf sock_read () + 3f
POP3 timeouts were enabled on both front and back ends, but it seemed
not to work on the front end. We're still running cyrus-imapd-2.3.8.
It's possible that this problem is fixed in the current version,
cyrus-imapd-2.3.16.
In any case, I wanted to try enabling TCP keepalive to see if it had
any effect on the problem. This only required a few lines of code:
--- pop3d.c-nokeep Wed Apr 11 10:49:59 2007
+++ pop3d.c Mon May 17 18:17:22 2010
@@ -494,6 +494,12 @@
if (getsockname(0, (struct sockaddr *)popd_localaddr, salen) ==
0) {
popd_haveaddr = 1;
}
+ /* Set keepalive option */
+ {
+ int oval = 1;
+ (void)setsockopt(0, SOL_SOCKET, SO_KEEPALIVE, (const void *)oval,
+sizeof(oval));
+ }
}
/* other params should be filled in */
A complete installation would include a configuration setting to
enable or disable TCP keepalive, along with ways to set keepalive
values that exist in many operating systems. This was just a test,
but it was quite impressive. `pop3d' processes no longer accumulated
on the front end, but were similar in number to the ones on the back
end. The cause must have been clients that disappeared without
closing their TCP connections. The TCP keepalive mechanism now does
this for them, after about half an hour of idleness.
Does anyone know if this problem has been solved by a timeout in
later Cyrus versions? That's actually a better solution. It does
only seem to happen when pop3d runs on a murder front end, relaying
connections to a back end. If it hasn't been solved, I'll proceed
with the keepalive solution. Otherwise, I'll plan for an upgrade.
--
-Gary Mills--Unix Group--Computer and Network Services-
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Experiment to test TCP keepalive for pop3d proxies
Since you mention it...
I took a look at a random frontend, and found 27 or 33 pop processes
from two days ago. I used gdb to get stack traces from 3 samples,
all looked like this:
(gdb) where
#0 0x008007a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x008d6ff3 in __read_nocancel () from /lib/tls/libc.so.6
#2 0x0806cb77 in prot_fill (s=0x8ecc148) at prot.c:470
#3 0x0806d924 in prot_fgets (buf=0xbff48160 , size=2047, s=0x8ecc148)
at prot.c:1186
#4 0x0804f57e in backend_connect (ret_backend=0x0,
server=0x81045a0 some.server, prot=0x80fad20,
userid=0xbff49cb0 someuser, cb=0x0, auth_status=0xbff48a40)
at backend.c:477
#5 0x0804c8df in openinbox () at pop3d.c:1635
#6 0x0804d6d9 in cmdloop () at pop3d.c:1227
#7 0x0804e6ad in service_main (argc=2, argv=0x8e6e008, envp=0xbff4ebf8)
at pop3d.c:579
#8 0x08052374 in main (argc=4, argv=0xbff4ebe4, envp=0xbff4ebf8)
at service.c:540
#9 0x0082ee93 in __libc_start_main () from /lib/tls/libc.so.6
#10 0x0804ba81 in ?? ()
(gdb)
In other words, they were all waiting in backend_connect() for the
backend server. That's not what's going on in your case, tho.
Looking at the code in backend_connect(), it's pretty clear that no
timeout is set when retrieving the banner. That's a bug, and it
impacts *every* tool that uses backend_connect() to communicate
within the cluster. It may not be your problem, but it's definitely
*a* problem. A simple:
prot_settimeout( ret-in, 360 );
right after:
ret-in = prot_new(sock, 0);
would probably do the trick (totally untested, to be sure).
For your problem, pop3d calls:
prot_settimeout(popd_in, popd_timeout);
just below where you've inserted the KEEPALIVE. What do you have
poptimeout set to? I wouldn't be surprised by a bug in prot, BTW.
I'm pretty sure I've seen a case where select() is used to implement
the timeout but once there's *some* input, read() is called with
blocking (wrong!).
In any case, if you can get a traceback with gdb for some hung
pop3d's, I'm sure we can pinpoint the issue.
:wes
On 27 May 2010, at 17:52, Gary Mills wrote:
Ever since I can remember, our Cyrus installation had a problem with
pop3d processes accumulating on the murder front end server. This
didn't happen with imapd processes or with pop3d on the back end. A
couple of weeks ago, I counted 423 pop3d processes on the front end
but only 37 on the back end. Some of them were months old. All had
an established TCP connection from a client. Here's a typical stack
trace:
# pstack 12708
12708: pop3d -s
feb1a5c5 read (0, 817faf0, b)
fec2dfaf sock_read () + 3f
POP3 timeouts were enabled on both front and back ends, but it seemed
not to work on the front end. We're still running cyrus-imapd-2.3.8.
It's possible that this problem is fixed in the current version,
cyrus-imapd-2.3.16.
In any case, I wanted to try enabling TCP keepalive to see if it had
any effect on the problem. This only required a few lines of code:
--- pop3d.c-nokeep Wed Apr 11 10:49:59 2007
+++ pop3d.c Mon May 17 18:17:22 2010
@@ -494,6 +494,12 @@
if (getsockname(0, (struct sockaddr *)popd_localaddr,
salen) == 0) {
popd_haveaddr = 1;
}
+ /* Set keepalive option */
+ {
+ int oval = 1;
+ (void)setsockopt(0, SOL_SOCKET, SO_KEEPALIVE, (const
void *)oval,
+sizeof(oval));
+ }
}
/* other params should be filled in */
A complete installation would include a configuration setting to
enable or disable TCP keepalive, along with ways to set keepalive
values that exist in many operating systems. This was just a test,
but it was quite impressive. `pop3d' processes no longer accumulated
on the front end, but were similar in number to the ones on the back
end. The cause must have been clients that disappeared without
closing their TCP connections. The TCP keepalive mechanism now does
this for them, after about half an hour of idleness.
Does anyone know if this problem has been solved by a timeout in
later Cyrus versions? That's actually a better solution. It does
only seem to happen when pop3d runs on a murder front end, relaying
connections to a back end. If it hasn't been solved, I'll proceed
with the keepalive solution. Otherwise, I'll plan for an upgrade.
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
