openldap-technical

openldap-technical@openldap.org

9951 discussions

Regarding the conclusion from ITS# 8521 and cn=config replication
by Nikos Voutsinas 07 Jan '17

07 Jan '17

I was looking at the latest issues/commits and came across ITS#8521 which discusses the correct sequence of setting up the serverID, the syncprov overlay and uploading the actual data in a replication scheme. So there, the conclusion is: "Bottom line, *always* inject the serverID and syncprov *before injecting some data, or be ready to do an update after having injected syncprov and serverID" This made me wonder how can we accomplish this with the replication of cn=config, and if the replication of cn=config requires any extra precaution at the initialization phase. Nikos

1 0

Re: Syncrepl and multipe values
by Quanah Gibson-Mount 06 Jan '17

06 Jan '17

--On Tuesday, January 03, 2017 10:03 PM +0000 Matheus Eduardo Bonifacio Morais <matheus_morais(a)sicredi.com.br> wrote: > > > Hi, > > > > I have one replication tool which makes some modifications in my OpenLDAP > master. For some shitty reason, that tool tries to modify one dn with > duplicated attributes. Here is the snippet of accesslog: Please file an ITS for this issue at http://www.openldap.org/its/ Preferably, include an example ldapmodify command triggering the behavior. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Re: help with ACL
by Quanah Gibson-Mount 06 Jan '17

06 Jan '17

--On Wednesday, January 04, 2017 2:44 PM +0100 Alberto Aldrigo <alberto.aldrigo(a)h-farm.com> wrote: > So an ACL could be: > > to dn.subtree="o=company1,dc=domain,dc=com" by group="c > cn=admins_company1,o=company1,dc=domain,dc=com" write > > I have 25 of these groups, so I need 25 ACLs like the one above: having > one per line can lead to a performance issue? Generally it should be fine, as it's not a particularly complex ACL. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Antw: Re: ppolicy overlay unable to set pwdAccountLockedTime on to-be-locked users due to ACLs
by Quanah Gibson-Mount 06 Jan '17

06 Jan '17

--On Tuesday, January 03, 2017 2:49 PM +0100 Matthieu Cerda <matthieu.cerda(a)nbs-system.com> wrote: > > > Le 03/01/2017 à 08:05, Ulrich Windl a écrit : >>>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 03.01.2017 um 00:11 >>>>> in >> Nachricht <F365AC223D2A1E22A5345243(a)[192.168.1.30]>: >>> (...) >>> >>> Note the bit about "all the operations, ..." >>> >>> If you think of a way to reword it that you feel is a better >>> explanation, that could certainly be considered. :) >> >> I think a notice who is the modifier on ppolicy changes would be woth >> it; specifically if it's related to RootDN ;-) I think I had already >> asked earlier about some notice on ACLs that ppolicy may or may not need >> to work. > > Well I certainly didn't understand the message as 'every operation will > be done assuming the rootdn identity' indeed. > > I agree with Ulrich, maybe a small note in the manpage saying exactly > that might help, just in case ? > > Here is a proposal patch on slapo-ppolicy.5 manpage to clarify that. Submissions need to be via the ITS system, http://www.openldap.org/its/ Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(host) and (uid) not indexed (after creating an account)
by Peng Yu 04 Jan '17

04 Jan '17

Hi, I can use the following command to change the password in openldap after I create an entry le. ~~~ $ sudo ldapsetpasswd le Changing password for user uid=le,ou=Users,dc=mydomain,dc=example New Password: Retype New Password: Successfully set password for user uid=le,ou=Users,dc=mydomain,dc=example ~~~ And I can see the userPassword field is changed upon calling the above command. ~~~ $ sudo ldapmodifyuser le [sudo] password for pengy: # About to modify the following entry : dn: uid=le,ou=Users,dc=mydomain,dc=example objectClass: account objectClass: posixAccount objectClass: shadowAccount cn: le uid: le uidNumber: 10103 gidNumber: 10002 homeDirectory: /home/le loginShell: /bin/bash gecos: le description: User account shadowMax: 180 shadowLastChange: 0 userPassword:: e1NTSEF9VzZHdlFnTkdDMitzUk5BRStpMGMzcElVWG9hVTYzRjk= # Enter your modifications here, end with CTRL-D. dn: uid=le,ou=Users,dc=mydomain,dc=example Successfully modified user entry uid=le,ou=Users,dc=mydomain,dc=example in LDAP ~~~ (BTW, why whenever I run ldapsetpasswd to set the same password, the userPassword field is set differently?) But the user le is not able to login to the servers (the servers connected to openldap for authentication) with the new password. In /var/log/syslog of the openldap server (ubuntu), I see the following lines. ~~~ Jan 2 12:17:22 openldapserver slapd[1082]: conn=2884 fd=39 ACCEPT from IP=172.17.1.6:51975 (IP=0.0.0.0:389) Jan 2 12:17:22 openldapserver slapd[1082]: conn=2884 op=0 BIND dn="" method=128 Jan 2 12:17:22 openldapserver slapd[1082]: conn=2884 op=0 RESULT tag=97 err=0 text= Jan 2 12:17:22 openldapserver slapd[1082]: conn=2884 op=1 SRCH base="dc=domain,dc=example" scope=2 deref=0 filter="(&(&(|(host=\2A)(host=elnath))(!(host=!elnath)))(&(|(host=\2A)(host=elnath))(!(host=!elnath)))(uid=le))" Jan 2 12:17:22 openldapserver slapd[1082]: <= bdb_equality_candidates: (host) not indexed Jan 2 12:17:22 openldapserver slapd[1082]: message repeated 3 times: [ <= bdb_equality_candidates: (host) not indexed] Jan 2 12:17:22 openldapserver slapd[1082]: <= bdb_equality_candidates: (uid) not indexed Jan 2 12:17:22 openldapserver slapd[1082]: conn=2884 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= ~~~ On the server to be logged in (named as elnath and is also a ubuntu server), /var/log/auth.log has the following line. ~~~ Jan 2 12:17:22 elnath sshd[21249]: Failed password for le from xxx.xx.xx.xx port 57155 ssh2 ~~~ I have tried to stop slapd service then run slapindex as root and then start slapd service on the openldapserver. But it still does not work. Could anybody let me know how to fix this issue? Thanks. -- Regards, Peng

3 4

Re: mdb_stat question
by Howard Chu 04 Jan '17

04 Jan '17

Frank Swasey wrote: > I have noticed that the mdb_stat (-e parameter) now shows the number of pages > used, so I can use that instead of running a du and compare it to the Max > pages value to see how "full" the data.mdb has become. > > We use nagios to monitor such things... is there a frequency of running > mdb_stat that would be too frequent and could cause issues with a moderately > loaded (handling 14 million operations per day) ldap server? It takes more CPU time to fork a process and load the mdb_stat binary than it takes to read and print the statistic. > Should I have nagios not perform the mdb_stat check more frequently than some > recommended amount of time? Whatever, it's your CPU load. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

mdb_stat question
by Frank Swasey 04 Jan '17

04 Jan '17

I have noticed that the mdb_stat (-e parameter) now shows the number of pages used, so I can use that instead of running a du and compare it to the Max pages value to see how "full" the data.mdb has become. We use nagios to monitor such things... is there a frequency of running mdb_stat that would be too frequent and could cause issues with a moderately loaded (handling 14 million operations per day) ldap server? Should I have nagios not perform the mdb_stat check more frequently than some recommended amount of time? Thanks, Frank

1 0

Re: help with ACL
by Quanah Gibson-Mount 04 Jan '17

04 Jan '17

--On Friday, December 23, 2016 11:16 AM +0100 Alberto Aldrigo <alberto.aldrigo(a)h-farm.com> wrote: > uid=user1 and uid=user6 are company1's administrators, so they can write > in whole o=company1 subtree Might be best to make an LDAP group with those users as members, and then write an ACL based off of that group for its specific privileges. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Syncrepl and multipe values
by Matheus Eduardo Bonifacio Morais 03 Jan '17

03 Jan '17

Hi, I have one replication tool which makes some modifications in my OpenLDAP master. For some shitty reason, that tool tries to modify one dn with duplicated attributes. Here is the snippet of accesslog: dn: reqStart=20170103135721.000411Z,cn=accesslog objectClass: auditModify reqStart: 20170103135721.000411Z reqEnd: 20170103135721.000413Z reqType: modify reqSession: 1184351 reqAuthzID: cn=manager,dc=br reqControls: {0}{2.16.840.1.113730.3.4.2} reqDN: ou=marili_advogados,ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=c om,dc=br reqResult: 0 reqMod:: U2ljcmVkaU1lbW86PSBt77+9Hu+/veKdqu+/vTA0LjUyOC4yNzYvMDAwMS0wNg1BVi4gT UFSRUNIQUwgRkxPUklBTk8gUEVJWE9UWA== reqMod: SicrediEntidadePai:= ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc =com,dc=br reqMod: SicrediEntidadePai:= ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc =com,dc=br reqMod: entryCSN:= 20170103135721.874447Z#000000#000#000000 reqMod: modifiersName:= cn=manager,dc=br reqMod: modifyTimestamp:= 20170103135721Z reqEntryUUID: 61dfd779-5799-4988-927b-914e75d6ae90 As you can see, the attribute "SicrediEntidadePai" is modified two times with the same value, which results in syncrepl to stuck, as described in one of our slaves logs: 2017-01-03T19:14:21.043501-02:00 ds1openldap5p slapd[2245]: syncrepl_message_to_op: rid=000 mods check (SicrediEntidadePai: multiple values provided) 2017-01-03T19:14:21.043599-02:00 ds1openldap5p slapd[2245]: do_syncrepl: rid=000 rc 19 retrying 2017-01-03T19:15:21.039822-02:00 ds1openldap5p slapd[2245]: syncrepl_message_to_op: rid=000 mods check (SicrediEntidadePai: multiple values provided) 2017-01-03T19:15:21.039863-02:00 ds1openldap5p slapd[2245]: do_syncrepl: rid=000 rc 19 retrying My workaround is remove the database on the slaves and let it to do a full replication. I'm looking in the replication tool to fix that modification bug but meanwhile I have two questions about that: 1 - Why that modification happen with no problem in OpenLDAP master and stuck syncrepl? 2 - Should I fill an issue on ITS or this is working as expected? 3 - There is any other workaround for this case? OpenLDAP: slapd 2.4.42 Thanks. Matheus Eduardo Bonifácio Morais Analista de Infraestrutura de TI, Plataforma e Aplicações Confederação Sicredi Centro Administrativo Sicredi - Porto Alegre +55 51 3358 7143 sicredi.com.br [1474907760585_sicredilogo.png] Esta mensagem é somente para uso do destinatário informado e pode conter informações privilegiadas, proprietárias ou privadas. Se você recebeu esta mensagem por engano, por favor, notifique o remetente imediatamente e apague a original. Qualquer outro uso deste e-mail é proibido. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

1 0

ldapsearch filter question
by Zhang,Jun 03 Jan '17

03 Jan '17

ldapsearch -x -b dc=myinstitute,dc=edu uid=user1 gidnumber gives me gidnumber=1234 I then tried, ldapsearch -x -b dc=myinstitute,dc=edu "(&(objectclass=groupofnames)(gidnumber=1234))" intending to find out the name of the group, but I got nothing. Thanks Jun The information contained in this e-mail message may be privileged, confidential, and/or protected from disclosure. This e-mail message may contain protected health information (PHI); dissemination of PHI should comply with applicable federal and state laws. If you are not the intended recipient, or an authorized representative of the intended recipient, any further review, disclosure, use, dissemination, distribution, or copying of this message or any attachment (or the information contained therein) is strictly prohibited. If you think that you have received this e-mail message in error, please notify the sender by return e-mail and delete all references to it and its contents from your systems.

4 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical