On 09/09/10 10:21 +0800, Wouter van Marle wrote:
That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
for instance:
dn: uid=jsmith,dc=example,dc=com ... userPassword: {SASL}jsmith
In this case, the user will have no valid password defined in LDAP (or at least not in the userPassword attribute).
When attempting to perform a non-sasl bind, slapd will use saslauthd to authenticate, by taking the username (from the userPassword field), and the password that was submitted.
On Wed, 2010-09-08 at 21:34 -0500, Dan White wrote:
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
When I got it working I am considering to write some tutorial - maybe useful. I haven't been able to find anything like it on the internet. The above I have never seen; just once a suggestion to change the password to {KERBEROS}username but well that also didn't work :)
It's much harder to get working than I ever expected, really. And even more so I'm surprised that openldap doesn't support this "out of the box", or with some minor settings.
Anyway I have changed my userPassword field (using GQ) to {SASL}wouter@SQUIRREL It still doesn't work of course. Also not when I set it to {SASL}wouter
In syslog I found the following error related to my attempt to open the address book in evolution: Sep 9 12:15:32 acorn slapd[15925]: conn=14 op=43 SEARCH RESULT tag=101 err=0 nentries=59 text= Sep 9 12:15:39 acorn slapd[15925]: conn=135 fd=54 ACCEPT from IP=192.168.2.4:39863 (IP=0.0.0.0:389) Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 BIND dn="uid=wouter,ou=People,dc=squirrel" method=128 Sep 9 12:15:39 acorn slapd[15925]: SASL [conn=135] Failure: cannot connect to saslauthd server: Permission denied Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 RESULT tag=97 err=49 text=
So there is something in saslauthd that does not accept connections from slapd. Now the big question is why? As I have no idea where to start searching for this.
Wouter.
for instance:
dn: uid=jsmith,dc=example,dc=com ... userPassword: {SASL}jsmith
In this case, the user will have no valid password defined in LDAP (or at least not in the userPassword attribute).
When attempting to perform a non-sasl bind, slapd will use saslauthd to authenticate, by taking the username (from the userPassword field), and the password that was submitted.
On 09/09/10 12:17 +0800, Wouter van Marle wrote:
Anyway I have changed my userPassword field (using GQ) to {SASL}wouter@SQUIRREL It still doesn't work of course. Also not when I set it to {SASL}wouter
In syslog I found the following error related to my attempt to open the address book in evolution: Sep 9 12:15:32 acorn slapd[15925]: conn=14 op=43 SEARCH RESULT tag=101 err=0 nentries=59 text= Sep 9 12:15:39 acorn slapd[15925]: conn=135 fd=54 ACCEPT from IP=192.168.2.4:39863 (IP=0.0.0.0:389) Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 BIND dn="uid=wouter,ou=People,dc=squirrel" method=128 Sep 9 12:15:39 acorn slapd[15925]: SASL [conn=135] Failure: cannot connect to saslauthd server: Permission denied Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 RESULT tag=97 err=49 text=
So there is something in saslauthd that does not accept connections from slapd. Now the big question is why? As I have no idea where to start searching for this.
Wouter.
You're close.
On Debian/Ubuntu, do:
adduser openldap sasl
The issue is that the /var/run/saslauthd directory, where the saslauthd unix socket is located, is only accessible by group 'sasl' (and root).
On Wed, 2010-09-08 at 23:38 -0500, Dan White wrote:
On 09/09/10 12:17 +0800, Wouter van Marle wrote:
Anyway I have changed my userPassword field (using GQ) to {SASL}wouter@SQUIRREL It still doesn't work of course. Also not when I set it to {SASL}wouter
In syslog I found the following error related to my attempt to open the address book in evolution: Sep 9 12:15:32 acorn slapd[15925]: conn=14 op=43 SEARCH RESULT tag=101 err=0 nentries=59 text= Sep 9 12:15:39 acorn slapd[15925]: conn=135 fd=54 ACCEPT from IP=192.168.2.4:39863 (IP=0.0.0.0:389) Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 BIND dn="uid=wouter,ou=People,dc=squirrel" method=128 Sep 9 12:15:39 acorn slapd[15925]: SASL [conn=135] Failure: cannot connect to saslauthd server: Permission denied Sep 9 12:15:39 acorn slapd[15925]: conn=135 op=0 RESULT tag=97 err=49 text=
So there is something in saslauthd that does not accept connections from slapd. Now the big question is why? As I have no idea where to start searching for this.
Wouter.
You're close.
On Debian/Ubuntu, do:
adduser openldap sasl
# adduser openldap sasl Adding user `openldap' to group `sasl' ... Adding user openldap to group sasl Done.
The issue is that the /var/run/saslauthd directory, where the saslauthd unix socket is located, is only accessible by group 'sasl' (and root).
True: drwx--x--- 2 root sasl 4096 2010-09-09 10:14 saslauthd
Still the same permission denied error message in syslog!
Wouter.
Wouter van Marle wrote:
On Wed, 2010-09-08 at 21:34 -0500, Dan White wrote:
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
When I got it working I am considering to write some tutorial - maybe useful. I haven't been able to find anything like it on the internet. The above I have never seen; just once a suggestion to change the password to {KERBEROS}username but well that also didn't work :)
It's much harder to get working than I ever expected, really. And even more so I'm surprised that openldap doesn't support this "out of the box", or with some minor settings.
It is not supported out of the box because it's generally the wrong thing to do. It is intentionally undocumented, to discourage people from pursuing this misguided course. Use GSSAPI.
On Wed, 2010-09-08 at 23:40 -0700, Howard Chu wrote:
Wouter van Marle wrote:
On Wed, 2010-09-08 at 21:34 -0500, Dan White wrote:
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
When I got it working I am considering to write some tutorial - maybe useful. I haven't been able to find anything like it on the internet. The above I have never seen; just once a suggestion to change the password to {KERBEROS}username but well that also didn't work :)
It's much harder to get working than I ever expected, really. And even more so I'm surprised that openldap doesn't support this "out of the box", or with some minor settings.
It is not supported out of the box because it's generally the wrong thing to do. It is intentionally undocumented, to discourage people from pursuing this misguided course. Use GSSAPI.
GSSAPI works: $ ldapwhoami -h acorn.squirrel SASL/GSSAPI authentication started SASL username: wouter@SQUIRREL SASL SSF: 56 SASL data security layer installed. dn:uid=wouter,cn=gssapi,cn=auth
But for whatever reason I have no option to choose GSSAPI as ldap authentication method in Evolution.
And actually now you start calling it "misguided course", I would really like to know what the proper course is.
My basic request is: - no passwords stored in the LDAP database. - LDAP authenticates users against a Kerberos server.
After a day of googling, searching for terms like the subject of this thread, I am not really closer to a solution. All solutions that I DID find were following variations of what I tried to do, and what you call misguided.
The thing that I talked about when I mentioned "support out of the box or with minor settings" was simply the Kerberos authentication. Why doesn't that work easily? Why can I not just tell openldap to use kerberos, be it via PAM, via GSSAPI directly, whatever - the method I don't care about - as long as it works. And the frustration now is that it still doesn't work.
Wouter.
Wouter van Marle wouter@squirrel-systems.com writes:
On Wed, 2010-09-08 at 23:40 -0700, Howard Chu wrote:
Wouter van Marle wrote:
On Wed, 2010-09-08 at 21:34 -0500, Dan White wrote:
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
When I got it working I am considering to write some tutorial - maybe useful. I haven't been able to find anything like it on the internet. The above I have never seen; just once a suggestion to change the password to {KERBEROS}username but well that also didn't work :)
It's much harder to get working than I ever expected, really. And even more so I'm surprised that openldap doesn't support this "out of the box", or with some minor settings.
It is not supported out of the box because it's generally the wrong thing to do. It is intentionally undocumented, to discourage people from pursuing this misguided course. Use GSSAPI.
GSSAPI works: $ ldapwhoami -h acorn.squirrel SASL/GSSAPI authentication started SASL username: wouter@SQUIRREL SASL SSF: 56 SASL data security layer installed. dn:uid=wouter,cn=gssapi,cn=auth
You may add an olcAuthzRegexp in order to map the sasl authentication string to a Distinguished Name.
But for whatever reason I have no option to choose GSSAPI as ldap authentication method in Evolution.
I don't know either, but my evolution shows the GSSAPI mechanism. In fact it shows all on my system available sasl mechanisms.
And actually now you start calling it "misguided course", I would really like to know what the proper course is.
My basic request is:
- no passwords stored in the LDAP database.
- LDAP authenticates users against a Kerberos server.
What do you mean by LDAP authenticates users against Kerberos? Authentication is the job of KDC, or do you want to run the Kerberos Database in LDAP?
After a day of googling, searching for terms like the subject of this thread, I am not really closer to a solution. All solutions that I DID find were following variations of what I tried to do, and what you call misguided.
As I mentioned already in a previous mail, it is quite simple to set up a kerberized system, just read the installation and administration documents of MIT krb5 and configure network based clients to use GSSAPI.
The thing that I talked about when I mentioned "support out of the box or with minor settings" was simply the Kerberos authentication. Why doesn't that work easily? Why can I not just tell openldap to use kerberos, be it via PAM, via GSSAPI directly, whatever - the method I don't care about - as long as it works. And the frustration now is that it still doesn't work.
I think you should get acquainted with principal authentication and authorization models, a LDAP server is just a dumb identity storage system and not a authentication and authorization broker as you seem to expect.
-Dieter
Dieter Kluenter wrote:
Wouter van Marlewouter@squirrel-systems.com writes:
On Wed, 2010-09-08 at 23:40 -0700, Howard Chu wrote:
Wouter van Marle wrote:
On Wed, 2010-09-08 at 21:34 -0500, Dan White wrote:
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
> That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
When I got it working I am considering to write some tutorial - maybe useful. I haven't been able to find anything like it on the internet. The above I have never seen; just once a suggestion to change the password to {KERBEROS}username but well that also didn't work :)
It's much harder to get working than I ever expected, really. And even more so I'm surprised that openldap doesn't support this "out of the box", or with some minor settings.
It is not supported out of the box because it's generally the wrong thing to do. It is intentionally undocumented, to discourage people from pursuing this misguided course. Use GSSAPI.
GSSAPI works: $ ldapwhoami -h acorn.squirrel SASL/GSSAPI authentication started SASL username: wouter@SQUIRREL SASL SSF: 56 SASL data security layer installed. dn:uid=wouter,cn=gssapi,cn=auth
You may add an olcAuthzRegexp in order to map the sasl authentication string to a Distinguished Name.
But for whatever reason I have no option to choose GSSAPI as ldap authentication method in Evolution.
Then your problem is with evolution, not OpenLDAP. Indeed, looking at the latest evolution source code, I see that they don't actually support SASL/GSSAPI in their LDAP module, and there's been an outstanding bug for this since at least 2006.
And actually now you start calling it "misguided course", I would really like to know what the proper course is.
As I already said, the proper course is to use SASL/GSSAPI.
My basic request is:
- no passwords stored in the LDAP database.
- LDAP authenticates users against a Kerberos server.
The thing that I talked about when I mentioned "support out of the box or with minor settings" was simply the Kerberos authentication. Why doesn't that work easily? Why can I not just tell openldap to use kerberos, be it via PAM, via GSSAPI directly, whatever - the method I don't care about - as long as it works. And the frustration now is that it still doesn't work.
OpenLDAP supports Kerberos perfectly, out of the box (via SASL/GSSAPI). Your problem is with evolution.
On Thu, 2010-09-09 at 10:43 +0200, Dieter Kluenter wrote:
Wouter van Marle wouter@squirrel-systems.com writes:
On Wed, 2010-09-08 at 23:40 -0700, Howard Chu wrote:
Wouter van Marle wrote:
On Wed, 2010-09-08 at 21:34 -0500, Dan White wrote:
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
> That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
When I got it working I am considering to write some tutorial - maybe useful. I haven't been able to find anything like it on the internet. The above I have never seen; just once a suggestion to change the password to {KERBEROS}username but well that also didn't work :)
It's much harder to get working than I ever expected, really. And even more so I'm surprised that openldap doesn't support this "out of the box", or with some minor settings.
It is not supported out of the box because it's generally the wrong thing to do. It is intentionally undocumented, to discourage people from pursuing this misguided course. Use GSSAPI.
GSSAPI works: $ ldapwhoami -h acorn.squirrel SASL/GSSAPI authentication started SASL username: wouter@SQUIRREL SASL SSF: 56 SASL data security layer installed. dn:uid=wouter,cn=gssapi,cn=auth
You may add an olcAuthzRegexp in order to map the sasl authentication string to a Distinguished Name.
Will look into that. I've seen bits and pieces about that before.
But for whatever reason I have no option to choose GSSAPI as ldap authentication method in Evolution.
I don't know either, but my evolution shows the GSSAPI mechanism. In fact it shows all on my system available sasl mechanisms.
Mail preferences yes: has some GSSAPI option. I haven't really tried that out.
Address book properties: no. Under the header Authentication I only have a login method (using dn or email or anonymous), and a field to enter the login name. I can not choose to use gssapi or whatever special method to authenticate to the ldap server.
And actually now you start calling it "misguided course", I would really like to know what the proper course is.
My basic request is:
- no passwords stored in the LDAP database.
- LDAP authenticates users against a Kerberos server.
What do you mean by LDAP authenticates users against Kerberos? Authentication is the job of KDC, or do you want to run the Kerberos Database in LDAP?
KDC authenticates, keeping its own database. That's cool, no need to stuff that in ldap again.
After a day of googling, searching for terms like the subject of this thread, I am not really closer to a solution. All solutions that I DID find were following variations of what I tried to do, and what you call misguided.
As I mentioned already in a previous mail, it is quite simple to set up a kerberized system, just read the installation and administration documents of MIT krb5 and configure network based clients to use GSSAPI.
The kerberised part is not the problem, that works fine. I'm using that to log in to my workstations, mail server, etc.
I think you should get acquainted with principal authentication and authorization models, a LDAP server is just a dumb identity storage system and not a authentication and authorization broker as you seem to expect.
Kerberos is the authentication system, it's specialised in that. At least that's what I learned about it. I have set it up in order to have a single sign-on, a single password for all services running on my network, makes it much easier for me to administer.
LDAP is a specialised database system storing typically personal information, I also use it for aliases database, userID, groupID, and other system info. This part works great as well.
Now all I want is for openldap to use kerberos as its authentication broker. Nothing more, nothing less. LDAP is now authenticating its users by itself which seems to be the default behaviour, and that's what I want to get rid of. As you say yourself LDAP is not an authentication broker, but why can it not easily be configured to use an external authentication broker, such as pam, which is designed to be just that?
Wouter.
-Dieter
On 09/09/10 12:47 +0800, Wouter van Marle wrote:
Adding user `openldap' to group `sasl' ... Adding user openldap to group sasl Done.
(Did you restart slapd?)
The issue is that the /var/run/saslauthd directory, where the saslauthd unix socket is located, is only accessible by group 'sasl' (and root).
True: drwx--x--- 2 root sasl 4096 2010-09-09 10:14 saslauthd
Still the same permission denied error message in syslog!
If I recall correctly, you mentioned running Postfix previously. Is it running chrooted? Have you customized the location of your saslauthd mux?
If so, you'll need to add:
saslauthd_path: /path/to/saslauthd
What's the output of /etc/default/saslauthd (minus the comments)?
Also, assuming IMAP is running on the same system, what's the output of:
grep sasl /etc/imapd.conf | sed 's/^sasl_//'
Is that substantially different from /usr/lib/sasl2/slapd.conf?
To trouble shoot, find out where saslauthd is listening:
# netstat -an | grep saslauthd unix 2 [ ACC ] STREAM LISTENING 9712 /var/run/saslauthd/mux
Set your saslauthd_path appropriately:
saslauthd_path: /var/run/saslauthd (minus the /mux)
and correct any permissions problems to that directory. The mux itself should have 777 permissions:
srwxrwxrwx 1 root root 0 2010-08-23 22:37 /var/run/saslauthd/mux
On 9 Sep 10, at 21:47, Dan White wrote:
On 09/09/10 12:47 +0800, Wouter van Marle wrote:
Adding user `openldap' to group `sasl' ... Adding user openldap to group sasl Done.
(Did you restart slapd?)
I don't remember... restarted it many times in the process :) I'm not used to need to restart apps in this situation.
The issue is that the /var/run/saslauthd directory, where the saslauthd unix socket is located, is only accessible by group 'sasl' (and root).
True: drwx--x--- 2 root sasl 4096 2010-09-09 10:14 saslauthd
Still the same permission denied error message in syslog!
If I recall correctly, you mentioned running Postfix previously. Is it running chrooted? Have you customized the location of your saslauthd mux?
Not chrooted; saslauthd mux is in the default location with proper 777 permissions.
If so, you'll need to add:
saslauthd_path: /path/to/saslauthd
What's the output of /etc/default/saslauthd (minus the comments)?
START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="pam" MECH_OPTIONS="" THREADS=5 OPTIONS="-c -m /var/run/saslauthd"
Also, assuming IMAP is running on the same system, what's the output of:
grep sasl /etc/imapd.conf | sed 's/^sasl_//'
pwcheck_method: saslauthd pam auto_transition: no (after removing lots of comments with sasl in it)
Is that substantially different from /usr/lib/sasl2/slapd.conf?
pwcheck_method: saslauthd mech_list: plain login gssapi external keytab: /etc/ldap/ldap.keytab
Most important difference is that pam is not mentioned here. But then from other mails I understand that slapd only wants to use saslauthd and not pam.
To trouble shoot, find out where saslauthd is listening:
# netstat -an | grep saslauthd unix 2 [ ACC ] STREAM LISTENING 9712 /var/run/saslauthd/mux
# netstat -an | grep saslauthd unix 2 [ ACC ] STREAM LISTENING 85098910 /var/run/saslauthd/mux
Cyrus uses saslauthd at least; that is working well. And saslauthd again talks to Kerberos.
For some reason it's still not possible for me to have slapd talk to pam or saslauthd for authentication. And for some other reason the authors insist the only way to use kerberos authentication for slapd is gssapi.
OK well just been playing a bit with ldapsearch: it now takes sasl/gssapi by itself and I don't have to enter a password to get results out of the ldap database. So something has improved all in all: $ ldapsearch -b 'ou=foobar,ou=addressbook,dc=squirrel' SASL/GSSAPI authentication started SASL username: wouter@SQUIRREL SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <ou=foobar,ou=addressbook,dc=squirrel> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 6 result: 32 No such object matchedDN: ou=addressbook,dc=squirrel
# numResponses: 1 ---------------------------------
Tls doesn't work, haven't bothered with that one too much yet. And I still have a {CRYPT} password set for myself in the LDAP data base. Interestingly according to klist I don't have a ticket, kinit doesn't give me a ticket, still it works. Maybe because it's all the same computer. I have just one machine for server.
Wouter.
Set your saslauthd_path appropriately:
saslauthd_path: /var/run/saslauthd (minus the /mux)
and correct any permissions problems to that directory. The mux itself should have 777 permissions:
srwxrwxrwx 1 root root 0 2010-08-23 22:37 /var/run/saslauthd/mux
-- Dan White
--On Thursday, September 09, 2010 5:13 PM +0800 Wouter van Marle wouter@squirrel-systems.com wrote:
Kerberos is the authentication system, it's specialised in that. At least that's what I learned about it. I have set it up in order to have a single sign-on, a single password for all services running on my network, makes it much easier for me to administer.
LDAP is a specialised database system storing typically personal information, I also use it for aliases database, userID, groupID, and other system info. This part works great as well.
Now all I want is for openldap to use kerberos as its authentication broker. Nothing more, nothing less. LDAP is now authenticating its users by itself which seems to be the default behaviour, and that's what I want to get rid of. As you say yourself LDAP is not an authentication broker, but why can it not easily be configured to use an external authentication broker, such as pam, which is designed to be just that?
You are directing your unhappiness at the wrong place, as Howard already noted. As someone who set up a large OpenLDAP directory service that only allows SASL/GSSAPI connections, the issue is not OpenLDAP. The problem is client software that, even though SASL has been a standard for many, many years, still fail to properly support it. This includes things like Evolution and Postfix. I used to maintain a patch for Postfix specifically that allowed it to do SASL/GSSAPI binds.
In sum, SASL is the RFC supported mechanism to use for doing these types of binds to LDAP. It has been the RFC supported method for a very, very long time. Unfortunately, people who write LDAP client software often skip implementing SASL support. This is not the fault of the OpenLDAP or any other directory project. If you have client software that doesn't support SASL that implements LDAP v3 support, then you need to contact the authors of that software or fix it yourself.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
You are directing your unhappiness at the wrong place, as Howard already noted. As someone who set up a large OpenLDAP directory service that only allows SASL/GSSAPI connections, the issue is not OpenLDAP. The problem is client software that, even though SASL has been a standard for many, many years, still fail to properly support it. This includes things like Evolution and Postfix. I used to maintain a patch for Postfix specifically that allowed it to do SASL/GSSAPI binds.
In sum, SASL is the RFC supported mechanism to use for doing these types of binds to LDAP. It has been the RFC supported method for a very, very long time. Unfortunately, people who write LDAP client software often skip implementing SASL support. This is not the fault of the OpenLDAP or any other directory project. If you have client software that doesn't support SASL that implements LDAP v3 support, then you need to contact the authors of that software or fix it yourself.
Quanah, I know that in the past you, Howard and others have contributed pieces of software to other LDAP-enabled software to enable SASL auth.
I had myself some bad experience in contributing things to software maintainers that did not even understand the need or the importance of what I was trying to contribute, but that's another story.
Maybe we could try, as the OpenLDAP project rather than as individuals, to promote and support better LDAP (not just OpenLDAP) integration in other generally useful FLOSS that can interact with OpenLDAP.
p.
At this point, your issues are most likely due to your sasl configuration, or other directory permissions problems. I don't feel that your saslauthd permissions problem is openldap related. In this case, openldap is just depending on libsasl to perform the authentication, and slapd is doing it's job (which is apparent from the saslauthd permissions problem in your logs).
(more below)
On 09/09/10 22:59 +0800, Wouter van Marle wrote:
What's the output of /etc/default/saslauthd (minus the comments)?
START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="pam" MECH_OPTIONS="" THREADS=5 OPTIONS="-c -m /var/run/saslauthd"
Also, assuming IMAP is running on the same system, what's the output of:
grep sasl /etc/imapd.conf | sed 's/^sasl_//'
pwcheck_method: saslauthd pam auto_transition: no (after removing lots of comments with sasl in it)
pam is not valid. libsasl has no direct communication with pam, so that's a dead config item (and it'll just use saslauthd in this instance).
The correct order is to have libsasl communicate with saslauthd over its mux, and in turn saslauthd communicates with pam, which is how you have it configured.
You probably want to have a:
sasl_mech_list: plain login gssapi external
line in /etc/imapd.conf, because clients will most likely choose the mechanism with greatest security bits, which would be digest-md5 (even if gssapi is offered), and digest-md5 will fail with your existing configuration.
Is that substantially different from /usr/lib/sasl2/slapd.conf?
pwcheck_method: saslauthd mech_list: plain login gssapi external keytab: /etc/ldap/ldap.keytab
Most important difference is that pam is not mentioned here. But then from other mails I understand that slapd only wants to use saslauthd and not pam.
Right. That's because, in this particularly instance, openldap is depending on the libsasl -> saslauthd -> pam path to authentication, which is a reasonable approach in your scenario.
To trouble shoot, find out where saslauthd is listening:
# netstat -an | grep saslauthd unix 2 [ ACC ] STREAM LISTENING 9712 /var/run/saslauthd/mux
# netstat -an | grep saslauthd unix 2 [ ACC ] STREAM LISTENING 85098910 /var/run/saslauthd/mux
Cyrus uses saslauthd at least; that is working well. And saslauthd again talks to Kerberos.
I'm still not convinced you've resolved any directory permissions problems. The reason I suggested that you restart slapd is so that it would pick up the new group membership (for sasl).
You could shotgun it in this case, but temporarily giving very permissiable permissions to your directory structure leading to the mux, or you could try to give the openldap user a shell and run testsaslauthd as that user. If you're not authenticating that way (but testsaslauthd works as root), then you've just got a permissions problem to fix.
Wouter van Marle wouter@squirrel-systems.com writes:
On 9 Sep 10, at 21:47, Dan White wrote:
On 09/09/10 12:47 +0800, Wouter van Marle wrote:
[...]
Most important difference is that pam is not mentioned here. But then from other mails I understand that slapd only wants to use saslauthd and not pam.
[...]
No, slapd doesn't want saslauthd, nor pam, it is just a hack. Please do not use saslauthd authentication agent in a kerberized environment. Make use of proper nativ sasl mechanism.
-Dieter
On 09/09/10 19:41 +0200, Dieter Kluenter wrote:
Wouter van Marle wouter@squirrel-systems.com writes:
On 9 Sep 10, at 21:47, Dan White wrote:
On 09/09/10 12:47 +0800, Wouter van Marle wrote:
[...]
Most important difference is that pam is not mentioned here. But then from other mails I understand that slapd only wants to use saslauthd and not pam.
[...]
No, slapd doesn't want saslauthd, nor pam, it is just a hack. Please do not use saslauthd authentication agent in a kerberized environment. Make use of proper nativ sasl mechanism.
Why has it been said that this is unsupported or a hack. Pass-through authentication is clearly documented in the Administrator's Guide (Section 14.5). Is it not supported?
The fact that GSSAPI/Kerberos5 is involved in not really relevant. Even though he has successfully performed a GSSAPI bind to the server, that doesn't have anything to do with the fact that he's wanting to perform pass-through authentication to libsasl.
If the response is "Your slapd server is configured properly for pass-through authentication. You're on the wrong list, go away", that's perfectly understandable. There's no reason I've seen that this should not work.
People will find solutions to solve their problems, even if said solution is not ideal. Just because it's not your ideal does not suggest it's a horrible ugly hack. Finding a solution for Evolution that does not involve a patch against X client systems is going to be a far smaller hack.
masarati@aero.polimi.it wrote:
You are directing your unhappiness at the wrong place, as Howard already noted. As someone who set up a large OpenLDAP directory service that only allows SASL/GSSAPI connections, the issue is not OpenLDAP. The problem is client software that, even though SASL has been a standard for many, many years, still fail to properly support it. This includes things like Evolution and Postfix. I used to maintain a patch for Postfix specifically that allowed it to do SASL/GSSAPI binds.
In sum, SASL is the RFC supported mechanism to use for doing these types of binds to LDAP. It has been the RFC supported method for a very, very long time. Unfortunately, people who write LDAP client software often skip implementing SASL support. This is not the fault of the OpenLDAP or any other directory project. If you have client software that doesn't support SASL that implements LDAP v3 support, then you need to contact the authors of that software or fix it yourself.
Quanah, I know that in the past you, Howard and others have contributed pieces of software to other LDAP-enabled software to enable SASL auth.
I had myself some bad experience in contributing things to software maintainers that did not even understand the need or the importance of what I was trying to contribute, but that's another story.
Maybe we could try, as the OpenLDAP project rather than as individuals, to promote and support better LDAP (not just OpenLDAP) integration in other generally useful FLOSS that can interact with OpenLDAP.
I'm ok with spending time on this, but I don't use evolution and have no direct need to get it working. How do we decide which "generally useful FLOSS" should get our attention?
Quanah, I know that in the past you, Howard and others have contributed pieces of software to other LDAP-enabled software to enable SASL auth.
I had myself some bad experience in contributing things to software maintainers that did not even understand the need or the importance of what I was trying to contribute, but that's another story.
Maybe we could try, as the OpenLDAP project rather than as individuals, to promote and support better LDAP (not just OpenLDAP) integration in other generally useful FLOSS that can interact with OpenLDAP.
I'm ok with spending time on this, but I don't use evolution and have no direct need to get it working. How do we decide which "generally useful FLOSS" should get our attention?
Well, the users of LDAP-capable FLOSS should :). My point is that developers of some LDAP-capable software, possibly pushed by requests from their users, should ask for support in better LDAP-enabling their software. This is not because LDAP-enabling software requires software sorcerers; only, with the support of the OL project it would probably require much less effort, and possibly lead to much better results. Think for example how long it took you to write ldapdb for SASL.
Of course this is not going to happen out of the blue; we'd probably need to advertise our availability, and give minimal commitment (in this, of course, everybody would commit only for himself). For example, users could "audit" the LDAP-friendliness of other software, and identify room for improvement.
p.
Dear list,
First of all thank you for all the comments on this problem.
It seems currently the ldap implementation of evolution is blamed, which is something I can not agree with.
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
So from my pov, the combination evo/openldap is working, and they are communicating well. So in that respect evo is not the problem here, as it supports at least one protocol to communicate authentication credits to openldap.
Now basically the problem is that ldap is using the wrong authentication type. Wrong as in not the one that I want it to use. It is using it's own, internal authentication - this I want to change to an external system. It seems I need something like you guys call 'pass-through authentication'. And what I learnt over the last year or so when I looked more into this and related matter, Linux provides sasl and pam as general authentication libs, designed exactly for this purpose. Sasl and pam even can talk to each other.
It seems openldap supports sasl for this purpose, great. Today I don't have time but over the weekend or next week I'm simply going to dig into it again and see what happens. I have the idea I'm close to getting it to work, just some small bits and pieces.
And then the next step is going to be tls, which for some reason also refuses to work for me :(
Wouter.
On Thu, 2010-09-09 at 19:41 +0200, Dieter Kluenter wrote:
Wouter van Marle wouter@squirrel-systems.com writes:
On 9 Sep 10, at 21:47, Dan White wrote:
On 09/09/10 12:47 +0800, Wouter van Marle wrote:
[...]
Most important difference is that pam is not mentioned here. But then from other mails I understand that slapd only wants to use saslauthd and not pam.
[...]
No, slapd doesn't want saslauthd, nor pam, it is just a hack. Please do not use saslauthd authentication agent in a kerberized environment. Make use of proper nativ sasl mechanism.
-Dieter
Wouter van Marle wouter@squirrel-systems.com writes:
It seems currently the ldap implementation of evolution is blamed, which is something I can not agree with.
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
That's what people are trying to tell you.
Now, there are various other ways of using Kerberos as a password verification service, which is what you apparently want to do because that's what Evolution requires. That's fine, if that's what you want to do. But that doesn't mean that Evolution is working properly. It's not. It isn't supporting Kerberos properly for LDAP lookups, and that's a bug in Evolution. And anyone who understands Kerberos is going to tell you the same thing.
Entering your password into applications and, particularly, having those applications send your Kerberos password over the network as Evolution is doing is DEFEATING THE WHOLE POINT of Kerberos.
Now basically the problem is that ldap is using the wrong authentication type. Wrong as in not the one that I want it to use. It is using it's own, internal authentication - this I want to change to an external system. It seems I need something like you guys call 'pass-through authentication'. And what I learnt over the last year or so when I looked more into this and related matter, Linux provides sasl and pam as general authentication libs, designed exactly for this purpose. Sasl and pam even can talk to each other.
No. This is not correct.
SASL is what you do when you implement Kerberos properly. Evolution is not doing this. It's either implementing a broken version of SASL where it only implements a single mechanism (PLAIN), or it's actually not doing SASL at all (most likely). The problem is exactly that Evolution is not properly implementing Kerberos SASL mechanisms.
PAM is indeed a way to verify passwords, but it has nothing to do with SASL except in the very limited special case that there is one SASL mechanism that communicates a password to the server, and once the password is on the server, you might want to use PAM to check it. PAM is not a network protocol; PAM is a way of plugging together password verification systems on a local system and was really designed for either console login or remote authentication that requires a password (such as ssh without any Kerberos support). If you have Kerbeors and yet you're resorting to using it with network services like LDAP, that means your client software (in this case Evolution) is crappy and broken.
Sadly, lots of client software is crappy and broken, so this is not an uncommon thing to have to do, but that doesn't make Evolution any less broken.
On 09/09/10 20:05 -0700, Russ Allbery wrote:
Wouter van Marle wouter@squirrel-systems.com writes:
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do.
Performing simple binds have precisely the same negative security footprint regardless of where his passwords may be stored. I'm assuming Evolution supports ldaps or STARTTLS, which would go a long way in mitigating that risk. If it didn't support TLS, I'd think that'd be a much more urgent focus (GSSAPI only provides 56 bits of encryption).
Now basically the problem is that ldap is using the wrong authentication type. Wrong as in not the one that I want it to use. It is using it's own, internal authentication - this I want to change to an external system. It seems I need something like you guys call 'pass-through authentication'. And what I learnt over the last year or so when I looked more into this and related matter, Linux provides sasl and pam as general authentication libs, designed exactly for this purpose. Sasl and pam even can talk to each other.
At this point, I'd agree with the above.
No. This is not correct.
SASL is what you do when you implement Kerberos properly. Evolution is not doing this. It's either implementing a broken version of SASL where it only implements a single mechanism (PLAIN), or it's actually not doing SASL at all (most likely). The problem is exactly that Evolution is not properly implementing Kerberos SASL mechanisms.
Would you agree that any application which does not support the full range of SASL mechanisms is broken? What about simple binds? Would you suggest that OpenLDAP remove all support for simple binds? If not, why not?
PAM is indeed a way to verify passwords, but it has nothing to do with SASL except in the very limited special case that there is one SASL mechanism that communicates a password to the server, and once the password is on the server, you might want to use PAM to check it. PAM is not a network protocol; PAM is a way of plugging together password verification systems on a local system and was really designed for either console login or remote authentication that requires a password (such as ssh without any Kerberos support). If you have Kerbeors and yet you're resorting to using it with network services like LDAP, that means your client software (in this case Evolution) is crappy and broken.
Most protocols have support for legacy (pre-SASL) authentication. IMAP has login, POP has user/pass, LDAP has simple binds. (SMTP being one exception to this).
In an ideal world we could just do away with all software that only has support for legacy authentication, but that'd break a good chunk of the ISP services I help to maintain. I'm not really a big fan of that.
Sadly, lots of client software is crappy and broken, so this is not an uncommon thing to have to do, but that doesn't make Evolution any less broken.
Dan White dwhite@olp.net writes:
On 09/09/10 20:05 -0700, Russ Allbery wrote:
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do.
Oh, probably not. Because we'd all assume that he didn't have Kerberos or didn't want to use it. What gets me is going to all the work to set up Kerberos and then not getting the benefit of it.
I know it's common, and it's hard to avoid, but it bugs me.
But I only jumped in because there was a lot of confusion over just how Kerberos authentication works. Sending a password to the server which then checks it against the Kerberos KDC is *not* Kerberos authentication. That's not the Kerberos protocol. If that's what you want to do, then OpenLDAP does indeed support it, and sometimes that's what you have to do, but you should know that it's not Kerberos and you're losing the security benefit from Kerberos by doing that.
SASL is what you do when you implement Kerberos properly. Evolution is not doing this. It's either implementing a broken version of SASL where it only implements a single mechanism (PLAIN), or it's actually not doing SASL at all (most likely). The problem is exactly that Evolution is not properly implementing Kerberos SASL mechanisms.
Would you agree that any application which does not support the full range of SASL mechanisms is broken?
When the same application already supports the full range of SASL mechanisms for IMAP? When the application is on a platform (Linux) with client libraries generally already available for doing LDAP queries with proper full SASL support? Yes, absolutely, without question.
What about simple binds? Would you suggest that OpenLDAP remove all support for simple binds? If not, why not?
We disable simple binds (apart from anonymous; I don't recall if that's considered simple or not) on our LDAP servers. I don't think removing all support for them is a good idea because backward compatibility with broken software is frequently required in the real world. But that doesn't make the software not broken.
On Thu, 2010-09-09 at 23:02 -0500, Dan White wrote:
On 09/09/10 20:05 -0700, Russ Allbery wrote:
Wouter van Marle wouter@squirrel-systems.com writes:
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do.
Which is indeed what I have now slowly found out. I'm not an expert in openldap or security; in the end I just want it to work. And unfortunately evolution doesn't support all possible protocols; which is of course why other applications try to support as many as possible, to at least and up with one match. Now Evolution can talk to openldap, and can authenticate, which is why I can't call it "broken". Maybe it could be done better, maybe there are newer protocols. But it's not broken in the sense of "doesn't work".
On top of that as long as it's on my own LAN, not out over the Internet, I'm not worried about using plain passwords over unencrypted connections. If an attacker manages to start sniffing passwords off of my LAN (which is physically inside my office; all wired) then I have worse security issues to worry about.
Performing simple binds have precisely the same negative security footprint regardless of where his passwords may be stored. I'm assuming Evolution supports ldaps or STARTTLS,
Evolution does support encryption using TLS and SSH connections (that is how it's called in the settings). And if I understand everything well then plain authentication using one of those protocols is still pretty secure.
Wouter.
which would go a long way in mitigating that risk. If it didn't support TLS, I'd think that'd be a much more urgent focus (GSSAPI only provides 56 bits of encryption).
Now basically the problem is that ldap is using the wrong authentication type. Wrong as in not the one that I want it to use. It is using it's own, internal authentication - this I want to change to an external system. It seems I need something like you guys call 'pass-through authentication'. And what I learnt over the last year or so when I looked more into this and related matter, Linux provides sasl and pam as general authentication libs, designed exactly for this purpose. Sasl and pam even can talk to each other.
At this point, I'd agree with the above.
No. This is not correct.
SASL is what you do when you implement Kerberos properly. Evolution is not doing this. It's either implementing a broken version of SASL where it only implements a single mechanism (PLAIN), or it's actually not doing SASL at all (most likely). The problem is exactly that Evolution is not properly implementing Kerberos SASL mechanisms.
Would you agree that any application which does not support the full range of SASL mechanisms is broken? What about simple binds? Would you suggest that OpenLDAP remove all support for simple binds? If not, why not?
PAM is indeed a way to verify passwords, but it has nothing to do with SASL except in the very limited special case that there is one SASL mechanism that communicates a password to the server, and once the password is on the server, you might want to use PAM to check it. PAM is not a network protocol; PAM is a way of plugging together password verification systems on a local system and was really designed for either console login or remote authentication that requires a password (such as ssh without any Kerberos support). If you have Kerbeors and yet you're resorting to using it with network services like LDAP, that means your client software (in this case Evolution) is crappy and broken.
Most protocols have support for legacy (pre-SASL) authentication. IMAP has login, POP has user/pass, LDAP has simple binds. (SMTP being one exception to this).
In an ideal world we could just do away with all software that only has support for legacy authentication, but that'd break a good chunk of the ISP services I help to maintain. I'm not really a big fan of that.
Sadly, lots of client software is crappy and broken, so this is not an uncommon thing to have to do, but that doesn't make Evolution any less broken.
Dan White wrote:
On 09/09/10 20:05 -0700, Russ Allbery wrote:
Wouter van Marlewouter@squirrel-systems.com writes:
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do.
Performing simple binds have precisely the same negative security footprint regardless of where his passwords may be stored. I'm assuming Evolution
No, it makes a difference, and the fact that you're not aware of the difference demonstrates that you haven't thought it through enough to be qualified to render an opinion on it.
Kerberos is secure precisely because client passwords are never transmitted across the network. Period. When you break that guarantee, everything else about the Kerberos system is jeopardized, and typically, when Kerberos is in use at a site, there's a large ecosystem of apps dependent on it and all of their security goes down the drain at the same time.
supports ldaps or STARTTLS, which would go a long way in mitigating that risk. If it didn't support TLS, I'd think that'd be a much more urgent
ldaps or TLS might be ok, assuming you're not using a broken SSL implementation. Abusing Kerberos in the requested way and relying on other security systems to take up the slack is opening yourself up to a whole world of unintended consequences, and we need only look at Debian last year to see how real those problems may be.
focus (GSSAPI only provides 56 bits of encryption).
The strength of GSSAPI's encryption layer is irrelevant in this discussion since, when used properly, it NEVER exposes the client's secret key to anybody else.
SASL is what you do when you implement Kerberos properly. Evolution is not doing this. It's either implementing a broken version of SASL where it only implements a single mechanism (PLAIN), or it's actually not doing SASL at all (most likely). The problem is exactly that Evolution is not properly implementing Kerberos SASL mechanisms.
Would you agree that any application which does not support the full range of SASL mechanisms is broken? What about simple binds? Would you suggest that OpenLDAP remove all support for simple binds? If not, why not?
RFC4513 pretty much deprecates Simple Binds. Certainly it discourages using them on an unprotected session, and the OP has already stated that he has yet to get TLS working. And applications don't have to implement specific SASL mechanisms, that's all hidden inside libldap and libsasl2. All they have to do is use the right libldap calls and they automatically get support for all mechanisms, currently known as well as future mechs.
--On Thursday, September 09, 2010 11:02 PM -0500 Dan White dwhite@olp.net wrote:
focus (GSSAPI only provides 56 bits of encryption).
Wrong. Cyrus-SASL is hard coded to report only 56 bits of encryption. The actual amount of encryption depends on the strength of your keys. Which may or may not be more secure than your SSL session.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Dan White dwhite@olp.net writes:
If it didn't support TLS, I'd think that'd be a much more urgent focus (GSSAPI only provides 56 bits of encryption).
Incidentally, where are you getting this? If you use Kerberos with GSSAPI and AES keys, you get 128-bit encryption so far as I can see. RFC 4121 defers to the Kerberos crypto specification for the encryption, and RFC 3962 definitely doesn't artificially limit the encryption strength of AES to 56 bits.
SASL reports a security factor of 56, but I believe that's just because there's no good way at present of getting the actual security factor bubbled up to the SASL layer so that it can report it properly to the application. I don't believe that's an accurate reflection of the on-wire encryption.
On 09/09/10 21:25 -0700, Howard Chu wrote:
Dan White wrote:
On 09/09/10 20:05 -0700, Russ Allbery wrote:
Wouter van Marlewouter@squirrel-systems.com writes:
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do.
Performing simple binds have precisely the same negative security footprint regardless of where his passwords may be stored. I'm assuming Evolution
No, it makes a difference, and the fact that you're not aware of the difference demonstrates that you haven't thought it through enough to be qualified to render an opinion on it.
Do you really believe that's true?
My point is that in this scenario, slapd is ignorant of, and should be ignorant of, that fact that kerberos is involved. The fact that pass-through authentication is documented means that users are free to use slapd in this manner, and if a user chooses to use simple binds, there is no security difference with regards to which PAM module is ultimately used.
Users don't really care to be preached to. If something is supported, it's supported.
On 09/09/10 21:35 -0700, Quanah Gibson-Mount wrote:
--On Thursday, September 09, 2010 11:02 PM -0500 Dan White dwhite@olp.net wrote:
focus (GSSAPI only provides 56 bits of encryption).
Wrong. Cyrus-SASL is hard coded to report only 56 bits of encryption. The actual amount of encryption depends on the strength of your keys. Which may or may not be more secure than your SSL session.
Then I stand corrected. Howard's right though. It's not really relevant to the authentication portion of the bind.
Dan White wrote:
On 09/09/10 21:25 -0700, Howard Chu wrote:
Dan White wrote:
On 09/09/10 20:05 -0700, Russ Allbery wrote:
Wouter van Marlewouter@squirrel-systems.com writes:
At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information.
If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period.
So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do.
Performing simple binds have precisely the same negative security footprint regardless of where his passwords may be stored. I'm assuming Evolution
No, it makes a difference, and the fact that you're not aware of the difference demonstrates that you haven't thought it through enough to be qualified to render an opinion on it.
Do you really believe that's true?
My point is that in this scenario, slapd is ignorant of, and should be ignorant of, that fact that kerberos is involved. The fact that pass-through authentication is documented means that users are free to use slapd in this manner, and if a user chooses to use simple binds, there is no security difference with regards to which PAM module is ultimately used.
Or it could just be a doc bug. {KERBEROS} is in the docs too, but the code for that was deleted long ago (2004), since it was a security vulnerability.
Users don't really care to be preached to. If something is supported, it's supported.
If users don't like it that's tough. In this business "the customer is always wrong." If you (generic you) knew more about this than us you wouldn't be here asking questions. Certainly you're in no position to proclaim "I believe it ought to do X" when you lack any understanding of the issues. We discourage particular usage for solid reasons. If you're not going to listen and learn, that's your problem. If you want to go shoot yourself in the foot that's entirely your business too, just don't come back here blaming us when someone drives a tank through your compromised security.
Howard Chu hyc@symas.com writes:
masarati@aero.polimi.it wrote:
[...]
Quanah, I know that in the past you, Howard and others have contributed pieces of software to other LDAP-enabled software to enable SASL auth.
I had myself some bad experience in contributing things to software maintainers that did not even understand the need or the importance of what I was trying to contribute, but that's another story.
Maybe we could try, as the OpenLDAP project rather than as individuals, to promote and support better LDAP (not just OpenLDAP) integration in other generally useful FLOSS that can interact with OpenLDAP.
I'm ok with spending time on this, but I don't use evolution and have no direct need to get it working. How do we decide which "generally useful FLOSS" should get our attention?
I have a large list :-) just a few examples:
- postfix, enable compare - (X)Emacs, ldapv3 - php-ldap, controls, strong binds - Net::LDAPapi, documentation
-Dieter
On 10/09/10 09:07 +0200, Dieter Kluenter wrote:
Howard Chu hyc@symas.com writes:
masarati@aero.polimi.it wrote:
[...]
Quanah, I know that in the past you, Howard and others have contributed pieces of software to other LDAP-enabled software to enable SASL auth.
I had myself some bad experience in contributing things to software maintainers that did not even understand the need or the importance of what I was trying to contribute, but that's another story.
Maybe we could try, as the OpenLDAP project rather than as individuals, to promote and support better LDAP (not just OpenLDAP) integration in other generally useful FLOSS that can interact with OpenLDAP.
I'm ok with spending time on this, but I don't use evolution and have no direct need to get it working. How do we decide which "generally useful FLOSS" should get our attention?
I have a large list :-) just a few examples:
- postfix, enable compare
- (X)Emacs, ldapv3
- php-ldap, controls, strong binds
- Net::LDAPapi, documentation
FreeRADIUS is a big one for me. No SASL support in its LDAP module.
An Apache authentication module would be nice too. I hacked something together and submitted a SASL enabled LDAP module a couple of years back to an Apache list, but didn't get any responses.
--On Friday, September 10, 2010 8:17 AM -0500 Dan White dwhite@olp.net wrote:
I have a large list :-) just a few examples:
- postfix, enable compare
- (X)Emacs, ldapv3
- php-ldap, controls, strong binds
- Net::LDAPapi, documentation
FreeRADIUS is a big one for me. No SASL support in its LDAP module.
An Apache authentication module would be nice too. I hacked something together and submitted a SASL enabled LDAP module a couple of years back to an Apache list, but didn't get any responses.
On a related note, the SASL patch for Postfix is being worked with by one of the Postfix developers, so I expect it will be incorporated into their code for some future minor release version.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Friday, 10 September 2010 08:07:52 Dieter Kluenter wrote:
Howard Chu hyc@symas.com writes:
masarati@aero.polimi.it wrote:
[...]
Quanah, I know that in the past you, Howard and others have contributed pieces of software to other LDAP-enabled software to enable SASL auth.
I had myself some bad experience in contributing things to software maintainers that did not even understand the need or the importance of what I was trying to contribute, but that's another story.
Maybe we could try, as the OpenLDAP project rather than as individuals, to promote and support better LDAP (not just OpenLDAP) integration in other generally useful FLOSS that can interact with OpenLDAP.
I'm ok with spending time on this, but I don't use evolution and have no direct need to get it working.
I note that KMail/Kaddressbook have SASL support in their LDAP backend. The Evolution people seem more focused on making Evolution "work with Exchange" than supporting standards ...
How do we decide which "generally useful FLOSS" should get our attention?
Well, the question is, what aspects should we consider. For people who need simple binds in some cases (e.g. access to systems from outside the "secure" network), ppolicy support is quite an issue, in:
-freeradius -apache -jabber2 -probably most IMAP servers
Of course, some issues between Heimdal/smbk5pwd/ppolicy also need to be resolved (hopefully once the new ppolicy draft is finalised and Heimdal and MIT support it).
I have a large list :-) just a few examples:
- postfix, enable compare
- (X)Emacs, ldapv3
- php-ldap, controls, strong binds
- Net::LDAPapi, documentation
Regards, Buchan
On Thursday, 9 September 2010 08:12:11 Wouter van Marle wrote:
On Wed, 2010-09-08 at 23:40 -0700, Howard Chu wrote:
Wouter van Marle wrote:
On Wed, 2010-09-08 at 21:34 -0500, Dan White wrote:
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you will need to replace the password (userPassword attribute) with:
userPassword: {SASL}username@realm
When I got it working I am considering to write some tutorial - maybe useful. I haven't been able to find anything like it on the internet. The above I have never seen; just once a suggestion to change the password to {KERBEROS}username but well that also didn't work :)
It's much harder to get working than I ever expected, really. And even more so I'm surprised that openldap doesn't support this "out of the box", or with some minor settings.
It is not supported out of the box because it's generally the wrong thing to do. It is intentionally undocumented, to discourage people from pursuing this misguided course. Use GSSAPI.
GSSAPI works: $ ldapwhoami -h acorn.squirrel SASL/GSSAPI authentication started SASL username: wouter@SQUIRREL SASL SSF: 56 SASL data security layer installed. dn:uid=wouter,cn=gssapi,cn=auth
But for whatever reason I have no option to choose GSSAPI as ldap authentication method in Evolution.
File bugs on Evolution. Kmail/Kaddressbook support GSSAPI ...
And actually now you start calling it "misguided course", I would really like to know what the proper course is.
Don't send passwords in the clear to authenticate via Kerberos when you already have the means to do so without ever sending the password ....
My basic request is:
- no passwords stored in the LDAP database.
- LDAP authenticates users against a Kerberos server.
Then every LDAP client needs to support SASL, unless you also want: -Reveal my passwords which are never revealed anywhere else, when I do a simple bind to LDAP, and use pass-through authentication
After a day of googling, searching for terms like the subject of this thread, I am not really closer to a solution. All solutions that I DID find were following variations of what I tried to do, and what you call misguided.
The thing that I talked about when I mentioned "support out of the box or with minor settings" was simply the Kerberos authentication. Why doesn't that work easily? Why can I not just tell openldap to use kerberos, be it via PAM,
Because Kerberos authentication can't be done via PAM (which only supports username/password). You *can* do PAM authentication against a KDC, but this should only be done for initial (e.g. physical login) authentication. PAM and Kerberos can both be done via SASL, which OpenLDAP supports (but, you haven't configured your SASL setup correctly).
via GSSAPI directly, whatever - the method I don't care about - as long as it works. And the frustration now is that it still doesn't work.
But, none of it is an OpenLDAP problem, your problems are with: -Evolution -SASL
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Dan White -
Dieter Kluenter -
Howard Chu -
masarati＠aero.polimi.it -
Quanah Gibson-Mount -
Russ Allbery -
Wouter van Marle