Re: Unrespected Password Problem

MensajeHi Florencia,
it's true, by default WTK sets local user and remote user to the same value when logging in to a 
remote host via "rlogin" protocol.
However we added a resource in WTKSRV.INI to surround this (since version 3.54.1a) :
[RLOGIN]

;;;;;;;;;;;;;;;;;;
; Specify the local user sent in the rlogin protocol
; by default LOCAL_USER = USER
; you will need to set this explicitly here if the local user
; is a different one
; Default: value of USER
; LOCAL_USER can be:
;
;1. a real user name foo
;2. @USR -> the OS function GetUserName() is called
;3. @USERNAME -> the environment variable USERNAME is used
;4. @ENV{envname} -> an environment variable of choice is used
;  ( @ENV{MYUSER} for example )


LOCAL_USER=@USR

In your case I suggest to set LOCAL_USER TO "@USR" to let WTK fill in the actual Windows user name 
of the local user.
I didn't know that the REMOTEUSER environment variable is now set automagically from the rlogin 
daemon, but I can't find any note about that in the original RFC's 1258 and 1282  . Also the rlogin 
man page doesn't mention this. Is there any man page where I can find this ?
Kind Regards, Leo

----- Original Message ----- 
From: Florencia Vitale
To: [email protected]
Sent: Wednesday, February 22, 2006 3:14 PM
Subject: RE: [fourjs-users] Unrespected Password Problem


Hi all,

On this mail I'll give some more feedback on our actual problem, so to not lead to wrong 
conclusions.

First of all, the case where the user typed in 3 times a wrong password, we could not yet reproduce. 
I'll try to send a consultant to the customer asap, to clarify this. The customer insist's on this 
issue, and sends me printscreens, and all that, but I cannot confirm for sure. And the consultant 
that wen't last time, he didn't see that case really, but the other one. Where the user changed the 
username after the second failure, and succeeded login in with that second account, but saw the 
first username on the terminal window, and on our application first screen.

So here's my feedback on that second case (changin usernames) :

The problem wasn't a security issue at all, but a bug (anoying but not so critical) in the "ilogin" 
application. What happens is that "ilogin" sets the REMOTEUSER variable on the Linux server, with 
the original username, the one defined as default in the shortcut, or the first one you set if there 
was no default user, and not with the user that finally logged in.

I found out, because I could finally reproduce it here, against Fedora Core 4, and there I saw that 
the Linux user was Ok. (with a "who" from another session). But the database conection user, was 
wrong. And that was because in our programs we use REMOTEUSER if it's set, as the Connection and 
Application user. If it's not set, we use the "SELECT user FROM table_with_one_row". We use the 
REMOTEUSER because when we run a program from cli-java or from GASD (in Genero) the Application 
Server always connects to the database with the same user, which is the user that runs the daemon. 
But we need the real username, which we obtain with REMOTEUSER, when the user authenticates with 
HTTP Auth, or any other Auth system we choose.

So, the bug can be divided into 2 problems :

- upon "ilogin" the internal variable @USER is wrongly set. It always shows as the original 
(default) user. This is shown on the ilogin terminal window and confuses the user. This is not 
critical, and most of the times we don't even show the terminal window, in fact we only activated it 
for debugging issues.

- the major problem is that probably that same @USER variable is the one that ilogin uses to set the 
server REMOTEUSER variable. This is only done with Linux servers, on Unix servers it doesn't 
populate that variable at all, as in fact it's not a remote user, but a user from the same server 
it's authenticating the login. So I guess, it shouldn't be populated on Linux, as it's not on Unix, 
and also the @USER should be populated with the actual user that logged in.

I hope this give's some light upon my previous mail.

Florencia

-----Mensaje original-----
De: [email protected] [mailto:[email protected]] En nombre de Florencia Vitale
Enviado el: Jueves, 16 de Febrero de 2006 11:39
Para: [email protected]
Asunto: RE: [fourjs-users] Unrespected Password Problem


Hi Jennifer,

Well, yes, it happened to a customer of us, too.

If you search for a thread with subject "Ilogin Authentication problem" you'll see what I posted. 
But I got no real answer from fourjs. After several tests here, in my environment, I found that the 
username was wrong on the window header, but the real user had logged in.

Then the customer insisted that that was not their case, and they showed me that not changing the 
user, but putting the wrong password 3 times, lets the user log in, with that username, as it's then 
showed in the firt screen of out application where we show the username obtained from the database 
engine.

But after Oliver's answer (see last mail of my thread) I've tried to solve this issue with our local 
support. No solution yet !!!

Florencia
-----Mensaje original-----
De: [email protected] [mailto:[email protected]] En nombre de Jennifer Yu
Enviado el: Miércoles, 15 de Febrero de 2006 18:22
Para: [email protected]
Asunto: [fourjs-users] Unrespected Password Problem


Hi All,

Has anybody come across the problem where a user may type in any password and still log onto the 
Windows Front End?  We noticed this issue in January 2006, but did not have this problem in the 
previous years of using this product.  Our wtksrv files have not been modified.  Telnet connection 
to the system still checks if the entered password matches what is saved for the user.

Hopefully a solution exists since it is a security problem.

Regards,
Jennifer