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?
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.
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.
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.
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.
--On Friday, March 04, 2011 1:59 PM -0700 Zach Schimke zschimke@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
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.
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.
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.
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@MARS.ASU.EDU" authzid="zschtest@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.
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%20a...
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
openldap-technical@openldap.org
-
Andrew Findlay -
Dan White -
Quanah Gibson-Mount -
Zach Schimke