GOT@PSUECL.ECL.PSU.EDU.UUCP (01/20/87)
We recently aquired Excelans TCP/IP hardware and software for use in our VAX 11/785. The package includes TELNET, FTP, and some other support packages (I wrote a program for the finger socket). Both the TELNET and FTP software work fine outgoing (to other nodes), and the TELNET works fine incoming, but the FTP fails to allow remote logins (either from our machine to our machine, or from other machines to our machine). The error message it returns is 530 Login Failed. login failed. after you enter your password. We have had an engineer from Excelan working on the problem for a day or two, but he has gotten nowhere. He speculates that there is something wrong with the SYSUAF file, although we have made no changes to the file. any ideas? anyone out there using Excelans TCP/IP?
Klensin@MIT-MULTICS.ARPA (John C Klensin) (01/20/87)
Aha. We have been struggling with that problem since mid-fall, and
finally solved it -- with superhuman help from Excelan -- this last
weekend. Problem is that they made a "feature" with this release of the
FTP server such that an FTP login requires access to use "Network"
logins, even if you are not otherwise using DECNet (which is the only
other thing that uses that access class).
So, go into AUTHORIZE and, for every account for which you are having
the problem,
MODIFY userid /NETWORK
and everything will be in great shape.
Excelan's reasoning as to why they are checking this is logical,
incidentally, even it is causes some nasty surprises (especially nasty
for those of us who were running the previous version of their software,
which was completely insensitive to the problem). They've told us that
the "production" version of the software (you forgot to mention that you
are running a beta version) will have this feature noted in the
documentation in large and prominent letters.
John Klensin, MITcetron%utah-ced@UTAH-CS.ARPA (Ed Cetron) (01/20/87)
I saw a similar problem with telnet using the wollongong and tektronix software when inbound from 4.3bsd unix sites.... seems that the mil-std spec for telnet connections is to never send just a <cr> by itself....if what is desired is a 'newline' meta-character, then <cr><lf> should be sent. If what is desired is really just the <cr> then <cr><nul> should be sent..... So far so good. Now the early wollongong and tektronix tcp/ip's tried to emulate 4.2bsd WHICH DOES NOT FOLLOW THE SPEC'S. 4.2bsd sends either <cr><lf> or just <cr>.... What now happens is the following when a 4.3bsd site sends <cr><nul>: Loginout is spawned and the gets the string name<cr><nul> from the tcp/ip software. It parses out the name<cr> and treats this as proper input for the username prompt. It then prompts for the password and parses out the <nul> which IS an acceptable password input even though it isn't the correct one and one gets the old 'user authorization failure'..... The correction is to have the tcp/ip code brought up to mil-std and strip out the <nul> characters IF they follow a <cr>.... What does this have to do with FTP, well, supposedly, FTP uses telnet protocols on the control channel and therefore could be bombing in the same way as telnet did. A good test for this is to turn on log failure alarms, turn on a security operator terminal and bang into it a couple of times and the look at the security log files. -ed cetron center for engineering design Univ of Utah cetron%utah-ced@utah-cs.arpa cetron@utahcca.bitnet
KLENSIN@INFOODS.MIT.EDU (John C Klensin) (01/20/87)
Hmm. Bless their hearts, two problems, same symptom. We are not trying
to get to the thing from UNIX, or anything else that is broken or
otherwise severely damaged. And our difficulties showed up even with
very short passwords.
So, I guess the moral is:
1) User must have network authorization.
2) If user passwords are longish, make sure the user system is doing
the right thing (or trick it into doing so).
The latter problem, incidentally, is easily checked with the Excelan
software. To detect, turn on debugging in SERVER.DAT for FTP (use the
-d -l options) and see if the passwords are coming through correctly
into the system log. To paraphrase Excelan, be careful about using this
because it doesn't do wonderful things for system security.
Some of these little hints, incidentally, are buried in the "Network
Administration and Security Notes" document, not in the reference
manual.
John Klensin, MITssmith@nrtc-wobot.UUCP ("Stephen P. Smith") (01/21/87)
Query: >Both the TELNET and FTP software work fine outgoing (to other nodes), >and the TELNET works fine incoming, but the FTP fails to >allow remote logins (either from our machine to our machine, or from >other machines to our machine). The error message it returns is > >530 Login Failed. >login failed. >after you enter your password. Response: >Problem is that they made a "feature" with this release of the >FTP server such that an FTP login requires access to use "Network" >logins, even if you are not otherwise using DECNet (which is the only >other thing that uses that access class). We have the same problem at our site, and the /network class had nothing to do with it. It turns out that many ftp client programs on Unix are broken and in auto-prompt mode only allow an 8 character password. If your password on VMS is longer than 8 characters, you lose. To check this, from your Unix machine, do: ftp -d vmsmachine You should get the standard auto-prompt for username and password. The -d switch shows what gets sent over to the server. Note the truncated password if it is longer than 8 characters. To get things to work, turn off the auto-prompt with ftp -n vmsmachine and then enter the line user myusername mypassword This explictly sends the full password over (of course, it means you type it with echo on). Of course, you could fix the Unix ftp program. --Steve ******************************************** * Dr. Stephen P. Smith * * Research Technical Staff * * Northrop Research and Technology Center * * ARPAnet: ssmith@nrtc.northrop.com * * USnail: Palos Verdes CA 90274 * ********************************************
carl@CITHEX.CALTECH.EDU.UUCP (01/21/87)
Thanks for letting those of us who were having the same problem but hadn't got around to figuring out the reason for it know about the auto-prompt "feature" on the unix machines. By the way, if you happen to have an ftp that won't let you disable the auto-prompt, you can also get around the problem by letting your login fail the first time then issuing the commands QUOTE USER username QUOTE PASS password
Klensin@MIT-MULTICS.ARPA.UUCP (01/21/87)
Just to close the loop, I spoke to Excelan Tuesday afternoon about another issue and they mentioned that they had finally tracked the PSU problem down and were getting a fix (or a patch) out. "None of the above". Difficulty had to do with PSU's having modified the UAF format in a way that created longer records which, in turn, fouled up Excelan's testing as to whether or not login was permitted. For the information of people trying to check out Server FTP and similar software, one of the sensible ways to implement one of those things (I don't know what other VMS implementations do, but I've seen analogues on several other systems) involves running the server code as a highly privileged process. When an FTP "login" request comes in, the server code itself goes off to the UAF (or whatever it is called on the host system) and verifies that login would be permitted if the user were logging in (with whatever name, password(s), privileges, times of day, etc., are needed). Then it sends or receives the relevant file(s) on behalf of the user (whatever "on behalf of" means locally). If there is not a good, vendor/system supplied and supported subroutine call for "tell me if this combination of user-password-whatever is legal for login", this approach provides all sorts of opportunities for an FTP server to not work in some way (accepting the illegitimate or rejecting the legitimate) when interactive logins (Telnet in this case) work fine. At least one of the suggestions mentioned above would have caused Telnet logins to fail also; a characteristic of these TCP/IP FTP server failures is that the same user ids and passwords work fine with Telnet. Incidentally, another characteristic of this approach is that generating "logfail" accounting records and auditing records when an FTP login attempt fails (and maybe even auditing records when it succeeds) gets a little dicey. Excelan does not now do it and has no immediate plans, having not heard an outcry from anyone but us. Other Excelan users who see this as a problem should probably let them know; this is the sort of non-functional feature that they are [quite reasonably] likely to do something about only if several people tell them that it is important. Has anyone ever requested a supported and documented a "please validate this user/password/..." routine from Digital, and, if so, what was the response? John Klensin, MIT
cetron%utah-ced@UTAH-CS.ARPA.UUCP (01/21/87)
I found the best approach (which is being implemented in the tek tcp/ip by Kevin Carosso) is to use the digital supplied "please validate this user/ password" routine - loginout. If the initial FTP server simply starts up, establishes the connection and then spawns loginout to create the FTP control process, waits to establish that it successfully completed, then passes the tcp/ip connection over to the FULLY VALIDATED ( or at least as well as any other interactive process on the machine :-) process and exits.... another line of defense would be to also use loginout to create the data process and let vms right away verify whether the user has access to data, not just the system....this would allow full protection based on uic as well as (if done right) special ACL's to allow/disallow ftp access. -ed cetron center for engineering design Univ of Utah cetron%utah-ced@utah-cs.arpa cetron@utahcca.bitnet