Ittermittent login failures in OSU

[Willem Grooters]

One of my clients reports a problem with OSU.
Application data is accesable by a webbrowser by starting a gateway procedue that launches a program on VMS, which in turn is able to deliver HTML-pages containing the data, based on a report definion.
This access requires the user to login - once per session. The normal amount of data transferred is quite limited - up to a few KByte per request.
See attacehment for details.
Now there is an autoamted process that will create a session ever 4 minutes or so, and use EXACTLY the same processing for retrieving data in much larger numbers, being returned in XML format, and close the session after that. Same URL-type, just the report definition and parameters are different.

Now once in a while, this porcess faces login failures. Theer is no pattern found why - the only thing i can think of is time-out- because the sheer amount of data to be transferred.

What can I look for to locate the cause of trouble?
I did already look for different server processes, found only one (that had a huge amount of IO). I would expect multiple processes, but I could find out how to set that up.

[David Jones_21]

I'm having trouble keeping track of the pieces in your problem description. Is the gateway procedure a web server script or something else? Protected scripts that required a username and password aren't really 'sessions', web requests are stateless. What output are you receiving that makes you conclude there is a login failure? Did you do a "SHOW INTRUSION" to check for breakin evasion?

Script processes are reused, so the I/O total can reflect the activity of multiple activations. (BTW, scripts should always check for write failures to the network link and quit themselves since the web server does NOT stop script processes if the client aborts).

[Willem Grooters]

Quite understandable - it took me some time to understand. COnsider it to be just another CGI-procedure. Hopefully, the attachement gives some better idea.

The location where this procedure is located, is protected (UAF-based), so users need to login (once) to access the script.

The problem is NOT with this script itself. It works fine, for both interactive as automated access. The problem faced is that the automated process encounters a login failure once in a while.

[Willem Grooters]

Some new information came up:

The appplication that encounters these errors resides on a system used by a large number of processes and interactive users. This is a non-VMS system - either Windows, some Unix or Linux. It seems to hold an Oracle Application server.
On the VMS box a large number (266) of intrusions are shown, originating from this system.
It has been reported that other users - presumably from that Oracle server system - have the same problem with accessing the web-application on the VMS box.

What I did understand is that the both the interactive users and automated process do login sucesfully, but in the cause of their activity, all of a sudden they gate a "401" error back from OSU.

Now my suspiscion is that the number of intrusions blocks access to the VMS box even by the web interface, and that this may trigger a "401" authentication error. Or OSU /DECNet is too occupied with a large number of invalid requests, it will timeout and have OSU return the same error.

Or the webserver is simply too busy.

Any suggestions?

I am not at that machine at all, but if you need more information, just ask, I have asked to pass me any information you need.

[Robert Gezelter]

Willem,

Check the AUDIT log, it should contain records of the failures, hopefully in more detail than what users are reporting.

- Bob Gezelter, http://www.rlgsc.com

[Volker Halle]

Willem,

did you check the security audit logfile on the VMS system to find the reason(s) for the login failures and the intrusion records ?

There is also the recent VMS732_SECSRV-V0100 patch, which solves a performance problem with many intrusions present.

Volker.

[Joseph Huber_1]

Yes, the HTTP_SERVER/EXT_AUTHENTICATOR is only the victim of the intrusion evasion in progress, and nothing can be done on the HTTP_SERVER side .

You have to find out and avoid the cause of the preceeding unsuccessfull logins leading to the evasion.

[Willem Grooters]

The requesting authentication seems to run on a Citric server, or acces the web application via this machine, as well as interactive users trying to login to the machine that runs the OSU webserbver (for their normal work using TELNET sessions). At times, the number of failed logins exceeds the threshold for break-in detection and the whole Citrix server is locked out completely (standard behaviour - I've seen that happen before). The application login data will be invalidated and a new login refused.
A batchjob runs on VMS to clear the intrusions on a regular basis, so new logins are again accepted - and the whole cycle repeats.
This explains the intermittend character of the problem.

Recommended solution: Put the application on a separate machine without other access to the VMS box causing this type of lock-out..