FDB (fast db?) - off the top of my head, seems unique enough
On Sun, Nov 13, 2011 at 5:17 PM, Howard Chu <hyc(a)symas.com> wrote:
> What's in a name... Apparently "MDB" is already a well-known suffix for
> Microsoft Access database files. "mdb" is also the name of a debugger tool
> in Solaris. To avoid confusion with those unrelated items, it might be a
> good idea to rename our MDB to something else. Now, before the next
> OpenLDAP release is published. Comments?
*The only thing that interferes with my learning is my education.*
That was just an example I wrote while writing the email. Actual one does
have a "by".
The ACLs parse without warning (except the catch-all where dn=*). This is
the real one in my slapd config:
by group/groupOfNames/member.expand="cn=admins,ou=groups,$1" +w continue
by * break
On Fri, Nov 11, 2011 at 11:58 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Friday, November 11, 2011 11:40 AM -0800 Rakesh Aggarwal <
> rakesh.aggarwal(a)gmail.com> wrote:
>> Hi folks!
>> I am using OpenLdap 2.4.23 on RedHat, and using Apache Directory Studio
>> as the client on a different machine.
>> I am having issues trying to setup ACL using Group. The only non-standard
>> aspect in my schema design is that the groups container is located in a
>> organization specific sub-tree of DIT and not under DIT root, e.g.
>> access to dn.subtree="ou=resources,ou=**dept1,ou=ns1,dc=example,dc=**
>> attrs = "entry,@myResourceClass"
>> write continue
>> by * break
>> access to * by * read
> What you pasted is not a valid ACL statement. I expect it to fail. You
> may want to try adding the word "by" in front of "group.exact".
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> Zimbra :: the leader in open source messaging and collaboration
I am using OpenLdap 2.4.23 on RedHat, and using Apache Directory Studio as
the client on a different machine.
I am having issues trying to setup ACL using Group. The only non-standard
aspect in my schema design is that the groups container is located in a
organization specific sub-tree of DIT and not under DIT root, e.g.
* access to dn.subtree="ou=resources,ou=dept1,ou=ns1,dc=example,dc=com"
attrs = "entry,@myResourceClass"
by * break*
*access to * by * read*
I am logging in with a user who is a member to this group but not getting
the desired write access to the entry.
Is the location of the group entries in DIT really matter for ACL to work?
I've implemented a sync job which has to also sync passwords with a password
modification timestamp from an Oracle DB to OpenLDAP. There's a latency in
this password sync so the exact password modification timestamp has to be
copied from the source DB to attribute pwdChangedTime in OpenLDAP.
Setting the pwdChangedTime alone with the Relax Rules control is no problem.
But when the add or modify request also contains the userPassword attribute
slapo-ppolicy also wants to add a (later) value for pwdChangedTime and this
Constraint violation: attribute 'pwdChangedTime' cannot have multiple values
Any chance to achieve this in a single add/modify request? I think this
scenario is not so unusual in the real world. So slapo-ppolicy should not
generate 'pwdChangedTime' if it's already in the write request in case of
Relax Rules control enabled.
One thing that stopped working since I introduced the new directives which
fixed the authentication problem is
being able to peruse the directories using Apache Directory Studio. I can
still see the AD branches but when I try to look at them I get an error
which in the server logs is reported as
res_errno: 1, res_error: <000004DC: LdapErr: DSID-0C0906E8, comment: In
order to perform this operation a successful bind must be completed on the
connection., data 0, v1db1>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
So I must still be missing something in my configuration.
>On 09/11/11 19:34 +0000, Gabriella Turek wrote:
>>The way I got it to work (by pure chance mind you , I just happened on a
>>blog entry somewhere) was to add this entry to the slapd.config file:
>># Configure slapd-ldap back end to connect to AD
>>suffix "ou=user accounts,dc=niwa,dc=local"
>>Nowhere in any documentation did I see this mentioned, and yet it worked
>>So I don't know what to think.
>>On 10/11/11 6:37 AM, "Dan White" <dwhite(a)olp.net> wrote:
>>>On 07/11/11 21:57 +0000, Gabriella Turek wrote:
>>>>Hello, I've set up an openLDAP server (2.4.23) which chains to an
>>>>Active Directory (2008). I can successfully search for users, it will
>>>>find them in Active Directory if they are not in openLDAP, but I
>>>>authenticate the Active Directory users.
>>>>The error is "Invalid credentials (49)"
>>>>Everything is currently configured with clear text
>>>>ldapSearch works fine when pointed directly to the Active Directory.
>>>>The chaining configuration in the slapd.conf is:
>>>> binddn="cn=SDT Tester,ou=NIWA Staff
>>>>Accounts,ou=User Accounts, dc=niwa,dc=local"
>>>Does mode="none" work? If my reading of slapd-ldap(5) is correct, with
>>>config other than 'none', slapd will attempt to assert the proxyAuthz
>>>I checked our local AD server (2003) and it does not appear to support
>>>ldapsearch -LLL -x -H ldap://<AD.ip> -s "base" -b "" supportedControl
>>>proxyAuthz control == 2.16.840.1.1137184.108.40.206 (RFC 4370)
>Ph 918.366.0248 (direct) main: (918)366-8000
>Fax 918.366.6610 email: dwhite(a)olp.net
We would like to setup a kind of replica. We don't want to replicate some
attributes like userpassword, lmpassword, ntpassword. How can we configure
the replica to proxy the authentication somewhere else.
Is there a way to do that via an overlay or something else?
Ingénieur Systèmes et Réseaux
I'm observing an issue where a large number of searches against an openldap server results in a large amount of disk writes occurring.
I have 10 hosts performing the same workload, the hosts are running slapd 2.4.21 under Ubuntu Lucid. If I stop searching against one of the hosts I see disk write activity from that host drop dramatically. I initially noticed the high write activity in the VMware stats for the hosts and have used iostat on the hosts to gather further info. The hosts being searched are slaves in a slurpd replication environment; they do not have replication logging enabled, the directory is using a hdb backend.
Over a 5 minute period the average disk write activity is 8517KB/s when being searched, and 41KB/s when not being searched; over the same time period the average disk read activity is 8KB/s.
When performing searches against a host an average workload is 300 searches/second, average entry size is 450bytes, and average entries returned is 30.
The hosts have plenty of free RAM and are not using any swap. I have disabled the monitor backend but haven't seen much of an improvement by doing this, given the monitor database is instantiated at startup is this stored in memory? (if not, why not make that an option?)
Does anyone have any ideas as to why reading from the directory would be causing disk writes at such a high rate?
I configured accesslog overlay on a test server. Everything is working fine.
But when I use my LDAP client (aka Ldap Admin) I get an error : "Size
The thing is I specified in the slapd.conf configuration file to
rotate the data after 30 days.
Does this message occur because there is too much data in the database ?
I am trying to compile ldapc++ library distributed with openldap-2.4.26 and
getting following error during make:
../src/LDAPAsynConnection.h: In function ‘int main(int, char**)’:
‘LDAPAsynConnection::LDAPAsynConnection(const LDAPAsynConnection&)’ is
startTls.cpp:43: error: within this context
make: *** [startTls.o] Error 1
make: Leaving directory
make: *** [all-recursive] Error 1
I am attaching my config log as well, is there anything which I am missing
Another thing, I would like to know does this library have Referral Chasing
capability during bind, also is it thread safe or its caller's
responsibility to make it thread safe?
Thanks for the help, I appreciate it very much.