Conference vaxaxp::vmsnotes

320.0. "%LOGIN-F-NOSUCHUSER over network" by SWETSC::WESTERBACK (Panta rei) Thu Mar 13 1997 08:57

Hi,

I have a scheduler jobs that runs every 5 minutes on node STKOSC (VMS Alpha 6.2
and DECnet OSI 6.3) that copies files to node STKEIS. This was working fine 
when STKEIS ran VMS VAX 6.1, but since upgrading to 6.2 (OSI 6.3 ECO 5 both 
and after) it intermittently fails with this message:


Security alarm (SECURITY) and security audit (SECURITY) on STKEIS, system id: 51321
Auditable event:          Network login failure
Event time:               13-MAR-1997 11:21:41.27
PID:                      00000113        
Process name:             NET$ACP         
Username:                 CONS2WWW        
Remote node id:           490032AA00040026C821
Remote node fullname:     DEC:.SOO.STKOSC
Remote username:          ISOPER
Status:                   %LOGIN-F-NOSUCHUSER, no such user



After a couple of failures, the intruder flag is set, and then of course it 
keeps failing.
    
    NETWORK      INTRUDER     29   14-MAR-1997 11:35:48.36 
    DEC:.SOO.STKOSC::ISOPER
    

If I delete the intrusion, it normally works OK again. Like this:

%%%%%%%%%%%  OPCOM  13-MAR-1997 11:26:04.26  %%%%%%%%%%%
Message from user AUDIT$SERVER on STKEIS
Security alarm (SECURITY) on STKEIS, system id: 51321
Auditable event:          Network login
Event time:               13-MAR-1997 11:26:04.25
PID:                      000169E4
Process name:             FAL_1415000F
Username:                 CONS2WWW
Process owner:            [PCFS,CONS2WWW]
Image name:               DSA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Remote nodename:          STKOSC
Remote node fullname:     DEC:.SOO.STKOSC
Remote username:          ISOPER




I've listed some UAF entries here:

STKEIS >> uaf sho cons2www


Username: CONS2WWW                         Owner:  249291_SYSTEM
Account:  DECNET                           UIC:    [376,3776] ([PCFS,CONS2WWW])
CLI:      DCL                              Tables: DCLTABLES
Default:  DISK$ISLOCAL:[CONS2WWW]
LGICMD:   _NL:
Flags:  Restricted
Primary days:   Mon Tue Wed Thu Fri        
Secondary days:                     Sat Sun
Primary   000000000011111111112222  Secondary 000000000011111111112222
Day Hours 012345678901234567890123  Day Hours 012345678901234567890123
Network:  ##### Full access ######            ##### Full access ######
Batch:    -----  No access  ------            -----  No access  ------
Local:    -----  No access  ------            -----  No access  ------
Dialup:   -----  No access  ------            -----  No access  ------
Remote:   -----  No access  ------            -----  No access  ------
Expiration:            (none)    Pwdminimum:  8   Login Fails: 13231
Pwdlifetime:         90 00:00    Pwdchange:   2-MAR-1995 07:57 
Last Login:            (none) (interactive), 13-MAR-1997 11:26 (non-interactive)
Maxjobs:         0  Fillm:       300  Bytlm:        32768
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:        40  JTquota:       4096
Prclm:           2  DIOlm:        40  WSdef:         2048
Prio:            4  ASTlm:        40  WSquo:         4096
Queprio:         0  TQElm:        40  WSextent:     10240
CPU:        (none)  Enqlm:      3000  Pgflquo:      32768
Authorized Privileges: 
  NETMBX    TMPMBX
Default Privileges: 
  NETMBX    TMPMBX


STKEIS >> uaf sho/proxy stkosc::isoper

 Default proxies are flagged with (D)

DEC:.SOO.STKOSC::ISOPER
    CONS2WWW


These are the commands executed from STKOSC in the scheduler job:

$!
$ copy/nolog *.tmp stkeis"cons2www"::[.www.psw]*.txt
$ copy/nolog *.html stkeis"cons2www"::[.www.psw]*.htm
$ delete/nolog *.tmp.*
$ purge/keep=5/nolog sys$elsewhere:[isoper.log]*.*
$ purge/keep=5/nolog sys$elsewhere:[isoper]CONS2WWW.HTML
$ purge/nolog stkeis"cons2www"::[.www.psw]*.*
$ exit


Can anyone explain why suddenly 
Status:                   %LOGIN-F-NOSUCHUSER, no such user
    
Is something not working properly after the upgrade?


Regards,
Hans Westerback
CCS Sweden

I can't say for sure this is your problem, but if you haven't installed
any TIMA kits that deal with the security server and proxies, you should.

VAXLOAD02_070 is the VAX kit.

\john

    OK, installed the patch mentioned yesterday, same problem again 
    today. Any more ideas on fixes/troubleshooting?
    
    Rgds,
    Hans

   I'd log a QAR or IPMT, and I'd initially log it against DECnet-Plus. 
   (This might be an OpenVMS problem, but it's not clear what's going on
   inside DECnet-Plus, given that this works sometimes.)

   %%%LOAD02_070 did fix proxy problems.  (VAXLOAD02_070 is the VAX kit,
   I hope you used the ALP... kit, and I will assume you rebooted...)

   Is the NET$PROXY logical name -- if used -- defined in SYLOGICALS.COM
   on STKEIS::, and on all nodes in the same VMScluster as STKEIS::, if
   STKEIS:: is in a VMScluster?

   Do you have any audits or alarms from the 29 failures?  (If not, can
   you enable them and then try to provoke the problem...)

   See HELP::DECNET-OSI_FOR_VMS 3546.*, 3753.*, 3302.*, among others.

    Well I got the impression from reply .1 that the patch was to be
    installed on the receiving side (VAX), which I did (reboot not
    necessary). Now afer reading Steve's reply I also installed the Alpha
    patch on the sender side, and rebooted both systems yesterday. Seems to
    have been stable since that. 
    
    Hans