NWFTPD, BackupExec, and other server-based processes can't login

Users cannot login to NetWare via FTP, BackupExec, and some other server-based (NLM-based) methods.

NCP clients login fine.

Some other server-based methods login fine, like DSREPAIR | Advance Options.

There are many ways an NLM can login to eDirectory. Some go through DS APIs in NETNLM32.NLM. Examples of this are NWFTPD.NLM, when it logs a FTP user into the tree, and apparently BackupExec.

Not all NLMs use this method. Some make more direct calls into eDirectory. Others use newer methods in LIBC.NLM.

NETNLM32 depends upon various forms of name resolution to connect to the tree. This name resolution is very important, even in cases of as single-server tree.

For proper functionality in a variety of conditions, the NetWare server's own hosts file should contain the simple version of the server's name, not just the name in the format host.domain.name.

For example, proper format of the server's own entry in its own SYS:ETC\HOSTS file is:

10.1.2.3 server1.novell.com SERVER1

Without the server name (by itself) as a hosts name alias, some process may fail in certain scenarios. If the hosts entry is changed in hopes of solving a problem, the change must be put into effect. Typically, hosts file changes will come into effect within 5 minutes; or upon issuing the command REINIT at the console prompt. However, in some cases, especially when changing the server's own hosts entry, it may be necessary to reboot the server to get the full effect of the change.

Here are some clues to cases when FTP can't login users, due to inability to communicate with eDirectory through NETNLM32.NLM.

1. SYS:ETC\FTPAUDIT.LOG will not log any information about the login attempts. That is because this log will only lists login attempts made against user objects that were actually found in eDirectory.

2. The following is only true if using subtree searching on the SEARCH_LIST parameter in FTPSERV.CFG: SYS:ETC\FTPINTR.LOG will log an entry for the failed attempt, but without a fully qualified name. For example, if a user attempts to login as .bob.users.novell, and fails because that user is not found, the intruder log entry will look like:

Info , 15 , 2007-11-6 15:48:11 , 10.1.2.3 , .CN=bob. , 1 Wrong Password Attempts

In contrast, if the user object was found, but the password was wrong, the log will show:

Info , 15 , 2007-11-6 15:48:11 , 10.1.2.3 , .CN=bob.OU=users.O=novell , 1 Wrong Password Attempts

(NOTE: If subtree searching is not being used, all failed login attempts will show a fully qualified name, even if the object was not found).

3. If NETNLM32.NLM is unable to communicate with eDirectory, DSTRACE.NLM will not log any information about the user name resolution attempt for attempt. From DSTRACE's viewpoint, it will seem as though no request is being made.

4. NETNLM32 debug traces (only available through special builds) will show errors 35324 (Ox89FC) when attempting to connect to the tree or server.