Re: Windows 2008 Network Level Authentication

Can't offer you a ready solution, but this is what I would do in
your situation:

1. temporarily block inheritance on all domain-wide GPOs on the OU
which contains the 2008 TS machines, to rule in/out that another
GPO is causing the problem
2. as a temporary fix: find out where in the registry the NLA
setting is defined, create a .regfile with the correct setting, and
schedule the .regfile to be imported into the registry on startup
3. open a support case with Microsoft to solve the matter
permanently.

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

=?Utf-8?B?RG91ZyBNdXJwaHk=?=
<DougMurphy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote on 13 jan 2009 in
microsoft.public.windows.terminal_services:

This is still not resolved. Does anyone have an answer to this?
The basic problem is:

1. Windows 2003 domain, containing (now) 2 Windows 2008
Terminals Servers, properly licensed and set up in a round-robin
farm

2. Using either the local GPO and Disabling the Network Level
Authentication, or, using the Remote System Properties to "Allow
connections...using any version of Remote Desktop" is easily
settable.

3. Upon a re-boot of the Terminal Servers (or ANY Windows 2008
server, for that matter), the setting reverst to Enabled,
effectively blocking access from all clients except Vista or
XP/SP3 with credssp enabled.

4. We have no (or little) control over the 4000-some-odd client
computers connecting, and need to have Network Level
Authentication turned completely off, and remain so.

Anyone?

"Doug Murphy" wrote:

Agreed, it does seem that way, but the DC-level policies are
all Windows 2003. I don't know of one that would affect
Network level Authentication, which, I believe, is new with
Vista and Windows 2008.

In addition, these 4 servers are in test mode, now, and have no
domain-level GPOs linked to them, except for the default domain
policy. I've hunted through that looking for something that
would trigger the re-enabling, with no success.

Unless you, or someone, knows of a particular GPO that could
keep re-enabling it??

"Ramasamy Pullappan [MSFT]" wrote:

Is it possible that there is a DC level policy setting that
is causing this behavior?
This seems to be more of DC/GP behavior than TS.
-ram.

--
This posting is provided "AS IS" with no warranties, and
confers no rights.

"Doug Murphy" <DougMurphy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:40769291-D73A-4727-B652-184E4D2DDD61@xxxxxxxxxxxxxxxx
Ok, I have read all the threads about CredSSP and XP
clients, and have even
tested the change sucessfully. My issue is a little
broader, however:

I have 4,000+ users, with a mix of XP and Vista (probably)
that need to access , consistently, a 4 server farm that
consists of 2 physical servers and 2 VMs under Hyper-V
(these are on another server). All 4 are Windows Server
2008. This is working just fine using a CoyotePoint
Equalizer as a hardware load balancer. However, these
servers are in a Windows 2003 domain,
and we have no plans to change that in the near future. I
have no control over the bulk of the remote users, as they
are home systems or belong to another, allied organization
in which I have minimal influence. In esssence,
there is no way that I'm going to be able to dictate that
CredSSP and RDP v6.0 be installed on all these remote
systems.

My problem is this: I want to TURN OFF Network Level
Authentication for all 4 of these Terminal Servers.
Simple, right? Agreed, but the setting in
the GPO:
Computer Configuration
- Administrative Templates
- Windows Components
- Terminal Services
- Terminal Server
- Security

"Require user authentication for remote connections by
using Network Level Authentication"

will not remain persisitently Disabled or Not Configured.
After every re-boot, the setting reverts to Enabled. This
is extraorinarily frustrating
as users who could connect yesterday, cannot connect today
due to a Critical
Updates session re-boot, unless we manually go in and reset
the GPO to Disabled.

Is there something else I can do to get this setting to
remain persistently
OFF??

Thx,
Doug Murphy
.

Relevant Pages

  • Re: Terminal Server GPO Issue
    ... servers that is not in the OU where the GPO is supposed to be applied and I ... Microsoft Windows Operating System Group Policy Result tool v2.0 ... Sharepoint Auth GPO ... Event Log Settings ...
    (microsoft.public.windows.server.active_directory)
  • Re: GP/OU Problem/Question
    ... Create OU & GPO for the TS: ... Right click 'Terminal Servers' OU, ... Ensure that TestUser1 is a member of Domain Users & Remote Desktop ... Make the Security group member of RDU. ...
    (microsoft.public.windows.terminal_services)
  • Re: Loopback Policy Not Taking Effect
    ... Have you rebooted your servers yet? ... Terminal Servers in the OU ... loopback GPO to the "Terminal Servers" OU but to the OU that holds my TS ... ad TS Lockdown Policy and assigned them mostly Computer ...
    (microsoft.public.windows.terminal_services)
  • Re: Group Policy Firewall Exception Problem
    ... It can only be done in the .inf file or through a GPO as far as ... I have set up about a dozen or more Windows 2003, R2 servers on our AD ... Firewall with exceptions for things such as File Sharing and Remote Desktop, ...
    (microsoft.public.windows.group_policy)
  • Re: 802.1X help needed
    ... Check the Internet Authentication Service wireless ... If the GPO is listed, ... Reason = The connection attempt failed because remote access ... access policy, enable remote access permission for that remote access ...
    (microsoft.public.windows.server.sbs)