NetWare FTP login problems after NW Support Pack or Security Service update

After applying NetWare 6.5 SP6 (or higher), or Security Services Update 2.0.3 (or higher), FTP sessions may have various problems:

 

1. If IP Address restrictions are present on the account, and the NetWare server has an eDir replica, then even if the user is expected to be admitted, the login may fail with the error:

 

530 Login Failed for User username

Login failed.

 

This is because the local NMAS authentication is unable to determine the source IP address of the login attempt, so it denies access even though the address (if known) would have been allowed.

 

2. User accounts with very long FDNs are failing to login. This is due to buffer overflows in interactions between OS libraries and NMAS functions.

 

3. User accounts that have an expired password but are running on grace logins will see an informative message upon login:

 

230 Passwd expired for user dpartrid, Grace login used

 

However, the user may not be placed in his or her correct home directory, and will not be able to see or do anything there. Errors that may be seen include (but are not limited to):

 

Upon 'dir' or 'ls':

550 No Such Directory "/sys/public"

 

Upon 'get file.txt'

550 sys/public/file.txt : No such file or directory

Upon 'cd /vol1/dir1'
550 Could not change to Directory "/vol1/dir1"

 

4.  FTP users in containers where eDirectory intruder detection is activated may get locked out as intruders.

 

5.  The FTP anonymous user can no longer login.

Upon the above mentioned updates, the legacy methods of login which NWFTPD.NLM begin to be redirected through NMAS, so that NMAS features like access to Universal Password can be used. This redirection is happening at a layer lower than FTP itself, so NWFTPD has no direct control over it. The NMAS method is generally working for FTP sessions in most cases, but problems have been encountered in the above-mentioned scenarios.

 

Fixes for items number 1 and 2 above are included in NetWare 6.5 SP7.

 

If the fixes are desired without applying the complete SP7, then the same fixes can be obtained as follows:

Issue 1 is fixed in Security Services Update 2.0.5 for NetWare (ss205_NW.tgz)

Issue 2 is fixed in library updates nwlib6k.zip.

 

Item 3 may be addressed later, but the best and immediate solution is to set a new password once the previous one has expired. Note that passwords cannot be set through an FTP client. It can be done by the user at a NCP client. It could also be done by an administrator, as long as it is done in a way that will not cause the administrator-set password to immediately expire again upon first login attempt.

 

Item 4 is a symptom that came to Novell's attention more recently, and it may have more than one possible cause.  For example, NMAS will increment a user's "Login Intruder Attempts" counter in many more situations than a traditional login will.  I.E.  If the password submitted is correct, but the login still fails because of other login restrictions, NMAS increments the counter; a traditional login would not.  This issue, as well as some other NMAS concerns that could cause a login failure, have been fixed in NMAS 3.3.1.3, which is available at:

 

 

NOTE:  This update should be applied both to the FTP server itself, and to any replica servers which will be contacted to authenticate the users in question.  Depending on your version of eDirectory, you may already have this or newer NMAS in place.

 

Item #5:  For details on dealing with anonymous user login failures, search https://support.novell.com/search/kb_index.htm for KB 7003549.

For any of the above problems, or for any other login symptom which is believed to be caused by this change from traditional logins to NMAS logins, the problems can usually be worked around by following the troubleshooting guidelines below.

 

 

Troubleshooting:

 

For troubleshooting or testing to confirm that an FTP issue is being caused by the new use of NMAS:

 

Rename the SYS:SYSTEM\SPMNWCC.NLM to another name, then reboot. Without this NLM in place, the authentication methods won't be redirected, and behavior will return to normal. The absence of this NLM should not cause any issue, other than preventing NLM-based legacy login methods from using NMAS.

 

While renaming this NLM can be used as a workaround, this is not the ideal long term solution.  Even if this NLM is renamed to avoid the problem, a new copy may be put on the system any time a Support Pack, Security Services update, NMAS update, or eDir update is applied.

 

additional keywords:  lockout