This content is 20 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).