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: I can't login in my system using OpenLDAP
Please find attached my libnss-ldap.conf and pam_ldap.conf Even now I can't connect on the system using user that I created. Please, may be I missing some settings. -- Yours truly, Eric KOM 110 LAWN STREET ROSETTENVILLE 2190 JOHANNESBURG SOUTH AFRICA Phone: +27 (0) 788 791 334 Fax: +27 (0) 865 563 009 E-mail: eric...@namekom.co.za Websites: www.erickom.co.za | www.namekom.co.za/erickom | www.namekom.co.za libnss-ldap.conf Description: Binary data pam_ldap.conf Description: Binary data
Re: I can't login in my system using OpenLDAP
Le 09/09/2010 09:11, Eric KOM a écrit : Please find attached my libnss-ldap.conf and pam_ldap.conf Even now I can't connect on the system using user that I created. Please, may be I missing some settings. Installing and setting up slapd as a server is one thing (a network available LDAP server). Being able to log in to a system using accounts from LDAP is another. To acheive this, I suggest you google one of many tutorials on PAM NSS LDAP. Hope this helps, Jonathan -- == Jonathan CLARKE -- Normation 44 rue Cauchy, 94110 Arcueil, France -- Telephone: +33 (0)1 83 62 26 96 -- Web:http://www.normation.com/ ==
Re: I can't login in my system using OpenLDAP
On 9-9-2010 9:34, Jonathan CLARKE wrote: Le 09/09/2010 09:11, Eric KOM a écrit : Please find attached my libnss-ldap.conf and pam_ldap.conf Even now I can't connect on the system using user that I created. Please, may be I missing some settings. Installing and setting up slapd as a server is one thing (a network available LDAP server). Being able to log in to a system using accounts from LDAP is another. To acheive this, I suggest you google one of many tutorials on PAM NSS LDAP. Some time ago I wrote an article on that topic. Please see if you can use it. http://www.boosten.org/creating-my-own-ldap-directory-part-3/ Peter -- http://www.boosten.org
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
objectClass index from slapd.conf is not working
Hello, I've a strange behavior while using index objectClass for searching. In my slapd.conf I have defined the index in the database section: index objectClass eq Other indexes follows in the config. All of them working fine. If I search via ldapsearch like: ldapsearch -x -h localhost -w password -Dcn=admin,ou=root -bou=root (objectclass=Guest) I can find following Message in the syslog (loglevel -1): Sep 1 14:02:52 LDAP01 slapd[17856]:EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: = key_read Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_index_read: failed (-30989) Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_equality_candidates: id=0, first=0, last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_filter_candidates: id=0 first=0 last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_filter_candidates Sep 1 14:02:52 LDAP01 slapd[17856]:EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: = key_read Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_index_read 355545 candidates Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_equality_candidates: id=-1, first=228, last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_list_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_list_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_filter_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: = test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: = test_filter 5 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: = entry_decode(cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_dn2id(cn=aaa,cn=bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_dn2id: got id=0x1b696 Sep 1 14:02:52 LDAP01 slapd[17856]: = test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following... As result, the entires are found, but not in the index and the search takes a very long time. After this, I have rebuild the complete database via slapcat/slapadd, rebuild the index via slapindex for objetClass, but nothing helped. In tried the test above on: * OpenSuSE 11.1 and openLDAP 2.4.21 and 2.4.23 (linked against libdb-4.5) * OpenSuSE 11.0 and openLDAP 2.4.9 (linked against libdb-4.5) * Debian Lenny and openLDAP 2.4.11 (linked against libdb-4.2) with different databases and a search against a objectClass. If I try another index (not objectClass) from the slapd.conf the index works, example: ldapsearch -x -h localhost -w password -Dcn=admin,ou=root -bou=root (mypk=1234-234) Sep 1 14:03:44 LDAP01 slapd[17856]: = bdb_equality_candidates (mypk) Sep 1 14:03:44 LDAP01 slapd[17856]: = key_read Sep 1 14:03:44 LDAP01 slapd[17856]: = bdb_index_read 1 candidates Sep 1 14:03:44 LDAP01 slapd[17856]: = bdb_equality_candidates: id=1, first=112838, last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: = bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: = bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: = bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: = bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: = bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: bdb_search_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: = test_filter Sep 1 14:03:44 LDAP01 slapd[17856]: EQUALITY Sep 1 14:03:44 LDAP01 slapd[17856]: = test_filter 6 Sep 1 14:03:44 LDAP01 slapd[17856]: = send_search_entry: conn 1002 dn=cn=Fff,cn=Eee,... Sep 1 14:03:44 LDAP01 slapd[17856]: = send_search_entry: conn 1002 exit. Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_result: conn=1002 op=1 p=3 Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_response: msgid=2 tag=101 err=0 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_get(12): got connid=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_read(12): checking for input on id=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: op tag 0x42, time 1283342624 Sep 1 14:03:44 LDAP01 slapd[17856]: conn=1002 op=2 do_unbind Sep 1 14:03:44 LDAP01 slapd[17856]: connection_close: conn=1002 sd=12 Why does only the objectClass index not work? The only difference I can see, is that all other indexes are based on normal attributes. I don't know, if it is necessary, but for objectClass I
rwm rewrite
Hi I have googled and read over slapo-rwm man page, some great examples there BUT I cant seem too grasp the rewrite rule. Basically I have merged a couple of individual openldap directories under a meta database which works fine. Some of the individual directories have clashing posix uidnumber attributes ie uid=joe,dc=subdomain1,dc=test uidnumber: 1023 uid=soap,dc=subdomain2,dc=test uidnumber: 1023 uid=user2,dc=sudomain2,dc=test uidnumber: 1024 what I am trying too do is create a rwm overlay that would rewrite the uidnumber attribute for subdomain2 so add a 10 in front of each uidnumber for each user in the subdomain database. ie uid=soap,dc=subdomain2,dc=test uidnumber: 101023 uid=user2,dc=sudomain2,dc=test uidnumber: 101024 -- Thank you, Mark Adrian Coetser m...@tux-edo.co.za http://www.tux-edo.co.za http://www.tux-voip.co.za cel: +27 76 527 8789 fax: +27 86 677 4117
Re: rwm rewrite
Hi I have googled and read over slapo-rwm man page, some great examples there BUT I cant seem too grasp the rewrite rule. Basically I have merged a couple of individual openldap directories under a meta database which works fine. Some of the individual directories have clashing posix uidnumber attributes ie uid=joe,dc=subdomain1,dc=test uidnumber: 1023 uid=soap,dc=subdomain2,dc=test uidnumber: 1023 uid=user2,dc=sudomain2,dc=test uidnumber: 1024 what I am trying too do is create a rwm overlay that would rewrite the uidnumber attribute for subdomain2 so add a 10 in front of each uidnumber for each user in the subdomain database. ie uid=soap,dc=subdomain2,dc=test uidnumber: 101023 uid=user2,dc=sudomain2,dc=test uidnumber: 101024 slapo-rwm(5) by design can only muck with DN-valued attributes, for the purpose of creating virtual views of existing data. It cannot modify the contents of other attributes. For this purpose you probably need to write some specific piece of code. p.
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: rwm rewrite
On 2010/09/09 02:56 PM, masar...@aero.polimi.it wrote: slapo-rwm(5) by design can only muck with DN-valued attributes, for the purpose of creating virtual views of existing data. It cannot modify the contents of other attributes. For this purpose you probably need to write some specific piece of code. p. would I be able too use slapo-translucent to create my own local uidnumber? Thank you, Mark Adrian Coetser m...@tux-edo.co.za http://www.tux-edo.co.za http://www.tux-voip.co.za cel: +27 76 527 8789 fax: +27 86 677 4117
Re: objectClass index from slapd.conf is not working
Hello, Sorry, I made a mistake (during sanitize) in my posting. Ldapsearch is looking/starting the search dirctly (-b) in the Container DN with 88000 entires. Only this Container (searchbase) has the objectClass Guest. So the request is look like: ldapsearch -x -h localhost -w password -Dcn=admin,ou=root-bcn=Bbb,ou=root (objectclass=Guest) Because of the long time for searching today I moved (ldapmodify -f , moddn) all 88000 entires in an other location (from cn=Bbb,ou=root to cn=Ccc,ou=root) Example: dn: cn=Aaa,cn=Bbb,ou=root changetype: moddn newrdn: cn=Aaa deleteoldrdn: 1 newSuperior: cn=Ccc,ou=root and tried the ldapsearch again. The Container old is now empty like expected. The result from the displaying immediately (because the container has the objectclass Guest), but the search is continuing and takes a long time too. In the logfile now I can see following error messages from the slapd: Sep 9 16:25:20 LDAP02 slapd[26832]: bdb_search: 112279 scope not okay Sep 9 16:25:20 LDAP02 slapd[26832]: bdb_search: 112280 scope not okay . . Sep 9 16:25:20 LDAP02 slapd[26832]: bdb_search: 113276 scope not okay Sep 9 16:25:20 LDAP02 slapd[26832]: bdb_search: 113277 scope not okay Sep 9 16:25:20 LDAP02 slapd[26832]: entry_decode: cn=Xxx,cn=Ccc,ou=root Sep 9 16:25:20 LDAP02 slapd[26832]: = entry_decode(cn=Xxx,cn=Ccc,ou=root) Sep 9 16:25:20 LDAP02 slapd[26832]: bdb_search: 113278 scope not okay . . Sep 9 16:25:29 LDAP02 slapd[26832]: entry_decode: cn=Zzz,cn=Ccc,ou=root Sep 9 16:25:29 LDAP02 slapd[26832]: = entry_decode(cn=Zzz,cn=Ccc,ou=root) Sep 9 16:25:29 LDAP02 slapd[26832]: bdb_search: 154297 scope not okay Sep 9 16:25:29 LDAP02 slapd[26832]: entry_decode: cn=Kkk,ou=abc...,... , ou=root Sep 9 16:25:29 LDAP02 slapd[26832]: = entry_decode(cn=Kkk,ou=abc...,... , ou=root) Sep 9 16:25:29 LDAP02 slapd[26832]: bdb_search: 154298 scope not okay . . Sep 9 16:26:16 LDAP02 slapd[26832]: entry_decode: cn=123,ou=xvz...,... , ou=root Sep 9 16:26:16 LDAP02 slapd[26832]: = entry_decode(cn=123,ou=xvz...,... , ou=root) Sep 9 16:26:16 LDAP02 slapd[26832]: bdb_search: 355754 scope not okay I found following Posting in the mailing List with the same message. http://www.openldap.org/lists/openldap-bugs/200410/msg1.html What is going wrong? Thanks Tim 2010/9/9 Howard Chu h...@symas.com: tim stone wrote: Hello, I've a strange behavior while using index objectClass for searching. In my slapd.conf I have defined the index in the database section: index objectClass eq Other indexes follows in the config. All of them working fine. If I search via ldapsearch like: ldapsearch -x -h localhost -w password -Dcn=admin,ou=root -bou=root (objectclass=Guest) I can find following Message in the syslog (loglevel -1): Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: = key_read Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_index_read: failed (-30989) Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_equality_candidates: id=0, first=0, last=0 Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_filter_candidates: id=0 first=0 last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_filter_candidates Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: = key_read Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_index_read 355545 candidates Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_equality_candidates: id=-1, first=228, last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_list_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_list_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_filter_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: = test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]:= test_filter 5 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]:= entry_decode(cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: = bdb_dn2id(cn=aaa,cn=bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]:= bdb_dn2id: got id=0x1b696 Sep 1 14:02:52 LDAP01 slapd[17856]: = test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following... As result, the entires are found, but not in the index and the search takes a very long time. The index is working as designed, it's just filled with
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: cn=config and ACL formatting
ben, ben thielsen schrieb am 08.09.2010 23:42 Uhr: On Sep 01, 2010, at 10.14, Marc Patermann wrote: b...@bitrate.net schrieb am 31.08.2010 16:47 Uhr: some ldap clients/browsers support different editors for different types of data. for example, in my case, i use apache directory studio quite a bit, and was able to configure it so that when editing olcaccess attributes, it uses it's built in multiline text editor rather than the default inline editor. this allows for some formatting, making things a bit more readable. Can you please explain a bit more in detail how you did that? specifically, in apache directory studio, you can do the following: preferences - apache directory studio - ldap browser - value editors. then, in the value editors by attribute types, add a new item. if your dit is set up properly, you should be able to choose olcaccess from the list box for attribute type or oid:, and then select text editor from the value editor list box. once you've saved those settings, double clicking on an olcaccess entry will open the built in text editor instead of using the in place editor. Thanks, I found it. BTW it is in the context menu, too. If it is needed only now and then. Thanks Marc
Re: slapcat generate extra space characters in LDIF output
On Thu, Sep 9, 2010 at 12:33 PM, Emmanuel Lecharny elecha...@gmail.com wrote:
10) When an attrval-spec, distinguishedName, or rdn is base64-
encoded, the encoding rules specified in [5] are used with the
following exceptions: a) ***The requirement that base64 output
streams must be represented as lines of no more than 76
characters is removed.***
Point. Based on a quick reread of RFC 2849, LDIF doesn't mandate line
wrapping. But it does explicitly allow it, so tools that process LDIF
need to be able to deal with wrapped lines.
And it occurs to me that the unfold script can also be done a perl one-liner:
perl -pe 'BEGIN { undef $/; } s/\n //gms'
--
Mark J. Reed markjr...@gmail.com
Re: slapcat generate extra space characters in LDIF output
I'd note that while the current maximum width of lines is enforced to 76 chars, they happen to be 78 char long (because of an extra LDIF_KLUDGE set to 1 and, I guess, of the leading blank). In any case, in the spirit of being liberal when needed, I have nothing against allowing OpenLDAP tools to visualize LDIF with arbitrary width, as soon as the default behavior remains the original one, in order to avoid breaking existing software. 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: GSSAPI Bind across trusted realms
On 09/09/10 13:35 +0930, Indexer wrote: I have REALM.A and REALM.B in my KDC setup. There is a two way trust between REALM.A and REALM.B. I have a client computer on REALM.A, and can correctly kinit to get tickets from both realms via this trust pathway. I also have an OpenLDAP server on the server with REALM.B, and it is identified by ldap/ldap.real...@realm.b When i obtain a ticket on REALM.A via this , and try to execute a SASL bind to the ldap server, i get an error of SASL/GSSAPI authentication started ldap_err2string ldap_sasl_interactive_bind_s: Local error (-2) It says that Minor code may provide more information (Server ldap/ldap.real...@realm.b not found in Kerberos database). My understanding and memory of the flow of tickets in this case (Wireshark is very helpful here) is that your client should be requesting and receiving a TGT from the KDC for REALM.A, and another one from the KDC for REALM.B, *then* a ticket for ldap/ldap.real...@realm.b, directly from the KDC for REALM.B. After receiving the ldap/ldap.real...@realm.b ticket, it would then present it to the ldap server during GSSAPI exchange. Note that if one of the KDCs is a Microsoft AD server, then it handles cross realm ticket requests differently, where the client is expected to obtain REALM.B tickets proxied from the KDC for REALM.A (or something like that). I'd set up a wireshark capture and see which KDC is returning the error. You should see the Kerberos error codes transmitted over the wire. A user from REALM.B can access the LDAP server correctly with GSSAPI klist shows that i am getting a TGT for both REALM.A and REALM.B on my u...@realm.a. Is this an issue with kerberos being unable to find the ticket across the realm trust for ldap to be verified? What steps can i follow to help fix this issue? Are there principal flags that i am forgetting to add to my LDAP principal for this to work? -- Dan White
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
