Joe,
 
>> this was a feature that we have implemented in the past, using IMail v6 and Windows NT4.  we imported NT4 user accounts, then users were able to change their passwords and it would synch with the database - that was my understanding.
You do have the option of importing accounts, from NT into the IMail Auth method.  This saves you from having to create all the accounts when using an authentication method other than NT auth.  This is a manual process when you click on that button, which is to say that the Imail DB is not automatically updated when additional accounts are created or removed in NT unless you were to re-import them again.  This also is not capable of synchronizing passwords between NT and the IMail auth methods.
 
So while the IMail password server works for non-NT auth (even with accounts that have been imported - or copied over from NT user list), it will not work when using NT auth because the pw server doesn't have the authority to set or change NT/AD passwords.  This is a good thing because all passwords in IMail are sent in clear-text, unless using SSL, and would compromise your NT domain security policies (someone could easily sniff for an admin's password, using it to set other people's passwords or passwords for accounts used for application services).
 
If you use NT auth, IMail just asks NT "can you authorize this account with this password?".  You actually manage the accounts from NT user administration GUIs, so passwords would have to be changed from the NT/AD domain user tools.
 
Using NT is good if all of your mail users already have domain accounts - all within the same NT and mail domain.  This prevents you from having to duplicate account management.  If you do use NT auth, and password security is important to you, be sure to secure traffic to your IMail server (any connections from internet should be SSL, local connections should either be SSL or LAN should be on switched hubs to prohibit passwords from being sniffed).
 
-ives

Reply via email to