How can I search for displaying all members in ou=Groups only? I added
a filter (&(objectClass=posixGroup)(ou=Groups)), but nothing displayed
(I can get every entries if the filter is not used)
ldapsearch -x -W -D cn=insecure,dc=ldap,dc=hce,dc=org
# extended LDIF
# base <dc=ldap,dc=hce,dc=org> (default) with scope subtree
# filter: (&(objectClass=posixGroup)(ou=Groups))
# requesting: ALL
# search result
result: 0 Success
# numResponses: 1
I have troubles using openldap replication in Centos 6.4. and Centos 5.3
I have two server with following version of openldap from centos repository
configures as multimaster replication (internal servers):
Then I have one external server with following products:
Then two internal servers are configured as multi-master replication and
everything is working fine. The external server is configures as slave
replication from one of those internal servers using the following
CODE: SELECT ALL
index entryCSN,entryUUID eq
index objectClass eq,pres
index ou,cn,mail eq,pres,sub
There is a problem with replication from internal server to external. If I
delete the database of external server and start the consumer, everything
is correctly replicated from the provider (internal server) to the
consumer. Therefore I assume, that the replication is configured correctly.
But if the servers are running for a while and changes are made on the
Provider (internal server) some data are not replicated to the consumer.
More precisely the contextCSN of the root of the tree of consumer (external
server) is updated and is the same as on the Provider(internal server),
but some entries lower in the three are not replicated correctly, both the
entry entryCSN and the entry data itself are not updated on the Consumer.
Do you have any idea where could be the problem?
I am having a small problem with an OpenLDAP master at work. Twice
today, at seemingly random intervals, it has stopped responding to all
queries, and all clients lose connection to the master, immediately
after printing the following message in the debug log:
Jan 7 10:04:58 ldap slapd: send_search_entry: conn 1851 ber write failed.
There are no more messages printed before or after this for hours.
I looked at the source, but it didn't seem particularly illuminating (it
looks like this happens when send_ldap_ber() doesn't write anything and
returns 0 bytes, but I don't know how to debug that, since there are a
lot of conditions there that return 0).
I saw this thread, but we are already using 2.4.23 on Debian Squeeze,
so it appears to not be the same problem:
@(#) $OpenLDAP: slapd 2.4.23 (Dec 16 2012 11:48:44) $
I am not aware of performing any changes to our LDAP configuration
How should I go about debugging this? Is this a known issue? I searched
openldap-bugs, but I didn't find anything recent that seemed related.
Thank you for the reply, Dieter. I tried the following config:
rwm-suffixmassage "ou=user,dc=company,dc=com" "OU=All
rwm-map attribute uid sAMAccountName
Simple searches work ( ldapsearch -W -x -b "ou=user,dc=company,dc=com"
uid=michael), but some of our application needs to specify the binding of
which OU the user belongs to. From the above example, if we do a search on
proxy with "ldapsearch -xW -b "cn=Michael Lois,ou=user,dc=company,dc=com",
the proxy would need to translate it into "cn=Michael
Lois,ou=Accounting,OU=All Users,dc=internal,dc=company,dc=com" on AD,
without the need for user to provide that Michael Lois on the Accounting
OU. Is this possible?
I think my problem is similar to this one in the older thread in 2009, but
seems like this quesiton was still open:
In August this year, I submitted some new IETF drafts with the intent
that they would replace NIS and RFC2307. It introduces Directory Based
Information Services (DBIS).
Michael Ströder suggested I post a link to this mailing list. The
following article (and further articles on my blog) discuss some of the
aspects of DBIS, and link to all of the relevant internet drafts:
I am currently working on a reference implementation here:
This may be coming out of the blue for many of you, and I appreciate you
may need some time to read and digest my drafts, and then ask me lots of
But my first question to you is, where is the best place for discussion
related to these drafts? Is this the mailing list to use?
I am trying to get mod_athnz_ldap module to connect apache server with
openldap server in Fedora 19. But there are RPM modules for fedora except
for Fedora 19. How can i achieve this? Any Suggestion.
Thanks in advance.
I use ppolicy overlay and enabled ppolicy_use_lockout to separate between invalid password and locked accounts.
# PPolicy Configuration
I tried to lock user account by entering wrong password couple of times (pwdMaxFailure)
The user is being locked but when I try to login again I still get the same error:
Invalid credentials (49)
Any idea why i am not getting diffrent error to disticnt between the cases?
This e-mail and the information it contains may be privileged and/or confidential. It is intended solely for the use of the named recipient(s). If you are not the intended recipient you may not disclose, copy, distribute or retain any part of this message or attachments. If you have received this e-mail in error please notify the sender immediately [by clicking 'Reply'] and delete this e-mail.
First off, best wishes for 2014.
I've been looking into the deref control that was pointed out here (in
the Oracle OpenLDAP PPolicy ppolicy and the hierarchy thread).
With some trail and error I got things working so I thought to document
what I did in the hopes that it may be useful for other people wanting
to use this control.
First of all, get a slapd instance running with the deref overlay. With
older versions (at least 2.4.31) it was sufficient to load the module to
have the relevant control being shown in the root DSE. However, due to
ITS#7436 this didn't actually do anything.
With later slapd versions (at least 2.4.38) loading the overlay
apparently isn't sufficient but you have to also configure it for each
In terms of using the API you have to first create a control with
ldap_create_deref_control() and pass it along with ldap_search_ext().
After the call to search, free the control again with
The control is built up of an array of LDAPDerefSpec structs that
contains the attribute name that contains the link and a list of
attributes to retrieve from the linked entry (just like you would pass
A bump in the road here was that ldap_create_deref_control() was broken
(reported earlier and already fixed in Git) but
ldap_create_deref_control_value() seems to work.
Any response entries will have a control available that can be extracted
with ldap_get_entry_controls() and parsed with
ldap_parse_derefresponse_control() (and freed with
The returned control data is a linked list of LDAPDerefRes structs, one
per link attribute value. Each struct contains the attribute name, the
original value and a linked list of LDAPDerefVal structs. The DerefVal
structs contain per requested attribute from the linked entry (if the
entry has the attribute) the attribute name and a list of values.
This has been implemented in the development branch of nss-pam-ldapd and
will probably land in the next 0.9 release.
- adding the request control:
- parsing the response control information:
- complete functionality (merge commit):
Hope this is helpful for someone.
-- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/ --
I have one file that I need to use to import about 50 people, it doesn't like the fact that I have more than one user in the file for some reason. I might have another 200 in the future and need to figure out why it isn't working... Help please.
Is my syntax wrong? Did I place something in the wrong order or something more than once that isn't needed.
I have included two users, all are the same except the actual username.
# USER ENTRY
pwdCheckModule: Standard Policy
pwdCheckModule: Standard Policy
ldapadd -v -d 1 -D "cn=Admin,dc=test,dc=com" -w test -f /tmp/T/.ldif
adding new entry cn=New.user01,ou=People,dc=test,dc=com
ldap_add: Type or value exists
ldap_add: additional info: objectClass: value #1021 provided more than once
CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately.