Vsevolod (Simon) Ilyushchenko wrote:
I don't think the code is designed to do one way sync. The way sync works with AD is that FDS pulls changes from AD (using the DirSync control) and pushes changes to AD (using plain old LDAP operations). AD never contacts FDS (except for password sync, and that's a different issue), so you don't need to specify a supplier DN.Rich, Thanks for your answers! Richard Megginson wrote on 04/26/2006 02:55 PM:Vsevolod (Simon) Ilyushchenko wrote:Hi, I've half gotten the AD sync to work, but I have a couple of issues:1. The updates are not propagated on their own. If I choose 'Send/Receive updates' from the sync agreement, they are immediately transferred, but it never happens on it's own.Try turning on the replication error log level.Okay, I see "Replica has no update vector. It has never been initialized." My updates are indeed not sent from FDS to AD, but I don't want this anyway.The Windows sync docs do not specify which replica role I have to choose first. I actually need a dedicated consumer (AD->FDS only), but if I choose that role, I have to specify a supplier DN, and I'm not sure what I should put there for the Windows sync scenario. So I had to choose 'single master', and that implies sending FDS->AD updates, which currently doesn't work. Looks like these updates won't be sent until I initialize the consumer (AD), and I DON'T want to do this.So I'm in a bind. :(
../shared/bin/pk12util -d . -P slapd-fa22 -o servercert.pfx -n Server-Cert pk12util-bin: find user certs from nickname failed: security library: bad database.Are you missing the trailing "-" after slapd-fa22?Yes, that was it! Now that I know what to look for, I've noticed this on the wiki in the SSL article (though the WindowsSync pages in the Netscape docs and on the wiki do not mention it :).Thanks, Simon
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
