Set_FDCC_LGPO – Source code

The source code and Visual Studio project files for the Set_FDCC_LGPO utility are included at an attachment to this post.

To build the project, you need Visual Studio 2005 and the Windows SDK.  The current NIST FDCC policy files are included in the attachment; to build with updated policy files, the attachment includes a PowerShell script to collect files from a locally-extracted copy of the NIST GPO files.

Source code is provided “AS-IS” without warranty, and is not supported by Microsoft customer support.

[Attachment removed, as a newer version is available — bookmark the landing page for the most up-to-date-links.]

Comments (5)

  1. Anonymous says:

    In my environment, all machines have the same settings, so we don’t mind the loss of any previous settings (local policy is just a fall back in case a machine comes off our domain anyway…local policy changes don’t happen very often). Set_FDCC_LGPO is much better than what I had, though. I was just using what I had at the time. I’m glad that I finally know of a better way to handle local policy changes. Thanks for all the work on the tool. I really like the entire FDCC blog so far. Keep up the good work!

  2. Anonymous says:

    Latest versions of utilities published on the FDCC blog for automating the management of Local Group Policy Objects.

  3. Anonymous says:

    Set_FDCC_LGPO utility updated to conform to NIST’s 2008 Q1 update. Set_FDCC_LGPO is a utility to apply FDCC settings to Local Group Policy.

  4. Anonymous says:

    First, let me say this is a great help and very much needed.  We are required to have a system secured before it is attached to the network.  AD GPO’s will help us manage and enforce those settings, but we still need the security there first.

    I really wish you had used Visual Basic rather than C++.  I haven’t looked at the code yet, but I saw a .cpp and am assuming it is C++.  Anyway, I think in the programing world, C, C++, C#, may be the way to go, but in the systems world we know VB Script
    and in some cases VB.  I think, given the audience, Visual Basic 2005 or 2008 would have been the better choice of a programming language.

    I have one request.  We are considering using this to secure existing systems (because of the file ACL’s) by pushing it out in an SMS package.  Our SMS engineers are complaining that this tool operates asynchronously, meaning it exits before the work is
    done, fooling the SMS client into thinking the package has completed when the tool is still working.  I would like to request this tool be updated so the tool does not stop running until all the work it is doing is completed.

    Right now our plan is to push this out with SMS and then follow the execution of this tool with a tool of our own that undoes the settings we initially have to deviate on.  I suppose updating the tools code may be an option, but again, I’m not sure any of
    us are comfortable updating C++ code and maintaining that code into the future.

    Finally, have you tried compiling this code with Visual C++ 2008 Express Edition and the Windows SDK?


    [Aaron Margosis]  Thanks for the kind words.  Sorry to disappoint re the choice of programming language.  It seemed the best bet given the binary file format parsing and API calling that was required.  If I had done it in VB.NET, I would probably have
    had to resort to using advanced techniques which would probably present problems for less-experienced developers; I don’t even want to think about how anyone would implement this tool in VBScript! 🙂

    Re the "asynchronous" issue:  the Set_FDCC_LGPO.exe process does not actually exit until all its work is completed.  The reason you might think it’s asynchronous is because it’s a Windows GUI ("WinMain") app instead of a console ("main()") app, so if
    you run it from a command prompt, the command prompt returns right away — the same as if you run Notepad from a command prompt.  (You can have CMD.EXE wait for the program to exit before giving you another prompt by running it with "start /w".)  I don’t know
    SMS very well, but if it can tell when a process has completed, then this should not be an issue.

    I haven’t tried upgrading the project to VS2008 yet, but I would be very surprised if there were any issues.

  5. Anonymous says:

    I just came across this. I haven’t tried to look at the source code yet, but if it only updates the local GP (including administrative templates), then it’s not that hard to do with VBScript.

    I made something a while back (I will probably end up going to this in the future, though, depending on how easy it is to use) that updates all of this. The ADM templates were the only fairly difficult part, and that was easy after playing around with it
    a little bit.

    I found that all I had to do was configure the machine and user admin template settings on a freshly loaded machine. After that, I would grab the ‘registry.pol’ files from ‘%systemroot%system32grouppolicy’ under the machine and user folders. If you copy
    those to another machine and then increment the version in gpt.ini (convert to hex first and split into two four digit numbers and increment each of those before converting back to decimal) and run a gpupdate /force, it will update the policy just fine. If
    gpt.ini doesn’t exist on the machine, you may have to put the GP extension GUIDs in, but that’s easy since they are always the same. You may also have to create the ‘Adm’ folder and copy the adminstrative templates in so that all the settings will be visible
    when you open the policy editor.

    Any other GP settings can be taken care of with a security template and the ‘secedit.exe’ command.

    Like I said, I may start using the tool that you have made after I look into it a little bit. I just wanted to let you know how to do it with VBScript without any API calls since I saw the comment above about wondering how to do it.

    [Aaron Margosis]  Make sure you’re picking up the latest version.  The
    LGPO tools landing page will always point to the current versions.  This one was just updated last week, in fact.

    Directly replacing registry.pol files is not supported.  In addition, you’re blowing away any other administrative template settings that had been present.  This utility calls supported Group Policy programmatic interfaces, a technique that is fully
    supportable and which doesn’t remove other settings that may be present.  Those interfaces require C++ — they can’t be scripted.

    Security templates in the FDCC GPOs (GptTmpl.inf) are in fact applied using secedit.exe.  If you specify /log on the Set_FDCC_LGPO command line, it will capture all the secedit log output into the log file that you specify.