RE: Unrespected Password Problem

Hi Leo,

I've done the tests based on you mail and my conclusion is that the default
value of LOCAL_USER should be ok for us. The problem is that the variable
USER is wrongly set, when you change users.

I've done the tests, on :

DVM 3.54.1a (under 3 different OS)
WFE 3.54.2e (all under XP)

----------------------------------------------------------------------------
---------------------------------------
O.S.			LOCAL_USER=USER		LOCAL_USER=@USR or @USERNAME
LOCAL_USER=@ENV{LOGNAME}
----------------------------------------------------------------------------
---------------------------------------
Fedora Core 4	REMOTEUSER (*1)		REMOTEUSER (*2)
empty REMOTEUSER (*3)
Red Hat 8.0		REMOTEUSER (*1)		REMOTEUSER (*2)
empty REMOTEUSER (*3)
Solaris 8		unset REMOTEUSER		unset REMOTEUSER
unset REMOTEUSER
----------------------------------------------------------------------------
---------------------------------------

(*1) REMOTEUSER obtains the value of the first USER set in the ilogin "User"
field. If you change it and then login, you keep getting the original one.
This is the BUG.

(*2) REMOTEUSER gets the "windows network username" no matter what username
I use to login on the Linux/Unix server. This is not what I need, maybe it's
usefull for others.

(*3) REMOTEUSER is set, but has an Empty value, even though LOGNAME is set
in the Linux/Unix environment.

On Solaris the variable REMOTEUSER is always "unset" (not empty, just
unset).

Then I tried to find out WHY we use that variable REMOTEUSER, and tracked it
down to cli-java. In cli-java, in the cjac.cnf file, it is set with
FGL_AUTHUSER (it came on the original example), so we used it to obtain the
REMOTE Username authenticated by the Web Server. It never caused problems
before, because we don't much use "ilogin", and maybe most of the customers
that do use it, have Unix servers. So this problem hadn't happen before.

So, I guess setting the REMOTEUSER variable is not a FourJ's problem, so we
can stop using it.

But now we need to have another way to obtain the Remote Web Server User,
and we need a way that can work across all front-ends (BDS and Genero) or to
know excatly how to do it for each front-end to build internal libraries to
obtain that "user".

Some more info on this matter :

1) in a mail with subject "[fourjs-users] Product News - Four J's Business
Development Suite 3.53 (FOUR J'SJAVA FRONT END)" from April 2nd. 2003, it
says :

		  ~ All JFE previous versions had specialized way to manage
browsers authentification
		    (via the variable FGL_AUTHUSER) and parameters passed
via an URL.
		    In this version, all these features follow the same
standard than Web Front End.

		 ~ For more information, please see the Discovering Web
Front End 3.53 documentation.

	I read that "Discovering WFE 3.53 documentation" and couldn't find
anything about it.

2) I searched all Genero documentation and couldn't find how that same thing
(Web Auth) is done in Genero. What I did found out was that in our already
"converted to Genero" programs, instead of using REMOTEUSER, we are using a
variable "FGL_WEBSERVER_REMOTE_USER". I've searched all bds and genero user
lists mails, and all my FourJ's support mails, and couldn't find out where I
got that info from. But I've tested it with GDC-AX enabling HTTP Auth, and
it works.

So, if I want to use only one method for all the front ends, is that
FGL_WEBSERVER_REMOTE_USER the actual variable for all web front-ends in BDS
and Genero ? If so, can you point out the documentation so I can analyze
this further ?

And if there isn't one unique way, can you tell me for each of these
front-ends, which is the way to obtain the Authenticated User ?

	- BDS Cli-Html Client
	- BDS Cli-Java Client
	- Genero GDC-AX
	- Genero Java Client
	- Genero Web Client

Thanks,

Florencia

> -----Mensaje original-----
> De: [email protected]
> [mailto:[email protected]] En nombre de Leo Schubert
> Enviado el: Miércoles, 22 de Febrero de 2006 12:44
> Para: [email protected]
> Asunto: Re: [fourjs-users] 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
>