donv&r

Hi all,

I posted this in another group but I don't think it was the right group, so
I'll post here again.

I have a small yet vital application that is distrobuted through an internal
website. The client goes to the website, downloads the cab file and installs
an Active-X control automatically.

We're trying to remove local administrator rights from machines, but to
perform the upgrade for this application's ActiveX, the user will have to be
administrator for a brief period.

I created a GPO that adds the "NL7Pilot" group as a member of the Local
Administrators group through Restricted Groups, as well as the Domain Admins
group, the local administrator user, and the tech support group.

If I "gpupdate /force", reboot the computer, and then log in as a user that
is a member of "NL7Pilot", the user does not have administrator rights.
However, if I go to the command prompt and execute 'net localgroup
administrators' the "NL7Pilot" group shows up as a member of administrators.

If I log out, and then immediately log back in as the same user, the user
will then have administrative rights. It's almost acting as if the restricted
groups settings aren't taking effect until a user logs in the first time. I
thought since it was a computer policy, it should take effect as soon as the
computer starts up, or as soon as a policy update occurs (either in the
background or as a result of a 'gpupdate /force')

Am I not understanding the behaviour of restricted groups properly, or is
there something else I'm not doing.

Thanks,
Don

jorge de almeida pinto mvp - ds

have you...
* a GPO linked to the OU where the computer account is in
* in the GPO restricted group: ADMINISTRATORS (members) your_group

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------

donv&r

Yeah, I think I've got that covered.

The contents of the group are:
Administrator
Domain\Domain Admins
Domain\NL7Pilot

It works after a second login, just not the first time a user logs in after
the policy has seemingly been applied to the computer.

I'm stumped.

- DZ

jorge de almeida pinto mvp - ds

http://blogs.dirteam.com/blogs/jorge/archive/2006/08/31/Using-Diagnostic-Logging-within-Windows.aspx

have a look at:
Enable UserEnv.Log logging of policies and profiles (This policy enables
verbose logging of policy to the userenv.log file, which can be found in
%SystemRoot%\Debug\UserMode\")
a.. HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
b.. UserEnvDebugLevel (in: %windir%\debug\usermode\UserEnv.log)
a.. NONE 0x00000000
b.. NORMAL 0x00000001
c.. VERBOSE 0x00000002
d.. LOGFILE 0x00010000
e.. DEBUGGER 0x00020000
f.. The default value is NORMAL|LOGFILE (0x00010001)

to see why that GPO is not applied
--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------

donv&r

Thanks for the suggestion. I had some time to look at this issue this
afternoon and got some logging information.

From what I can see, it does not indicate that the computer is not applying
the policy for any reason. It looks like it's applied, still the first time a
user in the newly added group logs into that machine, they are not given
administrative rights. The group that the user is a member of shows up in the
output of "net localgroup administrators" but that user does not get
administrative rights until they log off and log back on.

I'm kind of stumped here. I am posting part of the log excerpt below this.

Thanks,
Don


Here is what I think is the vital part of the userenv.log pertaining to the
policy in question:
USERENV(1b4.37c) 15:22:44:098 ProcessGPO: ==============================
USERENV(1b4.37c) 15:22:44:098 ProcessGPO: Searching
<CN={E89A49F5-A3E9-4F4F-BF97-32302731DFEA},CN=Policies,CN=System,DC=MyDomain,DC =Local>
USERENV(1b4.37c) 15:22:44:098 ProcessGPO: Machine has access to this GPO.
USERENV(1b4.37c) 15:22:44:098 ProcessGPO: GPO passes the filter check.
USERENV(1b4.37c) 15:22:44:098 ProcessGPO: Found functionality version of: 2
USERENV(1b4.37c) 15:22:44:098 ProcessGPO: Found file system path of:
<\\MyDomain.Local\SysVol\MyDomain.Local\Policies\{ E89A49F5-A3E9-4F4F-BF97-32302731DFEA}>
USERENV(1b4.37c) 15:22:44:348 ProcessGPO: Found common name of:
<{E89A49F5-A3E9-4F4F-BF97-32302731DFEA}>
USERENV(1b4.37c) 15:22:44:348 ProcessGPO: Found display name of:
<Directory Only>
USERENV(1b4.37c) 15:22:44:348 ProcessGPO: Found machine version of: GPC is
22, GPT is 22
USERENV(1b4.37c) 15:22:44:348 ProcessGPO: Found flags of: 0
USERENV(1b4.37c) 15:22:44:348 ProcessGPO: Found extensions:
[{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}]
USERENV(1b4.37c) 15:22:44:348 ProcessGPO: ==============================

--- The machine then processes other GPOs, then the next time that policy is
mentioned in the userenv.log file is:

USERENV(1b4.37c) 15:22:47:783 ProcessGPOs: -----------------------
USERENV(1b4.37c) 15:22:47:783 ProcessGPOs: Processing extension Security
USERENV(1b4.37c) 15:22:47:783 ReadStatus: Read Extension's Previous status
successfully.
USERENV(1b4.37c) 15:22:47:783 CompareGPOLists: Different version numbers
found
USERENV(1b4.37c) 15:22:47:793 ProcessGPOList: Entering for extension Security
USERENV(1b4.37c) 15:22:47:793 MachinePolicyCallback: Setting status UI to
Applying Security policy...
USERENV(1b4.37c) 15:22:47:793 MachinePolicyCallback: Extension requested
status UI when status UI is not available.
USERENV(1b4.37c) 15:22:47:823 LogExtSessionStatus: Successfully logged
Extension Session data
USERENV(1b4.37c) 15:22:47:863 MachinePolicyCallback: Setting status UI to
Applying security policy...
USERENV(1b4.37c) 15:22:47:863 MachinePolicyCallback: Extension requested
status UI when status UI is not available.
USERENV(1b4.37c) 15:22:47:863 MachinePolicyCallback: Setting status UI to
Directory Only
USERENV(1b4.37c) 15:22:47:873 MachinePolicyCallback: Extension requested
status UI when status UI is not available.
USERENV(1b4.37c) 15:22:48:514 MachinePolicyCallback: Setting status UI to
Configuring security policy to the system.
USERENV(1b4.37c) 15:22:48:514 MachinePolicyCallback: Extension requested
status UI when status UI is not available.
USERENV(1b4.37c) 15:22:50:487 MachinePolicyCallback: Setting status UI to
Applying computer settings...
USERENV(1b4.37c) 15:22:50:487 MachinePolicyCallback: Extension requested
status UI when status UI is not available.
USERENV(1b4.37c) 15:22:50:487 ProcessGPOList: Extension Security returned 0x0.
USERENV(1b4.37c) 15:22:50:487 ProcessGPOList: Extension Security was able to
log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit
USERENV(1b4.37c) 15:22:50:507 ProcessGPOs: -----------------------

roger abell [mvp]

You may simply be seeing the effect of async gp application.
With this enabled, as is default, the login is allowed to happen
even before gp refresh has completed. Hence, you see logged
successful application, but it is after the user token is built at
login. By the time the second login comes about all is in place.
There is a policy to disable async processing, but there are good
reasons it is allowed in the default.

Roger