openldap-software

openldap-software@openldap.org

2719 discussions

slapd-meta and acls
by Irina Shetukhina 27 Nov '08

27 Nov '08

Hi. I have meta-backend o=vega and two databases o=vega-main and ou=devel on the same server. I'd configure meta-backend o=vega with suffixmassage "o=vega" "o=vega-main" and suffixmassage "ou=devel,ou=sites,o=vega" "ou=devel" I'd like to write acls per database, but provide DIT as single suffix o=vega. Members of cn=sysadmins,ou=groups,o=vega (really cn=sysadmins,ou=groups,o=vega-main) should grant write permissions to ou=devel,ou=sites,o=vega (really ou=devel). But they grant only read to o=vega. Where am I wrong? My slapd.conf: database meta suffix "o=vega" uri "ldap://ldap.irka.int.masterhost.ru/ou=devel,ou=sites,o=vega" suffixmassage "ou=devel,ou=sites,o=vega" "ou=devel" rootdn "cn=ldapadm,o=vega" rootpw X uri "ldap://ldap.irka.int.masterhost.ru/o=vega" suffixmassage "o=vega" "o=vega-main" database hdb suffix ou=devel rootdn "cn=ldapadm,ou=devel" rootpw XX directory /var/db/openldap-data/devel checkpoint 32 8 access to dn.sub="ou=devel" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,ou=vega-main" write by * read database hdb suffix o=vega-main rootdn "cn=ldapadm,o=vega-main" rootpw XXX directory /var/db/openldap-data/vega-main checkpoint 32 8 access to dn.sub="ou=SUDOers,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=mail,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.regex="ou=.*,ou=groups,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=groups,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=users,o=vega-main" attrs=userPassword by self write by anonymous auth by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write access to dn.sub="ou=users,o=vega-main" attrs=mail by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=users,o=vega-main" attrs=@inetOrgPerson,@inetLocalMailRecipient,@intraPerson,cn by self write by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=users,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="o=vega-main" by anonymous auth by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by * read My openldap version 2.4.11 on FreeBSD 7.0-amd64. -- Irina Shetukhina

1 0

Can't get olcPasswordHash to take effect...
by Andrzej Jan Taramina 26 Nov '08

26 Nov '08

Howard had said in a post last year: > For better backward compatibility, olcPasswordHash is allowed in both the > olcGlobal entry and the frontendDB entry. The preferred location for this > setting is now in the frontendDB entry. When generating a slapd.d from a > slapd.conf file, only the frontendDB entry will carry the attribute. Existing > slapd.d configs with the attribute in the global entry should continue to work > but they should be manually updated to use only the frontendDB entry. I'm trying to set my OpenLDAP config to use MD5 as the default password hashing algorithm (to be compatible with some other things we use). I'm using the latest OpenLDAP install for Ubuntu Intrepid, which is version 2.4.11. I added the olcPasswordHash attribute, and the relevant output of my cn=config (using ldapsearch -xLLL -b cn=admin,cn=config -W) now looks like this: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcPasswordHash: {MD5} But my passwords, when added/modified using ldappasswd still seem to use something other than MD5. Just wondering if anyone might have an idea what's causing the problem? Thanks! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com

2 2

alternative listener and kerberos realm
by David Bonnafous 26 Nov '08

26 Nov '08

hi, My aim was to be able to communicate with slapd (2.3.43) using two hostnames (using alternative listeners), one HOSTNAME_A in a kerberos realm REALM_A and the second one, HOSTNAME_B, in realm REALM_B (according to krb5.conf section [domain_realm]). [domain_realm] HOSTNAME_A = REALM_A HOSTNAME_B = REALM_B slapd is running on a machine called HOSTNAME_A (command uname). My problem is that slapd only use HOSTNAME_A to create sasl context, as written in servers/slapd/sasl.c sc = sasl_server_new( "ldap", global_host, global_realm, iplocalport, ipremoteport, session_callbacks, SASL_SUCCESS_DATA, &ctx ); where global_host is not set according from where the connexion comes from. So my questions are: 1- is it a known stuff 2- do you think it is difficult to change this behavior so global_host depends on the hostname used to connect to slapd thank you, -- David Bonnafous Institut de Mathématiques Université de Toulouse - France

1 0

delta-syncrepl problems with 2.4.12
by John Morrissey 25 Nov '08

25 Nov '08

I'm upgrading a site from OpenLDAP 2.3.42 to 2.4.12 in an attempt to alleviate http://www.openldap.org/its/index.cgi/Incoming?id=5631 (slapd crashes due to assertion failure). For us, doing so requires dumping and recreating two back-bdb databases since the OpenLDAP 2.4.x Debian packaging is linked against a newer version of BDB. The larger database contains about a million entries. Instead of slapcat(8)/slapadd(8)ding the old databases, we're removing the existing databases and allowing slapd(8) to delta-syncrepl a copy from scratch. Ironing out this use case is especially important for us since we expect to be adding a number of consumers in the coming months and would obviously prefer to bring them online without having to shut down any other slapd instances for slapcat(8)ting. The Administrator's Guide seems to indicate this is an accepted use case, since its guide to bringing up a new consumer involves simply configuring the consumer and starting slapd. When the consumer slapd comes up, it enters the refresh(?) phase and begins adding entries to the fresh, empty bdb database. When it finishes, contextCSN on the suffix entry is set to 20081111135024Z#000000#00#000000 (roughly when slapd was started) and this change is visible with ldapsearch(1). At this point, slurpd seems to start processing the accesslog. The first entry references a nonexistent DN (uid=nava209,...) and the backend operation returns LDAP_NO_SUCH_OBJECT. This is interesting, since this entry was created months ago should have been found during the refresh phase and created. ldapsearch(1)ing against the provider with the same filter used by the consumer syncrepl ('(objectclass=*)') yields this entry, so it doesn't appear to be index corruption on the provider. At this point, several hundred subsequent search entries are discarded; possibly due to the be_modify operation failing? After some time, slapd continues processing entries and does so successfully until it encounters another error (a modrdn that returns LDAP_ALREADY_EXISTS since the accesslog entry that modrdn'd the existing object out of the way was ignored by the consumer). After a while, slapd starts processing the same batch of modifications again, and repeats until the retry counter is exhausted. contextCSN on the suffix entry is never updated during this process, based on debugging output and ldapsearch(1). It's interesting that two consumers have successfully delta-syncrepl'd complete databases from scratch without experiencing this problem. At least four other consumer machines fail in this manner. There seems to be no rhyme or reason as to which machines succeed or fail; they're all running the same binaries, same OS release and patches, some are even on the same Ethernet segment as the provider. The provider slapd has been up consistently (without crash nor restart) during at least two attempts. Syncrepl (level 16384) debug output, sans ~400Mbytes of entry processing during the refresh phase, is at: http://horde.net/~jwm/slapd-syncrepl-debug john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

4 8

unique_uri strict ?
by ghenry＠OpenLDAP.org 24 Nov '08

24 Nov '08

Hi, Do we have an example for an "unique_uri strict" uri? unique_uri strict ldap:///?mail?sub? says this is invalid, but it it probably my misunderstanding of what it expects. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

4 7

Re: Uninvited listener?
by Chris Evans 24 Nov '08

24 Nov '08

Thanks Ralf and Howard. That fixed the problem, and all the tests succeeded except the illusive 007. C. > Am Sonntag 23 November 2008 20:57:46 schrieb Howard Chu: > > Most likely you are both seeing a bug in glibc, documented in our ITS#5251. > To workaround the problem remove "localhost", from the "::1" line in > /etc/hosts. The underlying glibc problem will be fixed with openSUSE 11.1. > regards, > Ralf > > Chris Evans wrote: > > > I am new to LDAP, and am trying to get OpenLDAP installed on a computer > > > running SUSE 11.0. (Actually, I did this on two similarly configured > > > machines with the same result.) Everything goes smoothly up until the > > > > > > "make test" step, which produces: [etc]

1 0

Cannot start kerberos signing/sealing when using TLS/SSL
by Jeremiah Martell 24 Nov '08

24 Nov '08

I'm getting this error, but googling hasn't really explained what it means or what I'm doing wrong. Any ideas? Thanks, -- - Jeremiah Martell http://inlovewithGod.com

1 0

Re: unique_uri strict ?
by ghenry＠OpenLDAP.org 24 Nov '08

24 Nov '08

----- "Andrew Findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > On Mon, Nov 24, 2008 at 03:57:35PM +0000, Gavin Henry wrote: > > > > > unique_uri "<[strict ][ignore ]URI[URI...]...>" > > > > > > Well, the <> clearly indicates it's a single argument. Maybe an > > > example, or a remark, would help not overlooking it. > > > > That's fine then. I just misread that syntax. Leave as is. > > Hmm - I think the syntax is sufficiently unusual that an example and > note would save a lot of confusion. Well < > are used all over the docs, I just didn't pick up on it. > I am also wondering what happens when the URI itself would need > quoting when used alone - e.g. a URI with spaces in it. Do we need > to put quoted quotes inside the overall quotes, or is the one set > enough? Probably the same as any URI config line, until end of line? > It would also be worth adding a note about *when* the unique_uri > syntax became available (2.4.x). This sort of thing is useful when > doing upgrades and also as a reminder when dealing with configs > for older versions. I'm pretty sure it's been in 2.4 all along. It appeared "Tue Apr 10 00:38:54 2007" and 2.4 was out officially on 2007/10/31. So no worries there. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: syncrepl refreshAdnPersist
by Gavin Henry 24 Nov '08

24 Nov '08

----- "Serge Dubrouski" <sergeyfd(a)gmail.com> wrote: > On Mon, Nov 24, 2008 at 9:41 AM, Gavin Henry > <ghenry(a)suretecsystems.com> wrote: > > > >> US Database has approximately 100000 records and GB Database has > >> approximately 70000 records. After a month of piloting this > >> infrastructure I noticed that shadows are missing about 10 records > >> for > >> US and GB database. Any idea what is wrong with this configuration > >> and > >> why not all records get populated from Master to Shadows? > >> > >> Thanks. > > > > It's hard to say without knowing the entries and data, but you are > two point release > > behind now that have had lots of replication fixes: > > Data is pretty simple though almost each record has binary data: a > user certificate or CRL. OK. > > http://www.openldap.org/software/release/changes.html > > Thanks, I'll take a look and try to upgrade. Great! > > What have you noticed on your logs? > > Nothing really, but my logging setting are pretty basic. What would > be > the best value for loglevel to catch problems like this one? sync and stats are good for replication and general monitoring: "loglevel sync stats" or "loglevel 16640" Thanks. -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

syncrepl refreshAdnPersist
by Serge Dubrouski 24 Nov '08

24 Nov '08

Hello - I'm trying to implement an OpenLDAP infrastructure with one Master Server supporting 4 databases and two Shadow Servers using syncrepl replication. I'm using OpenLDAP 2.4.11 and Berkeley DB 4.6.21 as backend DB. Configuration looks like this: Master: #US database database bdb suffix "c=US" rootdn "cn=admin,c=US" rootpw **** directory /var/lib/ldap/US checkpoint 1024 5 index objectClass eq index mail,cn,ou,o,c eq,pres,sub index serialNumber eq index uid eq index entryUUID eq index entryCSN eq overlay syncprov syncprov-checkpoint 10 5 syncprov-sessionlog 200 #GB database database bdb suffix "c=GB" rootdn "cn=admin,c=GB" rootpw ******* directory /var/lib/ldap/GB checkpoint 1024 5 index objectClass eq index mail,cn,ou,o,c eq,pres,sub index serialNumber eq index uid eq index entryUUID eq index entryCSN eq overlay syncprov syncprov-checkpoint 10 5 syncprov-sessionlog 200 database bdb suffix "c=JP" rootdn "cn=admin,c=JP" rootpw ******** directory /var/lib/ldap/JP checkpoint 1024 5 index objectClass eq index mail,cn,ou,o,c eq,pres,sub index serialNumber eq index uid eq index entryUUID eq index entryCSN eq overlay syncprov syncprov-checkpoint 10 5 syncprov-sessionlog 200 #Corp database database bdb suffix "o=My Company." rootdn "cn=admin, o=My Company." rootpw ******* directory /var/lib/ldap/dst checkpoint 1024 5 index objectClass eq index mail,cn,ou,o,c eq,pres,sub index serialNumber eq index uid eq index entryUUID eq index entryCSN eq overlay syncprov syncprov-checkpoint 10 5 syncprov-sessionlog 200 Shadow: #US database database bdb suffix "c=US" rootdn "cn=admin,c=US" rootpw ****** directory /var/lib/ldap/US checkpoint 1024 5 index objectClass eq index mail,cn,ou,o,c eq,pres,sub index serialNumber eq index uid eq index entryUUID eq index entryCSN eq # Syncrepl syncrepl rid=11 provider=ldap://master.server type=refreshAndPersist interval=00:00:01:00 searchbase="c=US" attrs="*,+" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin,c=US" credentials=***** retry="60 10 300 +" #GB database database bdb suffix "c=GB" rootdn "cn=admin,c=GB" rootpw ******* directory /var/lib/ldap/GB checkpoint 1024 5 index objectClass eq index mail,cn,ou,o,c eq,pres,sub index serialNumber eq index uid eq index entryUUID eq index entryCSN eq # Syncrepl syncrepl rid=12 provider=ldap://master.server type=refreshAndPersist interval=00:00:01:00 searchbase="c=GB" attrs="*,+" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin,c=GB" credentials=****** retry="60 10 300 +" #JP database database bdb suffix "c=JP" rootdn "cn=admin,c=JP" rootpw ****** directory /var/lib/ldap/JP checkpoint 1024 5 index objectClass eq index mail,cn,ou,o,c eq,pres,sub index serialNumber eq index uid eq index entryUUID eq index entryCSN eq # Syncrepl syncrepl rid=13 provider=ldap://master.server type=refreshAndPersist interval=00:00:01:00 searchbase="c=JP" attrs="*,+" scope=sub schemachecking=off bindmethod=simple binddn="cn=diradmin,c=JP" credentials=****** retry="60 10 300 +" #Corp database database bdb suffix "o=My Company." rootdn "cn=admin, o=Company." rootpw ****** directory /var/lib/ldap/corp checkpoint 1024 5 index objectClass eq index mail,cn,ou,o,c eq,pres,sub index serialNumber eq index uid eq index entryUUID eq index entryCSN eq # Syncrepl syncrepl rid=14 provider=ldap://master.server type=refreshAndPersist interval=00:00:01:00 searchbase="o=My Company." attrs="*,+" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin, o=My Company." credentials=****** retry="60 10 300 +" US Database has approximately 100000 records and GB Database has approximately 70000 records. After a month of piloting this infrastructure I noticed that shadows are missing about 10 records for US and GB database. Any idea what is wrong with this configuration and why not all records get populated from Master to Shadows? Thanks. -- Serge Dubrouski.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software