Hey all,

We have ID-Sync for Windows installed and connected to our test AD and test DSEE instance. Everything appears to be configured correctly, the idsync resync command shows that data is being read and that accounts are connected, but the ISW attributes in the LDAP (destinationIndicator, the dspsw* attrs) are always blank.

One the account that I am using to test with, there are always LDAP error 65 messages in the LDAP log for the "bannerID" (an internal attr that we use, similar to an employee ID) whenever ISW tries to access the account. The ACL for the ISW service account allows full read/write access for the entire subtree, and this is the only app or account that has trouble with this attribute.

Has anyone else seen this error, or does anyone have any input as to what might be causing this error?

 

 

Error code 65 means an objectclass violation.
Something is trying to modify the bannerID in a way that would step outside of objectclass rules.
Questions to ask yourself:
- Is the bannerID a required attribute?
- Is the app trying to remove (delete) the bannerID attribute from an entry?
- Is the app trying to add an entry without a bannerID attribute?

 

 

Digging through the logs, I see these errors on the LDAP connector:

[12/Jun/2007:14:12:16.860 -0500] FINE    335  CNN101 dsdev  "LDAP Modify Request: [REPLACE dspswuserlink: yG+lkU1n1k+xRt
Qkx3xPnw==] [REPLACE dspswvalidate: true] [REPLACE objectclass: dspswuser, inetOrgPerson] [REPLACE dspswloop: true] [REP
LACE dspswloop: ] "
[12/Jun/2007:14:12:16.868 -0500] FINE    335  CNN101 dsdev  "LDAP operation on entry uid=aax328,ou=People,dc=utsa,dc=edu
 failed at ldap://dsdev:1389, error(65): Object class violation." (Action ID=CNN100-112DF11532B-24754, SN=9)
[12/Jun/2007:14:12:16.871 -0500] SEVERE  335  CNN101 dsdev  "LDAP modify operation of entry uid=aax328,ou=People,dc=utsa
,dc=edu failed at null. Error code: 65, reason: null" (Action ID=CNN100-112DF11532B-24754, SN=10)
 

This leads me to think that the LDAP connector is intentionally trying to replace the entire list of objectclasses that an object belongs to with the two objectclasses "dpswsuser" and "inetOrgPerson". I can see adding the "dspswuser" objectclass if it doesn't exist, in order to make sure that the dspsw attrs are available on every object (not the most elegant way, but...OK), but completely replacing all objectclasses???

We have 2 objectclasses that extend upon inetOrgPerson, a custom internal one, and the eduPerson schema from EduCause. I have hunted through the documentation and the config GUI for ISW, and I can not find anywhere where this is mentioned.

 

 

I'm having the same issues on two different ISW installation (along with DSEE 6.2). I've not yet found the solution.

How did you fixed it ?

Olivier.

 

 

Hate to add nothing other than a me too to this thread but I just got started with ISW and ran into the very same thing. DSEE6.2 with a test user added by Comms Suite 5. It does look like it wants to add object classes that already exist for the user. Any pointers appreciated.--

 

 

A fix is available from Sun support, when contacting support please reference bug 6691600. ?Users with auxiliary objectclasses fail to link?

follow these steps:

1. stop the IMQ and ISW instances.
2. backup /opt/SUNWisw/lib/connector.jar
3. Replace the connector.jar at the installation directory (/opt/SUNWimq/lib/connector.jar) with the one from Sun support
4. Repeat this procedure on all the hosts which has the Connectors installed.
5. Start IMQ and ISW

Edited by: JoGersh on May 2, 2008 1:57 PM

 

 

I just applied the fix and now it fails because it does not seem to attempt to add the object class of dspswuser when linking. This causes another object class violation, this time on the dspswuserlink attribute. Is it just me or is anyone else encountering this problem with the hot fix?

 

 

I have the same problem. But didn't know where to download the connector.jar for work around, any ideas?

 

 

AFAIK, the hot fix (connector.jar) is only available from Sun Support. I may be wrong though, it has happened before ;-).

 

 

Thank you for your reply. I've replaced the connector.jar, but still getting the same problem...

 

 

As you can tell from previous posts, the hotfix did not correct the issue for me either. I'm working with Sun support. When I have an answer, I'll post here.

 

 

How do I add "shadowaccount", "posixaccount" to the Auxilary objectclass in the ISW console ?

---

Bug ID: 6691600

Synopsis: linking fails for existing SunDS entries which contain auxiliary objectclasses performs replace op

Category: idsync

Subcategory: linkusers-resync

State: 8-Fix Available

Description:

When linking users to/from SunDS/AD connector it will fail on existing entries on the SunDS
source if the entry contains any objectclass outside the default 'inetOrgPerson'. The failure
will be seen in the ISW audit logs showing "error(65): Object class violation" and in the
SunDS errors log with some more detailed reasons for the schema violation. The violation
will take place on the entries first attribute that falls outside the 'inetOrgPerson' OC and parent entries.

Date Modified: 2008-04-21 19:25:14 GMT+00:00


Work Around:

add all objectclass in the Auxilary objectclass filed in the ISW console.

ex. take the case mentioned in the comment.
the workaround is add "shadowaccount", "posixaccount" to the Auxilary objectclass in the ISW console

Date Modified: 2008-04-28 13:22:38 GMT+00:00

 

 

I am trying to sync group between AD to Sun Ldap. I am able to sync groups successfully but while syncing groups I am getting element mapper error, I tried above workaround also, but no luck. Does anyone did successful synchronization between.
Please provide me detail of attribute for group synchronization

 

 

Hi,

I have included all the available objectClasses in the console (in auxilliary objectClass).
I also disabled schema checking in the directory server (bad bad bad).

Replication is working and the linking is performed.
However objectClasses like posixAccount, shadowAccount, ntUser are deleted from LDAP ... even if "-o Sun" is specified in idsync.
In advance the attributes of those objectClasses are not deleted.

Any news on this?

thanx in advance
Giannis

 

 

Hi Giannis, First you are correct you should not have schema checking turned off in the DS. The reason the attributes are not removed is due to the schema checking is disabled. It is also the reason it is allowing the objectclasses to be removed in the first place. What I need to see to fix your configuration is an example from your ISW log file. The log level in ISW needs to be set to "FINE". Make sure a user is added which will require linking and creation on the AD side and it does contain the correct auxiliary objectclasses & attributes. Perform the "idsync resync -o Sun" again and provide me a sample here that would look like the following. This will be in the audit log from the SunDS connector (CNN100) most times.

[16/Jul/2008:18:18:30.349 -0400] FINE 80 CNN100 power "The accessor has received the following outbound a
ction from the controller: Type: LINK SUL: SUL1 {Data Attrs: [REPL dspswuserlink: euSrPbvwO0qJBtS9QNDhKg==] [A
DD objectclass: dspswuser, inetOrgPerson]} {Other Attrs: dspswuserlink: euSrPbvwO0qJBtS9QNDhKg== dn: uid=hdoe,
ou=people,dc=sun,dc=com}." (Action ID=CNN101-11B2DE216AF-13, SN=5)
[16/Jul/2008:18:18:30.353 -0400] FINE 80 CNN100 power "LDAP Modify Request: [REPLACE dspswuserlink: euSrP
bvwO0qJBtS9QNDhKg==] [REPLACE objectclass: dspswuser, inetOrgPerson, organizationalPerson, person, top, shadow
Account, posixAccount] [REPLACE dspswloop: true] [REPLACE dspswloop: ] "

The hotfix works properly, so the issue is within your ISW configuration.

Joel