Re: Authenticate to ldap using Kerberos
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}usern...@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: wou...@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
Re: Authenticate to ldap using Kerberos
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}usern...@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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Authenticate to ldap using Kerberos
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}usern...@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: wou...@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.
Re: Authenticate to ldap using Kerberos
Wouter van Marle wou...@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}usern...@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: wou...@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 Klünter | Systemberatung
sip: 7770...@sipgate.de
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
Re: Authenticate to ldap using Kerberos
On Thu, 2010-09-09 at 10:43 +0200, Dieter Kluenter wrote:
Wouter van Marle wou...@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}usern...@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: wou...@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
Re: Authenticate to ldap using Kerberos
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 -- Dan White
Re: Authenticate to ldap using Kerberos
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: wou...@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
Re: Authenticate to ldap using Kerberos
--On Thursday, September 09, 2010 5:13 PM +0800 Wouter van Marle wou...@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
Re: Authenticate to ldap using Kerberos
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.
Re: Authenticate to ldap using Kerberos
On 09/09/10 19:41 +0200, Dieter Kluenter wrote: Wouter van Marle wou...@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. -- Dan White
Re: Authenticate to ldap using Kerberos
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.
Re: Authenticate to ldap using Kerberos
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 wou...@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
Re: Authenticate to ldap using Kerberos
Dan White dwh...@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. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: Authenticate to ldap using Kerberos
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 wou...@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.
Re: Authenticate to ldap using Kerberos
Dan White wrote: On 09/09/10 20:05 -0700, Russ Allbery wrote: Wouter van Marlewou...@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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Authenticate to ldap using Kerberos
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 Marlewou...@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. -- Dan White
Re: Authenticate to ldap using Kerberos
On 08/09/10 22:53 +0800, Wouter van Marle wrote:
Hi group,
I have been fighting the whole day already for something that I think
is quite simple but I just can't get it to work: have slapd
authenticate users against kerberos. Following many tutorials, trying
many things, I give up on that and ask for your help.
System: Debian Lenny.
Situation:
- workstation logins over the network authenticate against kerberos
- credentials from LDAP
- postfix has its alias database etc in LDAP, as are the groups and
userIDs and everything - helps keeping uids the same on the
workstations. Essential for NFS.
- anything using pam will be authenticated against kerberos,
including imap, postfix, etc.
Except LDAP. Then slapd authenticates by itself against the password
stored there. And that's not what I want. There should be no
passwords in LDAP any more, everything against kerberos. Then at
least when a user changes their kerberos password, the same password
is used everywhere. I just can't get this to work for some reason. I
have followed many tutorials, so many that I forgot what I did, and
it still doesn't work.
Slapd should use pam to authenticate, or directly talk to the
kerberos server, whatever.
saslauthd has the gssapi module installed.
I have created an ldap/acorn.squir...@squirrel key, and added this
keytab in /etc/defaults/slapd. acorn.squirrel is the fqdn of the
server, SQUIRREL is its kerberos realm.
To have slapd use saslauthd for authentication, you'll need to create the
file /usr/lib/sasl2/slapd.conf, with these contents:
pwcheck_method: saslauthd
mech_list: plain login
and optionally
keytab: /etc/krb5.keytab (which is the standard location)
*If* you intend to perform a PLAIN sasl bind, you'll need this in your
/etc/ldap/slapd.conf:
sasl-secprops none
If you're planning on supporting non-sasl binds, but still wish to
authenticate via saslauthd, your userPassword entries should look like:
userPassword: {sasl}usern...@realm
and you'll need to verify that your slapd was compiled with the
--enable-spasswd option. See section 4.5 (Pass-Through authentication)
of the OpenLDAP Administrators Guide.
You could authenticate against a kerberos5 installation with saslauthd a
couple of different ways:
1. Authenticate saslauthd against PAM. Edit /etc/default/saslauthd and
specify 'pam' as your authentication backend. You'll then need to configure
a kerberos pam module to do that actual work.
2. Authenticate saslauthd against kerberos5 ('kerberos5' in
/etc/default/saslauthd). I'm not sure if you need to have a valid ticket
granting ticket, or if a proper /etc/krb5.conf is all you need.
Current situation after all the hacking:
$ ldapwhoami -x -D 'uid=wouter,ou=people,dc=squirrel' -W -h
acorn.squirrel
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
when entering my Kerberos password; it accepts my credentials when I
enter the LDAP stored password (a different password).
That requires pass-through authentication.
Then I just did:
===
wou...@acorn:~$ ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific)
error (80)
wou...@acorn:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_5lYS4w
Default principal: wou...@squirrel
Valid starting ExpiresService principal
09/08/10 22:42:07 09/09/10 08:42:07 krbtgt/squir...@squirrel
renew until 09/09/10 22:42:07
09/08/10 22:46:39 09/09/10 08:42:07 ldap/acorn.squir...@squirrel
renew until 09/09/10 22:42:07
Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached
===
Do you have ldap/acorn.squir...@squirrel in /etc/krb5.keytab, on the
server? Is it readable by the slapd user?
--
Dan White
Re: Authenticate to ldap using Kerberos
On 08/09/10 12:15 -0500, Dan White wrote: To have slapd use saslauthd for authentication, you'll need to create the file /usr/lib/sasl2/slapd.conf, with these contents: pwcheck_method: saslauthd mech_list: plain login and optionally keytab: /etc/krb5.keytab (which is the standard location) Check that. That should be: pwcheck_method: saslauthd mech_list: plain login gssapi external keytab: /etc/krb5.keytab Do you have ldap/acorn.squir...@squirrel in /etc/krb5.keytab, on the server? Is it readable by the slapd user? Also see: http://www.cyrusimap.org/mediawiki/index.php/FAQ#Cyrus_SASL_Questions -- Dan White
Re: Authenticate to ldap using Kerberos
To have slapd use saslauthd for authentication, you'll need to create the
file /usr/lib/sasl2/slapd.conf, with these contents:
pwcheck_method: saslauthd
mech_list: plain login
and optionally
keytab: /etc/krb5.keytab (which is the standard location)
Check. As per a previous trial I created the keytab in a different
location;
# cat /usr/lib/sasl2/slapd.conf
pwcheck_method: saslauthd
mech_list: plain login gssapi external
keytab: /etc/ldap/ldap.keytab
# ls -l /usr/lib/sasl2/slapd.conf
-rw-r--r-- 1 root root 95 2010-09-09 10:03 /usr/lib/sasl2/slapd.conf
# ls -l /etc/ldap/ldap.keytab
-rw-r- 1 root openldap 286 2010-09-08 16:03 /etc/ldap/ldap.keytab
*If* you intend to perform a PLAIN sasl bind, you'll need this in your
/etc/ldap/slapd.conf:
sasl-secprops none
Check.
Had some probs with SSL before so start with plain. Later I'm just going
to close that port in the firewall, for internal use it's secure enough.
If you're planning on supporting non-sasl binds, but still wish to
authenticate via saslauthd, your userPassword entries should look like:
userPassword: {sasl}usern...@realm
and you'll need to verify that your slapd was compiled with the
--enable-spasswd option. See section 4.5 (Pass-Through authentication)
of the OpenLDAP Administrators Guide.
This one I have no idea what that would do. My understanding is
obviously not deep enough.
You could authenticate against a kerberos5 installation with saslauthd a
couple of different ways:
1. Authenticate saslauthd against PAM. Edit /etc/default/saslauthd and
specify 'pam' as your authentication backend. You'll then need to configure
a kerberos pam module to do that actual work.
In /etc/default/saslauthd:
MECHANISMS=pam
Already configured like that.
Other logins authenticate fine against pam using my kerberos password
(like Cyrus IMAP, and Postfix's smtp authentication), so this part is
working fine.
2. Authenticate saslauthd against kerberos5 ('kerberos5' in
/etc/default/saslauthd). I'm not sure if you need to have a valid ticket
granting ticket, or if a proper /etc/krb5.conf is all you need.
I prefer to stick to pam as in that case it can fall back to my local
passwd file, where I have defined a password for root, so in case the
krb server (or the network) fails at least I can log in!
Current situation after all the hacking:
$ ldapwhoami -x -D 'uid=wouter,ou=people,dc=squirrel' -W -h
acorn.squirrel
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
when entering my Kerberos password; it accepts my credentials when I
enter the LDAP stored password (a different password).
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.
Then I just did:
===
wou...@acorn:~$ ldapsearch -LLL -s base -b '' '(objectClass=*)' +
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific)
error (80)
wou...@acorn:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_5lYS4w
Default principal: wou...@squirrel
Valid starting ExpiresService principal
09/08/10 22:42:07 09/09/10 08:42:07 krbtgt/squir...@squirrel
renew until 09/09/10 22:42:07
09/08/10 22:46:39 09/09/10 08:42:07 ldap/acorn.squir...@squirrel
renew until 09/09/10 22:42:07
Kerberos 4 ticket cache: /tmp/tkt1000
klist: You have no tickets cached
===
Do you have ldap/acorn.squir...@squirrel in /etc/krb5.keytab, on the
server? Is it readable by the slapd user?
Re: Authenticate to ldap using Kerberos
Also see: http://www.cyrusimap.org/mediawiki/index.php/FAQ#Cyrus_SASL_Questions I followed those steps, finding out that the client didn't have the sasl gssapi module installed (apparently necessary?! I guessed the authentication is done by slapd on the server?). All other tests mentioned check out fine. However when I access my address book in Evolution it still only accepts my ldap stored password, not my kerberos password! What could possible be wrong? Wouter.
Re: Authenticate to ldap using Kerberos
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}usern...@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.
--
Dan White
Re: Authenticate to ldap using Kerberos
On 09/09/10 12:17 +0800, Wouter van Marle wrote:
Anyway I have changed my userPassword field (using GQ) to
{sasl}wou...@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).
--
Dan White
Re: Authenticate to ldap using Kerberos
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}wou...@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.
