telnet.exe logging in anomaly

  • Thread starter Thread starter jameshanley39
  • Start date Start date
J

jameshanley39

I am not sure if this is an anomaly.. but it happened today when I was
messing with telnet.

SFS off. So, using AFS. So, Classic user authentication.

CompA, CompB.
CompA connecting to CompB.

Both had an account called Admin
(matching passwords, prob matching fullname)

To connect, I guess it logs in as whoever is logged in on CompA. So I
was running telnet.exe from the command prompt, and using RunAs (in a
bat to speed things up). So I could launch a command prompt as Admin
for example, and then do telnet compB 23


If the Admin account on CompA was made Limited/LUA. i.e. removed from
the administrative group, (CompB's Admin account, is Administrative)

Then I found that in order to log on onto compB, CompB had to be
logged in as Admin.

If CompB was logged in as anybody else, be it, built in administrator
(which is administrative). Or, as some limited user. CompA could
not connect to it.

I would get an error "Failure in initializing the telnet session.
Shell process may not have been launched..........", when I tried to
connect and CompB was not logged in as Admin locally.

I think it gave that error message repeatedly e.g. 3 times in a row if
I tried 3 times.

So that was where CompA had Admin limited. compB had it
administrative.


But after alot of fiddling around, I am not sure what changed things,
but now Admin acts like the other accounts. I can't reproduce the
behaviour. Even if CompA's Admin account is limited it still works
 
On Jun 18, 6:08 am, "(e-mail address removed)"
(note- with that cause of that failure, I think it only gives that
error once or twice.. if you keep trying to log in, it logs in as TMP
and as Admin.001 and things. And so I then fixed the Admin account to
point to the Admin directory, restarted windows 'cos you have to.  )
Click to expand...

<snip>

I meant to add.. that was done by
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion
\ProfileList

clicking through the SSID s in the left pane..
looking at this key in the right pane
ProfileImagePath
to see what usr account the SSID was related to
so it may say c:\docu\Admin or it may say c:\docu\Admin.001
if the latter, I would change it


And any time going into a user account.. locally on the remote
machine, or remotely on it, it was worth running the SET command to
display environment variables, so I could see if it had anything
suggesting it was referring to a funny folder like Admin.001. The big
giveaway is in a command prompt when it starts off there. Instead of
in c:\docu\admin it is in c:\docu\admin.001 So perhaps no need for
running the SET command.

And, given the nice situation where one can be prompted for a user/
pass when telnetting - (thus perhaps not requiring local accounts?) I
was able to reproduce the failure message.. maybe just for one of the
failure message situations.

I guess a few things came out of this
- vigilance to check that folder a user account is using
- perhaps usefulness of getting the user/pass prompt somehow (and
perhaps don't need duplicate accounts on each machine, and to be
logged in locally on the local machine, with the same account name as
you want to log in as remotely )
- the fact that you can sometimes get a Failure message when either
the account at the local end, or the account at the remote end, do
not match in terms of local/administrative
- it seems it may be that telnet only works with AFS..

It was a real mess.. I know many people don't look into it 'cos they
use 3rd party SSH program anyway. SSH being more secure.

I haven't run into such problems like I ran into here before.. It
seems very unpredictable in some ways. Easy to workaround / get to
work(log in administratively remotely one way or the toher using
telnet), but not so easy to know why it's doing the crap it's doing
and get predictable behaviour. Maybe a bit of bad luck
 
Back
Top