IdB NIM - Updates from Identity Broker not Presented to NIM

Hi Nick,

There's four change types for an adapter; Add, Delete, Modify and ModifyDN. The first three are supported by the adapter, the last one is not. I'm not sure why but I would guess there's a pretty good reason right now.

Is this DN change intentional on your part? If not, it might be worth looking to see if all the DNs that are being used are the same (FIM adapter generation, NIM adapter generation, FIM provisionining, whatever NIM does, etc)

Patrick, I am not trying to modify the DN, that is why we selected a GUID rather than the IdBID.

The modification I was trying to process was the addition of a Telephone Number. I am pretty sure that whatever the change is will have the same result.

This error is consistently reproducible in the lab if you want me to run you through it.

Ok, I think Adam and I have got it now.

I can provide you with something that should fix it and I'll explain what the problem is, but before I do that can you paste me XML samples for the following;

• New export
• Modify export

Specifically, I need to ensure that the DN is being sent through and matches what the adapter DN generators will create on an import.

New & Modify Export from NIM to Identity Broker

Ok, I suspect our original idea is not going to work as planned. Adam and I believe the problem is as follows (need to confirm with a solution obviously, but we're relatively sure);

Essentially the problem is that every export to Identity Broker, regardless of adapter source, needs to set a DN. In FIM this is mandatory and the DN is always set to the DN of the CSEntry, which is why we mandate that it has to be the same as the DN generation rule in the AdapterEngine file.

The NIM adapter does not appear to be setting the DN at all. As a result, the DN is null, so when the subsequent Identity Broker import creates one it changes from "null" to "UID=

" in all exports just as FIM is expected to do, we read it out and set it accordingly. It's easy for us, but obviously I can't speak for whether this is even possible for you to do.

If it's too difficult in the time frame you require, there is an 'extreme' option which is that I can hard code it to use "UID=

" as the DN, which will work for you but probably nowhere else. Not ideal, but it'll get you past this blocker issue. We'd still need to solve this some time down the road.

Hey Patrick, I have attempted to set the DN on export, here is an extract from the log:

6/06/2012 12:28:19.16v: 0 CIT Driver L3 ST:Submitting document to subscriber shim:
6/06/2012 12:28:19.16v: 0 CIT Driver L3 ST:
<nds dtdversion="3.5" ndsversion="8.x">
<source>
<product version="3.6.10.4747">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="person" event-id="W2K3-R2-001-NDS#20120606022818#1#1" qualified-src-dn="O=RES\OU=Users\OU=User\CN=BJ100843" src-dn="\SAWWFT\RES\Users\User\BJ100843" src-entry-id="35204">
<association state="manual"></association>
<add-attr attr-name="cn">
<value naming="true" timestamp="1303907772#31" type="string">BJ100843</value>
</add-attr>
<add-attr attr-name="company">
<value timestamp="1328238673#2" type="string">BRINY CITY COUNCIL</value>
</add-attr>
<add-attr attr-name="fullName">
<value timestamp="1316739347#32" type="string">Bjorn, </value>
</add-attr>
<add-attr attr-name="objectGUID">
<value timestamp="1303907772#32" type="octet">+FWpu6G1JU6k3G1IQepUvA==</value>
</add-attr>
<add-attr attr-name="sn">
<value timestamp="1303907772#3" type="string">Bjorn</value>
</add-attr>
<add-attr attr-name="title">
<value timestamp="1305977547#4" type="string">LIBRARY OFFICER</value>
</add-attr>
<add-attr attr-name="workforceID">
<value timestamp="1303907772#7" type="string">100843</value>
</add-attr>
<add-attr attr-name="DN">
<value type="dn">UID=+FWpu6G1JU6k3G1IQepUvA==</value>
</add-attr>
</add>
</input>
</nds>
6/06/2012 12:28:19.17v: 0 CIT Driver L3 ST:UnifySubscriptionShim: execute start
6/06/2012 12:28:19.17v: 0 CIT Driver L3 ST:UnifySubscriptionShim: createWebServiceInterface: URL: http://192.168.16.230:59990/IdentityBroker/NIMDriver.svc?wsdl
6/06/2012 12:28:19.17v: 0 CIT Driver L3 ST:UnifySubscriptionShim: createWebServiceInterface: Creating service
6/06/2012 12:28:19.17v: 0 CIT Driver L3 ST:UnifySubscriptionShim: createWebServiceInterface: Creating interface
6/06/2012 12:28:19.19v: 0 CIT Driver L3 ST:UnifySubscriptionShim: createWebServiceInterface: Returning port
6/06/2012 12:28:19.20v: 0 CIT Driver L3 ST:UnifySubscriptionShim: execute end
6/06/2012 12:28:19.20v: 0 CIT Driver L3 ST:SubscriptionShim.execute() returned:
6/06/2012 12:28:19.20v: 0 CIT Driver L3 ST:
<nds dtdversion="1.0" ndsversion="8.5">
<output>
<response event-id="W2K3-R2-001-NDS#20120606022818#1#1" level="error">
Unify.Framework.AdapterSchemaException: 1 items failed schema validation during Adapter operation. Check log for validation errors.
at Unify.Framework.Adapter.SaveEntities(IEnumerable`1 entities, Boolean reflect, Boolean ignoreChanges)
at Unify.Framework.Adapter.SaveEntities(IEnumerable`1 entities, Boolean reflect)
at Unify.Framework.Adapter.SaveEntity(IAdapterEntity entity, Boolean reflect)
at Unify.Framework.AdapterNotifierDecorator.SaveEntity(IAdapterEntity entity, Boolean reflect)
at Unify.Adapters.NovellIdentityManagerIdentityBrokerDriverAdapter.PerformSubscribeAddAction(XElement actionNode, IAdapter adapter)
</response>
</output>
</nds>

I can't find any additional information in the IdB Logfiles... Any suggestions

Hi Patrick, the value that is returned for the "Association" is supposed to be the DN of the record in the connected system.

I believe that it would be valid to set the DN to that whatever that value is, is it possible to do that within IdB?

... I also don't understand the comment that the DN is not set in IdB as it shows in the UNIFY Management console?

I wasn't very clear on a few things, so let me clarify

• The DN we need to export from NIM would be a kind of "metadata", not an entity field. Take your src-dn field for example - I actually thought that would be "UID= {objectGUID}" as it would be in FIM, but obviously you have your own internal DNs as well. There would need to be a new attribute on the add/modify element, something like target-dn, which is equal the DN IdB generates.
  
  * It appears as though there's a few "associations" returned - srcDn and srcId being two of them, the other being the single-valued key (objectGUID). None of these match "UID={objectGUID}

  " - perhaps they should, you'd have to let me know. We can't use your current srcDn as the DN as the DN generators in the AdapterEngine would have to generate exactly the same thing.

• Regarding the last statement, the DN is not set by the NIM adapter (our 'bug', but I need to know where I can get a valid DN before I can set it and give you the fix) as the FIM adapter is required to do, just the subsequent import. As a result, the entity starts with null on the export and ends with _UID= {objectGUID}

  _ on the import (which is the DN you're seeing in the console). This fires of a "Modify DN" as Identity Broker thinks the DN has been changed and it needs to notify the adapted source that it should be moved.

If you'd like to arrange a Lync session I can show you on my screen as I think that'll help me explain it better. I'm free all afternoon.

Hi Nick,

Attached is the fix we discussed. Let me know if this solves your problem.