Why is Apacheds not importing users with the top attribute set in the ldif file? - ldap

Apacheds apacheds-2.0.0.AM26.exe. Importing ldif file with Apache Directory Studio 2.0.0.v20210213-M16
When "objectClass: top" is included in my ldif file I get an invalidAttributeSyntax error. Full error below.
I have deduced that it is the top attribute because all the other attributes show up normally in the log. The top one shows up as objectClass:: dG9wIA==.
If I remove top it works. If I put top back and import again with the update option it works.
Error:
#!RESULT ERROR
#!CONNECTION ldap://myhost:10389
#!DATE 2021-05-27T11:13:27.212
#!ERROR [LDAP result code 21 - invalidAttributeSyntax] INVALID_ATTRIBUTE_SYNTAX: failed for MessageType : ADD_REQUEST Message ID : 17 Add Request : Entry dn: uid=jsmith,ou=Users, dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson uid: jsmith givenName: Jerry sn: Smith cn: Jerry Smith userPassword: 0x52 0x61 0x74 0x31 0x6F 0x6E 0x61 0x6C : ERR_13246_INVALID_VALUE_PER_SYNTAX Invalid upValue per syntax dn: uid=jsmith,ou=Users, dc=example,dc=com changetype: add uid: jsmith givenName: Jerry sn: Smith cn: Jerry Smith objectClass:: dG9wIA== objectClass: person objectClass: organizationalPerson objectClass: inetorgperson userPassword:: UmF0MW9uYWw=
Ldif data:
User:
dn: uid=jsmith,ou=Users,dc=example,dc=com
givenName: Jerry
sn: Smith
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
uid: jsmith
cn: Jerry Smith
userPassword: MyPasswordInClearText
Ldif to create the Group and Users objects which I have tested both as part of the larger ldif file and as two separate imports. This part first then the users second.
dn: ou=Groups,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: Groups
dn: ou=Users,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: Users

Related

No highestCommittedUSN attribute found for AD root - How to configure the (admin) User?

The problem feels THAT basic, that I couldn't find an answer - I feel stupid - whatever ...
"Hand-crafted" LDAP-Directory to connect to ...
Setup (probaply not needed):
Connecting Atlassian-Confluence to a LDAP Directory
The connection itself works (Host, Password etc.)
Pic - generally works
As it can be seen, the synchronisation does not work.
(as 'first' in this video ~3:08 min)
Another Confluence-Page sais: Look into the 'Confluence Logs'
Pic - failed connection
In the LOGs it says:
2020-06-15 10:03:18,099 INFO [Caesium-1-1] [agent.service.check.StaleChecksCleaner] info Cleaning stale checks
2020-06-15 10:03:40,676 INFO [http-nio-8090-exec-4] [embedded.admin.list.DirectoriesController] sync User directory synchronisation requested: [ Active-Directory-Server ], type: [ CONNECTOR ]
2020-06-15 10:03:40,720 INFO [Caesium-1-1] [atlassian.crowd.directory.DbCachingRemoteDirectory] synchroniseCache INCREMENTAL synchronisation for directory [ 294914 ] starting
2020-06-15 10:03:40,722 INFO [Caesium-1-1] [atlassian.crowd.directory.DbCachingRemoteDirectory] synchroniseCache Attempting INCREMENTAL synchronisation for directory [ 294914 ]
2020-06-15 10:03:40,723 INFO [Caesium-1-1] [directory.ldap.cache.UsnChangedCacheRefresher] synchroniseChanges After restarting, full sync of directory [294914] is necessary before incremental sync is possible.
2020-06-15 10:03:40,723 INFO [Caesium-1-1] [atlassian.crowd.directory.DbCachingRemoteDirectory] synchroniseCache Incremental synchronisation for directory [ 294914 ] was not completed, falling back to a full synchronisation
2020-06-15 10:03:40,723 INFO [Caesium-1-1] [atlassian.crowd.directory.DbCachingRemoteDirectory] synchroniseCache INCREMENTAL synchronisation for directory [ 294914 ] was not successful, attempting FULL
2020-06-15 10:03:40,765 INFO [Caesium-1-1] [atlassian.crowd.directory.DbCachingRemoteDirectory] synchroniseCache failed synchronisation complete for directory [ 294914 ] in [ 45ms ]
2020-06-15 10:03:40,773 INFO [CrowdUsnChangedCacheRefresher:thread-2] [directory.ldap.cache.UsnChangedCacheRefresher] call found [ 0 ] remote groups in [ 48ms ]
2020-06-15 10:03:40,781 ERROR [Caesium-1-1] [atlassian.crowd.directory.DbCachingDirectoryPoller] pollChanges Error occurred while refreshing the cache for directory [ 294914 ].
com.atlassian.crowd.exception.OperationFailedException: No highestCommittedUSN attribute found for AD root
at com.atlassian.crowd.directory.MicrosoftActiveDirectory.fetchHighestCommittedUSN(MicrosoftActiveDirectory.java:700)
at com.atlassian.crowd.directory.ldap.cache.UsnChangedCacheRefresher.synchroniseAll(UsnChangedCacheRefresher.java:148)
at com.atlassian.crowd.directory.DbCachingRemoteDirectory.synchroniseCache(DbCachingRemoteDirectory.java:978)
at com.atlassian.crowd.manager.directory.DirectorySynchroniserImpl.synchronise(DirectorySynchroniserImpl.java:67)
at com.atlassian.crowd.directory.DbCachingDirectoryPoller.pollChanges(DbCachingDirectoryPoller.java:45)
at com.atlassian.crowd.manager.directory.monitor.poller.DirectoryPollerJobRunner.runJob(DirectoryPollerJobRunner.java:85)
at com.atlassian.confluence.impl.schedule.caesium.JobRunnerWrapper.doRunJob(JobRunnerWrapper.java:117)
at com.atlassian.confluence.impl.schedule.caesium.JobRunnerWrapper.lambda$runJob$0(JobRunnerWrapper.java:87)
at com.atlassian.confluence.impl.vcache.VCacheRequestContextManager.doInRequestContextInternal(VCacheRequestContextManager.java:84)
at com.atlassian.confluence.impl.vcache.VCacheRequestContextManager.doInRequestContext(VCacheRequestContextManager.java:68)
at com.atlassian.confluence.impl.schedule.caesium.JobRunnerWrapper.runJob(JobRunnerWrapper.java:87)
at com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:134)
at com.atlassian.scheduler.core.JobLauncher.launchAndBuildResponse(JobLauncher.java:106)
at com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:90)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.launchJob(CaesiumSchedulerService.java:435)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeLocalJob(CaesiumSchedulerService.java:402)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeQueuedJob(CaesiumSchedulerService.java:380)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeJob(SchedulerQueueWorker.java:66)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeNextJob(SchedulerQueueWorker.java:60)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.run(SchedulerQueueWorker.java:35)
at java.base/java.lang.Thread.run(Thread.java:834)
2020-06-15 10:03:40,785 INFO [CrowdUsnChangedCacheRefresher:thread-1] [directory.ldap.cache.UsnChangedCacheRefresher] call found [ 0 ] remote users in [ 61ms ]
Actual problem:
To fulfill the "No highestCommittedUSN attribute found for AD root"-Warning, I live in the assumption that I need a 'cn' in a specific folder.
Example LDAP-Directory:
picture3
Pic - Example LDAP-Directory
Some Admin-Accounts were created (equal, except the cn), but none is working.
LDAP-Scheme for lookup and Basis-DN (Confluence lookup Information):
Pic - LDAP-Scheme
If i get the oreilly-openbook right, the user shall be a 'cn' as in here
dn: cn=JaneAdmin,o=vbrew
objectClass: organizationalRole
cn: JaneAdmin
description: Linux System Admin Guru
Finally:
Do I use 'the wrong Tag' (e.g.: 'cn') on the User?
Is there a flaw in the LDAP-Scheme lookup?
Does the "admin"-user need to be in another specific folder?
What else could be wrong?
Thanks already for reading :D
Finally it worked with the following sample data (no personal information in there).
The following ldif data can e.g. be imported via Apache Directory Studio into the LDAP-Directory.
Save the data via any text editor with .ldif ending.
version: 1
dn: dc=testdir,dc=net
objectClass: domain
objectClass: top
dc: testdir
dn: ou=appOne,dc=testdir,dc=net
objectClass: groupOfUniqueNames
objectClass: top
cn: appOne
uniqueMember: uid=p0009,ou=users,dc=testdir,dc=net
ou: appOne
dn: ou=appOne-Edit,ou=appOne,dc=testdir,dc=net
objectClass: groupOfUniqueNames
objectClass: top
cn: appOne-Edit
uniqueMember: uid=p0009,ou=users,dc=testdir,dc=net
ou: appOne-Edit
dn: ou=appOne-Lead,ou=appOne,dc=testdir,dc=net
objectClass: groupOfUniqueNames
objectClass: top
cn: appOne-Lead
uniqueMember: uid=p0009,ou=users,dc=testdir,dc=net
ou: appOne-Lead
dn: ou=appOne-Read,ou=appOne,dc=testdir,dc=net
objectClass: groupOfUniqueNames
objectClass: top
cn: appOne-Read
uniqueMember: uid=p0009,ou=users,dc=testdir,dc=net
ou: appOne-Read
dn: ou=appTwo,dc=testdir,dc=net
objectClass: groupOfUniqueNames
objectClass: top
cn: appTwo
uniqueMember: uid=p0009,ou=users,dc=testdir,dc=net
ou: appTwo
dn: ou=appTwo-Edit,ou=appTwo,dc=testdir,dc=net
objectClass: groupOfUniqueNames
objectClass: top
cn: appTwo-Edit
uniqueMember: uid=p0009,ou=users,dc=testdir,dc=net
ou: appTwo-Edit
dn: ou=appTwo-Lead,ou=appTwo,dc=testdir,dc=net
objectClass: groupOfUniqueNames
objectClass: top
cn: appTwo-Lead
uniqueMember: uid=p0009,ou=users,dc=testdir,dc=net
ou: appTwo-Lead
dn: ou=appTwo-Read,ou=appTwo,dc=testdir,dc=net
objectClass: groupOfUniqueNames
objectClass: top
cn: appTwo-Read
uniqueMember: uid=p0009,ou=users,dc=testdir,dc=net
uniqueMember: uid=p1115,ou=users,dc=testdir,dc=net
ou: appTwo-Read
dn: ou=roles,dc=testdir,dc=net
objectClass: organizationalUnit
objectClass: top
ou: roles
dn: ou=users,dc=testdir,dc=net
objectClass: organizationalUnit
objectClass: top
ou: users
dn: uid=p1110,ou=users,dc=testdir,dc=net
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: p1110
sn: Maribel Speed
uid: p1110
userPassword:: p1110
dn: uid=p1111,ou=users,dc=testdir,dc=net
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: p1111
sn: Bryce Holt
uid: p1111
userPassword:: p1111
dn: uid=p1112,ou=users,dc=testdir,dc=net
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: p1112
sn: Wade Whitmore
uid: p1112
userPassword:: p1112
dn: uid=p1113,ou=users,dc=testdir,dc=net
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: p1113
sn: Darlene Shepherd
uid: p1113
userPassword:: p1113
dn: uid=p1114,ou=users,dc=testdir,dc=net
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: p1114
sn: Andrew Dixon
uid: p1114
userPassword:: p1114
dn: uid=p1115,ou=users,dc=testdir,dc=net
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: p1115
sn: Summer Pond
uid: p1115
userPassword:: p1115
dn: uid=p0009,ou=users,dc=testdir,dc=net
objectClass: inetOrgPerson
objectClass: organizationalPerson
cn: admin
sn: super
uid: p0009
userPassword:: admin
Have fun ;-)

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

LDAP : Uploading LDIF

I am trying to upload entries to LDAP, but i keep getting error.
I have installed LDAP server in STS, and created my new partition as so :
name : messenger
id : o=messenger
cache=100
Auto generate Context Entry = unchecked
After starting the server and connecting, i try to upload the following ldif file :
dn: ou=roles, o=messenger
objectClass: top
objectClass: organizationalunit
ou: roles
dn: ou=people, o=messenger
objectClass: top
objectClass: organizationalunit
ou: people
dn: cn=USER, ou=roles, o=messenger
objectClass: top
objectClass: groupOfNames
cn: USER
member: uid=Lazaruss, cn=Bojan Milojkovic, ou=people, o=messenger
member: uid=Kale, cn=Davor Milojkovic, ou=people, o=messenger
member: uid=Jovana, cn=Jovana Pozek, ou=people, o=messenger
dn: cn=ADMIN, ou=roles, o=messenger
objectClass: top
objectClass: groupOfNames
cn: ADMIN
member: uid=Lazaruss, cn=Bojan Milojkovic, ou=people, o=messenger
dn: uid=Lazaruss, cn=Bojan Milojkovic, ou=people, o=messenger
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Bojan Milojkovic
sn: Milojkovic
uid: Lazaruss
name: Bojan
userPassword: Welcome11
dn: uid=Kale, cn=Davor Milojkovic, ou=people, o=messenger
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Davor Milojkovic
sn: Milojkovic
uid: Kale
name: Davor
userPassword: Kale01
dn: uid=Koala, cn=Jovana Pozek, ou=people, o=messenger
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Jovana Pozek
sn: Pozek
uid: Koala
name: Jovana
userPassword: zrenjanin
But it keeps failing with error :
LDAP: error code 32 - NO_SUCH_OBJECT: failed for MessageType :
ADD_REQUEST...
...
ERR_251_PARENT_NOT_FOUND Parent cn=Bojan Milojkovic, ou=people,
o=messenger not found
Please help.
You need to add the entry for cn=Bojan Milojkovicbefore the entry for uid=Lazaruss. Or possibly you intend for these to be a single entry, in which case its RDN should be formed as uid=Lazaruss+cn=Bojan Milojkovic.

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".

Add 'memberOf' attribute to ApacheDS

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.