openldap-software December 2007

openldap-software@openldap.org

75 participants
90 discussions

Re: ldap queries rewriting
by Aaron Richton 06 Dec '07

06 Dec '07

If the copier has a Bind DN option, then something along the lines of... access to dn.subtree="ou=Engineering,dc=example,dc=com" by dn.exact="cn=EngineeringCopier,ou=Engineering,dc=example,dc=com" read by [...everythingelse...] access to * by dn.exact="cn=EngineeringCopier,ou=Engineering,dc=example,dc=com" none by [...everythingelse...] If it doesn't, you could substitute the "dn.exact" with "peername.ip." Super disgusting, but it'd probably work. (NOTE: if you're going to write back "they're all in ou=People" try access to dn.subtree="ou=People,dc=example,dc=com" filter="(dept=Engineering)" by dn.exact="cn=EngineeringCopier,ou=Devices,dc=example,dc=com" read by [...everythingelse...])

2 1

access control
by Nathan Nobbe 06 Dec '07

06 Dec '07

hello all, i am working on my first installation of openldap, so please bear with me. i assure you in advance i have been digging through the manual and only resort to the mailing list after exhausting ability to understand how to write the access portion of slapd.conf by reading the administration guide. in particular, if some of the language i use in the email is a bit hazy, im trying my best. anyway here is the background; i have designed the tree structure as follows beneath the rootdn there are organizationalUnit objects and beneath those there are organizationalPerson objects. im trying to write the access control with the following *general* goal. the goal is authenticated users can only have read access to organizationalPerson objects beneath the organizationalUnit containing the organizationalPerson object the user authenticated against. the authenticated users should not be able to view any organizationalUnits except the one containing the organizationalPerson object they authenticated against. so now i will come to the problem. there is no way (that ive found in the administration guide) to access the entry a user authenticated against when writing the access control rules. therefore in order to support the above general goal i must hardcode the value of the ou attribute into an access rule for every organizationalUnit in the tree. obviously this is an maintenance nightmare as i would need to support modification of the slapd.conf file if i wanted to create an interface where administrators could add / remove organizationalUnits or modify the value of their ou attribute. please tell me there is a way to analyze the values of attributes in the entry an authenticated user authenticated against, or that there is some other way to tackle the problem. i am happy to send the relevant portions of slapd.conf. thanks, -nathan

3 3

slapadd import/slapd startup:AttributeType errors in Buchan RPMs??
by R.B. 05 Dec '07

05 Dec '07

Hi; I've recently installed Buchan's OpenLDAP rpms because I wanted to use more features of OpenLDAP... mainly the overlays/modules. I downloaded them from http://staff.telkomsa.net/packages/... and installation was fine. I've exported my database to LDIF format and when I try to import the data via slapadd using the new openldap server config, I get the following error: ###### -bash-3.00# /usr/sbin/slapadd -f /opt/ldap-master/etc/slapd.conf -l ldif-dump-20071119.txt /usr/share/openldap2.3/schema/core.schema: line 366: AttributeType not found: "description" slapadd: bad configuration file! -bash-3.00# ###### Looking at the core.schema file, I see that the "description" AttributeType is commented out because it's a "system schema".... along with a few others, like "userPassword". As I keep uncommenting the several attributes, the slapadd process succeeds a bit more. However, when starting slapd, it errors about duplicate attribute types... the ones I uncommented. So I decide to go back to leaving them commented as was intended by the author. But this case causes the import to fail. So, where is the "system schema" found and how do I include it in the main slapd.conf file so that the import process finds these attributes? I've looked through the distribution to find it, but I've not come up with anything. My guess is that it's included in a library or compiled into the daemon. So how do I fix my problem? Thoughts? Thanks, Rafael

2 1

CRL expiration
by Matt Kelley 05 Dec '07

05 Dec '07

I am using OpenLDAP 2.3.39. I have enabled CRL checking by including "TLSCRLCheck peer" in my slapd.conf file. I am having a problem when CRLs expire. I find that, after retrieving an updated CRL, I must restart slapd in order for it to be used. This seems to be true whether using TLSCACertificateFile or TLSCACertificatePath. Is this expected? Is there any way to update CRLs (or certificates, for that matter) without recycling slapd? Thanks in advance, Matt

3 2

sync replication fails
by RUMI Szabolcs 05 Dec '07

05 Dec '07

Hello! I've got a syncrepl setup with the following settings: provider slapd.conf: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 consumer slapd.conf: syncrepl rid=100 provider="ldaps://ldap-master.com.com" binddn="cn=syncrepl,ou=services,dc=com,dc=com" bindmethod=simple credentials="secret" searchbase="dc=com,dc=com" scope=sub type=refreshOnly interval=00:00:10:00 provider log: Dec 4 21:15:23 ldap-master slapd[18046]: conn=15053 fd=37 ACCEPT from IP=<slave_ip>:56390 (IP=0.0.0.0:636) Dec 4 21:15:24 ldap-master slapd[18046]: conn=15053 fd=37 TLS established tls_ssf=256 ssf=256 Dec 4 21:15:24 ldap-master slapd[18046]: conn=15053 fd=37 closed (connection lost) consumer log: Dec 4 21:15:24 ldap-slave slapd[6149]: do_syncrep1: rid 100 ldap_sasl_bind_s failed (-1) Dec 4 21:15:24 ldap-slave slapd[6149]: do_syncrepl: rid 100 quitting I've double checked the credentials, they're OK. /etc/openldap/ldap.conf has "TLS_REQCERT never" in order to exclude certificate issues. What could be wrong? Maybe it tries to authenticate by SASL despite bindmethod=simple? Thanks, Sab

2 2

Re: access control
by Quanah Gibson-Mount 05 Dec '07

05 Dec '07

--On December 5, 2007 1:41:49 PM -0500 Nathan Nobbe <quickshiftin(a)gmail.com> wrote: > i have not read any material on ideal directory layout. can you refer me > to good > resource? the design i have created is based only on intuition. that, > and the schema > reference available in phpLdapAdmin. truth be told, ive found the > documentation in > the openldap administration guide only marginally helpful. at least i > havent seen much > in there about ldap itself; the guide seems to presume preexisting > knowledge of ldap; > of which mine is scant :) Well, there's not hard rule. The general principal is, as flat as possible, as deep as necessary. The problem of course is compounded that bad design decisions at the beginning can haunt you for years. ;) > if i were to have a tree for organizationalUnit objects and another for > organizationalPerson > objects, what would the ideal root objectClass of those trees? The root objectClass of a tree really does not have to pertain to the objects contained in that tree. I tend to make my branch roots fairly benign, like: dn: cn=people,dc=myorg,dc=com objectclass: organizationalRole description: people cn: people > In answer to your question, however, you may find that using sets helps > with some of what you want to do. > > > what are sets in the context of ldap? That's an excellent question. Some day they'll be documented, hopefully. :) But here are some examples: access to dn.children="cn=people,dc=myorg,dc=com" by set.exact="this/uid & user/uid" read If THIS ENTRY and the BINDING USER have the same value for UID, allow READ access to dn.children="cn=nis,dc=myorg,dc=com" by set.exact="this/host & user" read if THIS ENTRY's host attribute matches the USER, allow READ --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

custom schema oddness?
by Mike Eggleston 05 Dec '07

05 Dec '07

I have a custom schema for my site that has five fields. During the LISA '07 conference I had an idea for two more fields. I added the fields to the schema and restarted slapd. The fields do not appear in the ldif output from ldapsearch nor do the fields appear in phpLdapAdmin. Do I need to slapcat and slapadd the entire database to get these new fields to appear? openldap 2.3.30 fedora core 5 Mike

2 1

[Fwd: Re: KDC {K5KEY} userPassword problem] Solved!!
by Kent Nasveschuk 05 Dec '07

05 Dec '07

Although I specified in slapd.conf on the slave servers: moduleload /opt/openldap-2.3.39/lib/smbk5pwd.la I omitted: overlay smbk5pwd I'm guessing slapd never passed credentials to KDC, hence the (49) error code. 1 more question, how does the smbk5pwd module handle a Kerberos password that is expired? Is there a specific error code? I suppose I could expire one then try it. 2 days of wrestling with this, finally got it to work. -- Kent L. Nasveschuk Systems Administrator Marine Biological Laboratory 7 MBL Street Woods Hole, MA 02543 Tel. (508) 289-7263

2 1

Problem with K5KEY implementation
by Kent Nasveschuk 05 Dec '07

05 Dec '07

Hello, I'm having a problem with OpenLDAP using Heimdal Kerberos via the {K5KEY} entry in userPassword. The problem is with the second KDC, works fine on the master LDAP/KDC just not the second one. Some info: This is an OpenLDAP server with Heimdal storing Kerberos stuff in LDAP. Master (mbauth01) Slave (mblauth02) OSs: CentOS5 OpenLDAP 2.3.39 Heimdal 1.0.1 On the second KDC I can use kadmin -l and do klist -l Princ and get results fine, so I know that the KDC can talk to the LDAP backend via ldapi. I don't think it is acls because I removed all and get the same result. >From a remote machine if I search the master: ldapsearch -Z -x -h mblauth01.mbl.edu -b ou=users,dc=mbl,dc=edu -D cn=<some user>,ou=users,dc=mbl,dc=edu -w <krb5 password> cn=<user> cn I get results >From a remote machine if I search the slave: ldapsearch -Z -x -h mblauth02.mbl.edu -b ou=users,dc=mbl,dc=edu -D cn=<some user>,ou=users,dc=mbl,dc=edu -w <krb5 password> cn=<user> cn I get: ldap_bind: Invalid credentials (49) It doesn't look like the mechanism in LDAP that refers userPassword with {K5KEY} to KDC is working on the slave machine. A couple things might cause this to fail. The {K5KEY} entry never made it from the Master to the slave via syncrepl. I verified that the entries are there. I also changed a password using kadmin cpw and verified that the change was replicated to the slave and they were. Any suggestions on how to troubleshoot this or get it working. Couple things about slapd.conf. I added write access to ldapi which should be read on the slave. The password-hash directive not quite sure what that should be set at. On the master it works fine with this omitted. slapd.conf on slave: include /opt/openldap-2.3.39/etc/openldap/schema/core.schema include /opt/openldap-2.3.39/etc/openldap/schema/cosine.schema include /opt/openldap-2.3.39/etc/openldap/schema/inetorgperson.schema include /opt/openldap-2.3.39/etc/openldap/schema/nis.schema include /opt/openldap-2.3.39/etc/openldap/schema/autofs.schema include /opt/openldap-2.3.39/etc/openldap/schema/samba.schema include /opt/openldap-2.3.39/etc/openldap/schema/RADIUS-LDAPv3.schema include /opt/openldap-2.3.39/etc/openldap/schema/hdb.schema #include /opt/openldap-2.3.39/etc/openldap/schema/rfc822.schema include /opt/openldap-2.3.39/etc/openldap/schema/qmail.schema include /opt/openldap-2.3.39/etc/openldap/schema/mblPerson.schema schemacheck on sasl-realm MBL.EDU sasl-host mblauth02.mbl.edu sasl-authz-policy both sasl-regexp "uidNumber=0\\\ +gidNumber=.*,cn=peercred,cn=external,cn=auth" "cn=admin,ou=users,dc=mbl,dc=edu" # logLevel 128(ACL proc) + 32(search filter) + 64(config proc) # loglevel 256(stats log connections/operations/results) + 8 (connection mamangement) #loglevel 288 loglevel 64 allow bind_v2 #modulepath /opt/openldap-2.3.39/libexec/openldap moduleload /opt/openldap-2.3.39/lib/smbk5pwd.la pidfile /opt/openldap-2.3.39/var/run/slapd.pid argsfile /opt/openldap-2.3.39/var/run/slapd.args password-hash {CLEARTEXT} {SSHA} {CRYPT} ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database hdb suffix "dc=mbl,dc=edu" rootdn "cn=admin,ou=users,dc=mbl,dc=edu" rootpw "secret" directory /opt/openldap-2.3.39/var/openldap-data syncrepl rid=111 provider=ldaps://mblauth01.mbl.edu:636 type=refreshAndPersist interval=00:00:01:00 scope sub searchbase="dc=mbl,dc=edu" bindmethod=simple updatedn="uid=syncrepl,ou=Users,dc=mbl,dc=edu" binddn="uid=syncrepl,ou=Users,dc=mbl,dc=edu" credentials=secret updateref ldaps://mblauth01.mbl.edu:636 index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index givenName pres,sub,eq index uid pres,sub,eq index sambaPrimaryGroupSID eq index sambaSID eq index sambaDomainName eq index uidnumber eq index gidNumber eq index sambaHomePath eq index entryUUID eq index automountinformation eq index proxNumber eq index krb5PrincipalName,krb5PrincipalRealm eq index memberUid eq index default sub limits dn.exact="uid=Devicemgr,ou=users,dc=mbl,dc=edu" size=unlimited time=unlimited limits dn.exact="uid=syncrepl,ou=users,dc=mbl,dc=edu" size=unlimited time=unlimited limits dn.exact="uid=onecard,ou=users,dc=mbl,dc=edu" size=unlimited time=unlimited access to dn.subtree="ou=users,dc=mbl,dc=edu" attrs=userPassword,sambaNTPassword,sambaLMPassword,proxNumber,employeeNumber by self read by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by * none access to dn.subtree="ou=users,dc=mbl,dc=edu" attrs=krb5key,krb5EncryptionType,krb5PasswordEnd,krb5KeyVersionNumber,krb5ValidEnd by sockurl.exact=ldapi:/// write by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by self read by * none access to dn.subtree="ou=Groups,dc=mbl,dc=edu" by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by users read by * none access to dn.subtree="ou=Devices,ou=Network,dc=mbl,dc=edu" by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by group.exact="cn=mac_admins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by self read by * none access to dn.subtree="ou=Servers,ou=Network,dc=mbl,dc=edu" by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by self read by * none access to dn.subtree="ou=Computers,ou=Network,dc=mbl,dc=edu" by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by self read by * none access to * by sockurl.exact=ldapi:/// write by self read by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by users read by * none TLSCipherSuite HIGH:MEDIUM:LOW:+SSLv2+TLSv1 # CA cert file TLSCACertificateFile /opt/openldap-2.3.39/etc/openldap/cacert.pem # Signed cert file TLSCertificateFile /opt/openldap-2.3.39/etc/openldap/newcert.pem # Private key TLSCertificateKeyFile /opt/openldap-2.3.39/etc/openldap/newkey.pem -- Kent L. Nasveschuk Systems Administrator Marine Biological Laboratory 7 MBL Street Woods Hole, MA 02543 Tel. (508) 289-7263

2 1

Re: 2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry 04 Dec '07

04 Dec '07

<quote who="Pierangelo Masarati"> > Quanah Gibson-Mount wrote: > >>> I'm confused here. Is it a 2.4 change? >> >> Must be, and seems to be a really odd requirement to me. Why does the >> consumer need to know about it? Why should it be required to load the >> accesslog module? > > As i said, when the __producer__ is configured with the > slapo-accesslog(5) overlay, gets the the auditContext operational > attribute set in the database's context entry. This may be useful to be > able to determine what log context is logging modifications to that > context. As soon as I added accesslog.la to my olcModuleLoad in cn=config, replication started again. I also see in auditlog.ldif (currently testing slapo-auditlog for docs): auditContext: cn=accesslog liek you said above. > As a side effect, syncrepl replicates this attribute as well in the > __consumer__. However, if this attribute is not defined in the > __consumer__'s schema, odd things could happen. i.e. replication stops and is broken ;-) > > So, the only reason to have slapo-accesslog(5) built and loaded **BUT > NOT INSTANTIATED** on the __consumer__ (doesn't sound such strikingly > resource intensive a requirement) is to have this attribute defined in > the schema. Yup, proved this by just loading the module, not using is via "overlay accesslog" etc. > If this sounds so unreasonable, please suggest (and code) a > better strategy. I'm open to everything (including zapping auditContext > at all, unless anyone out there finds it useful and is actively using it). Not unreasonable, just *totally* undocumented. It is, IMHO, a major missing part in the "Changes Since last version" section in the Admin Guide. It's not even in *any* man pages in HEAD. So Syncrepl won't work in 2.4 on any consumer, where the provider has accesslog enabled, i.e. delta-syncrepl. Much appreciated for the feedback Ando. Time for me to get writing ;-) Gavin. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

3 3

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software December 2007