On Thu, 2013-12-26 at 07:41 -0800, Howard Chu wrote:
This was developed at the request of the Samba team, and some of those
developers also worked on SSSD, so it has already been implemented in
significant volumes.
libraries/libldap/deref.c contains ldap_create_deref_control() which
uses
On 12/28/2013 10:34 AM, Arthur de Jong wrote:
On Thu, 2013-12-26 at 07:41 -0800, Howard Chu wrote:
This was developed at the request of the Samba team, and some of those
developers also worked on SSSD, so it has already been implemented in
significant volumes.
libraries/libldap/deref.c
Hi Howard,
On Wed, 25 Dec 2013, Howard Chu wrote:
See https://tools.ietf.org/html/draft-masarati-ldap-deref
Was going to reply but Michael beat me to it. Reiterating all the points
Michael made. There is no good reason to use memberUid or uniqueMember in
LDAP, both of these schema elements
On Wed, 2013-12-25 at 15:27 +0100, Michael Ströder wrote:
Arthur de Jong wrote:
Additionally, if you plan to use the contents of the tree
as Unix users and want to have reasonable performance for
large trees, you should either:
- use memberUid attributes
- user member or uniqueMember
Christian Kratzer wrote:
I was always intending to ask what the original use case for
groupOfUniqueNames
actually was as I totally fail to see the point in the uniqueMember
attributes.
I see lots of people using it just because oh yeas of course we want to
have unique members.
Most
On Wed, 2013-12-25 at 16:44 +0100, Michael Ströder wrote:
Furthermore there's slapo-deref which seems to work. The client
control can be used to retrieve all the 'uid' values in member
entries. The NSS provider has to extract the 'uid' values from the
response control value.
See
Christian Kratzer writes:
On Wed, 25 Dec 2013, Howard Chu wrote:
Was going to reply but Michael beat me to it. Reiterating all the points
Michael made. There is no good reason to use memberUid or uniqueMember in
LDAP, both of these schema elements are deeply flawed.
thanks to both of you
Arthur de Jong wrote:
On Wed, 2013-12-25 at 16:44 +0100, Michael Ströder wrote:
Furthermore there's slapo-deref which seems to work. The client
control can be used to retrieve all the 'uid' values in member
entries. The NSS provider has to extract the 'uid' values from the
response control
Arthur de Jong wrote:
You can cache things, put them in a local database and use something
other than LDAP search queries to search the data but that comes at a
price. Cache lookups have to take into account the lifetime of cached
entries and handle changes in LDAP gracefully (e.g. change uid
Arthur de Jong wrote:
On Wed, 2013-12-25 at 16:44 +0100, Michael Ströder wrote:
Furthermore there's slapo-deref which seems to work. The client
control can be used to retrieve all the 'uid' values in member
entries. The NSS provider has to extract the 'uid' values from the
response control
On Mon, 2013-12-23 at 22:52 +0100, Dieter Klünter wrote:
You use attribute type uniqueMember without any additional UID in order
to enforce uniqueness. The syntax of uniqueMember attribute type is
Name and optional UID. But without any additional UID any sort of
uniqueness cannot be provided.
Arthur de Jong wrote:
On Mon, 2013-12-23 at 22:52 +0100, Dieter Klünter wrote:
You use attribute type uniqueMember without any additional UID in order
to enforce uniqueness. The syntax of uniqueMember attribute type is
Name and optional UID. But without any additional UID any sort of
Michael Ströder wrote:
Arthur de Jong wrote:
Since you cannot do joins in LDAP, every group with member attributes
such as cn=Joe,ou=People,dc=... will require another lookup per member
to find the username (uid attribute).
This very much depends on the implementation of the NSS provider.
Michael Ströder wrote:
Michael Ströder wrote:
Arthur de Jong wrote:
Since you cannot do joins in LDAP, every group with member attributes
such as cn=Joe,ou=People,dc=... will require another lookup per member
to find the username (uid attribute).
This very much depends on the implementation
In Use: Oracle OpenLDAP 2.4.30, I cannot change to the OpenLDAP version that
one can compile.
Problem: I have the module and overlay in the conf files and slaptest says
it's fine. Both files are from Openldap.org version 2.4.37But how do I test it?
I have created unix shell scripts to do
Am Mon, 23 Dec 2013 18:16:29 +
schrieb David Barr david.ba...@mclaneat.com:
In Use: Oracle OpenLDAP 2.4.30, I cannot change to the OpenLDAP
version that one can compile. Problem: I have the module and overlay
in the conf files and slaptest says it's fine. Both files are from
Am Mon, 23 Dec 2013 18:16:29 +
schrieb David Barr david.ba...@mclaneat.com:
[...]
dn: cn=Directory Administrators,dc=bozo_company,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: Directory Administrators
uniqueMember: cn=clownadmin,ou=Special Users,dc=bozo_company,dc=com
17 matches
Mail list logo
