Identity Sync for Windows error : "Action dropped .. not in any sync scope"
Hi all ,
I'm using ID-Sync for Windows (1.1), to synchronize entries from Sun DS to Win AD. Entries are created in AD just fine, except for the password. In ID-Sync logs, it clearly says that password in AD is randomly generated.
I've checked password policies on both sides, and they're similar and consistent (and simple). But neither password creation or update does work.
In ID-Sync logs, I regularly get the following messages :
CNN100
"The controller has received the following inbound action from the accessor: Type: MODIFY {Data Attrs: [REPL cn: active-cs-CNN100]} {Other Attrs: cn: active-cs-CNN100 nsuniqueid: <etc...> objectclass: pswstatus, top dn: cn=active-cs-CNN100, ou=Status, ou=GlobalConfig, ou=1.1, ou=IdentitySynchronization, ou=Services, o=ccvrp changenumber: 277229}" (Action ID=CNN100-10C1A768FAB-73999, SN=0)
CNN100
"Action dropped because it is not in any sync scope. Action = Type: MODIFY {Data Attrs: [REPL cn: active-cs-CNN100]} {Other Attrs: cn: active-cs-CNN100 nsuniqueid: <etc...> objectclass: pswstatus, top dn: cn=active-cs-CNN100, ou=Status, ou=GlobalConfig, ou=1.1, ou=IdentitySynchronization, ou=Services, o=ccvrp changenumber: 277229}" (Action ID=CNN100-10C1A768FAB-73999, SN=1)
I really don't understand where the problem lies ...
Thanks for any light,
Regards,
<jean.lemoigne@sun.com>
[1419 byte] By [
jlemoigne] at [2007-11-26 8:28:22]
# 1
Hello Jean,
It looks like the entry you're testing with, either on the Sun or AD side,
doesn't match any SUL and thus, IDsync just do nothing.
I would first check that when you run your test, you're in a safe state,
that is :
- you managed to run "idsync resync ..." successfully
- the sync service is started
- if you stop and start it, you shouldn't have any severe error, just
warnings possibly,
- if you stop and start your directory server, the error log doesn't show
any error
- the connectors are in the SYNCING state
If one of the above is wrong, fix it before moving on ...
Now, if it's all OK, ldapsearch your Sun directory and AD with the same
BIND DN as IDsync, and with the SUL filter as argument, in order to test it and check the entry you use matches the SUL:
Maybe there's something wrong with your schema or ACL's .
Hope this helps ...
# 2
Dear M. Cgrosjean ,
You might pretty much be right, once again ...:-)
Actually, forget about the first part of your hypothesis : sync is working fine, and entries created in Sun DS just get synced in AD. But ... for the passwords.
Now, the DS machine is also a SunRay server, as well as a server for many other things (Native LDAP, customer project's related softwares, etc ...). And indeed, last time I was on site (yesterday), I just noticed we now have more than 10 ACIs on the root suffix of the Sun DS concerned by ID-Sync and the users' profiles (which was not at all the case when I performed the first ID-Sync install and config). But I didn't check further.
Thus, I will perform the last check you advise me to do, and there might actually be the limitation to passwords sync.
Many thanks Cyril,
@ +,
Jean
PS: d閟ol? je n'ai pas r閜ondu ?ton coup de fil l'autre jour (on est compl鑤ement ?la bourre ...). Le pb. 閠ait tout b阾e : je savais (par Michael Haines & co) que Native LDAP devait utiliser le port 636 (et uniquement celui-l? en TLS/SSL. Ce que j'ai d閏ouvert en client鑜e (mais j'aurais pu m'en douter ...), ce que le port non-secure, et indispensable m阭e en TLS, ne peut pas non plus 阾re autre chose que le ... 389 (!)
(alors que son choix reste libre, hors TLS)
:-)
# 3
Hi all ,
Many thanks to those who answered my previous posts (Kunal Sinha, Arun Ayyavu, ...).
Here is just a short feed-back, which might be useful to some people (although it may appear "naive" to many).
First of all, I have to admit that as far as ID-Sync is concerned, I haven't yet performed an extensive reading of all available docs (nor did I perform all kind of tests in all the various configurations one may think of ...), and there lies the origin of the problem encountered. However, we all know that we many times have to perform these fast "diagonal reading" of software docs, so as to put our products at work ASAP (at least try to ... )
Brief recall :
Using ID-Sync for Windows (1.1), to synchronize entries from Sun DS to Win AD. Entries were created/synced in AD just fine, but for the passwords. In ID-Sync logs, it clearly said that passwords in AD were randomly generated upon entries creation, and could not be updated.
In this perspective (the quick "diagonal" parsing of the documentation we have to do), I think it is *NOT* really obvious in the docs that when ID-Sync is synchronizing from Sun DS to AD, which implies talking to AD on SSL (port 636), SSL has to be enabled *on the Sun DS side AS WELL* , although one might consider that the Sun DS source acts just as a "client" to the AD server. As far as I understand (correct me if I'm wrong), this is because the ID-Sync Sun DS 'plug-in' (the one which syncs passwords from Sun LDAP to AD) works in an "all_SSL_or_nothing" manner : once SSL is enabled in ID-Sync config, the plug-in has to talk on SSL to ALL sources (AD and Sun DS). That's what I understand from the docs so far, from the error messages in Sun LDAP logs, and anyway, now that I enabled SSL on Sun DS (which implies requesting/installing a server certificate + CAs on the Sun DS as well), it works : passwords changes in Sun DS are now synced to AD.
By the way, one might remember I mentionned error messages in the ID-Sync logs, such as :
CNN100
"The controller has received the following inbound action from the accessor: Type: MODIFY ... (etc ...)"
CNN100
"Action dropped because it is not in any sync scope ... (etc ...)"
Actually, these messages still exist, and are absolutely irrelevant to the "passwords not syncing" problem : as far as I understand, they are generated upon the updates ID-Sync is permanently doing to its configuration, stored in Sun DS in the "Services/Identity Synchronization for Windows/v1.1/... (etc ...)" branch. What is kind of weird is that the search 'base_DN' (for users entries) declared in the SUL(s) for the Sun DS source lies absolutely elsewhere in the DIT.
The only 'link' I can see is :
- in this customer context, the Sun DS instance is unique (only one instance contains both the NetscapeRoot, the Services (ID-Sync config) and the users profiles branch at the same time : no dedicated 'config' LDAP instance)
- the 'root-suffix' is the same for both the 'Services' branch and the 'users data branch' (the search 'base_DN' for the SULs)
Thus, it's true that updates written to the 'Services' branch "do not fall in any SUL 'scope' " (!)What is weird is that ID-Sync permanently reports about these internal config updates in its error logs ... ( ?)
Hope this feed-back might be useful to somebody,
Comments welcome,
Regards,
Jean
