4:07 p.m.
Is there any trick to this?
I am able to get SASL/PLAIN and SASL/GSSAPI binds to work perfectly with
my ldap server. What I want to get working is the authentication
pass-through.
From what I can gather, it appears that LDAP should be able to
authenticate a simple bind, take a look at the userPassword attribute
(which contains '{SASL}username@REALM) and perform a SASL/PLAIN from there.
We want to avoid maintaining two separate passwords (LDAP and Kerberos
V) although some applications (like phpLDAPAdmin, Drupal, etc) do not
allow the use of Kerberos natively.
/etc/sasl2/slapd.conf (using CentOS):
pwcheck_method: saslauthd
Here's a snippet of my openldap.log during a simple bind:
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 ACCEPT from
IP=149.169.147.254:56106 (IP=0.0.0.0:636)
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 TLS established
tls_ssf=256 ssf=256
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 BIND dn="cn=test
account,ou=people,o=mars" method=128
Mar 3 16:45:49 kdc1 slapd[28132]: send_ldap_result: conn=2009 op=0
p=3
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 RESULT tag=97
err=49 text=
Mar 3 16:45:49 kdc1 slapd[28132]: connection_closing: readying
conn=2009 sd=39 for close
Mar 3 16:45:49 kdc1 slapd[28132]: connection_close: conn=2009 sd=-1
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 closed
(connection lost)
Anything I should double-check, modify, etc?
--
Zach Schimke
Mars Space Flight Facility
6:54 a.m.
On 03/03/11 17:07 -0700, Zach Schimke wrote:
Is there any trick to this?
I am able to get SASL/PLAIN and SASL/GSSAPI binds to work perfectly
with my ldap server. What I want to get working is the authentication
pass-through.
From what I can gather, it appears that LDAP should be able to
authenticate a simple bind, take a look at the userPassword attribute
(which contains '{SASL}username@REALM) and perform a SASL/PLAIN from
there.
We want to avoid maintaining two separate passwords (LDAP and
Kerberos V) although some applications (like phpLDAPAdmin, Drupal,
etc) do not allow the use of Kerberos natively.
/etc/sasl2/slapd.conf (using CentOS):
pwcheck_method: saslauthd
Here's a snippet of my openldap.log during a simple bind:
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 ACCEPT from
IP=149.169.147.254:56106 (IP=0.0.0.0:636)
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 TLS
established tls_ssf=256 ssf=256
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 BIND
dn="cn=test account,ou=people,o=mars" method=128
Mar 3 16:45:49 kdc1 slapd[28132]: send_ldap_result: conn=2009
op=0 p=3
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 RESULT tag=97
err=49 text=
Mar 3 16:45:49 kdc1 slapd[28132]: connection_closing: readying
conn=2009 sd=39 for close
Mar 3 16:45:49 kdc1 slapd[28132]: connection_close: conn=2009 sd=-1
Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 closed
(connection lost)
Anything I should double-check, modify, etc?
Verify that your openldap installation was compiled with
'--enable-spasswd'.
Try running saslauthd in debug mode to see if slapd is passing an
authentication attempt.
--
Dan White
12:22 p.m.
It was complied with '--enable-spasswd', defined properly in
portable.h, and I confirm that an ldd of the slapd binary show that it
is linked to sasl.
include/portable.h:
/* define to support SASL passwords */
#define SLAPD_SPASSWD 1
BUT, the logs say nothing about SASL when a simple bind is performed to
my account with a {SASL} userPassword.
Zach Schimke
Mars Space Flight Facility
On 3/4/2011 7:54 AM, Dan White wrote:
On 03/03/11 17:07 -0700, Zach Schimke wrote:
> Is there any trick to this?
>
> I am able to get SASL/PLAIN and SASL/GSSAPI binds to work perfectly
> with my ldap server. What I want to get working is the authentication
> pass-through.
>
> From what I can gather, it appears that LDAP should be able to
> authenticate a simple bind, take a look at the userPassword attribute
> (which contains '{SASL}username@REALM) and perform a SASL/PLAIN from
> there.
>
> We want to avoid maintaining two separate passwords (LDAP and
> Kerberos V) although some applications (like phpLDAPAdmin, Drupal,
> etc) do not allow the use of Kerberos natively.
>
> /etc/sasl2/slapd.conf (using CentOS):
> pwcheck_method: saslauthd
>
> Here's a snippet of my openldap.log during a simple bind:
> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 ACCEPT from
> IP=149.169.147.254:56106 (IP=0.0.0.0:636)
> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 TLS established
> tls_ssf=256 ssf=256
> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 BIND dn="cn=test
> account,ou=people,o=mars" method=128
> Mar 3 16:45:49 kdc1 slapd[28132]: send_ldap_result: conn=2009
> op=0 p=3
> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 RESULT tag=97
> err=49 text=
> Mar 3 16:45:49 kdc1 slapd[28132]: connection_closing: readying
> conn=2009 sd=39 for close
> Mar 3 16:45:49 kdc1 slapd[28132]: connection_close: conn=2009 sd=-1
> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 closed
> (connection lost)
>
> Anything I should double-check, modify, etc?
Verify that your openldap installation was compiled with
'--enable-spasswd'.
Try running saslauthd in debug mode to see if slapd is passing an
authentication attempt.
12:48 p.m.
On 04/03/11 13:22 -0700, Zach Schimke wrote:
It was complied with '--enable-spasswd', defined properly in
portable.h, and I confirm that an ldd of the slapd binary show that
it is linked to sasl.
include/portable.h:
/* define to support SASL passwords */
#define SLAPD_SPASSWD 1
BUT, the logs say nothing about SASL when a simple bind is performed
to my account with a {SASL} userPassword.
What log level are you capturing at? What version of OpenLDAP are you
using?
You said you were able to get a SASL PLAIN bind working, so I don't
believe you have a problem with your /etc/sasl2/slapd.conf config.
What happens if you provide the '{SASL}username@REALM' (or the value in
your userPassword attribute) as the password? Does it succeed?
On 3/4/2011 7:54 AM, Dan White wrote:
>On 03/03/11 17:07 -0700, Zach Schimke wrote:
>>Is there any trick to this?
>>
>>I am able to get SASL/PLAIN and SASL/GSSAPI binds to work
>>perfectly with my ldap server. What I want to get working is the
>>authentication pass-through.
>>
>>From what I can gather, it appears that LDAP should be able to
>>authenticate a simple bind, take a look at the userPassword
>>attribute (which contains '{SASL}username@REALM) and perform a
>>SASL/PLAIN from there.
>>
>>We want to avoid maintaining two separate passwords (LDAP and
>>Kerberos V) although some applications (like phpLDAPAdmin,
>>Drupal, etc) do not allow the use of Kerberos natively.
>>
>>/etc/sasl2/slapd.conf (using CentOS):
>> pwcheck_method: saslauthd
>>
>>Here's a snippet of my openldap.log during a simple bind:
>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 ACCEPT from
>>IP=149.169.147.254:56106 (IP=0.0.0.0:636)
>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 TLS
>>established tls_ssf=256 ssf=256
>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 BIND
>>dn="cn=test account,ou=people,o=mars" method=128
>> Mar 3 16:45:49 kdc1 slapd[28132]: send_ldap_result: conn=2009
>>op=0 p=3
>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 RESULT
>>tag=97 err=49 text=
>> Mar 3 16:45:49 kdc1 slapd[28132]: connection_closing:
>>readying conn=2009 sd=39 for close
>> Mar 3 16:45:49 kdc1 slapd[28132]: connection_close: conn=2009 sd=-1
>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 closed
>>(connection lost)
>>
>>Anything I should double-check, modify, etc?
>
>Verify that your openldap installation was compiled with
>'--enable-spasswd'.
>
>Try running saslauthd in debug mode to see if slapd is passing an
>authentication attempt.
>
--
Dan White
BTC Broadband
Ph 918.366.0248 (direct) main: (918)366-8000
Fax 918.366.6610 email: dwhite(a)olp.net
http://www.btcbroadband.com
12:59 p.m.
I'm using openldap-2.3.32, loglevel = -1 (log grows at 2MB/minute), and
neither of those tests work. I've even tried with and without the @REALM.
Zach Schimke
Mars Space Flight Facility
On 3/4/2011 1:48 PM, Dan White wrote:
On 04/03/11 13:22 -0700, Zach Schimke wrote:
> It was complied with '--enable-spasswd', defined properly in
> portable.h, and I confirm that an ldd of the slapd binary show that
> it is linked to sasl.
>
> include/portable.h:
> /* define to support SASL passwords */
> #define SLAPD_SPASSWD 1
>
> BUT, the logs say nothing about SASL when a simple bind is performed
> to my account with a {SASL} userPassword.
What log level are you capturing at? What version of OpenLDAP are you
using?
You said you were able to get a SASL PLAIN bind working, so I don't
believe you have a problem with your /etc/sasl2/slapd.conf config.
What happens if you provide the '{SASL}username@REALM' (or the value in
your userPassword attribute) as the password? Does it succeed?
> On 3/4/2011 7:54 AM, Dan White wrote:
>> On 03/03/11 17:07 -0700, Zach Schimke wrote:
>>> Is there any trick to this?
>>>
>>> I am able to get SASL/PLAIN and SASL/GSSAPI binds to work perfectly
>>> with my ldap server. What I want to get working is the
>>> authentication pass-through.
>>>
>>> From what I can gather, it appears that LDAP should be able to
>>> authenticate a simple bind, take a look at the userPassword
>>> attribute (which contains '{SASL}username@REALM) and perform a
>>> SASL/PLAIN from there.
>>>
>>> We want to avoid maintaining two separate passwords (LDAP and
>>> Kerberos V) although some applications (like phpLDAPAdmin, Drupal,
>>> etc) do not allow the use of Kerberos natively.
>>>
>>> /etc/sasl2/slapd.conf (using CentOS):
>>> pwcheck_method: saslauthd
>>>
>>> Here's a snippet of my openldap.log during a simple bind:
>>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 ACCEPT from
>>> IP=149.169.147.254:56106 (IP=0.0.0.0:636)
>>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 TLS
>>> established tls_ssf=256 ssf=256
>>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 BIND
>>> dn="cn=test account,ou=people,o=mars" method=128
>>> Mar 3 16:45:49 kdc1 slapd[28132]: send_ldap_result: conn=2009
>>> op=0 p=3
>>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 RESULT tag=97
>>> err=49 text=
>>> Mar 3 16:45:49 kdc1 slapd[28132]: connection_closing: readying
>>> conn=2009 sd=39 for close
>>> Mar 3 16:45:49 kdc1 slapd[28132]: connection_close: conn=2009 sd=-1
>>> Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 closed
>>> (connection lost)
>>>
>>> Anything I should double-check, modify, etc?
>>
>> Verify that your openldap installation was compiled with
>> '--enable-spasswd'.
>>
>> Try running saslauthd in debug mode to see if slapd is passing an
>> authentication attempt.
>>
>
1:05 p.m.
--On Friday, March 04, 2011 1:59 PM -0700 Zach Schimke
<zschimke(a)mars.asu.edu> wrote:
I'm using openldap-2.3.32, loglevel = -1 (log grows at
2MB/minute), and
neither of those tests work. I've even tried with and without the @REALM.
I would advise you to upgrade to a supported release, rather than using one
that contains numerous known issues. 2.3 is no longer supported, and the
current stable release is 2.4.23. The last 2.3 release was 2.3.43. Either
way, you are significantly behind modern times, and some serious bugs were
fixed between 2.3.32 and 2.3.43.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
1:09 p.m.
On 04/03/11 13:59 -0700, Zach Schimke wrote:
I'm using openldap-2.3.32, loglevel = -1 (log grows at
2MB/minute),
and neither of those tests work. I've even tried with and without the
@REALM.
Can you run your slapd in debug mode (-d -1), and your saslauthd in debug
mode (-d)?
Try performing your SASL PLAIN bind, and then your non-sasl pass-through
bind, and let us have a look at any relevant output you're seeing from
either daemon. It might help to have a look at both to compare.
--
Dan White
2:42 p.m.
Okay, I get nothing from saslauthd. The relevent logging slapd gives me:
daemon: epoll: listen=7 active_threads=0 tvp=NULL
daemon: epoll: listen=8 active_threads=0 tvp=NULL
daemon: epoll: listen=9 active_threads=0 tvp=NULL
daemon: epoll: listen=10 active_threads=0 tvp=NULL
do_bind
>> dnPrettyNormal: <cn=zach schimke -
test,ou=people,o=mars>
<<< dnPrettyNormal: <cn=zach schimke -
test,ou=people,o=mars>, <cn=zach
schimke - test,ou=people,o=mars>
do_bind: version=3 dn="cn=zach schimke - test,ou=people,o=mars"
method=128
==> hdb_bind: dn: cn=zach schimke - test,ou=people,o=mars
bdb_dn2entry("cn=zach schimke - test,ou=people,o=mars")
=> access_allowed: auth access to "cn=Zach Schimke -
TEST,ou=people,o=mars" "userPassword" requested
=> dn: [1] o=new
=> dn: [2] ou=rooms,o=mars
=> dn: [3] ou=acl,o=mars
=> dn: [4] ou=groups,o=mars
=> dn: [5] ou=people,o=mars
=> acl_get: [5] matched
=> acl_get: [5] attr userPassword
access_allowed: no res from state (userPassword)
=> acl_mask: access to entry "cn=Zach Schimke -
TEST,ou=people,o=mars", attr "userPassword" requested
=> acl_mask: to value by "", (=0)
<= check a_dn_pat: ou=admins,ou=people,o=mars
<= check a_dn_pat: cn=mars admin,ou=role,ou=people,o=mars
<= check a_dn_pat: *
<= acl_mask: [3] applying read(=rscxd) (stop)
<= acl_mask: [3] mask: read(=rscxd)
=> access_allowed: auth access granted by read(=rscxd)
send_ldap_result: conn=4 op=0 p=3
send_ldap_result: err=49 matched="" text=""
send_ldap_response: msgid=1 tag=97 err=49
daemon: activity on 1 descriptor
daemon: activity on:
15r
So, I do not see anything looking at SASL. Is there something special I
need to put in slapd.access to make the pass-through bit work? It seems
to be an ACL problem at this point (but regular password binds work
properly with other users).
Zach Schimke
Mars Space Flight Facility
On 3/4/2011 2:09 PM, Dan White wrote:
On 04/03/11 13:59 -0700, Zach Schimke wrote:
> I'm using openldap-2.3.32, loglevel = -1 (log grows at 2MB/minute),
> and neither of those tests work. I've even tried with and without the
> @REALM.
Can you run your slapd in debug mode (-d -1), and your saslauthd in debug
mode (-d)?
Try performing your SASL PLAIN bind, and then your non-sasl pass-through
bind, and let us have a look at any relevant output you're seeing from
either daemon. It might help to have a look at both to compare.
3:03 p.m.
Without seeing any output from your SASL/PLAIN bind, I suspect that
saslauthd may not be working with your slapd installation.
If that's the case, double check the permissions on your saslauthd mux, and
specify a saslauthd_path parameter within your sasl slapd.conf config if
necessary.
On 10/03/11 15:42 -0700, Zach Schimke wrote:
Okay, I get nothing from saslauthd. The relevent logging slapd gives
me:
daemon: epoll: listen=7 active_threads=0 tvp=NULL
daemon: epoll: listen=8 active_threads=0 tvp=NULL
daemon: epoll: listen=9 active_threads=0 tvp=NULL
daemon: epoll: listen=10 active_threads=0 tvp=NULL
do_bind
>>> dnPrettyNormal: <cn=zach schimke - test,ou=people,o=mars>
<<< dnPrettyNormal: <cn=zach schimke - test,ou=people,o=mars>,
<cn=zach schimke - test,ou=people,o=mars>
do_bind: version=3 dn="cn=zach schimke - test,ou=people,o=mars"
method=128
==> hdb_bind: dn: cn=zach schimke - test,ou=people,o=mars
bdb_dn2entry("cn=zach schimke - test,ou=people,o=mars")
=> access_allowed: auth access to "cn=Zach Schimke -
TEST,ou=people,o=mars" "userPassword" requested
=> dn: [1] o=new
=> dn: [2] ou=rooms,o=mars
=> dn: [3] ou=acl,o=mars
=> dn: [4] ou=groups,o=mars
=> dn: [5] ou=people,o=mars
=> acl_get: [5] matched
=> acl_get: [5] attr userPassword
access_allowed: no res from state (userPassword)
=> acl_mask: access to entry "cn=Zach Schimke -
TEST,ou=people,o=mars", attr "userPassword" requested
=> acl_mask: to value by "", (=0)
<= check a_dn_pat: ou=admins,ou=people,o=mars
<= check a_dn_pat: cn=mars admin,ou=role,ou=people,o=mars
<= check a_dn_pat: *
<= acl_mask: [3] applying read(=rscxd) (stop)
<= acl_mask: [3] mask: read(=rscxd)
=> access_allowed: auth access granted by read(=rscxd)
send_ldap_result: conn=4 op=0 p=3
send_ldap_result: err=49 matched="" text=""
send_ldap_response: msgid=1 tag=97 err=49
daemon: activity on 1 descriptor
daemon: activity on:
15r
So, I do not see anything looking at SASL. Is there something special
I need to put in slapd.access to make the pass-through bit work? It
seems to be an ACL problem at this point (but regular password binds
work properly with other users).
Zach Schimke
Mars Space Flight Facility
On 3/4/2011 2:09 PM, Dan White wrote:
>On 04/03/11 13:59 -0700, Zach Schimke wrote:
>>I'm using openldap-2.3.32, loglevel = -1 (log grows at
>>2MB/minute), and neither of those tests work. I've even tried
>>with and without the @REALM.
>
>Can you run your slapd in debug mode (-d -1), and your saslauthd in debug
>mode (-d)?
>
>Try performing your SASL PLAIN bind, and then your non-sasl pass-through
>bind, and let us have a look at any relevant output you're seeing from
>either daemon. It might help to have a look at both to compare.
>
--
Dan White
BTC Broadband
Ph 918.366.0248 (direct) main: (918)366-8000
Fax 918.366.6610 email: dwhite(a)olp.net
http://www.btcbroadband.com
3:32 p.m.
Okay, here's the log from a SASL/PLAIN bind working.
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: read active on 21
Mar 10 16:28:51 kdc1 slapd[2367]: connection_get(21)
Mar 10 16:28:51 kdc1 slapd[2367]: connection_get(21): got connid=41
Mar 10 16:28:51 kdc1 slapd[2367]: connection_read(21): checking for
input on id=41
Mar 10 16:28:51 kdc1 slapd[2367]: do_bind
Mar 10 16:28:51 kdc1 slapd[2367]: >>> dnPrettyNormal:
<uid=zschtest,cn=MARS.ASU.EDU,cn=auth>
Mar 10 16:28:51 kdc1 slapd[2367]: <<< dnPrettyNormal:
<uid=zschtest,cn=MARS.ASU.EDU,cn=auth>
<uid=zschtest,cn=mars.asu.edu,cn=auth>
Mar 10 16:28:51 kdc1 slapd[2367]: do_sasl_bind: dn
(uid=zschtest,cn=MARS.ASU.EDU,cn=auth) mech PLAIN
Mar 10 16:28:51 kdc1 slapd[2367]: ==> sasl_bind:
dn="uid=zschtest,cn=MARS.ASU.EDU,cn=auth" mech=PLAIN datalen=20
Mar 10 16:28:51 kdc1 slapd[2367]: SASL Canonicalize [conn=41]:
authcid="zschtest"
Mar 10 16:28:51 kdc1 slapd[2367]: slap_sasl_getdn: conn 41 id=zschtest
[len=8]
Mar 10 16:28:51 kdc1 slapd[2367]: slap_sasl_getdn: u:id converted to
uid=zschtest,cn=MARS.ASU.EDU,cn=PLAIN,cn=auth
Mar 10 16:28:51 kdc1 slapd[2367]: >>> dnNormalize:
<uid=zschtest,cn=MARS.ASU.EDU,cn=PLAIN,cn=auth>
Mar 10 16:28:51 kdc1 slapd[2367]: <<< dnNormalize:
<uid=zschtest,cn=mars.asu.edu,cn=plain,cn=auth>
Mar 10 16:28:51 kdc1 slapd[2367]: ==>slap_sasl2dn: converting SASL name
uid=zschtest,cn=mars.asu.edu,cn=plain,cn=auth to a DN
Mar 10 16:28:51 kdc1 slapd[2367]: slap_authz_regexp: converting SASL
name uid=zschtest,cn=mars.asu.edu,cn=plain,cn=auth
Mar 10 16:28:51 kdc1 slapd[2367]: slap_authz_regexp: converted SASL name
to ldap:///ou=people,o=mars??sub?(&(uid=zschtest)(objectClass=marsPerson))
Mar 10 16:28:51 kdc1 slapd[2367]: slap_parseURI: parsing
ldap:///ou=people,o=mars??sub?(&(uid=zschtest)(objectClass=marsPerson))
Mar 10 16:28:51 kdc1 slapd[2367]: str2filter
"(&(uid=zschtest)(objectClass=marsPerson))"
Mar 10 16:28:51 kdc1 slapd[2367]: begin get_filter
Mar 10 16:28:51 kdc1 slapd[2367]: AND
Mar 10 16:28:51 kdc1 slapd[2367]: begin get_filter_list
Mar 10 16:28:51 kdc1 slapd[2367]: begin get_filter
Mar 10 16:28:51 kdc1 slapd[2367]: EQUALITY
Mar 10 16:28:51 kdc1 slapd[2367]: end get_filter 0
Mar 10 16:28:51 kdc1 slapd[2367]: begin get_filter
Mar 10 16:28:51 kdc1 slapd[2367]: EQUALITY
Mar 10 16:28:51 kdc1 slapd[2367]: end get_filter 0
Mar 10 16:28:51 kdc1 slapd[2367]: end get_filter_list
Mar 10 16:28:51 kdc1 slapd[2367]: end get_filter 0
Mar 10 16:28:51 kdc1 slapd[2367]: >>> dnNormalize: <ou=people,o=mars>
Mar 10 16:28:51 kdc1 slapd[2367]: <<< dnNormalize: <ou=people,o=mars>
Mar 10 16:28:51 kdc1 slapd[2367]: slap_sasl2dn: performing internal
search (base=ou=people,o=mars, scope=2)
Mar 10 16:28:51 kdc1 slapd[2367]: => hdb_search
Mar 10 16:28:51 kdc1 slapd[2367]: bdb_dn2entry("ou=people,o=mars")
Mar 10 16:28:51 kdc1 slapd[2367]: search_candidates:
base="ou=people,o=mars" (0x00000002) scope=2
Mar 10 16:28:51 kdc1 slapd[2367]: => hdb_dn2idl("ou=people,o=mars")
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_filter_candidates
Mar 10 16:28:51 kdc1 slapd[2367]: AND
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_list_candidates 0xa0
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_filter_candidates
Mar 10 16:28:51 kdc1 slapd[2367]: OR
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_list_candidates 0xa1
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_filter_candidates
Mar 10 16:28:51 kdc1 slapd[2367]: EQUALITY
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_equality_candidates (objectClass)
Mar 10 16:28:51 kdc1 slapd[2367]: => key_read
Mar 10 16:28:51 kdc1 slapd[2367]: bdb_idl_fetch_key: [b49d1940]
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_index_read: failed (-30989)
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_equality_candidates: id=0,
first=0, last=0
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_filter_candidates: id=0 first=0
last=0
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_filter_candidates
Mar 10 16:28:51 kdc1 slapd[2367]: AND
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_list_candidates 0xa0
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_filter_candidates
Mar 10 16:28:51 kdc1 slapd[2367]: EQUALITY
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_equality_candidates (uid)
Mar 10 16:28:51 kdc1 slapd[2367]: => key_read
Mar 10 16:28:51 kdc1 slapd[2367]: bdb_idl_fetch_key: [7598d43a]
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_index_read 1 candidates
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_equality_candidates: id=1,
first=5721, last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_filter_candidates: id=1
first=5721 last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_filter_candidates
Mar 10 16:28:51 kdc1 slapd[2367]: EQUALITY
Mar 10 16:28:51 kdc1 slapd[2367]: => bdb_equality_candidates (objectClass)
Mar 10 16:28:51 kdc1 slapd[2367]: => key_read
Mar 10 16:28:51 kdc1 slapd[2367]: bdb_idl_fetch_key: [13f0c171]
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_index_read 2932 candidates
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_equality_candidates: id=2932,
first=3, last=5776
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_filter_candidates: id=2932
first=3 last=5776
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_list_candidates: id=1
first=5721 last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_filter_candidates: id=1
first=5721 last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_list_candidates: id=1
first=5721 last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_filter_candidates: id=1
first=5721 last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_list_candidates: id=1
first=5721 last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: <= bdb_filter_candidates: id=1
first=5721 last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: bdb_search_candidates: id=1 first=5721
last=5721
Mar 10 16:28:51 kdc1 slapd[2367]: => test_filter
Mar 10 16:28:51 kdc1 slapd[2367]: AND
Mar 10 16:28:51 kdc1 slapd[2367]: => test_filter_and
Mar 10 16:28:51 kdc1 slapd[2367]: => test_filter
Mar 10 16:28:51 kdc1 slapd[2367]: EQUALITY
Mar 10 16:28:51 kdc1 slapd[2367]: => access_allowed: auth access to
"cn=Zach Schimke - TEST,ou=people,o=mars" "uid" requested
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [1] o=new
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [2] ou=rooms,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [3] ou=acl,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [4] ou=groups,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [5] ou=people,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: => acl_get: [5] matched
Mar 10 16:28:51 kdc1 slapd[2367]: => acl_get: [5] attr uid
Mar 10 16:28:51 kdc1 slapd[2367]: => acl_mask: access to entry "cn=Zach
Schimke - TEST,ou=people,o=mars", attr "uid" requested
Mar 10 16:28:51 kdc1 slapd[2367]: => acl_mask: to value by "", (=0)
Mar 10 16:28:51 kdc1 slapd[2367]: <= check a_dn_pat:
ou=admins,ou=people,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: <= check a_dn_pat: cn=mars
admin,ou=role,ou=people,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: <= check a_dn_pat: *
Mar 10 16:28:51 kdc1 slapd[2367]: <= acl_mask: [3] applying read(=rscxd)
(stop)
Mar 10 16:28:51 kdc1 slapd[2367]: <= acl_mask: [3] mask: read(=rscxd)
Mar 10 16:28:51 kdc1 slapd[2367]: => access_allowed: auth access granted
by read(=rscxd)
Mar 10 16:28:51 kdc1 slapd[2367]: <= test_filter 6
Mar 10 16:28:51 kdc1 slapd[2367]: => test_filter
Mar 10 16:28:51 kdc1 slapd[2367]: EQUALITY
Mar 10 16:28:51 kdc1 slapd[2367]: => access_allowed: auth access to
"cn=Zach Schimke - TEST,ou=people,o=mars" "objectClass" requested
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [1] o=new
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [2] ou=rooms,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [3] ou=acl,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [4] ou=groups,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: => dn: [5] ou=people,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: => acl_get: [5] matched
Mar 10 16:28:51 kdc1 slapd[2367]: => acl_get: [5] attr objectClass
Mar 10 16:28:51 kdc1 slapd[2367]: => acl_mask: access to entry "cn=Zach
Schimke - TEST,ou=people,o=mars", attr "objectClass" requested
Mar 10 16:28:51 kdc1 slapd[2367]: => acl_mask: to value by "", (=0)
Mar 10 16:28:51 kdc1 slapd[2367]: <= check a_dn_pat:
ou=admins,ou=people,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: <= check a_dn_pat: cn=mars
admin,ou=role,ou=people,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: <= check a_dn_pat: *
Mar 10 16:28:51 kdc1 slapd[2367]: <= acl_mask: [3] applying read(=rscxd)
(stop)
Mar 10 16:28:51 kdc1 slapd[2367]: <= acl_mask: [3] mask: read(=rscxd)
Mar 10 16:28:51 kdc1 slapd[2367]: => access_allowed: auth access granted
by read(=rscxd)
Mar 10 16:28:51 kdc1 slapd[2367]: <= test_filter 6
Mar 10 16:28:51 kdc1 slapd[2367]: <= test_filter_and 6
Mar 10 16:28:51 kdc1 slapd[2367]: <= test_filter 6
Mar 10 16:28:51 kdc1 slapd[2367]: send_ldap_result: conn=41 op=0 p=3
Mar 10 16:28:51 kdc1 slapd[2367]: send_ldap_result: err=0 matched=""
text=""
Mar 10 16:28:51 kdc1 slapd[2367]: <==slap_sasl2dn: Converted SASL name
to cn=zach schimke - test,ou=people,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: slap_sasl_getdn: dn:id converted to
cn=zach schimke - test,ou=people,o=mars
Mar 10 16:28:51 kdc1 slapd[2367]: SASL Canonicalize [conn=41]:
slapAuthcDN="cn=zach schimke - test,ou=people,o=mars"
Mar 10 16:28:51 kdc1 slapd[2367]: SASL [conn=41] Error: unable to open
Berkeley db /etc/sasldb2: No such file or directory
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: epoll: listen=9
active_threads=0 tvp=NULL
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: epoll: listen=10
active_threads=0 tvp=NULL
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: activity on 1 descriptor
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: activity on:
Mar 10 16:28:51 kdc1 slapd[2367]:
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: epoll: listen=9
active_threads=0 tvp=NULL
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: epoll: listen=10
active_threads=0 tvp=NULL
Mar 10 16:28:51 kdc1 slapd[2367]: SASL Canonicalize [conn=41]:
authzid="zschtest"
Mar 10 16:28:51 kdc1 slapd[2367]: SASL proxy authorize [conn=41]:
authcid="zschtest(a)MARS.ASU.EDU" authzid="zschtest(a)MARS.ASU.EDU"
Mar 10 16:28:51 kdc1 slapd[2367]: SASL Authorize [conn=41]: proxy
authorization allowed authzDN=""
Mar 10 16:28:51 kdc1 slapd[2367]: send_ldap_sasl: err=0 len=-1
Mar 10 16:28:51 kdc1 slapd[2367]: do_bind: SASL/PLAIN bind: dn="cn=zach
schimke - test,ou=people,o=mars" ssf=0
Mar 10 16:28:51 kdc1 slapd[2367]: send_ldap_response: msgid=1 tag=97 err=0
Mar 10 16:28:51 kdc1 slapd[2367]: <== slap_sasl_bind: rc=0
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: activity on 1 descriptor
Mar 10 16:28:51 kdc1 slapd[2367]: daemon: activity on:
Mar 10 16:28:51 kdc1 slapd[2367]: 21r
Zach Schimke
Mars Space Flight Facility
On 3/10/2011 4:03 PM, Dan White wrote:
Without seeing any output from your SASL/PLAIN bind, I suspect that
saslauthd may not be working with your slapd installation.
If that's the case, double check the permissions on your saslauthd
mux, and
specify a saslauthd_path parameter within your sasl slapd.conf config if
necessary.
On 10/03/11 15:42 -0700, Zach Schimke wrote:
> Okay, I get nothing from saslauthd. The relevent logging slapd gives me:
> daemon: epoll: listen=7 active_threads=0 tvp=NULL
> daemon: epoll: listen=8 active_threads=0 tvp=NULL
> daemon: epoll: listen=9 active_threads=0 tvp=NULL
> daemon: epoll: listen=10 active_threads=0 tvp=NULL
> do_bind
>>>> dnPrettyNormal: <cn=zach schimke - test,ou=people,o=mars>
> <<< dnPrettyNormal: <cn=zach schimke - test,ou=people,o=mars>,
> <cn=zach schimke - test,ou=people,o=mars>
> do_bind: version=3 dn="cn=zach schimke - test,ou=people,o=mars"
> method=128
> ==> hdb_bind: dn: cn=zach schimke - test,ou=people,o=mars
> bdb_dn2entry("cn=zach schimke - test,ou=people,o=mars")
> => access_allowed: auth access to "cn=Zach Schimke -
> TEST,ou=people,o=mars" "userPassword" requested
> => dn: [1] o=new
> => dn: [2] ou=rooms,o=mars
> => dn: [3] ou=acl,o=mars
> => dn: [4] ou=groups,o=mars
> => dn: [5] ou=people,o=mars
> => acl_get: [5] matched
> => acl_get: [5] attr userPassword
> access_allowed: no res from state (userPassword)
> => acl_mask: access to entry "cn=Zach Schimke -
> TEST,ou=people,o=mars", attr "userPassword" requested
> => acl_mask: to value by "", (=0)
> <= check a_dn_pat: ou=admins,ou=people,o=mars
> <= check a_dn_pat: cn=mars admin,ou=role,ou=people,o=mars
> <= check a_dn_pat: *
> <= acl_mask: [3] applying read(=rscxd) (stop)
> <= acl_mask: [3] mask: read(=rscxd)
> => access_allowed: auth access granted by read(=rscxd)
> send_ldap_result: conn=4 op=0 p=3
> send_ldap_result: err=49 matched="" text=""
> send_ldap_response: msgid=1 tag=97 err=49
> daemon: activity on 1 descriptor
> daemon: activity on:
> 15r
>
>
> So, I do not see anything looking at SASL. Is there something special
> I need to put in slapd.access to make the pass-through bit work? It
> seems to be an ACL problem at this point (but regular password binds
> work properly with other users).
>
> Zach Schimke
> Mars Space Flight Facility
>
>
> On 3/4/2011 2:09 PM, Dan White wrote:
>> On 04/03/11 13:59 -0700, Zach Schimke wrote:
>>> I'm using openldap-2.3.32, loglevel = -1 (log grows at 2MB/minute),
>>> and neither of those tests work. I've even tried with and without
>>> the @REALM.
>>
>> Can you run your slapd in debug mode (-d -1), and your saslauthd in
>> debug
>> mode (-d)?
>>
>> Try performing your SASL PLAIN bind, and then your non-sasl
>> pass-through
>> bind, and let us have a look at any relevant output you're seeing from
>> either daemon. It might help to have a look at both to compare.
>>
>
2:33 a.m.
On Thu, Mar 10, 2011 at 04:32:16PM -0700, Zach Schimke wrote:
Okay, here's the log from a SASL/PLAIN bind working.
Mar 10 16:28:51 kdc1 slapd[2367]: SASL [conn=41] Error: unable to
open Berkeley db /etc/sasldb2: No such file or directory
That suggests that your SASL config is still wrong, as it is trying to
use the default secrets database.
It may well be that the SASL library is not reading the config
files that you are modifying. Try running slapd under strace and
look to see which files it opens. You are looking for something like
/usr/lib/sasl2/slapd.conf which should contain something like this:
mech_list: plain
pwcheck_method: saslauthd
saslauthd_path: /var/run/sasl2/mux
Also, take not of the suggested tests in the adming guide:
http://www.openldap.org/doc/admin24/security.html#Testing%20pass-through%...
In particular, you can use testsaslauthd to make sure that the back-end
authentication daemon is working.
This is very unlikely to be an ACL problem.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
4402
days inactive
4409
days old
openldap-technical@openldap.org
10 comments
4 participants
participants (4)
-
Andrew Findlay -
Dan White -
Quanah Gibson-Mount -
Zach Schimke