New & Updated Security Tools

When will get the new server 25 files? need to start the eval process.

While using the LGPO tool to to import a set of grouppolicy exports from a domain (e.g. delivered by our customers security office) which contains more than one securitypolicies (multiple gpttmpl.ini files).

I mentioned in the logfiles that the secpol.exe ist started with the "/overwrite" parameter...so only the last SecPol wins (no accumulation is done).
I would like to have a switch to change this behaviour...something like "/nooverwrite" to rebuild the "domain way" of applying policies.

Regards
Thomas

Thomas_Liebald : there are a number of settings that can be configured through secedit.exe (and thus by LGPO.exe) that simply apply the changes but don't necessarily record that they were configured by a security policy tool, and the /export option therefore does not report everything that might have been set through security policy. These include service configuration (start type and permissions), file and registry security descriptors, and many other things. At the same time, there are also bugs in secedit.exe /export that LGPO.exe compensates for, such as reporting user rights assignments that are granted to no one (secedit.exe /export fails to report them).

Has anyone mentined that the LGPO tool cannot export the *complete* local security policy...the service settings are missing in export file?
I think the problem starts here:

I have imported a security police with settings applying to nt-services

exerpt from my imported gpttmpl.inf:

[Service General Setting]
"XboxGipSvc",4,""
"XblAuthManager",4,""
"XblGameSave",4,""
"XboxNetApiSvc",4,""
"AppIDSvc",2,""

If you try to export the service settings that are defined in GptTmpl.inf under [service general settings] with

secedit.exe /export /cfg C:\Temp\cfg.ini /areas SERVICES

The tool will quit with "parameter incorrect" and nothing will be exported.

If you perform a complete export with

secedit.exe /export /cfg C:\Temp\cfg.ini

The tool will export all security settings but not the [service genberal setting] section.

Are there any plans to fix the bugs concerning secedit.exe ?
OS: Windows 10 IoT Enterprise LTSC 2019
SecEdit.exe Version: 10.0.17763.1

Basically, the Registry Policy (registry.pol) file format, which is used to deliver the majority of Group Policy settings, is a sequence of registry commands. Most of the time the commands set a registry value, but they can also be used to create a key, delete a specific value, or delete all values from a particular key. That's what Policy Analyzer is reporting.

Those Excel sheets are almost certainly being exported using Policy Analyzer. The PDF that comes with Policy Analyzer describes the "delete" and "delete all values" entries:

Policy Viewer shows ***CONFLICT*** in a cell to indicate that the GPO set has multiple definitions for the
setting that are not all the same. It reports [[[delete]]] to indicate that the GPO includes a command to
delete the registry value if it exists, and [[[Delete all values]]] to indicate that the GPO includes a
command to delete all values within a key. Several GPOs that manage lists of settings will delete all
values within a key before setting the values in the list.

"[[[create key]]]" was inadvertently omitted from the documentation. It's just that the GPO includes a command to create the key but does not necessarily populate it.

Documentation about the Registry Policy file format: Registry Policy File Format | Microsoft Learn

Thanks for this updated version! I'm returning to it after a couple of other projects, and am now using it at a new client.

In the Excel sheets I have exported, I find some entries such as "[[[create key]]], [[[delete]]] and [[[delete all values]]]". I cannot find the meaning of these entries documented anywhere. I'm guessing these are related to group policy preferences, but guessing is not really good enough.

Before anyone suggests it, I'm dependent on exports from the client's highly secure environment, so cannot simply fire up GPEdit and go look at those settings.

Any help greatly appreciated.

RS

That's what I'm saying: the data extracted by secedit.exe and auditpol.exe are more likely to include settings that came down from domain GPO. IIRC, the /b option uses secedit.exe and auditpol.exe to get those security settings and advanced auditing settings; it parses the local registry.pol files for most of the registry-based settings and the local gpt.ini to identify registered client-side extensions, and those files aren't touched by domain GPOs.

AaronMargosis_Tanium That's not it, at least auditing and securit dedicated tool to be extracted (secedit and I forgot the second one) and are always properly extracted, I'm talking a bout REG entries missing, in the latest case I found, all WSUS configuration was missed (but properly present in registry, since our review process also retrieves both SYSTEM and SOFTWARE hives for further analysis).

From what I could gather, it seems to only fetch the "main" GPOs, and misses most of the ones dedicated to specific groups / components (in this case, the WSUS configuration was in a dedicated policy).

sebfault - I'd have to check but my immediate guess is that it's probably some of the Security Settings (such as user rights assignments) and/or Advanced Auditing settings.

AaronMargosis_TaniumI saw that part, but I had some cases where configuration descended through GPO (not applied locally through LGPO) seemed to have been extracted despite this information, is there any exact definition on what is actually backed up (besides this warning) ?

And I concur on the addition of a gpresult-like coverage for the backup function.