Hide Forgot
Description of problem: With pam_passthru-plugin enabled and configured to use ELEMENT of uid to authenticate, the ns-slapd daemon segfaults when attempting to bind with a user account using ldapsearch. Pam is configured to authenticate through ldap (on a different ldap server) Version-Release number of selected component (if applicable): Initially found the problem running: 389-ds-base-1.2.6-1.el5.x86_64 Now upgraded to this version, the problem remains: 389-ds-base-1.2.8-0.2.a2.el5.x86_64 Server is installed on top of RHEL 5.5 (Linux vmdirectory 2.6.18-194.17.4.el5 #1 SMP Wed Oct 20 13:03:08 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux) How reproducible: Always Steps to Reproduce: 1. Enable the PAM Pass Through Auth plugin 2. Restart the dirsrv daemon 3. Attempt to bind to the server using ldapsearch using a entry which has a matching uid to a valid user account authenticated through pam_ldap using another source, in this case another LDAP server. % ldapsearch -x -h directory -b "dc=domain,dc=com" -D "cn=My L. Name,ou=People,dc=domain,dc=com" -W "uid=myname" Enter LDAP Password: ldap_result: Can't contact LDAP server (-1) ============================= dse.ldif section: dn: cn=PAM Pass Through Auth,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject objectClass: pamConfig cn: PAM Pass Through Auth nsslapd-pluginPath: libpam-passthru-plugin nsslapd-pluginInitfunc: pam_passthruauth_init nsslapd-pluginType: preoperation nsslapd-pluginEnabled: on nsslapd-pluginloadglobal: true nsslapd-plugin-depends-on-type: database pamMissingSuffix: ALLOW pamExcludeSuffix: cn=config pamIDMapMethod: ENTRY pamIDAttr: uid pamFallback: FALSE pamSecure: FALSE pamService: ldapserver nsslapd-pluginId: pam_passthruauth nsslapd-pluginVersion: 1.2.8.a2 nsslapd-pluginVendor: 389 Project nsslapd-pluginDescription: PAM pass through authentication plugin ==================================== /etc/pam.d/ldapserver: auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_ldap.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 #password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 password sufficient /lib/security/$ISA/pam_ldap.so use_authtok password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok shadow password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_ldap.so Actual results: ns-slapd segfaults. With errorlog-level enabled for trace and plugins, I get the following output in /var/log/dirsrv/slapd-vmdirectory/errors: [13/Feb/2011:20:12:38 -0800] - => str2entry_dupcheck [13/Feb/2011:20:12:38 -0800] - <= str2entry_dupcheck 0x1de56640 "cn=My L. Name,ou=People,dc=domain,dc=com" [13/Feb/2011:20:12:38 -0800] id2entry - id2entry id: 1973, dn "cn=my l. name,ou=people,dc=domain,dc=com" -- adding it to cache [13/Feb/2011:20:12:38 -0800] - -> attrcrypt_decrypt_entry [13/Feb/2011:20:12:38 -0800] - <- attrcrypt_decrypt_entry [13/Feb/2011:20:12:38 -0800] id2entry - <= id2entry( 1973 ) 1de3f740 (disk) [13/Feb/2011:20:12:38 -0800] - <= dn2entry 1de3f740 [13/Feb/2011:20:12:38 -0800] - <= find_entry_internal_dn found (cn=my l. name,ou=people,dc=domain,dc=com) [13/Feb/2011:20:12:38 -0800] - candidate list has 1 ids [13/Feb/2011:20:12:38 -0800] id2entry - => id2entry(1973) [13/Feb/2011:20:12:38 -0800] id2entry - <= id2entry 1de3f740, dn "cn=my l. name,ou=people,dc=domain,dc=com" (cache) [13/Feb/2011:20:12:38 -0800] id2entry - <= id2entry( 1973 ) 1de3f740 (disk) [13/Feb/2011:20:12:38 -0800] - => send_ldap_search_entry (cn=My L. Name,ou=People,dc=domain,dc=com) [13/Feb/2011:20:12:38 -0800] - Calling plugin 'deref' #2 type 410 [13/Feb/2011:20:12:38 -0800] - Calling plugin 'Legacy replication preoperation plugin' #4 type 410 [13/Feb/2011:20:12:38 -0800] - <= send_ldap_search_entry [13/Feb/2011:20:12:38 -0800] - => send_ldap_result 0:: [13/Feb/2011:20:12:38 -0800] - <= send_ldap_result [13/Feb/2011:20:12:38 -0800] - mapping tree release backend : userRoot [13/Feb/2011:20:12:38 -0800] pam_passthru-plugin - pam msg [0] = 1 Password: In /var/log/messages: Feb 13 20:12:39 vmdirectory kernel: ns-slapd[8820]: segfault at 00002aaaab5b2177 rip 00002acacb4934bb rsp 000000004ba10338 error 7 gdb output: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x4b63d940 (LWP 9447)] 0x00002b230066a4bb in strtok_r () from /lib64/libc.so.6 (gdb) bt #0 0x00002b230066a4bb in strtok_r () from /lib64/libc.so.6 #1 0x00002b22fefe25ed in ldap_str2charray () from /usr/lib64/libldap60.so #2 0x00002aaaab5a058d in ?? () from /usr/lib64/libldap-2.3.so.0 #3 0x00002aaaab5a2f0e in ldap_int_initialize_global_options () from /usr/lib64/libldap-2.3.so.0 #4 0x00002aaaab5a3048 in ldap_int_initialize () from /usr/lib64/libldap-2.3.so.0 #5 0x00002aaaab58c3b6 in ldap_create () from /usr/lib64/libldap-2.3.so.0 #6 0x00002aaaab58c73a in ldap_initialize () from /usr/lib64/libldap-2.3.so.0 #7 0x00002aaaab378d49 in ?? () from /lib/security/../../lib64/security/pam_ldap.so #8 0x00002aaaab3790bd in ?? () from /lib/security/../../lib64/security/pam_ldap.so #9 0x00002aaaab37985f in ?? () from /lib/security/../../lib64/security/pam_ldap.so #10 0x00002aaaab37a250 in pam_sm_acct_mgmt () from /lib/security/../../lib64/security/pam_ldap.so #11 0x00002b2308953dc7 in _pam_dispatch () from /lib64/libpam.so.0 #12 0x00002b23089535b8 in pam_acct_mgmt () from /lib64/libpam.so.0 #13 0x00002b2308720e2a in ?? () from /usr/lib64/dirsrv/plugins/libpam-passthru-plugin.so #14 0x00002b230872129e in pam_passthru_do_pam_auth () from /usr/lib64/dirsrv/plugins/libpam-passthru-plugin.so #15 0x00002b2308721840 in ?? () from /usr/lib64/dirsrv/plugins/libpam-passthru-plugin.so #16 0x00002b22fe04f60d in ?? () from /usr/lib64/dirsrv/libslapd.so.0 #17 0x00002b22fe04f77e in plugin_call_plugins () from /usr/lib64/dirsrv/libslapd.so.0 #18 0x000000000040e83f in config_get_allowed_to_delete_attrs () #19 0x0000000000413417 in config_get_allowed_to_delete_attrs () #20 0x00002b22ffda44ad in ?? () from /usr/lib64/libnspr4.so #21 0x00002b23003db73d in start_thread () from /lib64/libpthread.so.0 #22 0x00002b23006c3f6d in clone () from /lib64/libc.so.6
I don't think this will work on el5. The problem is that 389-ds-base on el5 uses mozldap but pam_ldap uses openldap - as you can see in the stack trace above the ldap functions use some from libldap-2.3 and some from libldap60 - these two different ldap libraries are not binary compatible and many problems such as crashes will ensue. I suppose you could try regular (not PAM) pass through authentication http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Using_the_Pass_through_Authentication_Plug_in or chaining backend/database links http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Configuring_Directory_Databases-Creating_and_Maintaining_Database_Links On Fedora 14 and later, and on EL6 and later, 389 is able to use openldap instead of mozldap
I've tried the regular pass through, but my bind dn's do not match on each ldap server. I need a way to map one bind dn to another. If you could help me with that I wouldn't need to use pam. I was originally going to use EL6 for the 389 directory, but it appears there is still no stable packages for EL6 in EPEL or koji. Using chaining might work for me, but It a bit complicated. I can't exactly wrap my head around it. What I'm trying to do is this... I have one directory running 389-ds which has no password values in the entries so binding as a user is not possible. I want to be able to authenticate access to this directory using a pass through mechanism to another ldap directory so that I can put the 389-ds directory out on a DMZ for address book queries without exposing my sensitive data stored in an internal directory (Red Hat DS 8.2).
(In reply to comment #2) > I've tried the regular pass through, but my bind dn's do not match on each ldap > server. I need a way to map one bind dn to another. If you could help me with > that I wouldn't need to use pam. I was originally going to use EL6 for the 389 > directory, but it appears there is still no stable packages for EL6 in EPEL or > koji. Using chaining might work for me, but It a bit complicated. I can't > exactly wrap my head around it. What I'm trying to do is this... 389-ds-base will be going into RHEL6, probably RHEL6.1. Since it will be part of RHEL, it cannot be in EPEL. > > I have one directory running 389-ds which has no password values in the entries > so binding as a user is not possible. I want to be able to authenticate access > to this directory using a pass through mechanism to another ldap directory so > that I can put the 389-ds directory out on a DMZ for address book queries > without exposing my sensitive data stored in an internal directory (Red Hat DS > 8.2). It will be complicated, but you can use replication and chain on update + chain on bind requests: http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate The host in the DMZ would be a read only replica - use Fractional Replication to only replicate those attributes you want to expose to address book clients. Set up the read only replica to chain BIND requests back to the master.
Thanks. I was able to set up a database link to chain the authentication.