Termserv loses security settings each night

When I come in each morning, administrators have no problem, but the
normal users can no longer login - they get a security message about
requiring access rights. My solution has been to set up security a
different way - for example, put a group into the remote dektop user
group, or go into term serv configuration and set permissions for RDP
protocol.
I know about the right way to use groups, and I get it working, but the
next day it fails.
It was working for months and started failing 3 days ago - when it
applied several service packs. I can't see any reason, since all the
security is/was working. I get it working, and the next day they are
locked out again, even though my settings are still in place.

A reboot has no effect. There's nothing consequential in the event
logs. I can't see why it happens overnight - there are no unusual
scheduled events that I can find.
I'm going to turn on all kinds of auditing and see what I get tomorrow
morning. It is currently broken, and I'm going to do what I've done
for 3 days - make a change and get it working (I hope.)
It's a pretty generic setup with some remote users on 8:00-5:00 and it
rests at night. The apps are not very unusual but of course anything
is possible.
Any suggestions welcome!!
-R-

Which OS is the server running? And which ServicePack?
Can you give us the *exact* error message that users get?
Is the server part of a domain?
Have you checked the domain security policy?
Are there any restricted groups, where membership is controlled and
changes to membership automatically undone?
What do you mean with:
> My solution has been to
> set up security a different way - for example, put a group into
> the remote dektop user group
This is how it should be done in the first place, so how did you do
it initially?

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

ramspede@gmail.com wrote on 14 jan 2006 in
microsoft.public.win2000.termserv.apps:

> When I come in each morning, administrators have no problem, but
> the normal users can no longer login - they get a security
> message about requiring access rights. My solution has been to
> set up security a different way - for example, put a group into
> the remote dektop user group, or go into term serv configuration
> and set permissions for RDP protocol.
> I know about the right way to use groups, and I get it working,
> but the next day it fails.
> It was working for months and started failing 3 days ago - when
> it applied several service packs. I can't see any reason, since
> all the security is/was working. I get it working, and the next
> day they are locked out again, even though my settings are still
> in place.
>
> A reboot has no effect. There's nothing consequential in the
> event logs. I can't see why it happens overnight - there are no
> unusual scheduled events that I can find.
> I'm going to turn on all kinds of auditing and see what I get
> tomorrow morning. It is currently broken, and I'm going to do
> what I've done for 3 days - make a change and get it working (I
> hope.) It's a pretty generic setup with some remote users on
> 8:00-5:00 and it rests at night. The apps are not very unusual
> but of course anything is possible.
> Any suggestions welcome!!
> -R-

Windows server 2003 standard edition service pack 1
It is a member server in a single-domain forest.
Domain Security Policy might be the key - see below.

The error is
"To logon to this remote computer, you must be granted the allow to log
on through terminal services right. By default, members of the Remote
Dektop Users group have this right. If you are not a member of the
Remote Desktop Users group or another group that has this right, or if
the remote dekstop users group does not have this right, you must be
granted the right manually."

Now that I enabled more auditing, I also receive this event log error:
Logon Failure:
Reason: The user has not been granted the requested
logon type at this machine
User Name: tsuser1
Domain: domainname
Logon Type: 10
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: TS1
Caller User Name: TS1$
Caller Domain: domainname
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 2432
Transited Services: -
Source Network Address: 67.71.89.117
Source Port: 1348
---
This morning, same problem. I got it working today by adding a GPO
that defines local policy for Allow to Logion to Terminal Services and
includes my TSUsers global group. It's working again - just like
yesterday and the day before. In fact, I can prove the GPO controls it
by adding/removing the policy and seeing it work/fail.

But I don't feel confident about this fix, because it is essentially
what I used before - I had already added both tsusers and remote
desktop users into a doamin-wide GPO earlier. That worked but only
temporarily. There's no inheritance blocking and or No Overrides in
effect that would explain why this is working.

I think the problem might lie somewhere in the GPOs but it doesn't
explain why it would break in the middle of the night, or why it would
break at all once it was functioning.

I initially setup security by putting the users into a TSUsers global
group, and placing the TSusers global group into the Remote Desktop
Users group on the termserver. When this failed (after working for a
month), I went into Terminal Services Configuration, Connections,
RDP-Tcp - properties. I added permissions to allow the global group
access (user access and guest access.) when that failed the next day,
I used a different global group that the users are a member of. I
don't remember the exact sequence, but I also have a domain level GPO
that defines local policy for terminal services access, and now today I
have a GPO for my termserv container.
I have been making changes in those places each day to get the users
back online.

The time frame for the initial failure was when it installed security
patch KB912919.

I've no idea, this sound very weird. But it seems to be something
in your GPOs. Are you using the Group Policy Management Console?

Download from
http://www.microsoft.com/windowsser...mc/default.mspx

I would run the GPO tools there, like Resultant set of Policies, to
see if that reveals something strange.

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

ramspede@gmail.com wrote on 15 jan 2006 in
microsoft.public.win2000.termserv.apps:

> Windows server 2003 standard edition service pack 1
> It is a member server in a single-domain forest.
> Domain Security Policy might be the key - see below.
>
> The error is
> "To logon to this remote computer, you must be granted the allow
> to log on through terminal services right. By default, members
> of the Remote Dektop Users group have this right. If you are
> not a member of the Remote Desktop Users group or another group
> that has this right, or if the remote dekstop users group does
> not have this right, you must be granted the right manually."
>
> Now that I enabled more auditing, I also receive this event log
> error: Logon Failure:
> Reason: The user has not been granted the requested
> logon type at this machine
> User Name: tsuser1
> Domain: domainname
> Logon Type: 10
> Logon Process: User32
> Authentication Package: Negotiate
> Workstation Name: TS1
> Caller User Name: TS1$
> Caller Domain: domainname
> Caller Logon ID: (0x0,0x3E7)
> Caller Process ID: 2432
> Transited Services: -
> Source Network Address: 67.71.89.117
> Source Port: 1348
> ---
> This morning, same problem. I got it working today by adding a
> GPO that defines local policy for Allow to Logion to Terminal
> Services and includes my TSUsers global group. It's working
> again - just like yesterday and the day before. In fact, I can
> prove the GPO controls it by adding/removing the policy and
> seeing it work/fail.
>
> But I don't feel confident about this fix, because it is
> essentially what I used before - I had already added both
> tsusers and remote desktop users into a doamin-wide GPO earlier.
> That worked but only temporarily. There's no inheritance
> blocking and or No Overrides in effect that would explain why
> this is working.
>
> I think the problem might lie somewhere in the GPOs but it
> doesn't explain why it would break in the middle of the night,
> or why it would break at all once it was functioning.
>
> I initially setup security by putting the users into a TSUsers
> global group, and placing the TSusers global group into the
> Remote Desktop Users group on the termserver. When this failed
> (after working for a month), I went into Terminal Services
> Configuration, Connections, RDP-Tcp - properties. I added
> permissions to allow the global group access (user access and
> guest access.) when that failed the next day, I used a
> different global group that the users are a member of. I don't
> remember the exact sequence, but I also have a domain level GPO
> that defines local policy for terminal services access, and now
> today I have a GPO for my termserv container.
> I have been making changes in those places each day to get the
> users back online.
>
> The time frame for the initial failure was when it installed
> security patch KB912919.

Yes I already use that console. The resultant set of policies is a
good idea - I'll check it out tomorrow. Today was interesting... Only
the TSUSERS can log on, but not administrators. I had no need to get
into a session, so I made an entry into a domain GPO to add domain
administrators and went on with my day. Wierdness prevails. I'll let
you know.
-R-