openldap-technical November 2011

openldap-technical@openldap.org

80 participants
91 discussions

multi-byte utf8 characters in DNs
by Chris Card 29 Nov '11

29 Nov '11

[I tried searching the docs for the answer without much luck, so apologies if I've missed it] Does openldap (2.4.26) support DNs containing utf8 multi-byte characters? e.g. a DN containing é like cn=été,dc=a,dc=b ? If not, what's the recommended way of handling such DNs? Chris

4 7

CUCM search
by W.Siebert＠t-systems.com 29 Nov '11

29 Nov '11

Hello, I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD targets. Cisco Unified Call Manager (CUCM) sends a rather simpy query: (&(objectclass=user)(!(objectclass=Computer))) If CUCM connects AD server directly, all is OK, gets a search result. But sending this search to Meta, does not work. Log: Nov 28 20:27:39 walrhel5 slapd[7447]: ber_get_next on fd 10 failed errno=0 (Success) Nov 28 20:27:39 walrhel5 slapd[7447]: connection_read(10): input error=-2 id=1000, closing. If I send the same search with various LDAP-Browsers (Softerra, LDP, Perlscript...), all is OK. I tried witch OpenLDAP version: 2.4.26 and 2.4.28 My config: include /usr/local/etc/openldap/schema/core.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel -1 ####################################################################### database meta lastmod off suffix "dc=meta,dc=pov" rootdn "cn=metaguru,dc=meta,dc=pov" rootpw XXXXXXX uri "ldap://10.11.11.112:389/dc=meta,dc=pov" suffixmassage "dc=meta,dc=pov" "dc=adwal,dc=corporate,dc=net" idassert-authzFrom "dn:*" idassert-bind bindmethod=simple binddn="cn=radiator,cn=Users,dc=adwal,dc=corporate,dc=net" credentials="XXXXXXX" mode=none uri "ldap://10.11.11.114:389/dc=meta,dc=pov" suffixmassage "dc=meta,dc=pov" "dc=second,dc=crocus,dc=com" idassert-authzFrom "dn:*" idassert-bind bindmethod=simple binddn="cn=predator,cn=Users,dc=second,dc=crocus,dc=com" credentials="XXXXXXX" mode=none Full Log: Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 fd=10 ACCEPT from IP=10.11.11.119:40478 (IP=0.0.0.0:389) Nov 28 20:27:39 walrhel5 slapd[7447]: connection_get(10) Nov 28 20:27:39 walrhel5 slapd[7447]: connection_get(10): got connid=1000 Nov 28 20:27:39 walrhel5 slapd[7447]: connection_read(10): checking for input on id=1000 Nov 28 20:27:39 walrhel5 slapd[7447]: op tag 0x60, time 1322508459 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=0 do_bind Nov 28 20:27:39 walrhel5 slapd[7447]: >>> dnPrettyNormal: <cn=metaguru,dc=meta,dc=pov> Nov 28 20:27:39 walrhel5 slapd[7447]: <<< dnPrettyNormal: <cn=metaguru,dc=meta,dc=pov>, <cn=metaguru,dc=meta,dc=pov> Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=0 BIND dn="cn=metaguru,dc=meta,dc=pov" method=128 Nov 28 20:27:39 walrhel5 slapd[7447]: do_bind: version=3 dn="cn=metaguru,dc=meta,dc=pov" method=128 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=0 meta_back_bind: dn="cn=metaguru,dc=meta,dc=pov". Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=0: rootdn="cn=metaguru,dc=meta,dc=pov" bind succeeded Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=0 BIND dn="cn=metaguru,dc=meta,dc=pov" mech=SIMPLE ssf=0 Nov 28 20:27:39 walrhel5 slapd[7447]: do_bind: v3 bind: "cn=metaguru,dc=meta,dc=pov" to "cn=metaguru,dc=meta,dc=pov" Nov 28 20:27:39 walrhel5 slapd[7447]: send_ldap_result: conn=1000 op=0 p=3 Nov 28 20:27:39 walrhel5 slapd[7447]: send_ldap_result: err=0 matched="" text="" Nov 28 20:27:39 walrhel5 slapd[7447]: send_ldap_response: msgid=1 tag=97 err=0 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=0 RESULT tag=97 err=0 text= Nov 28 20:27:39 walrhel5 slapd[7447]: connection_get(10) Nov 28 20:27:39 walrhel5 slapd[7447]: connection_get(10): got connid=1000 Nov 28 20:27:39 walrhel5 slapd[7447]: connection_read(10): checking for input on id=1000 Nov 28 20:27:39 walrhel5 slapd[7447]: op tag 0x63, time 1322508459 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 do_search Nov 28 20:27:39 walrhel5 slapd[7447]: >>> dnPrettyNormal: <dc=meta,dc=pov> Nov 28 20:27:39 walrhel5 slapd[7447]: <<< dnPrettyNormal: <dc=meta,dc=pov>, <dc=meta,dc=pov> Nov 28 20:27:39 walrhel5 slapd[7447]: SRCH "dc=meta,dc=pov" 0 3 Nov 28 20:27:39 walrhel5 slapd[7447]: 0 0 0 Nov 28 20:27:39 walrhel5 slapd[7447]: begin get_filter Nov 28 20:27:39 walrhel5 slapd[7447]: AND Nov 28 20:27:39 walrhel5 slapd[7447]: begin get_filter_list Nov 28 20:27:39 walrhel5 slapd[7447]: begin get_filter Nov 28 20:27:39 walrhel5 slapd[7447]: EQUALITY Nov 28 20:27:39 walrhel5 slapd[7447]: get_ava: illegal value for attributeType objectclass Nov 28 20:27:39 walrhel5 slapd[7447]: end get_filter 0 Nov 28 20:27:39 walrhel5 slapd[7447]: begin get_filter Nov 28 20:27:39 walrhel5 slapd[7447]: NOT Nov 28 20:27:39 walrhel5 slapd[7447]: begin get_filter Nov 28 20:27:39 walrhel5 slapd[7447]: EQUALITY Nov 28 20:27:39 walrhel5 slapd[7447]: get_ava: illegal value for attributeType objectclass Nov 28 20:27:39 walrhel5 slapd[7447]: end get_filter 0 Nov 28 20:27:39 walrhel5 slapd[7447]: end get_filter 0 Nov 28 20:27:39 walrhel5 slapd[7447]: end get_filter_list Nov 28 20:27:39 walrhel5 slapd[7447]: end get_filter 0 Nov 28 20:27:39 walrhel5 slapd[7447]: filter: (&(?objectClass=user)(!(?objectClass=Computer))) Nov 28 20:27:39 walrhel5 slapd[7447]: => get_ctrls Nov 28 20:27:39 walrhel5 slapd[7447]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) Nov 28 20:27:39 walrhel5 slapd[7447]: <= get_ctrls: n=1 rc=0 err="" Nov 28 20:27:39 walrhel5 slapd[7447]: attrs: Nov 28 20:27:39 walrhel5 slapd[7447]: Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 SRCH base="dc=meta,dc=pov" scope=0 deref=3 filter="(&(?objectClass=user)(!(?objectClass=Computer)))" Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1: meta_back_getconn[0] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1: meta_back_getconn[1] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 meta_back_getconn: candidates=2 conn=ROOTDN inserted Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_back_search_start[0] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_search_dobind_init[0] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_search_dobind_init[0]=4 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_back_search_start[0]=4 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_back_search_start[1] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_search_dobind_init[1] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_search_dobind_init[1]=4 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_back_search_start[1]=4 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 meta_back_search: ncandidates=2 cnd="**" Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_search_dobind_init[0] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_search_dobind_init[0]=2 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_search_dobind_init[1] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_search_dobind_init[1]=2 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_back_search_start[0] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_search_dobind_init[0] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_search_dobind_init[0]=1 Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_context_apply [depth=1] string='dc=meta,dc=pov' Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_rule_apply rule='((.+),)?dc=meta,[ ]?dc=pov$' string='dc=meta,dc=pov' [1 pass(es)] Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_context_apply [depth=1] res={0,'dc=adwal,dc=corporate,dc=net'} Nov 28 20:27:39 walrhel5 slapd[7447]: [rw] searchBase: "dc=meta,dc=pov" -> "dc=adwal,dc=corporate,dc=net" Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_context_apply [depth=1] string='(&(objectClass=user)(!(objectClass=Computer)))' Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Nov 28 20:27:39 walrhel5 slapd[7447]: [rw] searchFilter: "(&(objectClass=user)(!(objectClass=Computer)))" -> "(&(objectClass=user)(!(objectClass=Computer)))" Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_back_search_start[0]=1 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_back_search_start[1] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 >>> meta_search_dobind_init[1] Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_search_dobind_init[1]=1 Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_context_apply [depth=1] string='dc=meta,dc=pov' Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_rule_apply rule='((.+),)?dc=meta,[ ]?dc=pov$' string='dc=meta,dc=pov' [1 pass(es)] Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_context_apply [depth=1] res={0,'dc=second,dc=crocus,dc=com'} Nov 28 20:27:39 walrhel5 slapd[7447]: [rw] searchBase: "dc=meta,dc=pov" -> "dc=second,dc=crocus,dc=com" Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_context_apply [depth=1] string='(&(objectClass=user)(!(objectClass=Computer)))' Nov 28 20:27:39 walrhel5 slapd[7447]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Nov 28 20:27:39 walrhel5 slapd[7447]: [rw] searchFilter: "(&(objectClass=user)(!(objectClass=Computer)))" -> "(&(objectClass=user)(!(objectClass=Computer)))" Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 <<< meta_back_search_start[1]=1 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 meta_back_search[0] match="" err=0. Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 meta_back_search[1] match="" err=0. Nov 28 20:27:39 walrhel5 slapd[7447]: send_ldap_result: conn=1000 op=1 p=3 Nov 28 20:27:39 walrhel5 slapd[7447]: send_ldap_result: err=0 matched="" text="" Nov 28 20:27:39 walrhel5 slapd[7447]: send_ldap_response: msgid=2 tag=101 err=0 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Nov 28 20:27:39 walrhel5 slapd[7447]: connection_get(10) Nov 28 20:27:39 walrhel5 slapd[7447]: connection_get(10): got connid=1000 Nov 28 20:27:39 walrhel5 slapd[7447]: connection_read(10): checking for input on id=1000 Nov 28 20:27:39 walrhel5 slapd[7447]: op tag 0x42, time 1322508459 Nov 28 20:27:39 walrhel5 slapd[7447]: ber_get_next on fd 10 failed errno=0 (Success) Nov 28 20:27:39 walrhel5 slapd[7447]: connection_read(10): input error=-2 id=1000, closing. Nov 28 20:27:39 walrhel5 slapd[7447]: connection_closing: readying conn=1000 sd=10 for close Nov 28 20:27:39 walrhel5 slapd[7447]: connection_close: deferring conn=1000 sd=10 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=2 do_unbind Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 op=2 UNBIND Nov 28 20:27:39 walrhel5 slapd[7447]: connection_resched: attempting closing conn=1000 sd=10 Nov 28 20:27:39 walrhel5 slapd[7447]: connection_close: conn=1000 sd=10 Nov 28 20:27:39 walrhel5 slapd[7447]: =>meta_back_conn_destroy: fetching conn=1000 DN="cn=metaguru,dc=meta,dc=pov" Nov 28 20:27:39 walrhel5 slapd[7447]: daemon: removing 10 Nov 28 20:27:39 walrhel5 slapd[7447]: conn=1000 fd=10 closed Where is my mistake ? Can you help me please Kind regards Waldemar

1 0

Re: Unable to login on client nodes.
by Raffael Sahli 29 Nov '11

29 Nov '11

On 11/29/2011 07:00 AM, Jayavant Patil wrote: > > > On Mon, Nov 28, 2011 at 4:49 PM, Raffael Sahli > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote: > > On 11/28/2011 11:38 AM, Jayavant Patil wrote: >> >> >> On Mon, Nov 28, 2011 at 3:43 PM, Raffael Sahli >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote: >> >> >>Hi >> >> >> >>>but $cat /etc/shadow doesn't show any password information >> for user ldap_6. So, how do I know that userPassword >> attribute information is getting propagated to client nodes? >> >> >>/etc/shadow is only for local user accounts. >> >> >> >>su ldap_6 works? >> >> yes, su ldap_6 works. > > >How did you test that? With root acceess? > > From server machine > [root@server]$ssh root@n20 > [root@n20]$su ldap_6 > it doesn't ask password and switches to ldap_6 > [ldap_6@n20]$ Yes, it doesn't ask with root access, test it with a non root account...Then you should see a password prompt, and check the authentification syslog! You should see some PAM entries.... > On client node > $getent passwd shows > ldap_6:x:514:514:ldap_6:/home/ldap_6:/bin/bash > > $getent shadow shows > ldap_6:*:13998::99999:7::: > > That means password is not getting propagated. So, how to sync up the password? Thats correct, you don't have to sync the passwords! The password is only stored in the ldap tree. I guess with NSS everything is fine, you should check your pam log entries! > > >Test it with a normal user, so you have to enter a password for > the ldap account > > > I have set password for user ldap_6 with ldappasswd command and > userPassword attribute shows the hash of it when I do ldapsearch for > ldap_6. > > Why the password for ldap_6 is not getting propagated to client > nodes? Because of which I am unable to do $ssh > ldap_6@<client-node-name> from server node. > > > > >And kill the nscd daemon for ldap tests. > > > >> >> >Pam LDAP libraries installed and configured? >> >> nss_ldap and pam_ldap installed. >> >> >ldapsearch bind works? >> >> ldapsearch works on client nodes. >> >> >> >> >SSH Debug log? >> >> >> OpenSSH_5.3p1, OpenSSL 1.0.0a-fips 1 Jun 2010 >> debug1: Reading configuration data /root/.ssh/config >> debug1: Reading configuration data /etc/ssh/ssh_config >> debug1: Applying options for * >> debug1: Connecting to n20 port 22. >> debug1: Connection established. >> debug1: permanently_set_uid: 0/0 >> debug1: identity file /root/.ssh/identity type -1 >> debug1: identity file /root/.ssh/id_rsa type 1 >> debug1: identity file /root/.ssh/id_dsa type -1 >> debug1: Remote protocol version 2.0, remote software version >> OpenSSH_5.3 >> debug1: match: OpenSSH_5.3 pat OpenSSH* >> debug1: Enabling compatibility mode for protocol 2.0 >> debug1: Local version string SSH-2.0-OpenSSH_5.3 >> debug1: SSH2_MSG_KEXINIT sent >> debug1: SSH2_MSG_KEXINIT received >> debug1: kex: server->client aes128-ctr hmac-md5 none >> debug1: kex: client->server aes128-ctr hmac-md5 none >> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent >> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP >> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent >> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY >> debug1: Host 'n20' is known and matches the RSA host key. >> debug1: Found key in /root/.ssh/known_hosts:3 >> debug1: ssh_rsa_verify: signature correct >> debug1: SSH2_MSG_NEWKEYS sent >> debug1: expecting SSH2_MSG_NEWKEYS >> debug1: SSH2_MSG_NEWKEYS received >> debug1: SSH2_MSG_SERVICE_REQUEST sent >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> debug1: Authentications that can continue: >> publickey,gssapi-keyex,gssapi-with-mic,password >> debug1: Next authentication method: gssapi-with-mic >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> Credentials cache file '/tmp/krb5cc_0' not found >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> Credentials cache file '/tmp/krb5cc_0' not found >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> >> debug1: Next authentication method: publickey >> debug1: Trying private key: /root/.ssh/identity >> debug1: Offering public key: /root/.ssh/id_rsa >> debug1: Authentications that can continue: >> publickey,gssapi-keyex,gssapi-with-mic,password >> debug1: Trying private key: /root/.ssh/id_dsa >> debug1: Next authentication method: password >> ldap_6@n20's password: >> >> > > > Öhm, We need the server side log entries... And with debug log level > ? > > > >> >> >> >> >> -- >> Raffael Sahli >> public(a)raffaelsahli.com <mailto:public@raffaelsahli.com> >> >> >> >> >> On 11/28/2011 09:49 AM, Jayavant Patil wrote: >> >> Hi, >> >> I am using openLDAP-2.4.19-4 on fedora 12 machine. I >> have done all server and client configurations. The >> directory containing user information is getting >> available on client nodes(checked by $getent passwd) but >> I am unable to do >> >> $ssh <user-name>@client-node-name >> >> it shows >> Permission denied >> (publickey,gssapi-keyex,gssapi-with-mic,password). >> >> My client node .ssh/config file contents are as follows: >> >> ForwardX11 yes >> StrictHostKeyChecking no >> FallBackToRsh no >> BatchMode yes >> ConnectionAttempts 5 >> UsePrivilegedPort no >> Compression no >> Cipher blowfish >> UserKnownHostsFile /dev/null >> CheckHostIP no >> >> >> Even I am unable to login on the client node from >> console(i.e. from client node login window itself), it >> shows authentication failure message. >> >> On client node with $getent passwd, it shows >> >> ldap_6:x:514:514:ldap_6:/home/ldap_6:/bin/bash >> >> but $cat /etc/shadow doesn't show any password >> information for user ldap_6. So, how do I know that >> userPassword attribute information is getting propagated >> to client nodes? >> >> >> >> >> -- >> >> Thanks & Regards, >> Jayavant Ningoji Patil >> Engineer: System Software >> Computational Research Laboratories Ltd. >> Pune-411 004. >> Maharashtra, India. >> +91 9923536030. >> >> >> >> >> -- >> >> Thanks & Regards, >> Jayavant Ningoji Patil >> Engineer: System Software >> Computational Research Laboratories Ltd. >> Pune-411 004. >> Maharashtra, India. >> +91 9923536030. >> > > > -- > Raffael Sahli > public(a)raffaelsahli.com <mailto:public@raffaelsahli.com> > > > > > -- > > Thanks & Regards, > Jayavant Ningoji Patil > Engineer: System Software > Computational Research Laboratories Ltd. > Pune-411 004. > Maharashtra, India. > +91 9923536030. > -- Raffael Sahli public(a)raffaelsahli.com

1 0

Syncrepl error causes consumers to freeze
by Nick Milas 28 Nov '11

28 Nov '11

Hi, I am using 2.4.26 on syncrepl master (provider) (package on CentOS 5.7 x86_64) and 2.4.22, 2.4.26 on two consumers respectively. Last night, I edited a user account (hosted in LDAP) and when this tried to replicate to two consumers, both froze. This did not happen on another consumer (also 2.4.26) which was using replication over the Manager account. The two ones which froze are using a limited-privileged BindDN for replication which does not have access to user accounts (so, the user account should/would not be replicated on those two consumers). On the master: Nov 23 23:12:04 ldap slapd[2295]: syncprov_sendresp: cookie=rid=333,csn=20111123211204.601542Z#000000#000#000000 Nov 23 23:12:04 ldap slapd[2295]: syncprov_sendresp: cookie=rid=222,csn=20111123211204.601542Z#000000#000#000000 On slave 222: Nov 23 23:12:04 vdns slapd2.4[2145]: do_syncrep2: rid=222 cookie=rid=222,csn=20111123211204.601542Z#000000#000#000000 Nov 23 23:12:04 vdns slapd2.4[2145]: syncrepl_entry: rid=222 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Nov 23 23:12:04 vdns slapd2.4[2145]: syncrepl_entry: rid=222 be_search (0) Nov 23 23:12:04 vdns slapd2.4[2145]: syncrepl_entry: rid=222 uid=userx,ou=people,dc=example,dc=com Nov 23 23:12:04 vdns slapd2.4[2145]: slap_queue_csn: queing 0x2aaab0019970 20111123211204.601542Z#000000#000#000000 and /var/log/messages: Nov 23 23:12:04 vdns kernel: slapd2.4[2164]: segfault at 00000001075c61a8 rip 0000000000480ecb rsp 00000000424e04c0 error 4 On slave 333: Nov 23 23:12:04 dns2 slapd[2364]: do_syncrep2: rid=333 cookie=rid=333,csn=20111123211204.601542Z#000000#000#000000 Nov 23 23:12:04 dns2 slapd[2364]: syncrepl_entry: rid=333 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Nov 23 23:12:04 dns2 slapd[2364]: syncrepl_entry: rid=333 be_search (0) Nov 23 23:12:04 dns2 slapd[2364]: syncrepl_entry: rid=333 uid=userx,ou=people,dc=example,dc=com Nov 23 23:12:04 dns2 slapd[2364]: slap_queue_csn: queing 0x19e8cfa0 20111123211204.601542Z#000000#000#000000 and /var/log/messages: Nov 23 23:12:04 dns2 kernel: slapd[2736] general protection rip:4b5342 rsp:43c54530 error:0 I have not seen this behavior in months and months of use. Any advice? Thanks, Nick

4 6

Re: Unable to login on client nodes.
by Raffael Sahli 28 Nov '11

28 Nov '11

On 11/28/2011 11:38 AM, Jayavant Patil wrote: > > > On Mon, Nov 28, 2011 at 3:43 PM, Raffael Sahli > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote: > > >Hi > > > >>but $cat /etc/shadow doesn't show any password information for > user ldap_6. So, how do I know that userPassword attribute > information is getting propagated to client nodes? > > >/etc/shadow is only for local user accounts. > > > >su ldap_6 works? > > yes, su ldap_6 works. How did you test that? With root acceess? Test it with a normal user, so you have to enter a password for the ldap account And kill the nscd daemon for ldap tests. > > >Pam LDAP libraries installed and configured? > > nss_ldap and pam_ldap installed. > > >ldapsearch bind works? > > ldapsearch works on client nodes. > > > > >SSH Debug log? > > > OpenSSH_5.3p1, OpenSSL 1.0.0a-fips 1 Jun 2010 > debug1: Reading configuration data /root/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Connecting to n20 port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/0 > debug1: identity file /root/.ssh/identity type -1 > debug1: identity file /root/.ssh/id_rsa type 1 > debug1: identity file /root/.ssh/id_dsa type -1 > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 > debug1: match: OpenSSH_5.3 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.3 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-ctr hmac-md5 none > debug1: kex: client->server aes128-ctr hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Host 'n20' is known and matches the RSA host key. > debug1: Found key in /root/.ssh/known_hosts:3 > debug1: ssh_rsa_verify: signature correct > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic,password > debug1: Next authentication method: gssapi-with-mic > debug1: Unspecified GSS failure. Minor code may provide more information > Credentials cache file '/tmp/krb5cc_0' not found > > debug1: Unspecified GSS failure. Minor code may provide more information > Credentials cache file '/tmp/krb5cc_0' not found > > debug1: Unspecified GSS failure. Minor code may provide more information > > > debug1: Next authentication method: publickey > debug1: Trying private key: /root/.ssh/identity > debug1: Offering public key: /root/.ssh/id_rsa > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic,password > debug1: Trying private key: /root/.ssh/id_dsa > debug1: Next authentication method: password > ldap_6@n20's password: > > Öhm, We need the server side log entries... And with debug log level > > > > > -- > Raffael Sahli > public(a)raffaelsahli.com <mailto:public@raffaelsahli.com> > > > > > On 11/28/2011 09:49 AM, Jayavant Patil wrote: > > Hi, > > I am using openLDAP-2.4.19-4 on fedora 12 machine. I have > done all server and client configurations. The directory > containing user information is getting available on client > nodes(checked by $getent passwd) but I am unable to do > > $ssh <user-name>@client-node-name > > it shows > Permission denied > (publickey,gssapi-keyex,gssapi-with-mic,password). > > My client node .ssh/config file contents are as follows: > > ForwardX11 yes > StrictHostKeyChecking no > FallBackToRsh no > BatchMode yes > ConnectionAttempts 5 > UsePrivilegedPort no > Compression no > Cipher blowfish > UserKnownHostsFile /dev/null > CheckHostIP no > > > Even I am unable to login on the client node from console(i.e. > from client node login window itself), it shows authentication > failure message. > > On client node with $getent passwd, it shows > > ldap_6:x:514:514:ldap_6:/home/ldap_6:/bin/bash > > but $cat /etc/shadow doesn't show any password information for > user ldap_6. So, how do I know that userPassword attribute > information is getting propagated to client nodes? > > > > > -- > > Thanks & Regards, > Jayavant Ningoji Patil > Engineer: System Software > Computational Research Laboratories Ltd. > Pune-411 004. > Maharashtra, India. > +91 9923536030. > > > > > -- > > Thanks & Regards, > Jayavant Ningoji Patil > Engineer: System Software > Computational Research Laboratories Ltd. > Pune-411 004. > Maharashtra, India. > +91 9923536030. > -- Raffael Sahli public(a)raffaelsahli.com

1 0

per-dn limits
by Markus Wernig 28 Nov '11

28 Nov '11

Hello all I do not seem to be able to get per-dn limits working ... openldap-2.4.25 on Solaris 11 x86 I have put the following in slapd.conf: limits dn.exact="cn=repl_ldap,dc=domain,dc=com" size=unlimited time=unlimited access to * by dn="cn=repl_ldap,dc=domain,dc=com" read ... (obviously the syncrepl user ;-) and also: syncrepl rid=1 ... sizelimit="unlimited" timelimit="unlimited" searchbase="dc=domain,dc=com" binddn="n=repl_ldap,dc=domain,dc=com" on the consumer side But the DN always gets a maximum of 500 entries, whether using ldapsearch or during replication: # ldapsearch -x -h localhost '(objectClass=*)' -D"cn=repl_ldap,dc=domain,dc=com" -W -b "dc=domain,dc=com" Enter LDAP Password:XXXX [...] # search result search: 2 result: 4 Size limit exceeded # numResponses: 501 # numEntries: 500 While there are ~700 entries in the directory. The same happens during replication, where only 500 entries are synced to the consumer (eg. if I delete the local DB on the consumer and restart slapd) Only if I set ... sizelimit unlimited timelimit unlimited ... globally in the provider's slapd.conf (i.e. before any database definition), does repl_ldap receive all entries. Is there anything else I need to configure in order to allow the DN access to all entries? thx /markus PS: I have also tried different variants of the following: limits dn.exact="cn=repl_ldap,dc=domain,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

2 3

Re: Unable to login on client nodes.
by Raffael Sahli 28 Nov '11

28 Nov '11

Hi >but $cat /etc/shadow doesn't show any password information for user ldap_6. So, how do I know that userPassword attribute information is getting propagated to client nodes? /etc/shadow is only for local user accounts. su ldap_6 works? Pam LDAP libraries installed and configured? ldapsearch bind works? SSH Debug log? -- Raffael Sahli public(a)raffaelsahli.com On 11/28/2011 09:49 AM, Jayavant Patil wrote: > Hi, > > I am using openLDAP-2.4.19-4 on fedora 12 machine. I have done all > server and client configurations. The directory containing user > information is getting available on client nodes(checked by $getent > passwd) but I am unable to do > > $ssh<user-name>@client-node-name > > it shows > Permission denied > (publickey,gssapi-keyex,gssapi-with-mic,password). > > My client node .ssh/config file contents are as follows: > > ForwardX11 yes > StrictHostKeyChecking no > FallBackToRsh no > BatchMode yes > ConnectionAttempts 5 > UsePrivilegedPort no > Compression no > Cipher blowfish > UserKnownHostsFile /dev/null > CheckHostIP no > > > Even I am unable to login on the client node from console(i.e. from > client node login window itself), it shows authentication failure message. > > On client node with $getent passwd, it shows > > ldap_6:x:514:514:ldap_6:/home/ldap_6:/bin/bash > > but $cat /etc/shadow doesn't show any password information for user > ldap_6. So, how do I know that userPassword attribute information is > getting propagated to client nodes? > > > > > -- > > Thanks& Regards, > Jayavant Ningoji Patil > Engineer: System Software > Computational Research Laboratories Ltd. > Pune-411 004. > Maharashtra, India. > +91 9923536030. >

1 0

Unable to login on client nodes.
by Jayavant Patil 28 Nov '11

28 Nov '11

Hi, I am using openLDAP-2.4.19-4 on fedora 12 machine. I have done all server and client configurations. The directory containing user information is getting available on client nodes(checked by $getent passwd) but I am unable to do $ssh <user-name>@client-node-name it shows Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). My client node .ssh/config file contents are as follows: ForwardX11 yes StrictHostKeyChecking no FallBackToRsh no BatchMode yes ConnectionAttempts 5 UsePrivilegedPort no Compression no Cipher blowfish UserKnownHostsFile /dev/null CheckHostIP no Even I am unable to login on the client node from console(i.e. from client node login window itself), it shows authentication failure message. On client node with $getent passwd, it shows ldap_6:x:514:514:ldap_6:/home/ldap_6:/bin/bash but $cat /etc/shadow doesn't show any password information for user ldap_6. So, how do I know that userPassword attribute information is getting propagated to client nodes? -- Thanks & Regards, Jayavant Ningoji Patil Engineer: System Software Computational Research Laboratories Ltd. Pune-411 004. Maharashtra, India. +91 9923536030.

1 0

OpenLDAP 2.4.27 RPMs available on LTB-project
by Clément OUDOT 28 Nov '11

28 Nov '11

Hello, I built today RPMs for OpenLDAP 2.4.27, for those who are interested, they are available here: http://ltb-project.org/wiki/download#openldap You can find the description of the RPMs here: http://ltb-project.org/wiki/documentation/openldap-rpm They include an init script described here: http://ltb-project.org/wiki/documentation/openldap-initscript Hope it helps, Clément.

3 3

OpenLDAP Statistics
by Felip Moll 25 Nov '11

25 Nov '11

Hello all, I am new to this list and I would like to ask you a question regarding OpenLDAP. The fact is that I have an OpenLDAP server that receive a lot of operations every day. I have different kind of services that make use of LDAP and bind to this server. In a particular case, there are an ou=Users that contain approx. 200 users with their attributes. I am using also a private LDAP schema developed by me in which I have some extra attributes. Recently we have managed an audit promoted by our government in which a lot of security items had been checked and corrected if had found some issue. One of this security checks was about the management of user passowrds and an other regarding to user accounts. The first one could be satisfied by implementing the ppolicy overlay in LDAP. But in the second one, the audit people imposed us to have a control of which accounts were not being used in the last year, and to delete/backup/etc them if it were the case. The fact is that I searched for ways of gathering statistics of account usage. The alternatives that I found were: First, save the statistics in 2 attributes in each user: lastBind, failedBinds. 1. For each service, whenever a bind from a user has done to LDAP, send a ldapmodify operation for this user and if the bind was successful, write in user.lastBind the timestamp. If it was not, increment failedBinds++. It implies the modification of each service, taking in account that all has to be documented, that in many services the implementation is not trivial, and also taking care of the upgrades of the services. In conclusion, a lot of work and constant modifications and checks. 2. Act on the LDAP server and activate the "overlay accesslog" funcionality. In this case, monitor every bind operation, then create a daemon that reads every X time the LDAP accesslog tree and process it. For each entry processed: - Delete it from the ldap accesslog tree. - Check if the reqResult was 49 (invalid creds.) or 0 (success). - If it was 49, ldapsearch the reqDN who made the bind request, and read his failedBins attribute. Increment it in one, and send a ldapmodify to the user and with the new value of failedBinds. - If it was 0, ldapmodify the reqDN setting the lastBind as reqEnd. I programmed it in C++ and ldapc++ library, and it works. But the fact is that I am not convinced of this solution. It saved us from the audit but for the future there are some problems to take into account: - Deleting the ldap entry every time it's read is bad, because then we cannot use the overlay for delta syncrepl. - Every 10 minutes, ldap deletes the oldest entries, making that in some cases my dameon can fail (treated with an exception, but not cool). - 3000 binds / 10 minutes in normal hours. Up to 40.000 binds in one Monday morning. My question is obvious. Is there any way other than the daemon, the first option, or suicide, to accomplish the requeriments of the audit? How does a big company to register the last bind of every user account, if this account can use many different and heterogenous services? (VPN, FTP, WEBs, propietary software, Windows samba, Linux login, etc.) Best regards, sorry for my bad english and for my big post!. Felip Moll

4 6

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2011