On Tuesday August 2 2005 6:15 pm, David Boreham wrote: > >But I've checked and rechecked those. My bind DN is cn=Admin. That's > > the correct format, isn't it? > > > >- > > Indeed no. You want the DN for the Administrator user in AD. > Typically that would be something like 'cn=Administrator, ou=users, > dc=company, dc=com'. > However, I would recommend that you use ldapsearch to first establish > the correct DN > (search for all users in AD and go looking for the administrator user). David, I changed the DN as you suggested, and my sync worked (just as I imagine you expected it would). Thank you very much! If I may be so bold as to take advantage of your knowledge and kindness - when I created the Windows Sync Agreement, I specified the DS subtree as ou=People,dc=headquarters,dc=mydomain,dc=com, and the Windows subtree as cn=People,dc=headquarters,dc=mydomain,dc=com. When the sync completed, all Windows users and groups ended up in the FDS People subtree. How would I get Windows groups to populate the FDS gorups subtree, and only users to populate the People subtree? Dimitri

>If I may be so bold as to take advantage of your knowledge and kindness - > when I created the Windows Sync Agreement, I specified the DS subtree as > ou=People,dc=headquarters,dc=mydomain,dc=com, and the Windows subtree as > cn=People,dc=headquarters,dc=mydomain,dc=com. When the sync completed, > all Windows users and groups ended up in the FDS People subtree. How > would I get Windows groups to populate the FDS gorups subtree, and only > users to populate the People subtree? In this current release it's not possible to do exactly what you want (at least I can't think of an easy way to to it). The problem is that there are two conventions for storing users vs. groups in the DIT: a) put users and groups in the same container and b) put users in one container and groups in a sibling container. You can deploy either convention in both AD and FDS, but in order to have an easy life in terms of Winsync, you need to use the _same_ convention on both sides. Note that the fact that FDS has ou=People and ou=Groups is simply a convention in the sample data loaded on request at install time. You can easily adopt the same convention as is commonly used with AD: put users and groups in the same container. (AD didn't exist when we invented the ou=People, ou=Groups convention at Netscape way back). You _could_ defined two sync agreements : one to sync users and the other to sync groups. Problem is that you would be pointing both at the same subtree on the AD side and I believe that bad stuff would happen as a result (there's no way to tell an agreement to only sync groups, for example).