10:16 a.m.
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 actions like add, delete, modify, view, etc. I can
share these if requested.
But I am unsure on the lock, unlock, policy stuff.
Also, How should the OpenLDAP hierarchy look?
Here's mine:
dn: dc=bozo_company,dc=com
ou: com
objectClass: dcObject
objectClass: organizationalUnit
objectClass: top
dc: bozo_company
userPassword: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
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
uniqueMember: cn=david.barr,ou=People,dc=bozo_company,dc=com
dn: ou=Groups,dc=bozo_company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Groups
dn: ou=People,dc=bozo_company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: People
dn: ou=Special Users,dc=bozo_company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Special Users
description: Special Administrative Accounts
dn: cn=Accounting Managers,ou=groups,dc=bozo_company,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: Accounting Managers
ou: groups
description: People who can manage accounting entries
uniqueMember: cn=clownadmin,ou=Special Users,dc=bozo_company,dc=com
uniqueMember: uid=Replica,ou=People,dc=bozo_company,dc=com
uniqueMember: cn=david.barr,ou=People,dc=bozo_company,dc=com
dn: cn=HR Managers,ou=groups,dc=bozo_company,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: HR Managers
ou: groups
description: People who can manage HR entries
uniqueMember: cn=clownadmin,ou=Special Users,dc=bozo_company,dc=com
uniqueMember: cn=david.barr,ou=People,dc=bozo_company,dc=com
dn: cn=QA Managers,ou=groups,dc=bozo_company,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: QA Managers
ou: groups
description: People who can manage QA entries
uniqueMember: cn=clownadmin,ou=Special Users,dc=bozo_company,dc=com
uniqueMember: cn=david.barr,ou=People,dc=bozo_company,dc=com
dn: cn=PD Managers,ou=groups,dc=bozo_company,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: PD Managers
ou: groups
description: People who can manage engineer entries
uniqueMember: cn=clownadmin,ou=Special Users,dc=bozo_company,dc=com
uniqueMember: cn=david.barr,ou=People,dc=bozo_company,dc=com
dn: ou=Services,dc=bozo_company,dc=com
ou: Services
objectClass: top
objectClass: organizationalUnit
dn: ou=DML,ou=Services,dc=bozo_company,dc=com
ou: DML
objectClass: top
objectClass: organizationalUnit
dn: ou=1.0,ou=DML,ou=Services,dc=bozo_company,dc=com
ou: 1.0
objectClass: top
objectClass: organizationalUnit
dn: ou=UserForm,ou=1.0,ou=DML,ou=Services,dc=bozo_company,dc=com
ou: UserForm
objectClass: top
objectClass: organizationalUnit
dn: ou=Configuration,ou=1.0,ou=DML,ou=Services,dc=bozo_company,dc=com
ou: Configuration
objectClass: top
objectClass: organizationalUnit
dn: cn=Configuration:#ID#Configuration:SystemConfiguration,ou=Configuration,ou=1
.0,ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:SystemConfiguration
dn: cn=Configuration:#ID#Configuration:CustomRoles,ou=Configuration,ou=1.0,ou=DM
L,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:CustomRoles
dn: cn=Configuration:#ID#Configuration:DmlManagedDirectory,ou=Configuration,ou=1
.0,ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:DmlManagedDirectory
dn: cn=UserForm:#ID#UserForm:DefaultUserForm,ou=UserForm,ou=1.0,ou=DML,ou=Servic
es,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultUserForm
dn: cn=UserForm:#ID#UserForm:DefaultNtUserForm,ou=UserForm,ou=1.0,ou=DML,ou=Serv
ices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultNtUserForm
dn: cn=UserForm:#ID#UserForm:DefaultHomeForm,ou=UserForm,ou=1.0,ou=DML,ou=Servic
es,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultHomeForm
dn: cn=UserForm:#ID#UserForm:DefaultDMLObjectForm,ou=UserForm,ou=1.0,ou=DML,ou=S
ervices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultDMLObjectForm
dn: cn=UserForm:#ID#UserForm:DefaultCreateForm,ou=UserForm,ou=1.0,ou=DML,ou=Serv
ices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultCreateForm
dn: cn=UserForm:#ID#UserForm:DefaultObjectClassSelectionForm,ou=UserForm,ou=1.0,
ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultObjectClassSelectionForm
dn: cn=UserForm:#ID#UserForm:DefaultDisplayComponentFields,ou=UserForm,ou=1.0,ou
=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultDisplayComponentFields
dn: cn=UserForm:#ID#UserForm:DefaultEditFieldForm,ou=UserForm,ou=1.0,ou=DML,ou=S
ervices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultEditFieldForm
dn: cn=UserForm:#ID#UserForm:DefaultListFormsForm,ou=UserForm,ou=1.0,ou=DML,ou=S
ervices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultListFormsForm
dn: cn=UserForm:#ID#UserForm:DefaultEditFormForm,ou=UserForm,ou=1.0,ou=DML,ou=Se
rvices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultEditFormForm
dn: cn=UserForm:#ID#UserForm:DefaultGroupForm,ou=UserForm,ou=1.0,ou=DML,ou=Servi
ces,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultGroupForm
dn: cn=UserForm:#ID#UserForm:DefaultFindLibrary,ou=UserForm,ou=1.0,ou=DML,ou=Ser
vices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultFindLibrary
dn: cn=UserForm:#ID#UserForm:DefaultGroupFilterForm,ou=UserForm,ou=1.0,ou=DML,ou
=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultGroupFilterForm
dn: cn=UserForm:#ID#UserForm:DefaultOuForm,ou=UserForm,ou=1.0,ou=DML,ou=Services
,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultOuForm
dn: cn=UserForm:#ID#UserForm:DefaultDomainForm,ou=UserForm,ou=1.0,ou=DML,ou=Serv
ices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultDomainForm
dn: cn=UserForm:#ID#UserForm:DefaultLocalityForm,ou=UserForm,ou=1.0,ou=DML,ou=Se
rvices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultLocalityForm
dn: cn=UserForm:#ID#UserForm:DefaultFindForm,ou=UserForm,ou=1.0,ou=DML,ou=Servic
es,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultFindForm
dn: cn=UserForm:#ID#UserForm:DefaultSearchConfigForm,ou=UserForm,ou=1.0,ou=DML,o
u=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultSearchConfigForm
dn: cn=Configuration:#ID#Configuration:DefaultSearchOptions,ou=Configuration,ou=
1.0,ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:DefaultSearchOptions
dn: cn=UserForm:#ID#UserForm:DefaultCOSTemplateForm,ou=UserForm,ou=1.0,ou=DML,ou
=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultCOSTemplateForm
dn: cn=UserForm:#ID#UserForm:DefaultExtensionsEditForm,ou=UserForm,ou=1.0,ou=DML
,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultExtensionsEditForm
dn: cn=UserForm:#ID#UserForm:DefaultManagedDirectoryForm,ou=UserForm,ou=1.0,ou=D
ML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultManagedDirectoryForm
dn: cn=UserForm:#ID#UserForm:DefaultOrganizationPickerForm,ou=UserForm,ou=1.0,ou
=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultOrganizationPickerForm
dn: cn=UserForm:#ID#UserForm:DefaultListNamingAttributesForm,ou=UserForm,ou=1.0,
ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultListNamingAttributesForm
dn: cn=UserForm:#ID#UserForm:DefaultNamingAttributeForm,ou=UserForm,ou=1.0,ou=DM
L,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultNamingAttributeForm
dn: cn=UserForm:#ID#UserForm:DefaultRolesForm,ou=UserForm,ou=1.0,ou=DML,ou=Servi
ces,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultRolesForm
dn: cn=UserForm:#ID#UserForm:DefaultRoleForm,ou=UserForm,ou=1.0,ou=DML,ou=Servic
es,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultRoleForm
dn: cn=UserForm:#ID#UserForm:DefaultDeleteForm,ou=UserForm,ou=1.0,ou=DML,ou=Serv
ices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultDeleteForm
dn: cn=UserForm:#ID#UserForm:DefaultDeleteGeneralPurposeForm,ou=UserForm,ou=1.0,
ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultDeleteGeneralPurposeForm
dn: cn=UserForm:#ID#UserForm:DefaultEnableForm,ou=UserForm,ou=1.0,ou=DML,ou=Serv
ices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultEnableForm
dn: cn=UserForm:#ID#UserForm:DefaultDisableForm,ou=UserForm,ou=1.0,ou=DML,ou=Ser
vices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultDisableForm
dn: cn=UserForm:#ID#UserForm:DefaultRenameForm,ou=UserForm,ou=1.0,ou=DML,ou=Serv
ices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultRenameForm
dn: cn=UserForm:#ID#UserForm:DefaultConfigBackupRestoreForm,ou=UserForm,ou=1.0,o
u=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultConfigBackupRestoreForm
dn: cn=UserForm:#ID#UserForm:DefaultBrowseForm,ou=UserForm,ou=1.0,ou=DML,ou=Serv
ices,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultBrowseForm
dn: cn=Configuration:#ID#Configuration:ComponentProperties,ou=Configuration,ou=1
.0,ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:ComponentProperties
dn: cn=Configuration:#ID#Configuration:DefaultFormConfiguration,ou=Configuration
,ou=1.0,ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:DefaultFormConfiguration
dn: cn=Configuration:#ID#Configuration:DefaultRoles,ou=Configuration,ou=1.0,ou=D
ML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:DefaultRoles
dn: cn=Configuration:#ID#Configuration:DefaultCapabilities,ou=Configuration,ou=1
.0,ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:DefaultCapabilities
dn: cn=Configuration:#ID#Configuration:DefaultNamingAttributesConfiguration,ou=C
onfiguration,ou=1.0,ou=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:DefaultNamingAttributesConfiguration
dn: cn=UserForm:#ID#UserForm:DefaultEditPasswordForm,ou=UserForm,ou=1.0,ou=DML,o
u=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:DefaultEditPasswordForm
dn: cn=Configuration:#ID#Configuration:WPSearchOptions,ou=Configuration,ou=1.0,o
u=DML,ou=Services,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: Configuration:#ID#Configuration:WPSearchOptions
dn: cn=UserForm:#ID#UserForm:WPSearchLibrary,ou=UserForm,ou=1.0,ou=DML,ou=Servic
es,dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:WPSearchLibrary
dn: cn=UserForm:#ID#UserForm:WPSearchForm,ou=UserForm,ou=1.0,ou=DML,ou=Services,
dc=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:WPSearchForm
dn: cn=UserForm:#ID#UserForm:WPViewForm,ou=UserForm,ou=1.0,ou=DML,ou=Services,dc
=bozo_company,dc=com
objectClass: top
objectClass: applicationProcess
description::
cn: UserForm:#ID#UserForm:WPViewForm
dn: cn=clownadmin,ou=Special Users,dc=bozo_company,dc=com
sn: clownadmin
ou: People
ou: Special Users
cn: clownadmin
objectClass: top
objectClass: person
objectClass: organizationalPerson
userPassword: {SHA}ZC/bQou6tU8wl3TJ6dCoSasxgVA=
dn: uid=Replica,ou=People,dc=bozo_company,dc=com
uid: Replica
cn: Replica
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
shadowLastChange: 13761
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 22222
gidNumber: 100
homeDirectory: /tmp
gecos: Replica userid for slave LDAP servers
dn: cn=david.m.barr,ou=People,dc=bozo_company,dc=com
uid: david.m.barr
sn: david.m.barr
ou: People
cn: david.m.barr
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: uidObject
objectClass: pwdPolicyChecker
objectClass: pwdPolicy
pwdCheckModule:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
pwdAttribute: userPassword
userPassword: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
dn: cn=Test.user02,ou=People,dc=bozo_company,dc=com
uid: Test.user02
sn: Test.user02
ou: People
cn: Test.user02
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: uidObject
objectClass: pwdPolicyChecker
objectClass: pwdPolicy
pwdCheckModule:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
pwdAttribute: userPassword
pwdLockout: TRUE
userPassword: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
dn: cn=Test.user04,ou=People,dc=bozo_company,dc=com
uid: Test.user04
sn: Test.user04
ou: People
cn: Test.user04
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: uidObject
userPassword: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
dn: ou=Policies,dc=bozo_company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Policies
dn: cn=Password Policy,ou=Policies,dc=bozo_company,dc=com
objectClass: top
objectClass: pwdPolicy
objectClass: person
description: The default password policy
pwdAllowUserChange: TRUE
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdExpireWarning: 3600
pwdFailureCountInterval: 30
pwdGraceAuthNLimit: 5
pwdInHistory: 5
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdMaxAge: 5184000
pwdMaxFailure: 5
pwdMinAge: 3600
pwdMinLength: 5
pwdMustChange: TRUE
pwdSafeModify: FALSE
sn: Password Policy
cn: Password Policy
dn: ou=Standard Policy,ou=Policies,dc=bozo_company,dc=com
objectClass: top
objectClass: organizationalUnit
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
ou: Standard Policy
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdMaxFailure: 3
pwdMustChange: TRUE
pwdSafeModify: TRUE
pwdLockoutDuration: 0
pwdCheckModule: ou=Standard Policy,ou=Policies,dc=bozo_company,dc=com
pwdAllowUserChange: TRUE
description: Standard Password Policy
pwdMaxAge: 7776002
pwdExpireWarning: 432000
pwdFailureCountInterval: 120
pwdMinLength: 14
pwdInHistory: 10
pwdGraceAuthNLimit: 0
pwdMinAge: 86400
dn: cn=accesslogname,dc=bozo_company,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
ou: accesslogname
description: accesslog
sn: accesslogname
cn: accesslogname
dn: cn=john.d.doe,ou=People,dc=bozo_company,dc=com
uid: john.d.doe
sn: john.d.doe
ou: People
cn: john.d.doe
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: uidObject
userPassword: {SSHA}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Anyone out there who can help?
-David
dbc(a)usa.net
________________________________
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.
1:20 p.m.
Am Mon, 23 Dec 2013 18:16:29 +0000
schrieb David Barr <David.Barr2(a)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
Openldap.org version 2.4.37But how do I test it?
I have created unix shell scripts to do actions like add, delete,
modify, view, etc. I can share these if requested.
But I am unsure on the lock, unlock, policy stuff.
Also, How should the OpenLDAP hierarchy look?
Here's mine:
[...]
I am not arguing your tree design, because it is your decision how to
design a tree according to your requirements.
Giovanni Baruzzi had given presentation about directory design at
LDAPcon-2007
http://www.guug.de/veranstaltungen/ldapcon2007/slides/Design-of-a-Directo...
hopefully this paper will give you some hints.
Locking and unlocking a database operation is not a user operation,
same as locking and unlocking a file on a file system.
With regard to policy, better known as access control, you may read
http://www.openldap.org/faq/data/cache/189.html
as a starting point, the manual page slapd.access(5) provides further
information.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
1:52 p.m.
Am Mon, 23 Dec 2013 18:16:29 +0000
schrieb David Barr <David.Barr2(a)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
uniqueMember: cn=david.barr,ou=People,dc=bozo_company,dc=com
[...]
consider this as my private and personal crusade :-)
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. Just use member attribute type for group
membership, unless you want to enforce a proper uniqueness.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
4:49 a.m.
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. Just use member attribute type for group
membership, unless you want to enforce a proper uniqueness.
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 with user with uid in the DN
The reason for this is that whet you lookup group information the
information returned from a group should also include all the usernames
of the members.
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).
--
-- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/ --
6:27 a.m.
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
> uniqueness cannot be provided. Just use member attribute type for group
> membership, unless you want to enforce a proper uniqueness.
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 with user with uid in the DN
I strongly disagree here.
1. memberUid does not allow to use the same group in OpenLDAP ACLs
Also it's not possible to use slapo-refint to check/update the reference.
Furthermore slapo-memberOf only works with DN-based attributes.
This old group scheme should die, die, die.
2. As explained many times on this list the LDAP syntax
1.3.6.1.4.1.1466.115.121.1.34 (Name And Optional UID) is seriously broken -
especially when adding the arbitrary UID part behind a DN with DirectoryString
syntax in top-level DN part.
The reason for this is that whet you lookup group information the
information returned from a group should also include all the usernames
of the members.
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. AFAIK sssd
simply searches all posixAccount and posixGroup entries and resolves group
membership internally from the local sssd cache database. If a NSS provider
does not support something similar it should be expanded to do so or one
should not use it at all.
Ciao, Michael.
7:44 a.m.
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. AFAIK sssd
simply searches all posixAccount and posixGroup entries and resolves group
membership internally from the local sssd cache database. If a NSS provider
does not support something similar it should be expanded to do so or one
should not use it at all.
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 https://tools.ietf.org/html/draft-masarati-ldap-deref
Ciao, Michael.
2:39 p.m.
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 of the NSS provider. AFAIK sssd
> simply searches all posixAccount and posixGroup entries and resolves group
> membership internally from the local sssd cache database. If a NSS provider
> does not support something similar it should be expanded to do so or one
> should not use it at all.
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 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 are deeply flawed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:25 a.m.
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 are deeply flawed.
thanks to both of you of bringing this up once more.
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".
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
3:25 a.m.
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 people are using 'groupOfUniqueNames' *without* the UID part in
'uniqueMember' without further thinking just because it was the default in
Netscape/iPlanet/SunOne Directory Server.
Ciao, Michael.
5:07 a.m.
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 of bringing this up once more.
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 don't see a rationale in X.520, but RFCs 4517 and 4519 say the
bitstring can be used to differentiate objects with identical or
reused DNs. Different versions of someone's certificate, maybe?
Except that doesn't work for uniqueMember in X.500: If you search for
(DN, bitstring), it matches an object with the DN and no bitstring - but
not vice versa. Nobody in the X.500 community remembered why when we
asked, so in the LDAP standard we made the matching rule commutative.
Thus LDAP's uniqueMember probably doesn't even work right for its
original purpose, which nobody quite remembers anyway, but at least
it's no longer an implemnetation headache in the server.
--
Hallvard
4:47 a.m.
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 https://tools.ietf.org/html/draft-masarati-ldap-deref
Sadly, the Internet Draft expired without turning into an RFC. I also
can't find any documentation on slapo-deref, do you have any pointers?
Also, do you have any idea whether this is implemented by a significant
part of the LDAP servers out there (is it worth the effort to implement
this client-side)?
There is also a memberof overlay that populates memberOf attributes in
users. Would it be difficult to make a memberuid overlay that populates
memberUid attributes in the group?
Thanks,
--
-- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/ --
5:21 a.m.
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 value.
>
> See https://tools.ietf.org/html/draft-masarati-ldap-deref
Sadly, the Internet Draft expired without turning into an RFC.
Like many other expired Internet drafts we use (e.g.
draft-behera-ldap-password-policy in the context of the thread).
I also can't find any documentation on slapo-deref, do you have
any
pointers?
There's no official documentation yet. Simply build and enable the overlay and
try yourself.
Also, do you have any idea whether this is implemented by a
significant
part of the LDAP servers out there (is it worth the effort to implement
this client-side)?
It works with OpenLDAP servers. AFAICS sssd has client code using it.
There is also a memberof overlay that populates memberOf attributes
in
users. Would it be difficult to make a memberuid overlay that populates
memberUid attributes in the group?
Of course you can implement a slapo-memberuid and a slapo-attrvalueref if you
have enough spare time. There's also some experimental code in OpenLDAP's
contrib/ to use posixGroup/memberUID in ACLs. But IMO there's absolutely no
valid reason for wasting the time doing so.
Ciao, Michael.
7:41 a.m.
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 value.
>
> See https://tools.ietf.org/html/draft-masarati-ldap-deref
Sadly, the Internet Draft expired without turning into an RFC. I also
can't find any documentation on slapo-deref, do you have any pointers?
Also, do you have any idea whether this is implemented by a significant
part of the LDAP servers out there (is it worth the effort to implement
this client-side)?
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.
There is also a memberof overlay that populates memberOf attributes
in
users. Would it be difficult to make a memberuid overlay that populates
memberUid attributes in the group?
That would be counterproductive.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:34 a.m.
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 LDAP_CONTROL_PAGEDRESULTS (copy-pasted from
ldap_create_page_control()?).
Should probably be LDAP_CONTROL_X_DEREF instead.
As far as I can find sssd is the only software that uses this (Samba4
doesn't support OpenLDAP if I understand correctly).
--
-- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/ --
2:13 a.m.
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 contains ldap_create_deref_control() which
uses LDAP_CONTROL_PAGEDRESULTS (copy-pasted from
ldap_create_page_control()?).
Definitely possible and quite likely.
Should probably be LDAP_CONTROL_X_DEREF instead.
Fixed in git master, thanks.
p.
As far as I can find sssd is the only software that uses this (Samba4
doesn't support OpenLDAP if I understand correctly).
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
3:16 a.m.
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 with user with uid in the DN
I strongly disagree here.
1. memberUid does not allow to use the same group in OpenLDAP ACLs
Also it's not possible to use slapo-refint to check/update the
reference. Furthermore slapo-memberOf only works with DN-based
attributes. This old group scheme should die, die, die.
I know using DNs in groups can have some benefits in some ACLs and
internal LDAP state. Also, these methods allow for group nesting which
can be very convenient in some scenario's. But for external uses of LDAP
data such as Unix groups (posixGroup) the memberUid attribute is much
simpler to handle.
2. As explained many times on this list the LDAP syntax
1.3.6.1.4.1.1466.115.121.1.34 (Name And Optional UID) is seriously
broken - especially when adding the arbitrary UID part behind a DN
with DirectoryString syntax in top-level DN part.
I haven't seen "Name And Optional UID" before. I was talking about
having a DN with the uid attribute in it such as
uid=joe,ou=people,dc=example,dc=com
instead of
cn=Joe Black,ou=people,dc=example,dc=com
With the first DN style for users you can extract the uid attribute from
the DN. This has some problems, when e.g. a posixAccount has multiple
uid attributes but that causes so many other nasty side-effects that you
don't want that anyway.
With the second form, you always have to do an extra lookup.
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 of an
attribute of a cached entry). In general, caching is difficult to get
right and takes extra resources.
Thanks for your comments,
--
-- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/ --
5:26 a.m.
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 of an
attribute of a cached entry). In general, caching is difficult to get
right and takes extra resources.
Yes, caching is difficult.
But it's something you have to get done right anyway.
Ciao, Michael.
7:38 a.m.
Arthur de Jong wrote:
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 with user with uid in the DN
>
> I strongly disagree here.
>
> 1. memberUid does not allow to use the same group in OpenLDAP ACLs
> Also it's not possible to use slapo-refint to check/update the
> reference. Furthermore slapo-memberOf only works with DN-based
> attributes. This old group scheme should die, die, die.
I know using DNs in groups can have some benefits in some ACLs and
internal LDAP state. Also, these methods allow for group nesting which
can be very convenient in some scenario's. But for external uses of LDAP
data such as Unix groups (posixGroup) the memberUid attribute is much
simpler to handle.
It's the job of the NSS driver to map LDAP data to POSIX data. No other
applications have any legitimate reason to know about it. LDAP
identifiers/references are DNs. The LDAP namespace is hierarchical; simple
flat names are meaningless.
The fundamental flaw in the original RFC2307 was that it stored NIS data
verbatim instead of storing the semantic meaning of the data. E.g., it stored
password change and expiration times as /etc/shadow integers instead of actual
"time" values. This is the wrong way to use LDAP. It made RFC2307 only
directly useful for Solaris (and later Linux), as the stored values were
incompatible with the corresponding concepts in e.g. AIX, HPUX, and various
other OSs. The purpose of storing information in a distributed database like
LDAP is to make it universally useful. The reason there are standardized
syntaxes is to maximize the reusability of stored data. RFC2307 ignored the
majority of these standards. It is a vivid example of how not to design an
LDAP schema.
> 2. As explained many times on this list the LDAP syntax
> 1.3.6.1.4.1.1466.115.121.1.34 (Name And Optional UID) is seriously
> broken - especially when adding the arbitrary UID part behind a DN
> with DirectoryString syntax in top-level DN part.
I haven't seen "Name And Optional UID" before. I was talking about
having a DN with the uid attribute in it such as
uid=joe,ou=people,dc=example,dc=com
instead of
cn=Joe Black,ou=people,dc=example,dc=com
With the first DN style for users you can extract the uid attribute from
the DN. This has some problems, when e.g. a posixAccount has multiple
uid attributes but that causes so many other nasty side-effects that you
don't want that anyway.
With the second form, you always have to do an extra lookup.
Not with the Deref control.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3438
days inactive
3443
days old
openldap-technical@openldap.org
17 comments
8 participants
participants (8)
-
Arthur de Jong -
Christian Kratzer -
David Barr -
Dieter Klünter -
Hallvard Breien Furuseth -
Howard Chu -
Michael Ströder -
Pierangelo Masarati