Specifying Link criteria - integrating AD password into Domino
zquickr
Followed the excellent video from Eddie Hartmann but it's showing ver.
6.
It is when I'm running my assembly line - it seems like I have not
specified my "Link Criteria" the right way.
Here is a video showing the problem: http://screencast.com/t/M2I2MzNm
I have tested that I can connect to Domino and also AD before using my
"connectors"
When I click Run - the following err.msg'es appear in the console log:
-
14:35:43,734 INFO - [DeleteDomino] CTGDKC096I Opening Session to
Domino Server: Session Type='LocalClient',,
Hostname='uquickr02.hansenberg.dk', User ID='{2}', Requested IIOP/
SSL='false'.
14:35:44,062 INFO - [DeleteDomino] CTGDKC095I Session to Domino
Server is created.
14:35:44,062 INFO - [DeleteDomino] CTGDKC012I Sucessfully connected
to Domino Server: Name='', Version='Release 8.0.2|August 07,
2008 ', Platform='Windows/32'.
14:36:00,890 INFO - [DeleteDomino] CTGDKC018I Successfully opened the
Administration Requests Database: admin4.nsf.
14:36:00,906 INFO - [UpdateDomino] CTGDKC096I Opening Session to
Domino Server: Session Type='LocalClient',,
Hostname='uquickr02.hansenberg.dk', User ID='{2}', Requested IIOP/
SSL='false'.
14:36:00,906 INFO - [UpdateDomino] CTGDKC095I Session to Domino
Server is created.
14:36:00,906 INFO - [UpdateDomino] CTGDKC012I Sucessfully connected
to Domino Server: Name='', Version='Release 8.0.2|August 07,
2008 ', Platform='Windows/32'.
14:36:01,531 INFO - [UpdateDomino] CTGDKC018I Successfully opened the
Administration Requests Database: admin4.nsf.
14:36:01,531 INFO - CTGDIS087I Iterating.
14:36:02,312 ERROR - [UpdateDomino] CTGDIS810E handleException -
cannot handle exception , update
java.lang.Exception: CTGDIS143E No criteria can be built from input
(no link criteria specified).
at
com.ibm.di.server.SearchCriteria.buildCriteria(SearchCriteria.java:
1093)
at
com.ibm.di.server.AssemblyLineComponent.update(AssemblyLineComponent.java:
1639)
at
com.ibm.di.server.AssemblyLine.msExecuteNextConnector(AssemblyLine.java:
3630)
at
com.ibm.di.server.AssemblyLine.executeMainStep(AssemblyLine.java:
3259)
at
com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:
2899)
at
com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:
2882)
at com.ibm.di.server.AssemblyLine.executeAL(AssemblyLine.java:
2849)
at com.ibm.di.server.AssemblyLine.run(AssemblyLine.java:1285)
14:36:02,312 ERROR - CTGDIS266E Error in NextConnectorOperation.
Exception occurred: java.lang.Exception: CTGDIS143E No criteria can be
built from input (no link criteria specified).
java.lang.Exception: CTGDIS143E No criteria can be built from input
(no link criteria specified).
at
com.ibm.di.server.SearchCriteria.buildCriteria(SearchCriteria.java:
1093)
at
com.ibm.di.server.AssemblyLineComponent.update(AssemblyLineComponent.java:
1639)
at
com.ibm.di.server.AssemblyLine.msExecuteNextConnector(AssemblyLine.java:
3630)
at
com.ibm.di.server.AssemblyLine.executeMainStep(AssemblyLine.java:
3259)
at
com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:
2899)
at
com.ibm.di.server.AssemblyLine.executeMainLoop(AssemblyLine.java:
2882)
at com.ibm.di.server.AssemblyLine.executeAL(AssemblyLine.java:
2849)
at com.ibm.di.server.AssemblyLine.run(AssemblyLine.java:1285)
14:36:02,343 INFO - CTGDIS100I Printing the Connector statistics.
14:36:02,343 INFO - [ADChanges] Get:1
14:36:02,343 INFO - [IF delete] Branch True:0, Branch False:1
14:36:02,343 INFO - [DeleteDomino] Not used
14:36:02,359 INFO - [ELSE] Branch True:1, Branch False:0
14:36:02,359 INFO - [UpdateDomino] Errors:1
14:36:02,359 INFO - CTGDIS104I Total: Get:1, Errors:2.
14:36:02,359 INFO - CTGDIS101I Finished printing the Connector
statistics.
14:36:02,359 ERROR - CTGDIS077I Failed with error: CTGDIS143E No
criteria can be built from input (no link criteria specified)..
Really appreciate some assistance with this.
br Jan
Eddie Hartman
That error indicates that the Work Attribute you base
the Link Criteria on is missing or has a null value.
Try stepping through the AL using the AL Debugger
and viewing the contents of 'work' at the point of the
failure. For example, set a breakpoint in one of the
Error Hooks and then Continue. I think you'll see that
information is missing from your Changelog Iterator.
The default Null Behavior is that if the source for a
mapping assignment is missing or null, then that
Attribute is removed from the target (Work Entry).
Debugger How-To video:
http://www.youtube.com/watch?v=6h9Fg-SsToM
More on Null Behavior here:
http://www.tdi-users.org/twiki/bin/view/Integrator/LearningTDI#NullBehavior
Hope this helps!
-Eddie
Eddie Hartman
tombstone remains. The only Attribute available then
will be the objectGUID (and objectGUIDStr). So in
order to catch deletes you will need to use this as your
relational key between Domino and AD.
And, yeah, I guess I need to update that video/tutorial
some day when I get a little free time :)
-Eddie
zquickr
Hi Eddie,
Thanks for the reply :-) I think I got a little bit further in this my
first attempt with TDI.
I recorded this new video which shows where I am now:
http://screencast.com/t/YjZjYjc5ODg
I changed the link criteria to "seeAlso - $objectGUIDStr" and ran the
debugger.
Also cleaned up the Connector to include "*" as the mapping.
Running the debugger, "work" has now a value :-) but ends with an
error of "can't create document - Last Name is missing....."
Seems I'm on the right track 8)
But I only want to sync AD password into Domino when it is updated.
Could you steer me in the right direction from here.
Also, when I'm done with my testing, how do I set it into "production
mode"?
Your assistance is greatly appreciated :-)
br Jan
Eddie Hartman
which means that the Lookup for Update mode failed to find a match,
and the Connector is trying to Add a new Person - instead of just
updating the Password. In other words, the Link Criteria you set up is
not finding the right Person in Domino.
To prevent the Add from ever happening, just enable the Override Add
Hook of the Update Connector. You might want to add some script so you
can see that this is happening, for example:
task.logmsg("UpdateDomino - lookup failed to find: " +
work.objectGUIDStr + " " + work.getString("$dn"));
But as I said above, the problem is the Update lookup failing to find
a match.
-Eddie
zquickr
Hi Eddie - Thanks for helping me out with this :-)
Feel that I'm geting closer - now it runs without any errors :-)
Unfortunately it does not write the new password to the domino nab as
expected.
The Change connector registers an event in AD - great :-)
But the change is not registered back to the person document.
Hard to say what the problem is now :-(
I have created a new video with my progress and the config:
http://screencast.com/t/OWJjNmZiNTc
Also the console log is located here in this Quickr place:
https://qen.workplace.dk/opusneo-info
Appreciate your assistance!
br Jan (from DK :-) )
Eddie Hartman
You cannot simply read in the password and then
write it to Domino. This is an encrypted, binary value
and you need to write a clear text string to set the
Internet Password in the Person doc.
To catch passwords you instead use the TDI password
change intercept plugin for AD. This is installed on the
AD DC and acts like a "password strength checker".
Note that it must be the last plugin in the chain that gets
the password after a change.
The plugin then sends a password change message
securely to either a queue (like the bundled MQe) or
to a directory (using the schema extension provided with
the plugin). From there you have another AL that listens
for password change events (queue or LDAP Changelog
listening to the special sub-tree for these) and propagates
the new password to the target(s).
More on this here:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDI.doc_7.1/referenceguide137.htm#docs
...or in the comparable guide for the TDI version you
have.
-Eddie
zquickr
> Arrgh! Sorry, Jan, but I have been misleading you.
> You cannot simply read in the password and then
> write it to Domino. This is an encrypted, binary value
> and you need to write a clear text string to set the
> Internet Password in the Person doc.
>
> To catch passwords you instead use the TDI password
> change intercept plugin for AD. This is installed on the
> AD DC and acts like a "password strength checker".
> Note that it must be the last plugin in the chain that gets
> the password after a change.
>
> The plugin then sends a password change message
> securely to either a queue (like the bundled MQe) or
> to a directory (using the schema extension provided with
> the plugin). From there you have another AL that listens
> for password change events (queue or LDAP Changelog
> listening to the special sub-tree for these) and propagates
> the new password to the target(s).
>
>
> ...or in the comparable guide for the TDI version you
> have.
>
> -Eddie
Damn - I thought I was close to the goal...
Now I can see that seeAlso field is replaced with ObjectGUIDStr value.
So changedetector definitely works now.
Well - found the windows plugin guide - looks complicated.
Is there a tutorial video on how to perform this? Just a
suggestion ;-)
How do I build the AL - can't find any examples for this.
Would you have a scr.shot or a description or something?
There is nothing in the guide.
Appreciate your input.
br Jan
Thanks for the input for getting the first part done.
Eddie Hartman
should be pretty straightforward, just be sure and read through
ALL the documentation (accompanying the plugins themselves).
You could also try Googling for more info, like this link:
http://www.ibm.com/developerworks/tivoli/library/t-debug-tdiwps/index.html
The AL the reads the password change messages is really just
two Connectors:
1. An Iterator in Feed Section - LDAP or AD Changelog, depending
on if you use the LDAP option in the plugin, and which directory
you
write the change events to;
Or MQ/JMS to catch them from the queue if that option is used.
2. Update mode Connector to write the password.
And perhaps others reading this thread have insights to share...?
-Eddie
zquickr
> Sorry, Jan, but no tutorials on this subject. The plugin install
> should be pretty straightforward, just be sure and read through
> ALL the documentation (accompanying the plugins themselves).
> You could also try Googling for more info, like this link:
>
>
> The AL the reads the password change messages is really just
> two Connectors:
>
> 1. An Iterator in Feed Section - LDAP or AD Changelog, depending
> on if you use the LDAP option in the plugin, and which directory
> you
> write the change events to;
> Or MQ/JMS to catch them from the queue if that option is used.
>
> 2. Update mode Connector to write the password.
>
> And perhaps others reading this thread have insights to share...?
>
> -Eddie
Hi Eddie,
Seems like this is like 2 steps forward and a block :-(
I hope you could steer me further:
Following the Pluginsguide7.0.pdf, now configuring the LDAP password
store.
So far I have done the following on the Active Directory
Server:
- Updated registry
settings
- Modified the schema of Active
Directory
Page 62, 2a+2b has been completed. Step 2c, 2d, 2e are not
completed
- Configured a pwsync.props
file
- Tried to run the Proxy by the command: "pwsync_admin.exe
start_proxy" but is getting the
error:
C:\IBMTDI\pwd_plugins\windows>pwsync_admin.exe
start_proxy
INFO: : Executing the 'start_proxy'
command.
INFO: : Loading properties from file 'C:\IBMTDI
\pwsync.props'.
INFO: : Plugin configuration file
loaded.
INFO: : Starting
Proxy ...
ERROR: : Cannot start the Proxy:
PWPROXY_ERROR_ECONNREFUSED
ERROR: : Operation failed.
This is the props file:
proxyStartExe=C:\\IBMTDI/pwd_plugins/bin/startProxy.bat
serverPort=18001
logFile=C:\\IBMTDI/pwd_plugins/windows/plugin.log
checkRepository=true
javaLogFile=C:\\IBMTDI/pwd_plugins/windows/proxy.log
debug=true
accountTypes=NORMAL_ACCOUNT
syncClass=com.ibm.di.plugin.pwstore.log.LogPasswordStore
ldap.hostname=u08dc01
ldap.port=389
ldap.admindn=cn=Quickr_ldap,OU=xxx,DC=xxxx,DC=xxx,DC=local
ldap.password=xxxxx
ldap.waitForStore=true
ldap.delayMillis=2000
ldap.suffix=DC=unv,DC=xxx,DC=local
ldap.schemaPersonObjectName=ibm-diPerson
ldap.schemaUseridAttributeName=ibm-diUserId
ldap.schemaPasswordAttributeName=ibm-diPassword
Copied the pwd_plugin directory from the TDI server to the AD server
and modified the .props file in the windows directory under
pwd_plugin.
Not sure now if it is a bug or config problem.
Any hints would be greatly appreciated!
br Jan
PS: I have opened a PMR - just grasping at straws now.
Eddie Hartman
password plugins, whereas our L2 support wizards deal with this kind
of
setup all the time and can get you past your hurdle.
And please drop a note in here and share what you learn, Jan. Maybe
you'll preempt other calls for help with this :)
-Eddie
Prem
> Sorry, Jan, but no tutorials on this subject. The plugin install
> should be pretty straightforward, just be sure and read through
> ALL the documentation (accompanying the plugins themselves).
> You could also try Googling for more info, like this link:
>