In the first two parts of this article series,
I started listing error codes I found when implementing a new Active Directory driver.
I have done this before for other drivers, like the JDBC driver. You can read that series at:
I have enough error codes for part 5 collected, I just have to get around to writing it up!
I would love to see more people write articles like this, because we all run into error codes as we develop new drivers, and it would be awesome if you could just copy and paste the error code into Google and find out that someone else has already run into the error, and written an article explaining what went wrong and how they fixed it.
Missing Mandatory attribute:
[04/03/09 17:13:14.233]:EMEA-AD ST:
<nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.0.4294">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="user" dest-dn="CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp" event-id="mta-gwlab#200904032113
13#1#1" qualified-src-dn="O=Acme\OU=Users\CN=GetHellp" src-dn="\ACME-LAB-IDV\Acme\Users\GetHellp" src-entry-id="33273">
<add-attr attr-name="cn">
<value naming="true" timestamp="1238793114#25" type="string">GetHellp</value>
</add-attr>
<add-attr attr-name="givenName">
<value timestamp="1238793193#1" type="string">GetHelp</value>
</add-attr>
<add-attr attr-name="mail">
<value timestamp="1238793115#2" type="string">GetHellp@acme.com</value>
</add-attr>
<add-attr attr-name="preferredLanguage">
<value timestamp="1238793114#4" type="structured">
<component name="string">ENGLISH</component>
</value>
</add-attr>
<add-attr attr-name="sn">
<value timestamp="1238793114#5" type="string">Bambi</value>
</add-attr>
<add-attr attr-name="displayName">
<value>GetHelp Bambi</value>
</add-attr>
<add-attr attr-name="userPrincipalName">
<value type="string">GetHellp@acme.corp</value>
</add-attr>
<add-attr attr-name="dirxml-uACAccountDisable">
<value type="string">false</value>
</add-attr>
<password><!-- content suppressed --></password>
</add>
</input>
</nds>
[04/03/09 17:13:14.237]:EMEA-AD ST:Remote Interface Driver: Document sent.
[04/03/09 17:13:14.288]:EMEA-AD :Remote Interface Driver: Received.
[04/03/09 17:13:14.288]:EMEA-AD :
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\Acme\Drivers\IDM\EMEA-AD" version="3.5.3">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="mta-gwlab#20090403211313#1#1" level="error" type="driver-general">
<ldap-err ldap-rc="34" ldap-rc-name="LDAP_INVALID_DN_SYNTAX">
<client-err ldap-rc="34" ldap-rc-name="LDAP_INVALID_DN_SYNTAX">Invalid DN Syntax</client-err>
<server-err>00002081: NameErr: DSID-03050BF0, problem 2003 (BAD_ATT_SYNTAX), data 0, best match of:
'CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp'
</server-err>
<server-err-ex win32-rc="8321"/>
</ldap-err>
</status>
</output>
</nds>
This error bedeviled me for quite a while. I looked and looked, and nothing was wrong. Everything looked perfect in the document. In fact take a look and see if you can see the error. I was getting an LDAP INVALID DN SYNTAX as the error, and it was returning the full DN of the object in the error block but I could see nothing wrong with this document.
Ok, so if you cannot see the problem on the engine trace side of the error, look and see what the shim is doing, kick the trace up higher and higher, and often something will come out of it. Sometimes it is just enough to catch your attention and give you some new keyword to search on, or maybe some new avenue of approach to investigate.
As always, another approach is get someone else to look at it, A fresh set of eyes can often catch things you have missed. Sort of a forest and trees issue. You have been buried so deep in the problem for so long that you cannot see the issue.
Remote Loader side of above error:
DirXML: [04/03/09 17:12:21.85]: Loader: Calling subscriptionShim->execute()
DirXML: [04/03/09 17:12:21.85]: Loader: XML Document:
DirXML: [04/03/09 17:12:21.85]: <nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.0.4294">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="user" dest-dn="CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp" event-id="mta-gwlab#20090403211313#1#1" qualified-src-dn="O=Acme\OU=Users\CN=GetHellp" src-dn="\ACME-LAB-IDV\Acme\Users\GetHellp" src-entry-id="33273">
<add-attr attr-name="cn">
<value naming="true" timestamp="1238793114#25" type="string">GetHellp</value>
</add-attr>
<add-attr attr-name="givenName">
<value timestamp="1238793193#1" type="string">GetHelp</value>
</add-attr>
<add-attr attr-name="mail">
<value timestamp="1238793115#2" type="string">GetHellp@acme.com</value>
</add-attr>
<add-attr attr-name="preferredLanguage">
<value timestamp="1238793114#4" type="structured">
<component name="string">ENGLISH</component>
</value>
</add-attr>
<add-attr attr-name="sn">
<value timestamp="1238793114#5" type="string">Bambi</value>
</add-attr>
<add-attr attr-name="displayName">
<value>GetHelp Bambi</value>
</add-attr>
<add-attr attr-name="userPrincipalName">
<value type="string">GetHellp@acme.corp</value>
</add-attr>
<add-attr attr-name="dirxml-uACAccountDisable">
<value type="string">false</value>
</add-attr>
<password><!-- content suppressed --></password>
</add>
</input>
</nds>
DirXML: [04/03/09 17:12:21.85]: ADDriver: parse command
className user
destDN CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp
eventId mta-gwlab#20090403211313#1#1
association
DirXML: [04/03/09 17:12:21.85]: ADDriver: MadCommandAdd::onCommand
DirXML: [04/03/09 17:12:21.85]: ADDriver: MadCommandAdd::insertXdsAttributes()
DirXML: [04/03/09 17:12:21.85]: ADDriver: cn
DirXML: [04/03/09 17:12:21.85]: ADDriver: givenName
DirXML: [04/03/09 17:12:21.85]: ADDriver: mail
DirXML: [04/03/09 17:12:21.85]: ADDriver: preferredLanguage
DirXML: [04/03/09 17:12:21.85]: ADDriver: sn
DirXML: [04/03/09 17:12:21.85]: ADDriver: displayName
DirXML: [04/03/09 17:12:21.85]: ADDriver: userPrincipalName
DirXML: [04/03/09 17:12:21.85]: ADDriver: dirxml-uACAccountDisable
DirXML: [04/03/09 17:12:21.87]: ADDriver: Add user CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp
LDAPMod operations:
add attribute objectClass
>> user
add attribute objectCategory
>> CN=Person,CN=Schema,CN=Configuration,DC=acme,DC=corp
add attribute cn
>> GetHellp
add attribute givenName
>> GetHelp
add attribute mail
>> GetHellp@acme.com
add attribute sn
>> Bambi
add attribute displayName
>> GetHelp Bambi
add attribute userPrincipalName
>> GetHellp@acme.corp
DirXML: [04/03/09 17:12:21.90]: Loader: subscriptionShim->execute() returned:
DirXML: [04/03/09 17:12:21.90]: Loader: XML Document:
DirXML: [04/03/09 17:12:21.90]: <nds ndsversion="8.7" dtdversion="1.1">
<source>
<product version="3.5.3" asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\Acme\Drivers\IDM\EMEA-AD">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status level="error" type="driver-general" event-id="mta-gwlab#20090403211313#1#1">
<ldap-err ldap-rc="34" ldap-rc-name="LDAP_INVALID_DN_SYNTAX">
<client-err ldap-rc="34" ldap-rc-name="LDAP_INVALID_DN_SYNTAX">Invalid DN Syntax</client-err>
<server-err>00002081: NameErr: DSID-03050BF0, problem 2003 (BAD_ATT_SYNTAX), data 0, best match of:
'CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp'
</server-err>
<server-err-ex win32-rc="8321"/>
</ldap-err>
</status>
</output>
</nds>
DirXML: [04/03/09 17:12:21.90]:
DirXML Log Event -------------------
Driver = \ACME-LAB-IDV\Acme\Drivers\IDM\EMEA-AD
Thread = Subscriber Channel
Object = \ACME-LAB-IDV\Acme\Users\GetHellp (CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp)
Level = error
Message = <ldap-err ldap-rc="34" ldap-rc-name="LDAP_INVALID_DN_SYNTAX">
<client-err ldap-rc="34" ldap-rc-name="LDAP_INVALID_DN_SYNTAX">Invalid DN Syntax</client-err>
<server-err>00002081: NameErr: DSID-03050BF0, problem 2003 (BAD_ATT_SYNTAX), data 0, best match of:
'CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp'
</server-err>
<server-err-ex win32-rc="8321"/>
</ldap-err>
In this case, the remote loader shim trace was not that helpful. Sometimes the last attribute before it errors will be the culprit. In some other shims, it is the next attribute that causes the error. But at least this gives you some things to try.
You can see this part in the trace:
[04/03/09 17:12:21.85]: ADDriver: MadCommandAdd::onCommand
DirXML: [04/03/09 17:12:21.85]: ADDriver: MadCommandAdd::insertXdsAttributes()
DirXML: [04/03/09 17:12:21.85]: ADDriver: cn
DirXML: [04/03/09 17:12:21.85]: ADDriver: givenName
DirXML: [04/03/09 17:12:21.85]: ADDriver: mail
DirXML: [04/03/09 17:12:21.85]: ADDriver: preferredLanguage
DirXML: [04/03/09 17:12:21.85]: ADDriver: sn
DirXML: [04/03/09 17:12:21.85]: ADDriver: displayName
DirXML: [04/03/09 17:12:21.85]: ADDriver: userPrincipalName
DirXML: [04/03/09 17:12:21.85]: ADDriver: dirxml-uACAccountDisable
DirXML: [04/03/09 17:12:21.87]: ADDriver: Add user CN=GetHelp Bambi,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp
LDAPMod operations:
add attribute objectClass
>> user
add attribute objectCategory
>> CN=Person,CN=Schema,CN=Configuration,DC=acme,DC=corp
add attribute cn
>> GetHellp
add attribute givenName
>> GetHelp
add attribute mail
>> GetHellp@acme.com
add attribute sn
>> Bambi
add attribute displayName
>> GetHelp Bambi
add attribute userPrincipalName
>> GetHellp@acme.corp
The shim parses the XDS (Novell DirXML Script XML dialect) and converts it into operations that the shim can process, via an LDAPMod event. We see add attributes, one by one.
User Principal Name is the last attribute set, so I experimented with different values. This happens to be a child domain of the acme.corp domain, so I thought maybe it is enforcing something about user principal name. However, after testing it was clear it did not matter. Additionally I knew from a different client, that Active Directory is really strange about user principal name, as it mostly could care less about the value stored. At that particular client they had used a Global Configuration Value (GCV) to store the string to create the @acme.corp part, and in production they had made a typo and not noticed. Oops. So instead of being users.corp it was user.corp (Singular instead of plural) and there was no such domain as user.corp. They even had a SECOND typo as well! Well they had a couple of thousand users with these typos, and the only reason they noticed was that I was looking around and found it. I used one of my toolkit rules to fix the typos, and all was well. You can read more about my toolkit rule approaches at:
Using the toolkit approach, you can pretty easily change userPrincipalName in Active Directory on a whim and after some optimizing, I managed to get the entire fix down into the 5 minute range, instead of my first approach that took over 2 hours. The optimized approaches are discussed in the articles quoted above.
Well what next? Everything looks good so far, we have an overall good document, no obvious errors being called out. In this case it is often what is not there that causes the problem, instead of what is there.
I think that the issue is that two attributes were missing from this document. We have no Full Name attribute (though we do have display name, but I think that is a separate attribute from Full Name in Active Directory) and no sAMAccountName attribute.
Now sAMAccountName is usually not a mandatory as Active Directory seems to set a random value, starting with a dollar sign ($) if you do not specify one. But Full Name is mandatory in Active Directory schema, which is why the default Active Directory driver config has a rule in the Subscriber Create rule to veto if operational attribute Full Name is not available. In my case, we had been goofing around with schema mapping rules, and trying to be more like Active Directory in eDirectory. I know, I know, crazy, but we had a reason, maybe not a great reason, but a reason. Anyway, we were trying to map sAMAccountName in Active Directory to sAMAccountName in eDirectory, but gave up on it in the end.
At least I think that is why this error was occurring.
LDAP Server Down:
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20060706_164400" instance="\ACME-META\CIM\DirXML\Active Directory (bogota.acme.corp)" version="3.1.1">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="OSGLX002#20090401061654#1#1" level="retry" type="driver-general">
<ldap-err ldap-rc="81" ldap-rc-name="LDAP_SERVER_DOWN">
<client-err ldap-rc="81" ldap-rc-name="LDAP_SERVER_DOWN">Server Down</client-err>
</ldap-err>
</status>
</output>
</nds>
09:32:09 D7111BA0 Drvrs: bogotaLog ST:Applying schema mapping policies to input.
09:32:09 D7111BA0 Drvrs: bogotaLog ST:Applying policy: SchemaMapping.
09:32:09 D7111BA0 Drvrs: bogotaLog ST:Resolving association references.
09:32:09 D7111BA0 Drvrs: bogotaLog ST:Requesting 30 second retry delay.
09:32:09 D7111BA0 Drvrs: bogotaLog ST:
DirXML Log Event -------------------
Driver: \ACME-META\CIM\DirXML\Active Directory (bogota.acme.corp)
Channel: Subscriber
Status: Retry
Message: Code(-9006) The driver returned a "retry" status indicating that the operation should be retried later. Detail from driver: <ldap-err ldap-rc="81" ldap-rc-name="LDAP_SERVER_DOWN">
<client-err ldap-rc="81" ldap-rc-name="LDAP_SERVER_DOWN">Server Down</client-err>
</ldap-err>
We were getting a copy of a production driver working in the lab, and as we worked on starting up the driver we were getting this on a driver start. I think what happened was the password for the remote loader to authenticate with was wrong. We should have gotten the next error, LDAP AUTH UNKNOWN but instead we started with this error. It may be that we did not even offer a password in the driver configuration. When you import a driver from another tree the passwords do not come with it. They are stored encrypted and are not exportable. I often forget to properly reset them, see this error, smack myself on the forehead, say Doh, fix it and move on.
Bad password for Admin account in AD, on driver startup.
DirXML Log Event -------------------
Driver: \ACME-META\CIM\DirXML\Active Directory (bogota.acme.corp)
Channel: Publisher
Status: Fatal
Message: <message>unable to authenticate to Active Directory</message>
<ldap-err ldap-rc="86" ldap-rc-name="LDAP_AUTH_UNKNOWN">
<client-err ldap-rc="14"/>
</ldap-err>
[04/06/09 09:41:14.979]:bogotaLog PT:
DirXML Log Event -------------------
Driver: \ACME-META\CIM\DirXML\Active Directory (bogota.acme.corp)
Channel: Publisher
Status: Fatal
Message: Code(-9005) The driver returned a "fatal" status indicating that the driver should be shut down. Detail from driver: <message>unable to authenticate to Activ
e Directory</message>
<ldap-err ldap-rc="86" ldap-rc-name="LDAP_AUTH_UNKNOWN">
<client-err ldap-rc="14"/>
</ldap-err>
<application>DirXML</application>
<module>Active Directory (bogota.acme.corp)</module>
<object-dn></object-dn>
<component>Publisher</component>
After the previous error of LDAP SERVER DOWN, I set the password, and now got LDAP AUTH UNKOWN. This error I have referenced before in the article: Troubleshooting Synchronization in Identity Manager Installations and this is an easy one. Turns out, I set the password incorrectly.
LDAP Attribute or Value Exists error:
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\Acme\Drivers\IDM\EMEA-AD" version="3.5.3">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="Xidv1#20090407204533#1#1" level="error" type="driver-general">
<ldap-err ldap-rc="20" ldap-rc-name="LDAP_ATTRIBUTE_OR_VALUE_EXISTS">
<client-err ldap-rc="20" ldap-rc-name="LDAP_ATTRIBUTE_OR_VALUE_EXISTS">Attribute Or Value Exists</client-err>
<server-err>00002081: AtrErr: DSID-030F1225, #1:0: 00002081: DSID-030F1225, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 160027 (preferredLanguage)
</server-err>
<server-err-ex win32-rc="8321"/>
</ldap-err>
</status>
</output>
</nds>
I did not catch the event that triggered this error, but it was setting a value, and eDirectory provided the old value to be removed. But the value it provided was wrong. To resolve this one, figure out why it sent the wrong value to be removed and resolve that one. This is also possible when the engine is sending an add value command that already was there. Sort of like eDirectory's 606 error, attribute already exists.
This is why you will so often see an XDS document go by with a <remove-all-values> node before the <add-value> node. That is the difference between a set destination attribute and an add destination attribute token. With Set Destination Attribute, you always get a <remove-all-values> node first. With Add Destination Attribute the engine tries to decide what to do, based on what it reads out of both directories and optimizes to clean up the event.
Setting two values in a single valued attribute:
<nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.0.4294">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="user" dest-dn="CN=Another Test,OU=NeverJustBritain,OU=UnitedKingdom,dc=emea,dc=acme,dc=corp" event-id="mta-gwlab#20090407213955#1#1" qualified-src-dn="O=Acme\OU=Users\CN=AnotherT" src-dn="\ACME-LAB-IDV\Acme\Users\AnotherT" src-entry-id="33274">
<add-attr attr-name="cn">
<value naming="true" timestamp="1239137766#25" type="string">AnotherT</value>
</add-attr>
<add-attr attr-name="displayName">
<value timestamp="1239137959#7" type="string">Another Test</value>
</add-attr>
<add-attr attr-name="givenName">
<value timestamp="1239137959#1" type="string">Another</value>
</add-attr>
<add-attr attr-name="mail">
<value timestamp="1239137768#2" type="string">AnotherT@acme.com</value>
</add-attr>
<add-attr attr-name="sn">
<value timestamp="1239137766#5" type="string">Test</value>
</add-attr>
<add-attr attr-name="title">
<value timestamp="1239138795#1" type="string">Mr</value>
</add-attr>
<add-attr attr-name="userPrincipalName">
<value timestamp="1239140395#2" type="string">AnotherT@emea.acme.corp</value>
</add-attr>
<add-attr attr-name="userPrincipalName">
<value type="string">AnotherT@acme.corp</value>
</add-attr>
<add-attr attr-name="dirxml-uACAccountDisable">
<value type="string">false</value>
</add-attr>
<add-attr attr-name="preferredLanguage">
<value>ENGLISH</value>
</add-attr>
<password><!-- content suppressed --></password>
</add>
</input>
</nds>
[04/07/09 17:39:55.895]:EMEA-AD ST:Remote Interface Driver: Document sent.
[04/07/09 17:39:55.910]:EMEA-AD :Remote Interface Driver: Received.
[04/07/09 17:39:55.910]:EMEA-AD :
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\Acme\Drivers\IDM\EMEA-AD" version="3.5.3">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="mta-gwlab#20090407213955#1#1" level="error" type="driver-general">
<ldap-err ldap-rc="19" ldap-rc-name="LDAP_CONSTRAINT_VIOLATION">
<client-err ldap-rc="19" ldap-rc-name="LDAP_CONSTRAINT_VIOLATION">Constraint Violation</client-err>
<server-err>00002081: AtrErr: DSID-03151667, #1:
0: 00002081: DSID-03151667, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 90290 (userPrincipalName)
</server-err>
<server-err-ex win32-rc="8321"/>
</ldap-err>
</status>
</output>
</nds>
Here I goofed as I was trying to figure out if something was wrong with how I was setting UPName (User Principal Name) in Active Directory. (Can you guess which error I was trying to troubleshoot when this happened? Yep the missing mandatory from above. I was testing to be sure that User Principal Name did not care what value you inserted there) You can see that two values for userPrincipalName are being added. But of course in Active Directory schema defines userPrincipalName as single valued. Thus the LDAP Constraint violation error. We violated schema. This is similar to eDirectory's 613 invalid syntax errors that you might see in the Publisher channel.
Now I specifically added this in code, by mistake, (I added a new action to add the value, but forgot to disable the original action), so it depends where you do it, to see where you need to fix it.
My boss came up with a beautifully elegant solution to this general case problem, for use in the Output Transform rule. We probably will write an article about it later, but the idea was simplicity in itself and very elegant. The driver actually stores the application schema in an attribute on the Driver object, called DirXML-ApplicationSchema. Go take a look at it, it is long XML text string, that defines the application schema, as it retrieved it from the application.
Well it notes what attributes are multi valued and which are not. Well then, how hard would it be to grab that attribute from the driver, then for each attribute in the output document, check the schema, see if it multi or single valued, look at the output document and clean up if needed.
Sounds hard and complex? Well the XPATH is pretty cute, and it turns really short and simple to implement! He got it down to 14 lines of code in the Policy view!! One for-each, and an IF-THEN test! Amazing! Took me three or four times reading through to figure out what he was doing. Then I had to fix it a little since he forgot to check object class at the same time. But it was so elegant and simple that it was easy to fix, once I understood it.
I was concerned how much additional time it would add to events, since every output document needs to have the process repeated, but I was pleasantly surprised that it was really only a few milliseconds when I watched in trace. Look out for that article one of these days in the future.
This new rule was not yet in place, else it would have cleaned up this event and I never would have seen the error. Of course, I would have wondered where my attribute went to, as the cleanup solution (which can be modified to what you want) was set to only take the first value and throw away any extra values on single valued attributes. But you could easily change it to concatenate the values into a comma separated string or anything you like.
There is one minor twist we ran into where the DirXML-ApplicationSchema says two attributes (at least) are multi valued in Active Directory, but actually are not as far as we can tell.
Active Directory version of eDirectory 601 error:
[04/08/09 09:03:32.194]:Corp log ST:Remote Interface Driver: Sending...
[04/08/09 09:03:32.195]:Corp log ST:
<nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.5.10.20070918 ">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="group" dest-dn="CN=PMO,ou=GROUPS,ou=Dallas ,dc=acme,dc=corp" event-id="OSGLX002#20090408122945#1#1" qualified-src-dn="O=CIM\OU=Group\CN=PMO" src-dn="\ACME-META\CIM\Group\PMO" src-entry-id="40784">
<add-attr attr-name="description">
<value timestamp="1239137798#6" type="string">Access to PMO folder under Shares S:</value>
</add-attr>
<add-attr attr-name="member">
<value association-ref="a9152ff3e27f4d4d9b0c5ce484b41aa2" timestamp="1239138020#1" type="dn">\ACME-META\CIM\Person\Users\smithj</value>
</add-attr>
<add-attr attr-name="sAMAccountName">
<value type="string">PMO</value>
</add-attr>
</add>
</input>
</nds>
[04/08/09 09:03:32.206]:Corp log ST:Remote Interface Driver: Document sent.
[04/08/09 09:03:32.242]:Corp log :Remote Interface Driver: Received.
[04/08/09 09:03:32.243]:Corp log :
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20070823_095000" instance="\ACME-META\CIM\DirXML\Active Directory (acme.corp)" version="3.5.
1">AD</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="OSGLX002#20090408122945#1#1" level="warning" type="driver-general">
<ldap-err ldap-rc="32" ldap-rc-name="LDAP_NO_SUCH_OBJECT">
<client-err ldap-rc="32" ldap-rc-name="LDAP_NO_SUCH_OBJECT">No Such Object</client-err>
<server-err>0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of:
'DC=acme,DC=corp'
</server-err>
<server-err-ex win32-rc="8333"/>
</ldap-err>
</status>
</output>
</nds>
This is the Active Directory version of eDirectory's 601 error, object not found (or put another way, no such object).
In this case, the dest-dn has a bad DN, one of the OU's was renamed under us, so the object no longer exists. This particular case is pretty rare as two of us were goofing around and making change sin the lab at exactly the same time, and I was still trying to get some of the settings quite correct.
But you can imagine, if you generate a bad destination DN in your placement rule. how you could trigger this other ways. Here I was trying to place the object in a container that did not exist, thus the DN was not valid.
Tried setting CN to a short value, making it multi valued
<nds dtdversion="1.1" ndsversion="8.7">
<source>
<product asn1id="" build="20080229_143300" instance="\ACME-LAB-IDV\Acme\Drivers\IDM\EMEA-AD" version="3.5.3">AD</
product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status event-id="EMEA-AD##120a0d36d2c##0" level="error" type="driver-general">
<ldap-err ldap-rc="67" ldap-rc-name="LDAP_NOT_ALLOWED_ON_RDN">
<client-err ldap-rc="67" ldap-rc-name="LDAP_NOT_ALLOWED_ON_RDN">Not allowed on RDN</client-err>
<server-err>000020B1: UpdErr: DSID-030F0AE8, problem 6004 (CANT_ON_RDN), data 0
</server-err>
<server-err-ex win32-rc="8369"/>
</ldap-err>
</status>
</output>
</nds>
This error is a little different than the invalid syntax error from above. In that case, it was a simple schema violation on a normal every day attribute. That is a simple schema syntax error. In this case, (sorry I did not keep the original event) I had sent too many CN values, and since CN is a naming attribute it is not a simple syntax problem, it is a bigger LDAP NOT ALLOWED ON RDN since the CN is the Relative Distinguished Name of the object. We sometimes call the full DN the FQDN, Fully Qualified Distinguished Name, and thus the first part is the Relative Distinguished Name.
On that note, it seems like a good time wrap this one up. Stay tuned for more articles in this series. I have lots more error codes and examples to show you and talk about.
My collection of eDirectory error codes is growing, and I just recently got a really good set of Role Based Entitlement driver errors, so look out for those articles coming soon.
Hope you enjoy this series, and that you find it helpful. As always, if you do, consider contributing some errors you ran into yourself to help pay it forward!!
Support
Documentation
Learning Services
Partner Programs