R742MS5U@VB.CC.CMU.EDU (Marc Shannon) (04/22/88)
We've recently had a strange thing happen with our "anonymous" access to DECnet (user DECNET). Some time late last week, people could not access our machine without a username and password. Incoming MAIL, FAL, FINGER, etc (all except SET HOST) all started failing with "login information invalid at remote node". As far as I ~know~, nothing in NCP has been changed. In order to get everything working again, I had to go into NCP and execute a SET EXECUTOR NONPRIVILEGED USER DECNET PASSWORD DECNET. Oh, as another curious note, ACCOUNTING shows LOGFAILs for "Username: DECNET" and final status code "%LOGIN-F-NOSUCHUSR, no such user"??? There is a DECNET in our SYSUAF but when I try DIR CMCCVB"DECNET DECNET":: it works just fine. Anyone have any clues to this strange anomaly? --Marc Shannon Carnegie-Mellon University -------
CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (05/21/88)
Marc Shannon asked the following question recently concerning problems with the DECnet access over the network. > We've recently had a strange thing happen with our "anonymous" access to > DECnet (user DECNET). Some time late last week, people could not access > our machine without a username and password. Incoming MAIL, FAL, FINGER, > etc (all except SET HOST) all started failing with "login information > invalid at remote node". > As far as I ~know~, nothing in NCP has been changed. In order to get > everything working again, I had to go into NCP and execute a SET EXECUTOR > NONPRIVILEGED USER DECNET PASSWORD DECNET. > Oh, as another curious note, ACCOUNTING shows LOGFAILs for "Username: > DECNET" and final status code "%LOGIN-F-NOSUCHUSR, no such user"??? There > is a DECNET in our SYSUAF but when I try DIR CMCCVB"DECNET DECNET":: it works > just fine. I had a sililar thing happen to me complements of 'good intentions'. The problem boiled down to being a combination of things. 1. There was the same USERNAME on both the originating system and the target system. This was due to moving users to another machine and their original usernames had been left around for a little bit. The 'old' usernames on the target system HAD the /FLAGS set to DISUSER, thereby locking them out, but the record remained in SYSUAF. 2. The MAIL network object had PROXY access enabled on it for inbound connects. The result here is that when someone sent mail to the system where the user USED to be, they one with the SYSUAF record set to DISUSERED, the MAIL object said 'I have work to do' and attempted to create a process to receive the mail with the SAME username as the person sending. VMS said no way and aborted the mail process on the target node. The message gotten back was 'LOGIN information invalid on remote node'. There are two fixes we did. 1. Delete the SYSUAF records for the USERNAMES that had the DISUSER flag set on them. Note here that the MAILUAF record is NOT deleted as a result and that any changes, such as forwarding, is left on the target node. 2. Modify the DECnet characteristics on the MAIL object to disallow PROXY access on the object. This will force it to use the default DECNET account to create the process. I do not know about the other objects, and therefore do not know if it is safe to assume the same problems with them also. Hope this helps. :-) pdc Paul D. Clayton Address - CLAYTON%XRT@CIS.UPENN.EDU Disclaimer: All thoughts and statements here are my own and NOT those of my employer, and are also not based on, or contain, restricted information.