Re: ldap queries rewriting
by Aaron Richton
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...])
16 years
access control
by Nathan Nobbe
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
16 years
slapadd import/slapd startup:AttributeType errors in Buchan RPMs??
by R.B.
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
16 years
CRL expiration
by Matt Kelley
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
16 years
sync replication fails
by RUMI Szabolcs
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
16 years
Re: access control
by Quanah Gibson-Mount
--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
16 years
custom schema oddness?
by Mike Eggleston
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
16 years
[Fwd: Re: KDC {K5KEY} userPassword problem] Solved!!
by Kent Nasveschuk
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
16 years
Problem with K5KEY implementation
by Kent Nasveschuk
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
16 years
Re: 2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry
<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
> ---------------------------------------
>
>
>
16 years
