>From your mail, i understood that you are trying to sync passwords from AD to FDS. I am trying to sync accounts the other way round from FDS to AD. If pass sync doesn't full sync accounts between FDS and AD which i regard as a replica of FDS, when i create new user i have to create him on the AD and ask the user who's password is already saved on FDS to login and change his password which he just created! This is wasn't i hoped for :( regards, Abdelrahman <div>On 3/29/06, Daniel Shackelford <<a href="mailto:dshackel@arbor.edu">dshackel@arbor.edu</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I had some trouble myself with passwords from AD making it into FDS. Unfortunately no passwords are synced until they are changed on AD, which means that if you have a 7000 user base like we do, there are very few options for getting the passwords populated in FDS. PassSync uses a DLL to capture passwords in plain text during the set password process, and send them to FDS. This means that all those users that are synced magically when you set up replication, will not have passwords until they change their password on AD somehow. We started collecting credentials from our proxy auth, and storing them for a massive import after a few months. The import went well (I can tell you the process if you like), but we still have 5000 accounts without passwords in FDS for off-site users, and those who should be pruned. Now we are looking at a web interface for handling these special cases (is it special when it effects the majority of your users?). The PassSync that was distributed with FDS 7.1 did not give much info on what it was doing, and this led to an incorrect setup without knowing it was incorrect. If you use the most recent version, you can enable verbose logging, and see what is going on (it is a registry key under HKEY_Local_Machine->Software->PasswordSync->Log Level). It turned out that PassSync and FDS were not speaking to one another yet. I went through the key import process (pk12util + certutil), restarted the service, and away we went. If you think you might be able to get the unix crypted passwords via msSFU (Microsoft Services for Unix), and populate FDS, you would be right, unless you are also wanting to synchronize those passwords. I tried it and blew out the password for every user on our domain, and had to recover from tape. The crypt is one-way, so once it is in FDS, you can successfully authenticate, but it looks like junk to the password sync code, and it ends up syncing junk to AD, which in turn, syncs junk back to FDS. Bad bad bad. So it sounds like you may not have the PassSync service set up quite right, or you are expecting the passwords to be synced with the accounts, but they won't because that is not really what PassSync does. Either way you will have to address the issues of missing passwords in FDS. Do you have any secure way of collecting the credentials of users? A proxy/sniffer in front of your POP3 server? Just a suggestion. -- Daniel Shackelford Systems Administrator Technology Services Spring Arbor University 517 750-6648 "For even the Son of Man did not come to be served, but to serve, and to give His life a ransom for many" Mark 10:45 -- Fedora-directory-users mailing list <a href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users"> https://www.redhat.com/mailman/listinfo/fedora-directory-users</a> </blockquote></div>