[gptalk] GetGPOList Function Doesn't Return a Correct "Security Group Vetted" List of GPOs - What?

We have a self coded service that allows our remote devices to run their 
GPO-targeted Computer Startup scripts 'after' connecting to the corporate 
network via VPN. In updating the home-grown code recently (to support an 
upcoming release of Vista), we were asked to add one new feature by one of our 
GPO Administrators:

"Have the service only run the scripts in GPOs applicable to the device. [Okay, 
we thought we were doing this. - JC]  That is, the device should not get the 
GPO Computer Startup script when it is a member of a domain security group 
listed on the GPOs Delegation tab with the following properties: 'Allow-Read' 
and 'Deny-Apply Group Policy'." [ And we thought this was the case as well. - 
JC] Because it currently doesn't do this, I have to create separate OUs just to 
get our Computer Startup scripts correctly targeted. [Ouch, what's up here? - 
JC]

We have been running this code on 150,000+ systems since 2001 and, until now, 
no one has ever indicated that the list being returned was not the 'absolutely 
correct' list of GPOs. The service runs under Local System and uses the 
GetGPOList function (with the lpName and lpHostName parameters) to retrieve the 
list of GPOs for the computer.

Has anyone run into this situation before, specifically that using the lpName 
and lpHostName parameters, instead of the hToken parameter in the GetGPOList 
function returns an incorrect list of GPOs?

Also, if I ask the developer to switch to using the hToken parameter, which 
function might be the best to get hToken from [available functions from the 
article noted below are 
LogonUser<http://msdn.microsoft.com/en-us/library/cc447468(VS.85).aspx>, 
CreateRestrictedToken<http://msdn.microsoft.com/en-us/library/cc402001(VS.85).aspx>,
 DuplicateToken<http://msdn.microsoft.com/en-us/library/cc402013(VS.85).aspx>, 
OpenProcessToken<http://msdn.microsoft.com/en-us/library/cc447514(VS.85).aspx>, 
or 
OpenThreadToken<http://msdn.microsoft.com/en-us/library/cc447517(VS.85).aspx>] 
considering the remote nature of the device when connected via VPN?

MSDN link to GetGPOList
http://msdn.microsoft.com/en-us/library/aa373520(VS.85).aspx
...
The GetGPOList function is intended for use by services acting on behalf of a 
user or computer. The service calls this function to obtain a list of GPOs, 
then checks each GPO for service-specific policy. Calling this function with a 
token provides the most accurate list. The system can perform access checking 
for the user or computer. Calling this function with the user or computer name 
and the domain controller name is faster than calling it with a token. However, 
if the token is not specified, the system uses the security access of the 
caller, which means that the list may not be completely correct for the 
intended user or computer.

====================================================================
More (too much) Info  :)
====================================================================
 When I tested this out for the GPO Administrators, their statement (and 
experience) was correct.

The Test: I added a test machine account to a domain-side security group, added 
that security group to a standard GPO (that runs a Computer Startup script) and 
set the groups rights to 'Allow-Read' and 'Deny-Apply Group Policy'. I rebooted 
the device twice, verified it knew that it was a member of the group and 
validated that the GPO was no longer running the script. I unplugged the 
network cable, rebooted it, and then plugged in a non-company LAN line. Then I 
established a VPN session. Sure enough the service thought that the GPO 'was' 
still applicable and ran the script.

In researching this, their GPO typically has the Authenticated User group with 
'Allow-Read' and 'Allow-Apply Group Policy' permissions along with a second 
security group used to filter out certain machine accounts using 'Allow-Read' 
and 'Deny-Apply Group Policy'. Since we created the code in 2001, we cannot be 
sure that the text about GetGPOList not returning the absolutely correct list 
(above in red) was there at the time we were first working with it. However, it 
is there now and we have to deal with it.

Jerry Cruz

Other related posts: