Windows Server 2008 Normal users cannot log on remotely

1. Check Login permissions

If the file server is not authorized for the user, then the user naturally cannot telnet to the server system, the author decided to carefully check the file server system for their own use of the login account, granted remote login permissions. In this check, the author first in the file server as a system administrator logged in, click on the system's Start/program/Administrative Tools/Server Manager command, open the File Server System Manager console interface, from the display area on the left side of the interface, click Server Management , the server summary option, and then click the Configure Remote Desktop button in the corresponding option Settings area to enter the Remote Desktop Configuration dialog box for the file server system;

Click the "Select User" button in the dialog box, from the pop-up of the 1 Settings window, I see there is no account of their own use, is not the account of their own remote control permissions? I don't think so. Click the Add button to add your own account to the list of remote control permissions, and then click OK button to save the above setting operation. Originally thought that this can solve the problem, but again using their own account telnet to the file server, I found still unsuccessful.

2. Checking Account Restrictions

As you know, if the user account used by the login file server does not have a password set, then Windows Server 2008 will restrict the operation of the remote login, prohibit the use of the blank password of the account for a variety of normal operations, and only allow it to enter the console operation, Then will not be this factor caused the author can not enter the unit of the file server system, a variety of remote management operations? In order to verify their own speculation, I am prepared to carry out the following check operation:

First open the File server System Start menu, click on the "Run" command, in the System Run text box, enter the string command "Gpedit.msc", click the "OK" button, enter the server System Group Policy Edit dialog box;

Next, select the Computer Configuration node option in the list on the left side of the dialog box, and then expand Windows Settings, security settings, Local policies, security options, and then, from the right-side display area of security options, double-click Accounts: A local account that uses a blank password only allows console logons to the target Group Policy, open the target Group Policy Property Settings window shown in 2, where I see that the feature option has been disabled, which means that the culprit of the "blocking" Telnet operation is not a login restriction factor.

3, check the distribution of rights

If the file server prohibits the client system from accessing itself over the network, the user will not be able to remotely telnet into the unit's file server even if they have logon rights, even if they can perform various administrative operations. After the login permission is excluded, the login restriction factor will not be the right assignment, resulting in the file server does not allow the client system to access themselves through the network? The author is very doubtful about this, so the user rights Assignment check operation is unambiguous:

First open the File server System Start menu, click on the "Run" command, in the System Run text box, enter the string command "Gpedit.msc", click the "OK" button, enter the server System Group Policy Edit dialog box;

Next, expand the Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment Branch option from the display area on the left side of the dialog box, and then double-click the target Group Policy "Access this computer from the network" under the "User Rights Assignment" branch option. Open the target Group Policy Property Settings window shown in 3, where the author discovers that the file server allows a normal user to access the computer over the network, and it is clear that the failure to telnet to the server does not have any relationship to this factor.

4, check the login port

Because the file server can be normal ping, but we just can't connect it properly remotely, will not be the file server some features in order to enhance security performance, automatic modification of the Telnet port, causing us to log into a wrong place? Although this possibility is relatively small, but I decided to check it, See if the Remote Desktop Connection port that the file server system uses by default has changed:

First, click on the "Start"/"Run" command on the file Server System desktop, enter the string command "regedit" in the Popup system run box, then enter the registry console interface of the corresponding system after clicking the "OK" button;

Next, expand HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal server\winstations\ from the display area on the left side of the console interface. Rdp-tcp the registry branch, and then double-click the target registry key from below the target branch portnumber, from the PortNumber Key Value property setting window that appears, the author discovers that the Remote Desktop Connection port number currently used by the file server is still "3389", This means that the login port of the file server does not change, and the failure to telnet to the server is not related to the login port.

5, check the network verification

After the exclusion of the above factors, the author still can not telnet into the unit's file server, this is really frustrating! Under the helpless, the author has to try to query the Internet to solve the problem of the plan; During the query, I found that Windows 2008 A new network authentication feature has been added to the server system, and once enabled, the client system must have Windows Vista or Windows Server 2008 system installed in order to telnet into Windows Server normally 2008 Server System, is this new added security feature "blocking" Our normal server remote login? Compared to the operating system used by their own computer, the author more firmly this view, because the author's unit of the LAN client system is mostly Windows XP system, This means that in these client systems, regardless of how a user makes a remote Desktop connection, a connection to a file server that has a Windows Server 2008 system installed cannot succeed. In order to check whether the file server is enabled for network authentication, the author immediately hands-on the following check operation:

First, open the Start menu on the file Server system desktop, click "Settings"/"Control Panel" command, then double tap the system and maintenance, System icon in the System Control Panel window to open the Properties window of the server system;

Next click on the "Remote Settings" button in the Properties window, from the pop up in the 4 Settings window, I see the "only allow computer to run with network authentication Remote Desktop Connection (more secure)" feature option is already selected, it appears that the previous failed to log on server failure, is really by Windows The newly added network authentication feature of the Server 2008 system is caused.

After finding the cause of the failure, it is easier to resolve the failure to log on to the server, the author re-selected the "Allow computers running any version of Remote Desktop (less secure)" option, and then click the "OK" button to save the setup operation, and finally again from your own computer on the remote login test, Found this remote login server operation all smooth, so I can formally confirm that the failure to log on to the server is caused by the network authentication function of the new server system.

Windows Server 2008 Normal users cannot log on remotely