none
Scripting Advice

    Soru

  • Just as general advice from the scripting experts - is it possible to retrieve all local security policy settings from every PC in a domain. I am referring to those you can find if on an XP machine through > administrative tools > local security policy (or gpresult or rsop).

    More specifically put, if for example your default domain policy doesnt cover certain security policies, lets say for arguments sake "renaming of administrator account: ?" - then as far as I beleive you are dependant on the local security policy settings that were set during the devices build process? Correct?

    If so - and you arent confident on the consistency of the build process, is it a relatively easy script to say:

    List me all PC's in the domain with the value set against this security policy setting?

    And also - if you didnt want to cause performance issues - could you say here is a txt file of 200 machines - for each of these report back on the value set against these 5 security policy settings? And put it into excel for further analysis?

    Whats your views?

    20 Şubat 2012 Pazartesi 14:48

Yanıtlar

  • I'd still be inclined to go with jrv's suggestion, and use gpresult.  You can then easily parse the files for "Last time Group Policy was applied".

    You could save the report files to a central location, and just use Select-String or similar to check that Group Policy is being applied regularly.


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    GP CmdLets or GP scripts can return the last date easily.

    GP diagnostics tool will give you a report of all systems on a regular basis.

    This si all standard on all domains and has been since W2K.  The newer CmdLets bring thngs together and add some functionality but the GP reporting is not new.

    This is ths only way to check policy compliance.


    ¯\_(ツ)_/¯

    21 Şubat 2012 Salı 13:14

Tüm Yanıtlar

  • there is no easy way to obtain this information.  the powershell cmdlets that work with security settings and group policies are are more geared towards high level looks at the .pol files themselves but not the individual settings.  AFAIK, this cannot be done with either existing built-in cmdline tools or easily through scripting.
    • Düzenleyen thepip3r 20 Şubat 2012 Pazartesi 14:57
    20 Şubat 2012 Pazartesi 14:57
  • I'm assuming here that when the you refer to "Security Policy" you mean "Group Policy" and "Local Policy".  You are correct in that if policy setting are made at the Local level, if these are not over-ridden by Group Policy, they will take effect.  The priority is Local, Site, Domain, OU, OU, OU etc, with the last policy being applied last, and overriding any higher policies (if the are not enforced).

    @thepip3r, I'm not sure what I'm missing.  What about gpresult, that the OP mentions?  This is easy to script for remote machines.


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    20 Şubat 2012 Pazartesi 15:07
  • I'm assuming here that when the you refer to "Security Policy" you mean "Group Policy" and "Local Policy".  You are correct in that if policy setting are made at the Local level, if these are not over-ridden by Group Policy, they will take effect.  The priority is Local, Site, Domain, OU, OU, OU etc, with the last policy being applied last, and overriding any higher policies (if the are not enforced).

    @thepip3r, I'm not sure what I'm missing.  What about gpresult, that the OP mentions?  This is easy to script for remote machines.


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    Yes sorry by "security policy" I meant security settings applied by a domain GPO, or those configured in the local security policy?

    I dont know of anywhere that lets you see sort of a resultant set of policies, i.e.

    policy X was applied byt he local security policy

    policy Y was applied the the gpo AA112

    It was more a case of using a script for an administrative vulnerability scan - i.e. an extension of MBSA perhaps.

    I.e. here are our top 10 concerns (in the form of security policy settings) we know they arent currently being applied by a GPO at domain/OU level - and we arent confident on the consistency of the build process - so whats out there.

    These are the 200 machines we want to check, for these 10 settings, and some form of report at what each says, if it could be in a matrix type report i.e.

                      setting 1                setting 2

    --------------------------------------------------------------

    machine |

    machine 1 | enabled                    1

    machine 2 | disabled                    2

    machine 3 | disabled                     1

    That kind of concept.

    20 Şubat 2012 Pazartesi 15:13
  • @Bigteddy,

    i've never found gpresult to be completely exhaustive.  to describe what i'm talking about.  i just did a gpresult /v > results.txt.  the output file shows 1 logon script which i know to be wrong.  i run an rsop as a normal user and my rsop is showing 4 logon scripts.  so that's why i said it can't be done.  there are tools that give you *some* information, but not all in my experience.

    20 Şubat 2012 Pazartesi 15:25
  • Well, I'm not going to argue, I've only ever worked on one real domain (here at work), and I use gpresult regularly.  It seems to give me accurate results, in that they agree with what RSOP gives me.  But that's my domain, and I don't use logon scripts.

    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    20 Şubat 2012 Pazartesi 16:08
  •  

    Run RSOP on the DC using GPMC.  This can also be scripted with GP CmdLets on WS2008.

    The results of policy on the DC for the computer object are extremely accurate and up-to-date.  They tell us which policies were applied and which policy each setting came from.  The report contains summaries of GP objects and failures to apply policies or execute GP extensions.

    I believe the GP CmdLets allows us to extract RSoP to XML for aggregate analysis and reporting.

    GPResult will usually not work against Vista and later systems unless special steps are taken to allow remote access to policy.

    With any RSOP the results of the policy for a user reflect the last time the user logged onto that system.  If they have not logged on recently the policy will not reflect the latest changes.

    Computer policy will reflect the outcome of the last policy refresh interval.  The first important thing to look at is the last refresh time.

    Last time Group Policy was applied: 2/20/2012 at 1:17:54 PM

    If this is not within the last 60 minutes then there is GP failure somewhere.

    I have seen domains where no policy was being applied fo4r a long time.  The Admins had never detected this.

    If you gpresult does not reflect what you believe is the current policy at the DC then suspect GP failure and but RSOP failure. Remember that user policy only reflect the last logon application assuming that gP is working.


    ¯\_(ツ)_/¯

    20 Şubat 2012 Pazartesi 18:26
  •  

    Run RSOP on the DC using GPMC.  This can also be scripted with GP CmdLets on WS2008.

    The results of policy on the DC for the computer object are extremely accurate and up-to-date.  They tell us which policies were applied and which policy each setting came from.  The report contains summaries of GP objects and failures to apply policies or execute GP extensions.

    I believe the GP CmdLets allows us to extract RSoP to XML for aggregate analysis and reporting.

    GPResult will usually not work against Vista and later systems unless special steps are taken to allow remote access to policy.

    With any RSOP the results of the policy for a user reflect the last time the user logged onto that system.  If they have not logged on recently the policy will not reflect the latest changes.

    Computer policy will reflect the outcome of the last policy refresh interval.  The first important thing to look at is the last refresh time.

    Last time Group Policy was applied: 2/20/2012 at 1:17:54 PM

    If this is not within the last 60 minutes then there is GP failure somewhere.

    I have seen domains where no policy was being applied fo4r a long time.  The Admins had never detected this.

    If you gpresult does not reflect what you believe is the current policy at the DC then suspect GP failure and but RSOP failure. Remember that user policy only reflect the last logon application assuming that gP is working.


    ¯\_(ツ)_/¯

    Theres over 500 PC's to check though running RSOP against the DC - do you have do that for each machine?

    I need to see which machines have certain local security policies set.

    21 Şubat 2012 Salı 08:56
  • In a nutshell -- yes.  However, if you understand how Group Policy works and you are enforcing a particular setting, then unless you have group policy processing errors on those clients, you can assume that they're being applied.  Also, if you are running a client inventorying program like Microsoft's SMS/SCCM, you can query for the registry key, file version, etc. if you know what you're looking for.
    21 Şubat 2012 Salı 12:20
  • I'd still be inclined to go with jrv's suggestion, and use gpresult.  You can then easily parse the files for "Last time Group Policy was applied".

    You could save the report files to a central location, and just use Select-String or similar to check that Group Policy is being applied regularly.


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    21 Şubat 2012 Salı 12:50
  • I'd still be inclined to go with jrv's suggestion, and use gpresult.  You can then easily parse the files for "Last time Group Policy was applied".

    You could save the report files to a central location, and just use Select-String or similar to check that Group Policy is being applied regularly.


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    GP CmdLets or GP scripts can return the last date easily.

    GP diagnostics tool will give you a report of all systems on a regular basis.

    This si all standard on all domains and has been since W2K.  The newer CmdLets bring thngs together and add some functionality but the GP reporting is not new.

    This is ths only way to check policy compliance.


    ¯\_(ツ)_/¯

    21 Şubat 2012 Salı 13:14