Anybody know when the next release is going to be for this particular tool? Or any of if for that matter? -Ben Brian Peters wrote: > Well, I got impatient and did a little digging through the source and > found out the bad news for myself, but then I found some good news at > least. It looks like the current release has the search scope > hardcoded as one-level, but the bug had already been located and fixed > as of this commit in June: > > https://www.redhat.com/archives/fedora-directory-commits/2005-June/msg00000.html > > > So, I guess anyone else with this problem needs to wait for the next > release (or recompile if they are impatient). > > Brian > > Brian Peters wrote: > >> Hi, >> >> I have a user directory structure in AD that mimics a typical org >> chart such that my ou=People directory contains additional ou's as >> subtrees that represent different departments. I have a windows sync >> agreement in FDS set up, and after manually adding the various ou's >> on the FDS side, all the users sync over properly in all the subtrees. >> >> My problem is with the password sync service for windows. Upon >> changing a user's password that has already been replicated to FDS >> from AD, I see in the access logs a search along these lines: >> >> SRCH base="ou=People,dc=my,dc=domain" scope=1 >> filter="(ntUserDomainId=myUser)" attrs=ALL >> >> with the result indicating no entries found: >> >> RESULT err=0 tag=101 nentries=0 etime=0 >> >> The myUser account is at ou=MyDept,ou=People,dc=my,dc=domain, but the >> password sync service issues a search request to only search the >> ou=People directory non-recursively (i.e. scope=1). I don't see any >> options in either the PassSync.msi setup or in the registry keys to >> force the service to do a scope=2 recursive search. I tried to use >> the syntax "ou=People,dc=my,dc=domain?sub", but it doesn't seem to >> recognize that either. Is there any workaround for this besides to >> synchronize all of my users to a single directory on FDS? >> >> Thanks, >> Brian >
