Add 'memberOf' attribute to ApacheDS - ldap

I am trying to simulate Active Directory's memberOf attribute in Apache Directory. I have added the following entry for memberOf to my LDIF file:
dn: m-oid=1.3.6.1.4.1.18060.0.4.3.2.1,ou=attributeTypes,cn=other,ou=schema
m-usage: USER_APPLICATIONS
m-equality: distinguishedNameMatch
objectClass: metaAttributeType
objectClass: metaTop
objectClass: top
m-name: memberOf
m-oid: 1.3.6.1.4.1.18060.0.4.3.2.1
m-obsolete: FALSE
m-noUserModification: FALSE
m-syntax: 1.3.6.1.4.1.1466.115.121.1.27
When I start ApacheDS the following warning is logged:
WARN [ContainerBackgroundProcessor[StandardEngine[Catalina]]] entry.ServerStringValue - Cannot normalize the value :Encountered name based id of memberOf which was not found in the OID registry
This causes problems later on because my application tries to user the memberOf attribute as a search filter.
Is anything wrong with the way I specified the LDIF entry?

For my integration test cases on top of embedded Apache Directory Server I've added both memberOf and sAMAccountName attributes defined in Microsoft Active Directory server.
#########################################################
# MICROSOFT SCHEMA for sAMAccountName and memberOf
# these two attributes are not defined in Apache Directory Server
#########################################################
dn: cn=microsoft, ou=schema
objectclass: metaSchema
objectclass: top
cn: microsoft
dn: ou=attributetypes, cn=microsoft, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: attributetypes
dn: m-oid=1.2.840.113556.1.4.221, ou=attributetypes, cn=microsoft, ou=schema
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.4.221
m-name: sAMAccountName
m-equality: caseIgnoreMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
m-singleValue: TRUE
dn: m-oid=1.2.840.113556.1.4.222, ou=attributetypes, cn=microsoft, ou=schema
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.4.222
m-name: memberOf
m-equality: caseIgnoreMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
m-singleValue: FALSE
dn: ou=objectclasses, cn=microsoft, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: objectClasses
dn: m-oid=1.2.840.113556.1.5.6, ou=objectclasses, cn=microsoft, ou=schema
objectclass: metaObjectClass
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.5.6
m-name: simulatedMicrosoftSecurityPrincipal
m-supObjectClass: top
m-typeObjectClass: AUXILIARY
m-must: sAMAccountName
m-may: memberOf
#######################################################
# Megacorp employees
#######################################################
dn: cn=EmployeeABC,ou=nl_users,DC=corp,DC=megacorp,DC=COM
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectclass: simulatedMicrosoftSecurityPrincipal
cn: EmployeeABC
sn: EmployeeABC
givenName: EmployeeABC
mail: EmployeeABC#megacorp.com
MEMBEROF: CN=just-users,OU=mc_groups,DC=corp,DC=megacorp,DC=com
MEMBEROF: CN=best-users,OU=mc_groups,DC=corp,DC=megacorp,DC=com
SAMACCOUNTNAME: employeeabc

The ApacheDS team is aware of the desire for the memberOf virtual attribute. They mention that it will be part of the 2.1.0 release:
Le 5/20/13 5:53 PM, Danielsen, Jay a écrit :
I see from the January 2013 archives that memberOf virtual attribute is not yet supported.
Are there any plans or work-in-progress to support memberOf in an upcoming release ? Morst certainly in 2.1.0.
We are currently busy cleaning the 150 remaining issues before a
2.0.0-RC1 release, so I think this is something we can have in the next 6 months.
You can create a JIRA to request such a feature.
Thanks !
-- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
And here is the JIRA request.

You may need to add the schema that contains 'memberOf' into the ApacheDS configuration.

Related

How to add another LDAP entry in OPENLDAP using ldapadd

I added an LDAP entry with ldapadd and ldif file.
Now I have one entry.
I changed ldif file and tried to add a new entry.
dn: dc=my-domain,dc=com
objectclass: dcObject
objectclass: organization
o: dsm
dc: MY-DOMAIN
dn: cn=Manager,dc=my-domain,dc=com
objectclass: organizationalRole
cn: Manager
dn: cn=singer,dc=my-domain,dc=com
objectclass: organizationalRole
cn: singer
I got :
ldap_add: Already exists (68)
How can I add another entry in OPENLDAP?
Appears you are trying to add these again: (Remove these lines)
dn: dc=my-domain,dc=com
objectclass: dcObject
objectclass: organization
o: dsm
dc: MY-DOMAIN
dn: cn=Manager,dc=my-domain,dc=com
objectclass: organizationalRole
cn: Manager

UnboundID LDAP memberof-overlay

I'm trying to get the dynamic memberOf attribute to work in my in-memory-ldap-server. I'm using the standard edition of UnboundID.
I tried with the following .ldif-files if it is activated by default:
base.ldif:
dn: dc=example,dc=com
objectclass: domain
dc: example
dn: ou=Group,dc=example,dc=com
objectclass: organizationalUnit
ou: Group
dn: ou=People,dc=example,dc=com
objectclass: organizationalUnit
ou: People
dn: uid=test1,ou=People,dc=example,dc=com
objectclass: account
uid: test1
#Group 1.1
dn: cn=testUndergroup,ou=Group,dc=example,dc=com
objectclass: groupOfNames
cn: testUndergroup
#Group 1
dn: cn=testgroup,ou=Group,dc=example,dc=com
objectclass: groupOfNames
cn: testgroup
modify.ldif:
dn: cn=testgroup,ou=Group,dc=example,dc=com
changetype: modify
add: member
member: uid=test1,ou=People,dc=example,dc=com
when i do this ldap-search:
seach:
ldapsearch --hostname localhost --port 3268 --baseDN dc=example,dc=com "(uid=test1)" memberOf
i dont get the memberof in the answer:
# Connected to localhost:3268
dn: uid=test1,ou=People,dc=example,dc=com
# The search operation was processed successfully.
# Entries returned: 1
# References returned: 0
# Disconnected from the server
So it isn't activated by default.
How can i activate the memberOf attribute in UnboundID?
BTW: i can not use dynamic groups like they are mentioned here
The in-memory directory server shipped with the LDAP SDK does not support groups. The document that you are referencing on our community portal refers to the UnboundID Directory Server - which is a commercial product and distinct from the in-memory directory server. You can request a free trial download to the UnboundID Directory Server through the main website (https://www.unboundid.com or https://www.pingidentity.com). I hope this helps.

How to Modify TDS userid(uid) value using java API

I am trying to modify uid value in Tivoli directory server using API. Please review the below user structure.
dn: uid=user1,cn=demo,o=evault
uid: user1
userPassword: {AES256}mIJFA1UiEMYP6J2dVt3vcg==
objectclass: top
objectclass: demoObjectClass
objectclass: ePerson
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
sn: user1
cn: user1
ibm-entryuuid: 134f18c0-b251-1034-8575-a2f4cc94f892
Here i am trying yo change the uid. Is it possible?? Please guide me on this
You must perform a rename on the entry as uid is the "naming attribute".

LDAP: error code 67 - Not Allowed On RDN

I'm trying to import the following LDIF into Tivoli Directory Server ..
dn: dc=root,dc=ibm,dc=com
objectclass: domain
objectclass: top
dc: dc=root,dc=ibm,dc=com
dn: cn=users,dc=root,dc=ibm,dc=com
objectclass: domain
objectclass: top
dc: cn=users,dc=root,dc=ibm,dc=com
I get this warning .. According to the schema attribute CN is not allowed
Followed by an error .. LDAP: error code 67 - Not Allowed On RDN
I'm following some IBM documentation , so not sure where I'm going wrong?
http://www-01.ibm.com/support/knowledgecenter/SSZLC2_7.0.0/com.ibm.commerce.admin.doc/tasks/tmswmmdirserver.htm
The objectclass domain does not allow the cn attribute according to your current schema (neither does top which is the mother of all objectlasses). Try dn: dc=users,dc=root,dc=ibm,dc=com instead because the dc attribute is available on domain entries.
Went with this ..
dn: dc=root,dc=ibm,dc=com
objectclass: domain
objectclass: top
dc: dc=root,dc=ibm,dc=com
dn: cn=users,dc=root,dc=ibm,dc=com
objectclass: container
objectclass: top
cn: cn=users,dc=root,dc=ibm,dc=com

Adding certificate in userSMIMECertificate attribute of inetOrgPerson

I'm going to publish a certificate for my email using LDAP.
I already have a LDAP up and running (AD LDS) on windows 2012.
I'm going to add records using ldif file.
Here its contents
dc: dc=mysubdomain,dc=mydomain,dc=com
dn: dc=mysubdomain,dc=mydomain,dc=com
objectClass: top
objectClass: domain
dc: mydomain
dc: mysubdomain
description: Some root stuff
dn: ou=mysubdomaincertificates,dc=mysubdomain,dc=mydomain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: mysubdomaincertificates
dn: Mail=test#mysubdomain.mydomain.com,ou=mysubdomaincertificates,dc=mysubdomain,dc=mydomain,dc=com
objectClass: top
objectClass: person
objectClass: inetOrgPerson
cn: Test Test
sn: Test
Mail: test#mysubdomain.mydomain.com
userSMIMECertificate: #<What to put?>
I'm stuck in compiling my ldif file. As I understand, I need to put some binary encoded in Base64 with some prefix {CERT} or something.
My questions are
Will this ldif file make modifications into the directory?
Do I have problems except userSMIMECertificate field?
For example I'm using dc twice in the domain object, is it ok?
Am I missing some other important line?
What is exact syntax of putting certificate content in the userSMIMECertificate? (I've made a search, but could not find the examples)
Here is your LDIF with the appropriate changes:
dn: dc=mysubdomain,dc=mydomain,dc=com
changetype: add
objectClass: top
objectClass: domain
dc: mysubdomain
description: Some root stuff
dn: ou=mysubdomaincertificates,dc=mysubdomain,dc=mydomain,dc=com
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: mysubdomaincertificates
description: Provide some descriptive text here.
dn: Mail=test#mysubdomain.mydomain.com,ou=mysubdomaincertificates,dc=mysubdomain,dc=mydomain,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: inetOrgPerson
cn: Test Test
sn: Test
Mail: test#mysubdomain.mydomain.com
userSMIMECertificate: file:///path-cert-file
As a useful supplement to the existing answer from Terry Gardner
To avoid that your ldif depends on an external file, you might want to specify the userSMIMECertificate in such a way:
userSMIMECertificate:: Q29udGVudC1EaXNwb3NpdGlvbjogYXR0YWNobWVudDsKCWZpbGVuY
W1lPXNtaW1lLnA3cwpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3BrY3M3LXNpZ25hdHVyZTsK
[...]
This is basically the base64-encoded file contents.
In order to get rid of file dependencies, it's easiest to import the ldif with the file dependencies, then export the object to a new ldif. The export should create above format.