Windows Server

Jim Fischer · Guest

FYI: I'm working with Windows Server 2003 Standard, configured as an active
directory domain controller.

On the server I have a shared folder 'abc'. I created a user
non-administrator 'abcuser' and gave that user read-only privileges on the
shared folder 'abc'. I deleted the 'Everyone' permissions on the shared
folder 'abc'.

The goal now is to configure user 'abcuser' so that it has the following two
properties:

1) XP hosts in the domain can specify the user account 'abcuser' (and
abcuser's password) for authentication purposes to mount the shared folder
'abc' as a network drive, e.g.,

Steven L Umbach · Guest

I think you are over complicating things. If you do not want a user to logon
to a computer then make sure the user is not included in the user right to
logon locally on the computer offering the share. By default domain
controllers are configured that way - regular domain users can not logon to
them. Open Local Security Policy [secpol.msc] and go to local policies/user
rights and modify logon locally to suit your needs. For instance remove
users/everyone and just leave administrators and possibly other privileged
groups you want to logon locally. Keep in mind that the deny logon locally
user right overrides the logon locally user right so be very careful in
populating that list and never include users/everyone as administrators are
also members of users and everyone groups. --- Steve

Jim Fischer · Guest

Doh! I just figured out one of the missing puzzle pieces. Changes made to
the security policy are not necessarily applied immediately. (Note to self:
Some factors that affect the current GP settings: GP updates are pushed only
periodically, ~90 minutes; logout/logon; reboot.)

After I applied the domain security policy "Deny log on locally" to user
'abc', I ran the program 'gpupdate.exe' on the active directory server AND
on all of the XP hosts in the domain to manually update the group policy
settings on those machies. That did the trick. User 'abc' can no longer log
on to the XP hosts in the domain.

What I'm trying to figure out now is how to apply the domain security policy
"Deny log on locally" to the members of a security group. Here's what I
tried:

* I removed the domain security policy "Deny log on locally" from the user
'abc'.

* I ran 'gpupdate' on the domain controller and the XP hosts in the domain
and verified that I could once again log on to the XP hosts as user 'abc'.

* On the domain controller I created a security group 'def' and added the
user 'abc' to that group.

* On the domain controller I applied the domain security policy "Deny log on
locally" to group 'def'.

* I ran 'gpupdate' on the domain controller and the XP hosts in the domain.

When I tried logging on to an XP host as user 'abc', I was successful.
<sigh> So what am I missing here??? Why can user 'abc' still log on to the
XP hosts in the domain when user 'abc' is a member of the security group
'def', and security group 'def' has the domain security policy "Deny log on
locally" applied to it???

Jim

Steven L Umbach · Guest

It should work with a security group and I suggest you use global groups as
the security group for what you want to do. It could be for some reason the
user's security token has not been updated yet when he logged onto the XP
Pro computer [cached credentials maybe] or the security policy change had
not yet propagated. I would check Local Security Policy on the XP Pro
computer to make sure your group shows in the user right for deny logon
locally. If the user still can logon use the support tool whoami /groups to
see if his security token shows the group that is listed in the deny logon
user right. Also FYI in Windows XP Pro you can use rsop.msc to see the
current Group Policy settings applied to the computer and logged on user and
from what GPOs the settings came from. --- Steve

"Jim Fischer" <jfischer_link5809{at}now.here.com> wrote in message
news:%238ApPL15FHA.1184@TK2MSFTNGP12.phx.gbl...
[quote]Doh! I just figured out one of the missing puzzle pieces. Changes made to
the security policy are not necessarily applied immediately. (Note to
self: Some factors that affect the current GP settings: GP updates are
pushed only periodically, ~90 minutes; logout/logon; reboot.)

After I applied the domain security policy "Deny log on locally" to user
'abc', I ran the program 'gpupdate.exe' on the active directory server AND
on all of the XP hosts in the domain to manually update the group policy
settings on those machies. That did the trick. User 'abc' can no longer
log on to the XP hosts in the domain.

What I'm trying to figure out now is how to apply the domain security
policy "Deny log on locally" to the members of a security group. Here's
what I tried:

* I removed the domain security policy "Deny log on locally" from the user
'abc'.

* I ran 'gpupdate' on the domain controller and the XP hosts in the domain
and verified that I could once again log on to the XP hosts as user 'abc'.

* On the domain controller I created a security group 'def' and added the
user 'abc' to that group.

* On the domain controller I applied the domain security policy "Deny log
on locally" to group 'def'.

* I ran 'gpupdate' on the domain controller and the XP hosts in the
domain.

When I tried logging on to an XP host as user 'abc', I was successful.
sigh> So what am I missing here??? Why can user 'abc' still log on to the
XP hosts in the domain when user 'abc' is a member of the security group
'def', and security group 'def' has the domain security policy "Deny log
on locally" applied to it???

Jim

Roger Abell [MVP] · Guest

It should work using a group in the deny user right just as well
as it does when using the user in the deny user right.
Perhaps you have a little timelag issue again? or some other
blip in your experiment? Also, make sure that the group is
specified as domain\groupname in the policy so that the member
machine know not to expect machine local group.

	Windows Server Forum Index -> Security	All times are GMT
Page 1 of 1