Re: Unrespected Password Problem

Hi Florencia, I'm afraid I can't follow you completely.
To set the environment variable REMOTEUSER at your server side correctly with WFE 3.54 you can use 
the following command line for ilogin
(in case you want the name of the logged in UNIX user in REMOTEUSER):
export REMOTEUSER=`whoami`;@FGL;fglrun yourapp;exit

(in case you want the name of the WFE Windows user in REMOTEUSER):
export REMOTEUSER=@USR;@FGL;fglrun yourapp;exit

because the command line is sent after the rlogin protocol was successfully handled the rlogin 
daemon cannot change REMOTEUSER anymore. But be careful if you set REMOTEUSER in your login script, 
I guess you have something like that:
@FGL;myscript.sh;exit
and myscript.sh calls fglrun after a bunch of environment settings which might also set 
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.
Does this mean that if you change the name in the "User" field that you don't log in under the new 
User name,but as the user which was typed in the first time? That would be really a bug . Or is just 
REMOTEUSER broken ?
Kind Regards, Leo


----- Original Message ----- 
From: "Florencia Vitale" <[email protected]>
To: <[email protected]>
Sent: Monday, February 27, 2006 6:38 PM
Subject: RE: [fourjs-users] 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
>>