multi-byte utf8 characters in DNs
by Chris Card
[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
9 years, 4 months
CUCM search
by W.Siebert＠t-systems.com
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
9 years, 4 months
Re: Unable to login on client nodes.
by Raffael Sahli
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
9 years, 4 months
Syncrepl error causes consumers to freeze
by Nick Milas
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
9 years, 4 months
Re: Unable to login on client nodes.
by Raffael Sahli
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
9 years, 4 months
per-dn limits
by Markus Wernig
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
9 years, 4 months
Re: Unable to login on client nodes.
by Raffael Sahli
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.
>
9 years, 4 months
Unable to login on client nodes.
by Jayavant Patil
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.
9 years, 4 months
OpenLDAP Statistics
by Felip Moll
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
9 years, 4 months
