SCECLI 1202 and 0x4b8 errors: Oh my!

We wanted to get rid of desktop users with administrator rights on Windows XP. With administrator rights, the user is given full control of the C: drive. Reducing users to a regular or power user would mean they would lose modify access to files/folders they need to write to. For example: Cribware stores its configuration options in C:windowscwwin.ini. This is poor programming practice no doubt, but short of reprogramming the program myself my hands were tied. We decided to open parts of the C: drive using a file security GPO, then run a VBScript later on that would move users from the Administrator’s group to Power Users.

Upon creating and implementing the file security GPO, several workstations were throwing errors in the event log:

Event Type: Warning
Event Source: SceCli
Event Category: None
Event ID: 1202
Date: 11/9/2009
Time: 11:53:47 AM
User: N/A
Computer: XXXXXXX
Description:
Security policies were propagated with warning. 0x4b8 : An extended error has occurred.

Drilling into C:windowssecuritywinlogon.log, we find this on the problem PCs:

----Configure File Security...
Configure c:.
Warning 32: The process cannot access the file because it is being used by another process.
Error building security descriptor for c:pagefile.sys.
Configure c:program files.

File Security configuration was completed with one or more errors.

The section that was suppose to set security on the INI files in C:windows was completely missing.

I tried to copy/delete/recreate the GPO database on the workstations in question with no success. That’s when I called in Microsoft PSS to see what the deal was. The support person remoted into all of our DCs and everything at the Active Directory infrastructure level looked fine. He asked me to try the following command on a PC I pulled from the office:

secedit /configure /cfg %windir%repairsecsetup.inf /db secsetup.sdb /verbose

Of course, this fixed this particular PC, so I went to try it on 5 test computers. Only 1 of the 5 was fixed with this solution.

Going back to the trusty Google, I decided to search for “File Security configuration was completed with one or more errors” instead of “1202” and “0x4b8”. Up came up this gem of an article.

Essentially, any file or folder that secedit (what GPOs use to make these changes) encounters with a NULL DACL, it just stops with a warning. There are two ways of attacking this: the GUI way and the command line way. The GUI way is right-clicking on a folder, going to Security>Advanced>Change Permissions and then check the box that says “Replace all child object permissions with inheritable permissions from this object”. If you do a “gpupdate /force” and re-check the log event, SCECLI should now complete without error.

The command line way involves a 3rd party utility called FILEACL.
By running fileacl C:windows /inherit /sub /files, we refresh the ACLs on all files and folders defined at the C:windows level.

The story continues…at first I couldn’t get the CheckNullDacl.vbs script to work from the link above. When I copied the script from the web page, the “-1” in the script on line 72 wasn’t really -1, but some weird character representing “-” and cscript would not run the script. After this was fixed, I decided to find out what files and or folders were causing this issue. PC after PC lead to the same file: C:windowsopla.ini.

Null DACL

File Security

Peeking in the file, I found this:

[Watermark]
W0000001=72,45,12632256,0,0,400,0,0,Arial,,CONFIDENTIAL,,,3,2
W0000002=72,45,12632256,0,0,400,0,0,Arial,,COPY,,,3,0
W0000003=72,45,12632256,0,0,400,0,0,Arial,,DRAFT,,,3,0
[TrueType Substitutions OP]
Courier New=57
Wingdings=75
Symbol=76
Times New Roman=77
Arial=81

I Googled this filename, having no idea what this file was.  I found the text “C9300” in one of the OPLA.INI files and on Google this was related to an Okidata printer. Ah ha! We have 3 Okidata color printers in the building, but not everyone has it installed on their PC. This would explain why this file would be on certain PCs and not others. I confirmed the Okidata link by running Agent Ransack with a text search of “OPLA.INI” and found it in several DLL files in the Okidata 3037 print drivers. Upon running fileacl C:windowsopla.ini /inherit /replace, the group policies applied successfully! The shotgun approach isn’t necessary and we only have to touch one file.

It’s unclear why this possible problem is not listed in the Microsoft knowledge base, nor was it one of the solutions hinted at by PSS. I’m sure if I had continued to work with PSS, they might have suggested it down the road.

Local copies of FILEACL and CheckNullDacl.vbs on my web site.

– Soli Deo Gloria