Hi All. I have been struggling with creating a Windows Sync agreement that works the way I think it's supposed to. Maybe someone can educate me as to what I'm doing wrong. Documentation on this subject is sparse and incomplete. If I can get this problem solved, I would be happy to contribute the detailed document on how I did it back to this list. Sort of a "Complete Idiots Guide to Windows Sync Agreements" or something. First, the way I *think* it's supposed to work ... 1. If I create an account or group in AD, it replicates to FDS 2. If I create an account or group in FDS it replicates to AD 3. If I change a user's password in one directory, it updates in the other >From the Redhat documentation: "The Windows Sync feature allows synchronization of adds, deletes and changes in groups, user entries, and their passwords between Red Hat Directory Server and both Microsoft Active Directory and Microsoft Windows NT 4.0 Server." Seems vague enough. I am left with a big question, though: is it possible to replicate UNIX uid/gid information to Active Directory? Somewhere along the path I got it in my head that I needed to install Windows Services for UNIX in order to share UNIX uid/gid/shell/homedir information between the two directories. Further, I came to believe that the sync agreement code in the Directory Server magically handles the translations between schemas ... that is to say, in AD the UNIX uid is stored as MSSFU30uid (or something close to that), while it's simply uid in FDS; and the sync code does that translation. Is all that wishful thinking on my part? It does not appear to work this way. I have SFU installed in AD. Any UNIX data I put into AD does not replicate down to my FDS. Is there a way to do what I'm talking about? Secondly, it has never been clear to me how changes on the FDS side replicate back up to AD. Do I need to set the replication up as Multimaster/Single Master/?? I'd appreciate any help someone may be able to give -- even if it's just educating me about some misconception I seem to have. -- Brandon
