Always have to double logon with terminal services
Hi,
I'm using Windows Server 2008 and setting up TS for use with a program for a couple users. I want to have the users type their username/passwords in on their local RDP window rather than seeing the Server 2008 logon screen. When I go to:
Terminal Services Configuration--> RDP-tcp-->Logon Settings-->
The "always prompt for password" is checked, but greyed out. I believe this is where my problem is. No matter what setting I select above, that check box is still greyed out. I've tried changing settings in gpedit.msc, but to no avail. I've even moved this server into a "No inheritance" OU and rebooted but this check box is still greyed out. Any ideas? Thanks in advanced.
I'm using Windows Server 2008 and setting up TS for use with a program for a couple users. I want to have the users type their username/passwords in on their local RDP window rather than seeing the Server 2008 logon screen. When I go to:
Terminal Services Configuration--> RDP-tcp-->Logon Settings-->
The "always prompt for password" is checked, but greyed out. I believe this is where my problem is. No matter what setting I select above, that check box is still greyed out. I've tried changing settings in gpedit.msc, but to no avail. I've even moved this server into a "No inheritance" OU and rebooted but this check box is still greyed out. Any ideas? Thanks in advanced.
I think you're right about that checkbox being the problem. After you changed the GPO settings or moved it to the other OU, did you run gpupdate to refresh the policies on the terminal server? Are they running the new remote desktop client or the one that came with XP?
Another option to work around it is to just have them leave the password blank initially. Then when they're actually connected it will ask for their password and they can log in. I think in this case, since the terminal server is always asking for the password the 2nd time, it never processes the initial login, so leaving the password blank initially should not count as a bad password attempt.
Another option to work around it is to just have them leave the password blank initially. Then when they're actually connected it will ask for their password and they can log in. I think in this case, since the terminal server is always asking for the password the 2nd time, it never processes the initial login, so leaving the password blank initially should not count as a bad password attempt.
ASKER
CrashDummy_MS:,
Yes, I did run the gpupdate /force after I modified the settings & moved OUs. We are connecting from XPSP3 so it is RDP 6.1.
To answer your second question, yes that would work fine desable local credentials and have the user log on at the Server 2008 Screen, but what I left out was that we would like to use RemoteApp and just have them enter username/password at the small initial screen and then they would never see that 2008 logon screen and it would look truely seemless to the end user.
****Update*****
I've uninstalled Terminal ervices, modified the gpedit.msc "Prompt for credentials on the Client Computer" to enabled. Rebooted, and now the check box is unchecked, but still greyed out! Arrgh...
Reinstalled TS, and it does prompt for credentials only once, but still greyed out. Any clues?
Yes, I did run the gpupdate /force after I modified the settings & moved OUs. We are connecting from XPSP3 so it is RDP 6.1.
To answer your second question, yes that would work fine desable local credentials and have the user log on at the Server 2008 Screen, but what I left out was that we would like to use RemoteApp and just have them enter username/password at the small initial screen and then they would never see that 2008 logon screen and it would look truely seemless to the end user.
****Update*****
I've uninstalled Terminal ervices, modified the gpedit.msc "Prompt for credentials on the Client Computer" to enabled. Rebooted, and now the check box is unchecked, but still greyed out! Arrgh...
Reinstalled TS, and it does prompt for credentials only once, but still greyed out. Any clues?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Wierd wierd wierd. First of all, thank you CrashDummy. It doesn't matter how much you believe your settings are right, you should always double check. Currently the machine is in an OU that blocks GPO inheritance. I ran gpresult /v and looked through the list and sure enough, the reason my box is greyed out & unchecked is because of a local GPedit.
Initial Problem --> OU GPO applied
2nd Problem, after I moved to an ininherited OU, I still had the local "Do not allow passwords to be saved" Policy set to enabled.
They are both set to not configured, and my check box is back. Thanks
Initial Problem --> OU GPO applied
2nd Problem, after I moved to an ininherited OU, I still had the local "Do not allow passwords to be saved" Policy set to enabled.
They are both set to not configured, and my check box is back. Thanks
ASKER