openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Fwd: user removed from ldap group but Linux groups command still shows user as member of the group
by Bernard Fay 24 Feb '17

24 Feb '17

On Fri, Feb 24, 2017 at 9:08 AM, Dan White <dwhite(a)cafedemocracy.org> wrote: > On 02/24/17 08:55 -0500, Bernard Fay wrote: > >> I removed a user from an LDAP group about a week ago. Today, this user >> still shows as member of the group with the Linux command groups. Also, >> the >> group (Administrators) appears twice in the output of the command id: >> uid=10000(username) gid=10000(Administrators) >> groups=10001(users),10005(devel),10011(video),10015(ansible) >> ,10000(Administrators) >> >> The command getent though shows the proper group assignation: >> getent group | grep username | cut -d: -f1 >> users >> devel >> video >> ansible >> >> All of those groups are LDAP group. >> > > Is this from a long running shell? If so, start a new shell or > run newgrp. > > Otherwise, verify that it is not cached (such as with nscd), and trouble > shoot as an nss ldap problem. > > No, it is not from a long running shell. I logged out and logged back in since I remove this user from the group. By the way the group in question is Administrators. How can I verify it is not cached? My guess is that it is cached. I tried to use "nscd -i group" but that did not change anything.

1 0

Long ldap session when ldap server failover
by Huynh Phuoc Tai 24 Feb '17

24 Feb '17

Hi, I have an issue with long ldap session when ldap server failover. [01/Dec/2016:11:34:29 +0100] conn=7187095 op=-1 msgId=-1 - fd=89 slot=89 LDAPS connection from 10.14.97.45:55287 to 113.216.102.167 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=-1 msgId=-1 - SSL 128-bit AES-128; client CN=HRM3; issuer O=E,OU=eOAM,CN=jerarm003NECertCA [01/Dec/2016:11:34:29 +0100] conn=7187095 op=-1 msgId=-1 - SSL failed to map client certificate to LDAP DN (No such object) [01/Dec/2016:11:34:29 +0100] conn=7187095 op=0 msgId=1 - BIND dn="cn=ProxyUser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com" method=128 version=3 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=proxyuser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com" [01/Dec/2016:11:34:29 +0100] conn=7187095 op=1 msgId=2 - SRCH base="dc=jerarm,dc=roma,dc=te,dc=com" scope=2 filter="(&(&(objectClass=posixAccount)(|(eUserAuthenticationScope=HLRALL)(eUserAuthenticationScope=HRM3)(eUserAuthenticationScope=\2a)))(&(objectClass=posixAccount)(|(eUserAuthenticationScope=HLRALL)(eUserAuthenticationScope=HRM3)(eUserAuthenticationScope=\2a)))(uid=us000001))" attrs=ALL [01/Dec/2016:11:34:29 +0100] conn=7187095 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=2 msgId=3 - BIND dn="uid=us000001,ou=people,dc=jerarm,dc=roma,dc=te,dc=com" method=128 version=3 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=2 msgId=3 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=us000001,ou=people,dc=jerarm,dc=roma,dc=te,dc=com" [01/Dec/2016:11:34:29 +0100] conn=7187095 op=3 msgId=4 - BIND dn="cn=ProxyUser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com" method=128 version=3 [01/Dec/2016:11:34:29 +0100] conn=7187095 op=3 msgId=4 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=proxyuser,ou=proxyagent,ou=com,dc=jerarm,dc=roma,dc=te,dc=com" [01/Dec/2016:11:40:01 +0100] conn=7187095 op=4 msgId=5 - UNBIND [01/Dec/2016:11:40:01 +0100] conn=7187095 op=4 msgId=-1 - closing from 10.14.97.45:55287 - U1 - Connection closed by unbind client - [01/Dec/2016:11:40:01 +0100] conn=7187095 op=-1 msgId=-1 - closed. The openldap client didn't send UNBIND soon but sent after several minutes. Could you suggest me any way forward to find the root cause?openldap2-client-2.4.26-0.62.2 Regards,Tai

1 0

Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount 23 Feb '17

23 Feb '17

--On Friday, February 17, 2017 2:44 PM -0800 "Paul B. Henson" <henson(a)acm.org> wrote: > On Thu, Feb 16, 2017 at 03:53:40PM -0800, Quanah Gibson-Mount wrote: > >> It appears to be crashing while writing the change to the accesslog >> database. It's odd that the value for the attribute is NULL. Do we >> know for sure what the client doing the write op to the server is >> sending? > > The code is in perl, and looks like this: > > $entry->replace(eduPersonAffiliation => \@eduPersonAffiliation); > > In this case, the array @eduPersonAffiliation is empty, effectively > deleting the attribute. I'm not 100% sure what this generates on the > wire, I'd have to debug it. I can say it's the same code that's been > running for a decade or so with no issues. Ok, I can see if I can reproduce something like this. Do you have a link to the schema file in use that adds this attribute? Also, can you confirm your patch matches <https://github.com/Zimbra/packages/blob/master/thirdparty/openldap/patches/…> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Valgrind detecting memory leak on 2-way multi master setup on RHEL 6 - openldap 2.4.44
by ping-shin ching 22 Feb '17

22 Feb '17

Regarding this issue - our production servers are getting affected. Any help is greatly appreciated. Is there anything I can try? http://www.openldap.org/lists/openldap-technical/201702/msg00090.html Regards, Ping PS: I've lost some of my emails - so don't have the email chain

2 2

Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount 21 Feb '17

21 Feb '17

--On Tuesday, February 21, 2017 1:04 PM +0000 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > Years ago, I had code that did that and then I got a version of Net::LDAP > that sent null attributes across the wire. Even back then OpenLDAP was > upset by such behavior. I quickly updated my code to check if (in your > case) @eduPersonAffiliation had zero entries and issue a proper > $entry->delete('eduPersonAffiliation') call in that case. I've not had > any issues since. Perhaps, your Net::LDAP module version has changed and > it is sending what is being logged across the wire instead of the delete > you are expecting. Interesting... It would still be good for OpenLDAP to not crash in that case, however. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: syncrepl skipped entryCSN on openldap-2.4.44 on centos 6
by Quanah Gibson-Mount 21 Feb '17

21 Feb '17

--On Saturday, February 18, 2017 9:57 AM +0800 Daniel Jung <mimianddaniel(a)gmail.com> wrote: >> Do you mean contextCSNs? > No. ContextCSN is up to date. But some entries have old entryCSN compared > to the master. >> >> >>> I haven't been able to track the cause nor see anything in the log to >>> indicate the problem. However, we have had slapd become non-responsive >>> due to IO blocking on logging. Could this cause syncrepl to miss >>> updating the entries? Has anyone seen this behaviour? >> >> >> If slapd gets locked up, hard to say what the side effects could be. >> Do you have stats+sync logging enabled on all of the systems? > I do have stats and sync enabled. Well, theoretically slapd shouldn't lose changes, but it's really hard to know the full ramifications/effects in this scenario. You can file an ITS on the issue, for tracking, but it may be some time before it's investigated in depth, as it's not a common scenario. I guess it may be possible to emulate it by using iptables to drop packages from rsyslogd. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: syncrepl skipped entryCSN on openldap-2.4.44 on centos 6
by Howard Chu 19 Feb '17

19 Feb '17

Daniel Jung wrote: > Hi Quanah, > > Speaking of logging, is openldap-3 going to support udp based logging? I saw > while back that there is improved? syslog code that we can compile in the src. > I was thinking of just adding udp into that code and test it out. I have no plans to add UDP support. Could be done, but what's the benefit? If you want to add it, feel free to submit a patch. > > > On Feb 18, 2017 09:57, "Daniel Jung" <mimianddaniel(a)gmail.com > <mailto:mimianddaniel@gmail.com>> wrote: > > On Feb 18, 2017 05:41, "Quanah Gibson-Mount" <quanah(a)symas.com > <mailto:quanah@symas.com>> wrote: > > > > --On Friday, February 17, 2017 5:46 PM +0800 Daniel Jung > <mimianddaniel(a)gmail.com <mailto:mimianddaniel@gmail.com>> wrote: > > > >> > >> Hi, > >> > >> > >> I see that some entryCSN have not been synced properly with the > >> provider. > >> I run multimaster setup and with several slaves and sometimes i see that > >> some slaves have old entryCSNs and I am syncing them manually with -c > >> option. > > > > > > Do you mean contextCSNs? > No. ContextCSN is up to date. But some entries have old entryCSN compared > to the master. > > > > > >> I haven't been able to track the cause nor see anything in the log to > >> indicate the problem. However, we have had slapd become non-responsive > >> due to IO blocking on logging. Could this cause syncrepl to miss updating > >> the entries? Has anyone seen this behaviour? > > > > > > If slapd gets locked up, hard to say what the side effects could be. Do > you have stats+sync logging enabled on all of the systems? > I do have stats and sync enabled. > > > > --Quanah > > > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <http://www.symas.com> > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Re: syncrepl skipped entryCSN on openldap-2.4.44 on centos 6
by Daniel Jung 19 Feb '17

19 Feb '17

On Feb 18, 2017 05:41, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > > --On Friday, February 17, 2017 5:46 PM +0800 Daniel Jung < mimianddaniel(a)gmail.com> wrote: > >> >> Hi, >> >> >> I see that some entryCSN have not been synced properly with the >> provider. >> I run multimaster setup and with several slaves and sometimes i see that >> some slaves have old entryCSNs and I am syncing them manually with -c >> option. > > > Do you mean contextCSNs? No. ContextCSN is up to date. But some entries have old entryCSN compared to the master. > > >> I haven't been able to track the cause nor see anything in the log to >> indicate the problem. However, we have had slapd become non-responsive >> due to IO blocking on logging. Could this cause syncrepl to miss updating >> the entries? Has anyone seen this behaviour? > > > If slapd gets locked up, hard to say what the side effects could be. Do you have stats+sync logging enabled on all of the systems? I do have stats and sync enabled. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 1

slapo-rwm How to define order that Rewrite Contexts are processed
by Lowrie, Paul, Vodafone NZ 18 Feb '17

18 Feb '17

Hi I've been asked to configure a SLAPD/LDAP proxy with more than one LDAP Back-End. The users log into the LDAP client using their email address and the proxy uses the domain part of their UID to decide which slapd-ldap back-end to authenticate against. I have the proxy working - with two defined slapd-ldap back-ends. It's tested and works with one back-end at a time. I need rwm to process a rewrite of both the searchFilter and searchDN using a key piece of information identified the searchFilter to decide the searchDN. Original searchDN = "ou=people,ou=my,dc=proxy,dc=com" Original searchFilter="(&(objectClass=posixAccount)(uid=john(a)domain.one.com))" Rewritten searchDN = "ou=people,ou=domain,dc=one,dc=com" Rewritten searchFilter = "(&(objectClass=posixAccount)(uid=john))" I have: dn: olcOverlay={0}rwm,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmNormalizeMapped: FALSE olcRwmRewrite: {0}rwm-rewriteEngine on # #Unix LDAP authentication requests arrive with these three components: # searchDN: OU=people,DC=my,DC=proxy,DC=com - as defined on the LDAP client # searchFilter: (&(objectClass=posixAccount)(uid=john(a)domain.one.com)) # attributes: userPassword cn gidNumber uidNumber # loginShell objectClass gecos uid homeDirectory # # {1} searchFilter Context: # {2} rewrite john(a)domain.one.com: # Strip @domain.one.com part and set &&target to OU=people,DC=domain,DC=one,DC=com # {3} rewrite jane(a)domain.two.com: # Strip @domain.two.com part and set &&target to OU=people,DC=domain,DC=two,DC=com # {4} searchDN Context: # {5} rewrite OU=people,DC=my,DC=proxy,DC=com the value already defined in &&target # olcRwmRewrite: {1}rwm-rewriteContext SearchFilter # olcRwmRewrite: {2}rwm-rewriteRule "^(.+uid=[^,]+)(a)domain.one.com(,.*)$" "${&&target(\"ou=people,dc=domain,dc=one,dc=com\")}$1$2" ":" # olcRwmRewrite: {3}rwm-rewriteRule "^(.+uid=[^,]+)(a)domain.two.com(,.*)$" "${&&target(\"ou=people,dc=domain,dc=two,dc=com\")}$1$2" ":" # olcRwmRewrite: {4}rwm-rewriteContext searchDN # olcRwmRewrite: {5}rwm-rewriteRule "OU=people,[ ]?DC=my,[ ]?DC=proxy,[ ]?DC=com " "${**target}" ":" This results in a slapd crash because searchDN wants to use the **target variable, but its not yet defined because the searchFilter Context hasn't been run yet. How do I change the order that the rwm-rewriteContexts are executed so that the context for searcFilter is run first ? Thanks Paul

2 1

After few seconds slapd automatically closes connection. Why?
by Saša-Stjepan Bakša 18 Feb '17

18 Feb '17

After successful bind and some search actions my client is still bind to server but as I can see from trace few seconds after successful operation slapd shuts down connection. Why is that happening? Can I prevent it? We have monitoring in our software which find that as server down and lots of logs are generated. 229 1786.027248821 172.17.103.226 -> 10.50.200.191 LDAP 294 searchResEntry(49) "cn=config" 230 1786.027396894 172.17.103.226 -> 10.50.200.191 LDAP 68 searchResDone(49) success 231 1786.028152406 10.50.200.191 -> 172.17.103.226 TCP 60 56375 > ldap [ACK] Seq=576 Ack=130237 Win=65280 Len=0 232 1798.039843259 172.17.103.226 -> 10.50.200.191 TCP 54 ldap > 56375 [FIN, ACK] Seq=130237 Ack=576 Win=30336 Len=0 233 1798.042231511 10.50.200.191 -> 172.17.103.226 TCP 60 56375 > ldap [ACK] Seq=576 Ack=130238 Win=65280 Len=0 Br Sasa

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical