telnet.exe logging in anomaly

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
.
Any ideas what would cause that?

note- regarding that Failure error message, I managed to cause it
another way, which eventually I couldn't reproduce. I found that if I
made the Admin account non administrative on the remote machine, and
logged in locally on the remote machine, as Admin, then it could not
read the Admin folder. With that symptom, the other symptom was that
when I logged in remotely as Admin, it would give the failure message.

(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. )

It's not of great practical consequence.. though useful to know how it
is working. But it does mean that
You can get failure messages the other odd behaviour described when
connecting CompA to compB, and one of them is Limited the other
Administrative.
So it's nice to know a cause for that.. Since I got it in win xp 32-
bit, and the windows kb article said it was a 64-bit thing.

The KB article suggested something involving something like starting
and stopping and unregistering and registering tlntsvr. (one might
have to start it through the gui not command line, when I tried it I
got an error from command line when starting it).
It didn't make a diff for me anyway.
The other thing I found was to make sure that the service "Secondary
Login" was started (some people had their disabled or disabled theirs
because a windows 2k3 security book or something said to) That didn't
apply to me either, since mine was started anyway.

jameshanley39
Tue Jun 17 22:29:43 PDT 2008

On Jun 18, 6:08=A0am, "jameshanle...@yahoo.co.uk"
<jameshanle...@yahoo.co.uk> wrote:
<snip>
> (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. =A0)

<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