Telnet issues on Windows Server 2003

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve spent a good chunk of this morning trying to get the Telnet service working on Windows Server 2003. By default, this service is disabled and configuring the Telnet service to start automatically and then starting the service is straightforward enough, but when I tried to connect, after supplying username and password details, my clients received the following message:

Failure in initializing the telnet session. Shell process may not have been launched.

Telnet Server has closed the connection

Although the troubleshooting advice for Telnet at the Microsoft Windows Server 2003 TechCenter appears reasonably comprehensive, it didn’t detail this message at all; however Microsoft knowledge base article 309523 does – but only for 64-bit versions of Windows. My telnet server is also a domain controller, and as the advice involves demoting and promoting the server, I chose not to try it on a 32-bit version of Windows (a Google search revealed plenty of anecdotal evidence that it doesn’t work).

I had been trying to establish the connection from a Unix client, so thinking that was the issue, I tried telnet locahost from the server itself but received the same result and checking the application event log revealed various entries similar to the following:

Event Type: Error
Event Source: TlntSvr
Event Category: None
Event ID: 4049
Date: 11/01/2006
Time: 10:00:40
User: N/A
Computer: servername
Description: Error in creating CMD process. System Error: A required privilege is not held by the client.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Following the link in this event led me to check for the presence of %windir%\system32\login.cmd

One post on the microsoft.public.windows.server.general newsgroup looked hopeful, suggesting that the Secondary Logon service also needs to be started; however, when I checked, the Secondary Logon service was already running on my server. I restarted the Secondary Logon and Telnet services just in case (that made no difference) but the newsgroup post had got me thinking about the credentials used by the Telnet service (by default, this was NT AUTHORITY\LocalService). I changed the service to start using the Local System account, restarted the Telnet service and it started accepting connections. Just to be sure, I changed the credentials back to NT AUTHORITY\LocalService (which does not need a password) and restarted the service, breaking Telnet again. That confirmed that it was related to the service’s logon credentials and I went back to using the Local System account.

I’m not sure what the security implications of this hack are. Pretty severe I imagine, as membership of the TelnetClients security group doesn’t seem to make any difference to whether my users can logon to the server using Telnet or not, but at least I can get a console connection to my server from a Unix client now (my Windows clients can use RDP).

20 thoughts on “Telnet issues on Windows Server 2003”

  1. I haven’t tested this (telnet is not on my Windows Server 2003 and I only have limited time right now), but isn’t is just a matter of setting the correct permission on cmd.exe?

    Try cacls %windir%\system32\cmd.exe /e /g the-telnet-user:r

    og try to trace the server with filemon.

  2. Thanks for the tips Per.

    Unfortunately though I’ve tried changing permissions on both cmd.exe and login.cmd with no success. I’m sure it is a permissions issue (possibly privileges), but filemon is only reporting access denied on one file – c:\windows\debug\usermode\chkacc.log – and subsequent entries in the filemon trace suggest that it retries using another account and succeeds. Even when I grant Everyone access on that file (as a test), the telnet session fails to initialise (although the filemon trace looks better).

    I can’t believe I’m the only person who’s come up against this, but I guess not that many people use the Microsoft Telnet server and those who do are using Services for Unix (I’m not).

    Mark

  4. Hi Mark.

    Figured out that I needed to do a tlntsvc /service to get the Telnet Server installed.

    When I add the telnet user to the Users/TelnetClients group and grant this group the “allow log on locally” permission (this is a test domain controller), it works.

    (This test was done on SP1)

  5. Hi Per,
    Thanks for taking the time to look at this.

    I ran tlntsvr /service (despite the advice in Microsoft knowledge base article 309523 being not to do this) and saw the Telnet service disappear! Ran it again and it came back (phew!), but still only accepts connections when I switch the service account from NT AUTHORITY\LocalService to the Local System account.

    I did find out though that the reason my users could all connect to the Telnet server, irrespective of their membership of the TelnetClients group, was because all the users I tried were administrators and so had the log on locally user right assigned to them (doh!). Once I figured that out, I was happy that membership of the TelnetClients group was indeed allowing/disallowing access to the server, as any users who did not have the log on locally right (which incidentally I gave to the TelnetClient group using ntrights -u TelnetClients +r SeInteractiveLogonRight) received the following message:

    Access Denied: Specified user is not a member of TelnetClients group.
    Server administrator must add this user to the above group.

    Telnet Server has closed the connection

    Once a user was added to the TelnetClients group they were allowed Telnet server access (as expected). What I don’t know is whether that group already had the right to log on locally (as I didn’t check before running the ntrights tool from the Windows Server 2003 resource kit).

    So, in summary, everything works – but only by changing the service logon credentials to use the Local System account.

  6. Thanks. This article was very helpful to me. I am running Windows Server 2003 Standard x64 edition and had the same problem you did. I fixed it, as you suggested, by changing the telnet service to run as Local System.

  7. Hi Mark I am having the same problem and it has taken me some time. I am grateful u brought it up

  9. Thanks Rxiao but:

    […] when I checked, the Secondary Logon service was already running on my server. I restarted the Secondary Logon and Telnet services just in case (that made no difference) […]

  11. This worked for me (using local system account) but can someone tell me why when selecting the NT AUTHORITY /Local Service, the error will appear

  13. I’m sorry but I don’t have that information to hand – I’d have to consult my favourite search engine. Bigger question would be why are you running Windows Server 2003? It’s unsupported!

  14. Hi Mark

    we have some applications that are not supporting on windows server 2008 so why still we have 2003 .
    we are planing to go for 2008 but for now audit is forcing to stop telnet in 2003 . i searched too much but was unsuccessful .

  19. I’m sure you can block the client executable too; however you may be limited by the old OS. Anything you can do to re-engineer the solution and get onto a supported platform would be good. Ultimately, by running an unsupported OS you have much larger potential security issues than Telnet!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.