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@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.
Am Mon, 23 Dec 2013 18:16:29 +0000 schrieb David Barr David.Barr2@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-Directory-... 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
Am Mon, 23 Dec 2013 18:16:29 +0000 schrieb David Barr David.Barr2@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
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 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.
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.
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.
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.
Hi Howard,
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 see lots of people using it just because "oh yeas of course we want to have unique members".
Greetings Christian
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.
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.
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.
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 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.
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.
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.
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.
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).
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).
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.
- 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.
- 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 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.
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.
- 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.
- 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.
openldap-technical@openldap.org
-
Arthur de Jong -
Christian Kratzer -
David Barr -
Dieter Klünter -
Hallvard Breien Furuseth -
Howard Chu -
Michael Ströder -
Pierangelo Masarati