I don't think it matters since this appears to be an issue with Novell's UP (perhaps a policy setting?) not populating the NDS password field properly like it should.

I have been using Pegasus/Mercury since the mid 90's at our Non Profit Community Service agency. Since then, we have grown from a hand full of computers to nearly 300, with locations spread out over a 10 county area.  Our remote locations use POP3 (we are changing to IMAP). With the addition of remote access via an SSL/VPN connection I have gone to enforcing complex passwords. I have done this by setting up Universal Password (U.P.) Policies using eDirectory on our Novell Netware 6.5 servers.

Here is the problem. Any new user account that has U.P. assigned gets a Password failure when they use POP3 or IMAP. Preexisting users who have not changed their password can still use the system. Also, If I create users in a OU container that does not have U.P. assigned, they work also.

My assumptions are that preexisting users already have their password registered in the NDS password field in edirectory and so they work. New users' passwords are placed in the U.P. field and never get placed in the NDS password field.

Does anyone know of a way to have Mercury check the U.P. when authenticating a user?

As far as I know, this is presently unsupported, but I will pass it along to David Harris as a wish list item.

Just to confirm, this isn't a matter of using CRAM-MD5 and/or APOP authentication, correct?  Are you simply using plain text passwords with POP3/IMAP4?  If not, are your old users possibly using the PASSWORD.PM file in their PMAIL mailbox directory for authentication (with a password matching their existing NetWare password) while the new users are not?

No, that is not the case.  This problem started when I set up Universal Passwords (U.P.) so that I could set password policies in Netware.  We have never used PASSWORD.PM here.  From what I have figured out, once U.P. is used, netware no longer used the old netware password field in eDirectory, but instead stores them in U.P.

Okay, I've passed this along.

Okay, further on this.  I had to get some others to test this since I no work with Novell.

Two different beta testers use UP and have no problems with Mercury/32 and IMAP.  Here is a report from one of them:

My user has no trouble with mercury via imap after UP was enabled for his account.

Scenario:

Netware 6.5 sp7

Before:
Password_A for NDS
Password_B for Simple Password

Mercury used NDS password.

After assigning UP policy to user:

*Asked user to change password on a 4.91 client.  This caused all passwords to sync with the new one.

*User now uses UP transparently between regular windows clients using NDS password, CIFS via his Mac, and IMAP via Mercury.

Basically, the backwards compatibility of UP seems to work as advertised.

The mercury system is using 4.91sp4 and NMAS.

So, you may need to look elsewhere for why this isn't working.  Perhaps a Novell patch that fixed a backwards-compatibility issue?  Or perhaps the UP policy itself specifies whether or not to be backwards compatible by auto-filling in the NDS password field?

David K.

I do not remember if they said they were using Mercury/32 v4.52 or v4.61b2 when they did this test. 

.