openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Re: CUCM search
by masarati＠aero.polimi.it 30 Nov '11

30 Nov '11

> Hello, > > I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD > targets. ... > Nov 28 20:27:39 walrhel5 slapd[7447]: filter: > (&(?objectClass=user)(!(?objectClass=Computer))) The objectClasses "user" and "computer" are unknown. They need to be defined in the proxy's schema. p.

3 2

Read/Write Replication setup
by benoit 29 Nov '11

29 Nov '11

Hello, I have setup a ldap replicate, replicating data from an offsite ldap master. Replication is ok, but being a consumer replicate, my ldap server is read only. I need to add and modify attributes to this replicate, but i have no write access to the master and ldap master admin won't change/update schemas... >From the guide, i can't figure if it's possible. Please, let me know what solution i have (on any Linux distro). thanks Ben,

3 4

Trust between two server
by Raffael Sahli 29 Nov '11

29 Nov '11

Hi I have a huge openldap server and a small one with maybe 10 users. The small one contains it admistrator objects (or most of them are admins) and is complitly different from the huge one. So what I want is to include some userobjects or a specific basedn from the small one in the huge one. Im not sure whats the best way for that, maybe meta backend..? or some proxy auth points to the small one.. dc=hugeldap,dc=com |-ou=users |-ou=admins |->point to ldap://ldapserver.com?dc=smallldap,dc=net/memberof=hugeldap Thanks for your help -- Raffael Sahli public(a)raffaelsahli.com

2 1

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 28 Nov '11

28 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical