MSDN - Bypass Group Policy?

Author

Bypass Group Policy?

Wolfraider

2006-01-10, 3:59 am

Is there a way to bypass group policy from loading? We have some software
that we are trying to deploy to Windows XP machines. This software requires
the machines to be logged in to run. I have already scripted the install of
the software and created a autologin msi delivered through group policy to
install the software. The problem comes from that we already have a policy
that changes the default username to the machine name for security reasons. I
am just trying to figure out how to get these machines to pull the software
policy, reboot, autologin and install, then reboot and pull normal policies
again. I have found the registry key located in
HKEY_LOCAL_MACHINE\Software\Policies\Mic
rosoft\Windows\System but was told
that this would not work on policies delivered through the network. Thanks
for any help.

Ronny Ong

2006-01-10, 3:59 am

I suspect that an easier solution might be to change whatever is in your MSI
which requires a user to be logged in. If the only issue is that your
package needs administrative rights, you can push the MSI itself via the
Software installation section of group policy, instead of scripting
execution of msiexec. Group policy will automatically install the MSI with
elevated rights during next boot. This is really one of the key benefits of
MSI. Just make sure that the MSI is located in a file share which allows
read access by "Authenticated Users" (or any other security group which
contains the computer accounts of the target machines).

But if you really must avoid the policy, there are 2 options you might be
able to use, depending on your exact situation. If your scripted install is
using a dedicated user account (not used for any other purpose) then you can
get a Domain Admin to deny read permission to that user account for the
group policy object which contains your troublesome policy. In the Group
Policy Management Console, this is done with the Advanced button in the
lower right corner of the Delegation tab. If the policy is not all by itself
in a GPO, this will block all the policies in the entire GPO. If the policy
in question has been set in Default Domain Policy, then you really shouldn't
use this approach without first moving the policy to a separate GPO.

The other option is to temporarily move these machines outside scope of the
GPO. This basically means outside the OU where the GPO is linked. Here is
some example vbscript :

sContainer = "OU=TempInstall"
sParent = "OU=Workstations,DC=yourdomain,DC=local"
Set oSysInfo = CreateObject("ADSystemInfo")
sPath = oSysInfo.ComputerName
sLevels = Split(sPath, ",")
If sLevels(1) <> sContainer Then
Set oDest = GetObject("LDAP://" & sContainer & "," & sParent)
oDest.MoveHere "LDAP://" & sPath, sLevels(0)
End If

Note that this code is written to be run on the client machines themselves,
and it must run under domain credentials which have sufficient permissions
on the current and target OUs. In this example, the client moves itself from
the Workstations OU to the TempInstall OU in the yourdomain.local domain.
Then it could reboot and bypass any GPO linked to Workstations. Later, it
could move itself back and reboot again. Note that you may need to enable
the policy "Always wait for the network at computer startup and logon" for
both OUs. This policy is disabled by default. If you don't have it enabled,
you may need to run gpupdate immediately before each reboot, else Windows XP
may not see the policy change until another reboot. This XP-specific
behavior is by design.

This second option is not available at all if your GPO is Default Domain
Policy. If your GPO is linked at the root of the domain like Default Domain
Policy but is not the actual Default Domain Policy, you could manipulate
Security Filtering and group membership to accomplish the same thing as OU
swap, but this would almost certainly turn into an admin's nightmare.

Sorry if this seems overly complicated but understand that group policy
isn't designed to allow bypass (as long as a machine remains a member of the
domain). Otherwise, it wouldn't be worth using "for security reason" as you
say below.

"Wolfraider" <Wolfraider@discussions.microsoft.com> wrote in message
news:3D7BD43F-5524-4C44-9DD8-8856C4D4F324@microsoft.com...
> Is there a way to bypass group policy from loading? We have some software
> that we are trying to deploy to Windows XP machines. This software
> requires
> the machines to be logged in to run. I have already scripted the install
> of
> the software and created a autologin msi delivered through group policy to
> install the software. The problem comes from that we already have a policy
> that changes the default username to the machine name for security
> reasons. I
> am just trying to figure out how to get these machines to pull the
> software
> policy, reboot, autologin and install, then reboot and pull normal
> policies
> again. I have found the registry key located in
> HKEY_LOCAL_MACHINE\Software\Policies\Mic
rosoft\Windows\System but was told
> that this would not work on policies delivered through the network. Thanks
> for any help.
>

Wolfraider

2006-01-10, 3:59 am

We are delivering all the other software by using indvidual group policy
objects and msi's. This was some troublesome software that comes as an exe
and will not work stable when captured as a msi using Wise or using Altiris
RIP. I am trying to figure out how to get it installed on about 300 to 400
computers. I have 2 other pieces of software that needs to be installed this
way also.

"Ronny Ong" wrote:

> I suspect that an easier solution might be to change whatever is in your MSI
> which requires a user to be logged in. If the only issue is that your
> package needs administrative rights, you can push the MSI itself via the
> Software installation section of group policy, instead of scripting
> execution of msiexec. Group policy will automatically install the MSI with
> elevated rights during next boot. This is really one of the key benefits of
> MSI. Just make sure that the MSI is located in a file share which allows
> read access by "Authenticated Users" (or any other security group which
> contains the computer accounts of the target machines).
>
> But if you really must avoid the policy, there are 2 options you might be
> able to use, depending on your exact situation. If your scripted install is
> using a dedicated user account (not used for any other purpose) then you can
> get a Domain Admin to deny read permission to that user account for the
> group policy object which contains your troublesome policy. In the Group
> Policy Management Console, this is done with the Advanced button in the
> lower right corner of the Delegation tab. If the policy is not all by itself
> in a GPO, this will block all the policies in the entire GPO. If the policy
> in question has been set in Default Domain Policy, then you really shouldn't
> use this approach without first moving the policy to a separate GPO.
>
> The other option is to temporarily move these machines outside scope of the
> GPO. This basically means outside the OU where the GPO is linked. Here is
> some example vbscript :
>
> sContainer = "OU=TempInstall"
> sParent = "OU=Workstations,DC=yourdomain,DC=local"
> Set oSysInfo = CreateObject("ADSystemInfo")
> sPath = oSysInfo.ComputerName
> sLevels = Split(sPath, ",")
> If sLevels(1) <> sContainer Then
> Set oDest = GetObject("LDAP://" & sContainer & "," & sParent)
> oDest.MoveHere "LDAP://" & sPath, sLevels(0)
> End If
>
> Note that this code is written to be run on the client machines themselves,
> and it must run under domain credentials which have sufficient permissions
> on the current and target OUs. In this example, the client moves itself from
> the Workstations OU to the TempInstall OU in the yourdomain.local domain.
> Then it could reboot and bypass any GPO linked to Workstations. Later, it
> could move itself back and reboot again. Note that you may need to enable
> the policy "Always wait for the network at computer startup and logon" for
> both OUs. This policy is disabled by default. If you don't have it enabled,
> you may need to run gpupdate immediately before each reboot, else Windows XP
> may not see the policy change until another reboot. This XP-specific
> behavior is by design.
>
> This second option is not available at all if your GPO is Default Domain
> Policy. If your GPO is linked at the root of the domain like Default Domain
> Policy but is not the actual Default Domain Policy, you could manipulate
> Security Filtering and group membership to accomplish the same thing as OU
> swap, but this would almost certainly turn into an admin's nightmare.
>
> Sorry if this seems overly complicated but understand that group policy
> isn't designed to allow bypass (as long as a machine remains a member of the
> domain). Otherwise, it wouldn't be worth using "for security reason" as you
> say below.
>
>
> "Wolfraider" <Wolfraider@discussions.microsoft.com> wrote in message
> news:3D7BD43F-5524-4C44-9DD8-8856C4D4F324@microsoft.com...
>
>
>

Ronny Ong

2006-01-10, 6:59 pm

Why do you need to reboot and autologon in the first place? If it's just for
elevated rights, why not incorporate "Run As" functionality in your script
and let it be launched by the regular user's logon script. Have GPO set to
run logon scripts synchronously (otherwise XP defaults to asynchronous
execution in the background). This will prevent the user (or the user's
Startup folder) from having a chance to launch something which might
interfere with your install by locking files, loading conflicting DLLs, etc.

Although the built-in RunAs command is awkward to script, there are many
freeware equivalents which are script-friendly (e.g. CPAU, SuperiorSU,
RunAsAdmin, etc.). You can also use AutoIt script which can elevate itself
using RunAsSet().

This eliminates your first reboot. The second reboot (at the end of the
install) could also be eliminated unless your setup process specifically
needs it. Even if it does, there wouldn't be any reason to bypass GPO for
that reboot.

The logon script (or your own install script) would check for an existing
installation and skip the install upon subsequent user logons. In a batch
file, it would be as simple as:

IF EXIST %ProgramFiles%\Whatever\Whatever.exe GOTO EOF

"Wolfraider" <Wolfraider@discussions.microsoft.com> wrote in message
news:97B139E5-66DA-4F48-B39E-A45D51C345F7@microsoft.com...
> We are delivering all the other software by using indvidual group policy
> objects and msi's. This was some troublesome software that comes as an exe
> and will not work stable when captured as a msi using Wise or using
> Altiris
> RIP. I am trying to figure out how to get it installed on about 300 to 400
> computers. I have 2 other pieces of software that needs to be installed
> this
> way also.

Wolfraider

2006-01-10, 9:55 pm

We install software based on the computer policy, not the user. We like to
have all software installed before the user logs in. I have been trying to
figure out different ways of installing this software but have not come up
with an answer. We have tried a msi wrapper to run the software setup but it
did not work on this one.

"Ronny Ong" wrote:

> Why do you need to reboot and autologon in the first place? If it's just for
> elevated rights, why not incorporate "Run As" functionality in your script
> and let it be launched by the regular user's logon script. Have GPO set to
> run logon scripts synchronously (otherwise XP defaults to asynchronous
> execution in the background). This will prevent the user (or the user's
> Startup folder) from having a chance to launch something which might
> interfere with your install by locking files, loading conflicting DLLs, etc.
>
> Although the built-in RunAs command is awkward to script, there are many
> freeware equivalents which are script-friendly (e.g. CPAU, SuperiorSU,
> RunAsAdmin, etc.). You can also use AutoIt script which can elevate itself
> using RunAsSet().
>
> This eliminates your first reboot. The second reboot (at the end of the
> install) could also be eliminated unless your setup process specifically
> needs it. Even if it does, there wouldn't be any reason to bypass GPO for
> that reboot.
>
> The logon script (or your own install script) would check for an existing
> installation and skip the install upon subsequent user logons. In a batch
> file, it would be as simple as:
>
> IF EXIST %ProgramFiles%\Whatever\Whatever.exe GOTO EOF
>
>
>
> "Wolfraider" <Wolfraider@discussions.microsoft.com> wrote in message
> news:97B139E5-66DA-4F48-B39E-A45D51C345F7@microsoft.com...
>
>
>

Ronny Ong

2006-01-11, 6:57 pm

You can apply logon scripts based on computer policy by enabling "Loopback
Processing" in the GPO, then applying the GPO to computers as desired. The
logon script setting itself is in the user settings portion of the GPO (so
don't disable that portion) but when loopback processing is on, it is
automatically applied to any user who logs onto the computers (as long as
they are not deliberately blocked via security filtering).

"Wolfraider" <Wolfraider@discussions.microsoft.com> wrote in message
news:9A9A2B1F-E8EF-4E4A-B853-FE0C04C452B0@microsoft.com...[color=darkred]
> We install software based on the computer policy, not the user. We like to
> have all software installed before the user logs in. I have been trying to
> figure out different ways of installing this software but have not come up
> with an answer. We have tried a msi wrapper to run the software setup but
> it
> did not work on this one.
>
> "Ronny Ong" wrote:
>

Sponsored Links