referrals for meta directory use
by Brett ＠Google
Hello,
I am looking to learn about meta directories using ldap. So i am looking for
a way to create a tree structure which wiull be somewhat dynamic, that has
referrals (or aliases - whatever is possible) to a simpler structure in the
same directory.
something like ("real" data which does not change it's position the DIT) :
o=real
ou=unit x
cn=some person
....
ou=unit y
cn=some other person
then have a vutual structure (whick is both liable and likely to change)
o=virtual
ou=animal enthusiasts
ou=dog fanciers
ou=unit x (local referral to o=real, ou=unit x)
The intent is to have a "virtual" tree structure that represents a dynamic
representation of an organisations's structure, that is presented to the
real world, but have the actual data stored in a simple, static structure to
minimise configuration change.
this would provide an accurate representation of the shifting organisational
structure for presentation, but services which would be affected by this
frequently moving organisation structure (web or proxy authentication etc.,)
point to the static or "real" data so changes to the apparent organisational
structure do not affect critical system services.
i was thinking this could be implemented by referrals from the "dynamic"
part of the tree to the "static" part of the tree, but looking at the
referral format it seems to require a hostname, which would in this case be
it's own server.
i would suspect that it is not proper? for one server to refer to itself,
but if it was, is there a syntax for a referral which does not require a
hostname (or a way to specify a localtion in the local DIT) in the "ref"
attribute,
alternatively is there a native alias mechanism which several other servers
have, to graft (apparently for queries etc., not in reality) one part of an
openldap server's tree to another ?
Cheers
Brett
14 years, 7 months
configure's --program-suffix
by Francis Swasey
I am building OpenLDAP 2.4.13 (on RHEL5 if it matters) and using the
--program-suffix option of configure so I can install this without
replacing Red Hat's version (this time).
What I'm finding though is that although the binaries have the suffix --
/usr/sbin/slaptest2.4 (for example). The slapd binary does not
understand that "slaptest2.4" should make it run as the slaptest tool --
and it executes as slapd.
Is this behavior expected (ie, using this feature, I need to patch the
tools array in servers/slapd/main.c to put the suffix on the char string
for matching purposes)?
Thanks,
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
14 years, 7 months
Password policy request control parsing
by Kyle Blaney
I've upgraded from OpenLDAP 2.3.43 to 2.4.13 and I'm getting a server
response that didn't occur with 2.3.43, even though my client code is
unchanged. In particular, my server now complains that a password
policy request control with a zero-length control value is an LDAP
protocol error because the "control value is not absent". Note that
according to section 6.1 of the password policy specification
(http://tools.ietf.org/html/draft-behera-ldap-password-policy-09#section
-6.1), the request control has "no controlValue".
The relevant OpenLDAP code is the ppolicy_parseCtrl method of
servers/slapd/overlays/ppolicy.c. In 2.3.43, that method has the
following check:
if ( ctrl->ldctl_value.bv_len ) {
rs->sr_text = "passwordPolicyRequest control value not empty";
return LDAP_PROTOCOL_ERROR;
}
In 2.4.13, the check is:
if ( !BER_BVISNULL( &ctrl->ldctl_value ) )
rs->sr_text = "passwordPolicyRequest control value not absent";
return LDAP_PROTOCOL_ERROR;
}
Why did this change occur? Was OpenLDAP 2.3.43 too lenient in accepting
a control with zero length?
Kyle Blaney
14 years, 7 months
Re: Supplemental information regarding an recent(-ish) post to the openldap mailing list.
by Quanah Gibson-Mount
--On Thursday, February 12, 2009 7:09 PM -0700 Gary Brubaker
<gary.brubaker(a)microchip.com> wrote:
Hi Gary,
First, I don't know why you are emailing me directly. You should reply to
the list. Otherwise, I will assume you are contacting me because you wish
to open up a support relationship, at which point I will start billing you
at my current rates for the time it takes me to write these emails and any
further support you require. Please read:
<http://www.eyrie.org/~eagle/faqs/questions.html> to understand the
importance of following up emails where they belong. Also, the OpenLDAP
foundation already has a location for reporting bugs:
<http://www.openldap.org/its>. This includes documentation errors.
Thankfully, there are no bugs in your email here, read on to see why.
Second, your email is full of incorrect statements:
>
> I was reading the post, show below, on the mailing list archives, and
> thought
> you might like to know that this link:
>
> http://www.openldap.org/faq/data/cache/1117.html
>
> clearly shows:
[snip]
> which, as you can plainly see, contains the offending attribute setting:
>
> attrs="*,+"
There is nothing offending about this line in the example. As I said in
the email you quote, setting it to attrs="*" is what was broken, not that
setting it to attrs="*,+" is what is broken. That value is actually the
default value, and quite correct. It can also be omitted so that the
default value is used.
> Also, this link:
>
> http://www.openldap.org/faq/data/cache/1118.html
>
> Is very important! The reason for this; my particular problem was solved
> from
> this link. In particular, the examples for replication, obtained from:
>
> http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
>
> Clearly shows:
>
> retry="5 5 300 5"
>
> as does the syncrepl statement (shown above) illustrates:
>
> retry="60 +"
>
> neither of which function as expected. The actual parameter, which
> appears to function
> properly is:
>
> retry="60,+"
>
> NB: It is requisite that a comma (,) be placed between the retry
> parameters. This is
> a small but subtle thing which caused me to spend a lot of time trying to
> figure out
> why replication would only work for the first few moments the server was
> up and running
> and then never replicate thereafter (even with type=refreshAndPersist
> set).
Again, you are incorrect. A comma is *not* needed, and putting in a comma
is incorrect. I've always used the retry="[value] [value]+" format, and it
has always worked. Perhaps you have any number of problems with your
syncrepl statement, which you did not provide.
> Even section '5.2.5.8. olcSyncrepl' from the admin guide shows:
>
> [retry=[<retry interval> <# of retries>]+]
>
> NB: There is a blank space between the interval and the number of
> retries, and not a
> comma (,) character.
This is because that is the correct usage.
> It is unclear to me whether this is a documentation issue or if it is, in
> fact,
> a bug (not my call).
>
> None the less, it might be worthwhile to either update the documentation,
> or declare
> this a bug and fix it.
>
> From all outward appearances you seem to be a significant contributor to
> openldap;
> it seemed prudent to let you know.
>
> Thank you, in advance, for your time and consideration.
Sure thing. Fortunately, there are no real issues here that need
addressing.
--Quanah
> --On Tuesday, December 09, 2008 4:45 PM -0500 Justin Lintz
> <jlintz(a)gmail.com> wrote:
>
> Hi,
>
>
> I am currently working on trying to configure replication between 2
> ldap servers. Here is my current setup....
>
>
>
> slapd.conf on ldap02 is":
>
>
> directory /var/lib/ldap2.4
> checkpoint 256 5
> index objectClass eq
> index cn,mail,surname,givenname
> eq,subinitial index
> uidNumber,gidNumber,memberuid,member,uniqueMember
> eq index uid
> eq,subinitial index sambaSID,sambaDomainName,displayName
> eq referral ldaps://ldap01/
> syncrepl rid=123
> provider=ldaps://ldap01/
> type=refreshAndPersist
> searchbase="dc=example,dc=net"
> scope=sub
> schemachecking=off
> bindmethod=simple
> binddn="cn=manager,dc=example,dc=net"
> attrs="*"
> credentials=
>
>
> You should specify an attrs= line unless you know what you're doing. You
> should just leave it empty and accept the default (which is "*,+" btw).
> Right now you are excluding all the operational attrs, so it loses its
> ability to track where it is at replication wise. If you can identify
> where you got the idea to use that line, that'd be great so we can kill
> it, unless of course it came from offsite documentation.
>
> --Quanah
>
>
> --
>
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 7 months
Paged Results Control questions
by Maier, Nathan
Hi,
I have an LDAP client(LDP.exe) trying to send a paged search to the LDAP
server but get a result code of unavailableCriticalExtension(12), which
seems to indicate that the Paged Results extension isn't present (or
disabled???).
The OpenLDAP server is running slapd version 2.2.28, which according to
the OpenLDAP roadmap should have the "Simple Paged Results Extension".
http://www.openldap.org/software/roadmap.html
So the obvious question, does 2.2.28 support Paged Results? If it does,
could it be the extension is disabled? How would I enable it?
Also, what is a good LDAP query to verify extensions like the Simple
Paged Results?
Thanks in advance,
NJM
14 years, 7 months
Problem with rwm overlay when used with translucent
by Bryan Mesich
Good afternoon to all,
I've been trying to track down a problem that has been eluding me
for the past week and I think I've narrowed it down to the rwm
overlay. When the rwm overlay is used in conjunction with the
translucent overlay, slapd dies with the following error and
backtrace:
*** glibc detected *** ./libexec/slapd: double free or corruption
(fasttop): 0x0860ca38 ***
======= Backtrace: =========
/lib/libc.so.6[0x5ceac1]
/lib/libc.so.6(cfree+0x90)[0x5d20f0]
./libexec/slapd(do_search+0x10e)[0x807bbfe]
./libexec/slapd[0x8079845]
./libexec/slapd[0x8079c12]
./libexec/slapd[0x816d504]
/lib/libpthread.so.0[0x6f750b]
/lib/libc.so.6(clone+0x5e)[0x638b2e]
(I have the memory map if its useful)
I have been able to reproduce this error in 2.4.11, 2.4.13 and
the CVS HEAD as of Mon Feb 9 11:13:04 CST 2009.
I haven't found any documentation that mentions limitations
and/or bugs when using rwm with translucent. Here is portion of
my configuration file (am I stacking the overlays correctly?):
###############################################
# database backend modules to load
moduleload back_ldap.la
# overlay modules to load
moduleload translucent.la
moduleload rwm.la
# local database
database bdb
suffix "dc=nodak,dc=edu"
rootdn "cn=root,dc=nodak,dc=edu"
rootpw secret
directory /var/lib/ldap2.4
overlay translucent
uri "ldap://ldap.nodak.edu/";
overlay rwm
#rwm-rewriteEngine on
#rwm-rewriteContext searchFilter
#rwm-rewriteRule "^(.*objectClass=)posixAccount(.*)" "$1inetOrgPerson$2" ":@"
#rwm-map attribute uidNumber NID
###############################################
The use case for this configuration is to create a custom view
for clients who are using nss ldap. I'm using a translucent
overlay to provide attributes that are missing on the remote
server. The rwm overlay is used to map attributes that exist,
but are named differently on the remote server. I'm also using
a rewrite rule to manipulate incoming search filters.
Simply declaring the rwm overlay (as shown in my configuration)
is enough to produce the error when used with a translucent
overlay. slapd will usually answer one request after being
started before tipping over.
I can file an ITS if need be, but I thought I'd ask before doing
so. Maybe my configuration is wrong or I have missed a piece of
documentation explaining why my configuration doesn't work.
Bryan
14 years, 7 months
LDAP at the UKUUG Spring 2009 Conference
by Andrew Findlay
The UKUUG Spring 2009 Conference (24-26 March 2009 in London) has
a strong LDAP flavour.
OpenLDAP and other LDAP technologies are covered by several papers:
* OpenLDAP Replication Strategies
Gavin Henry (Suretec Systems & OpenLDAP project)
* OpenLDAP and MySQL: Bridging the Data Model Divide
Howard Chu (Symas Corp. & OpenLDAP project)
* Writing Access Control Policies for LDAP
Andrew Findlay (Skills 1st)
* Securing Access to UNIX, Linux and Mac with Active Directory
Barry Scott (Centrify)
There is also a Kerberos tutorial and several papers on systems
monitoring.
The programme is here:
http://www.ukuug.org/events/spring2009/programme/
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
14 years, 7 months
no write access to parent
by Irina Shetukhina
Hi.
There is acl in slapd.conf:
access to dn.one="ou=personal,ou=groups,o=vega"
by group/groupOfUniqueNames/uniqueMember="cn=users-admins,ou=groups,o=vega" write
by group/groupOfUniqueNames/uniqueMember="cn=tree-admins,ou=groups,o=vega" write
by users read
And when any of the members of "cn=users-admins,ou=groups,o=vega"
tries to add a new object, he's got an error:
no write access to parent
But he can modify exiting object without errors.
If I change dn.one to dn.sub, there is no errors at all.
Could anybody explain, what modification needs to parent object?
Our system:
$ uname -rs; pkg_info -Ix openldap-serv
FreeBSD 7.1-amd64-20090114-RELENG_7_1
openldap-server-2.4.13 Open source LDAP server implementation
--
Irina Shetukhina
14 years, 7 months
Replica timestamp wierdness
by Duncan Brannen
Hi,
Can anyone help me out understanding an issue with timestamps I'm
having, is there a config option
to use one or the other format or a search term that matches both?
If a user on out master ldap (Solaris 10, openldap 2.4.8 ) server is
updated, a timestamp is set with a trailing Z
and the record is propogated to the slaves (debian, openldap 2.3.30)
with the same timestamp.
eg 20090210151527Z
If a MODRDN is applied to a user, the tiemstamp on the master is still
of the format 20090210151527Z,
but on the slave it becomes more precise I.E. 20090210151527.623654
If I modify the user again, the timestamp reverts to the Z notation.
I wouldn't care, but I have a script that syncs up another system
looking for modified users and
modifyTimeStamp>=20090210150000Z doesn't match for the other format, nor
does dropping
the Z seem to help.
Thanks,
Duncan
--
The University of St Andrews is a charity registered in Scotland : No SC013532
14 years, 7 months
