security template file import

[Graham Turner]

this is a follow up to a previous post of mine titled "clear the database
before importing" which i closed on account of other issues but now it seems
down to the refresh of GPO values that are imported from a security template
file

we have used as a base line for the security of the domain controllers
security templates from Microsoft security operations guide

these have required modification to meet the site requirement

eg we have modified the startup value of the spooler service to a value
which is i think is the first value (changed from 4 to 2) after the service
name

the security template has been subsequenlty reimported following this change
but for some reason the value in the registry does not change

this suggests quite clearly that a previous value is "sticking" and contrary
to information in a previous post is not being overwritten as it should be

observed behaviour is that other registry values such as restrictanonymous
are being updated correctly

perhaps this is behaviour with refresh of service startup values ??

is this a known issue ??

would seem that the fix is to check the clear database before importing the
template file

this would be consistent with the listing of multiple entries for each value
from the security template file when you view the Domain Controller security
policy

wanted to understand the impact of this before doing so -

have established that this relates to secedit.sdb (presumably on the client
that processes the GPO ?)

i wanted to fully understand the client side processing of the securty
settings of a GPO - and by implication then the impact of the "clear
database before importing"

when we import the template does this somehow flag the GPO so that
scecli.dll on the client that processes the GPO removes all values from its
local secedit.sdb before processing the GPO ??

GT

 

[Graham Turner]

Nick, sorry for not getting back to you earlier on this one and thanks for
your ongoing help in this.

direct answers to your questions first;

1. the templates we are importing are those distributed with Microsoft
security operations guide with a few site specific modifications.

the one in particular i am having issue with is the MSS Baseline DC.inf as i
am defining security policy for the domain controllers container.

2. what are all these files in c:\winnt\security\templates\policies ???

look to be direct copies of the security template - does one of these get
created with an incremented gptxx.inf filename every time we import a
security template into a GPO ??

presumably they (or the latest one ??) are used in the generation of the GPO
that is processed the client.

I have set up a non-production machine and test debugging using winlogon.log
as you mention .

have noticed that it "processes these GP templates *.inf" -

i thought winlogon.log logged the processing of the group policy object or
are these entries merely some sort of pointer to the inf template that was
imported into the GPO ?

".... copy into the GPO's sysvol store"

you reference the GPO's current security template - is this one of these
files in the above folder ?

as you can see am struggling a bit !! with the processing of these security
templates

this might be better answered by say a direct scenario based question based
on testing;

1. i create a new GPO linked to the Domain controllers container

2. import a security template file into the GPO

3. secedit /refresh etc .. demonstrates the values in the security template

4. i then remove the link from the DC's container to the GPO

5. the imported values still remain - why ??

sorry for the length of this reply (perhaps you want to take offline) - but
this very important concept needs to be understood -

GT

 

[Nick Finco [MSFT]]

First up are you happy to keep this online ??

I'd rather keep it in the newsgroup. Others can benefit. Plus, if it can't
be answered here or an update is necessary, you need to go through PSS to
escalate the issue.

1. modify the security template (notepad as text editor seems to suffice) -
we have found the security configuration editor "messes" up the format of
the security template file

And this "messing up" of security templates is the service setting
duplication that you mentioned earlier, correct? This occurs when you edit
via the UI or import via the UI, correct? I just did this myself here on a
Win2k SP4 machine and saw the service duplication.

2. edit the GPO, then import the modifed security template file (leave the
clear database before importing unchecked).

If you are going through the process you've described of having a security
template outside of the GPO which you edit to contain all the security
settings for that GPO and reimport, you should check that box. You know
that everything in that template is what you want in the GPO so you
shouldn't do a template merge (by leaving the box unchecked). In addition,
this would remedy the duplicate service setting issue you are seeing which I
also just verified.

the ideal way forward it seems is to effectively start again - but given
your response of "you have to change the value in the policy to match the
original value" this seems not practically unacheivable ?

You shouldn't have to start again. Just check your hand crafted template to
make sure the issue doesn't show up there. Then reimport your template
while checking the box to "Clear this database before importing".

If you don't want to check the checkbox or if you need the merge
functionality when importing templates, you'll need to contact PSS, escalate
the issue, and get a patch. I'll see about getting a bug filed for this
from my end as well.

ps - where is this documented ??!!

Documentation on this is scattered in many whitepapers people have written
over the years. Also, news group searches sometimes work well.
Unfortunately, I don't have pointers handy to these currently.

N

 

[Graham Turner]

Nick ,thanks again for your help on this.

i sort a little more comfortable going through the reimport of the security
settings with the "clear this database before impoting" checkbox enabled

must confess that i am still not entirely comfortable with what is actually
going on here which is why i was seeking further documentation - this goes
way beyonf the grouppolwp.asp that i have used as a reference to date.

am starting to see the flow of data a bit - would you correct me if am way
off target;

when we create GPO obviously create a structure with a GUID under;

c:\winnt\sysvol\sysvol\mydomain\polices\GPOGUID\machine\microsoft\windowsNT\
secedit

in here is a single file - GPTTMPL.INF that lists the securtiy settings (and
as i can see is a copy of an imported security settings file) - is this the
"database" that gets cleared when we use the checkbox (or merged or not as
the case may be !!)

when the DC as a group policy client downloads the GPO it sticks the
contents of this file into one of the GPT*.inf in
c:\winnt\security\templates\policies\

it is these files (or the most recent one ?) that are processed by
seccli.dll to generate the resultant security policy (or running-config as i
would say in Cisco parlance !))

still not too sure about secedit.sdb though ?

hope i am getting this and thanks for your patience and help

GT

 

[Graham Turner]

and as another issue on this, not sure if this requires patching and is
consistent with your observed behaviuor is the refresh of the legal caption
text even with "clear database before importing" enabled

i can edit the securtiy file used as source for this setting, import it into
the GPO successfully - i say this on account of viewing the contents of
gpttmpl.inf in the secedit folder of the GPO file system folder

however despite secedit /refreshpolicy machine /enforce et al it does not
get propogated to the client

is this the scenario you describe of a "tattooed" entry that needs to be
undefined then reapplied ??

ps sure there are better ways of spending Sunday pm !!

GT

 

[Nick Finco [MSFT]]

Yes, you seem to have the gist of the process.

The gpttmpl.inf technically isn't the database that is being cleared when
you check the box, but it's close enough to the truth. If you think of
it as if checking the box clears this file and copies the contents of your
new template into it, that's the right concept. When you don't check the
box, that file isn't cleared so any settings that are in it but not in the
new template remain in the resultant template. That's the merge aspect of
it.

The GPT*.inf files are actually named in order of precedence. The higher
the number in the filename, the higher the precedence of the GPO which it
came from. If you open those files, you can also find the GUID of the GPO
that it was copied from. All of these files are merged together in order to
produce the resulting security policy on the system.

secedit.sdb fits into the picture during the merge process. That's the
database all of the merging happens in. In win2k, it also stores the local
policy settings (which is the lowest priority GPO to be merged). As a side
note, don't let virus scanners scan the file. It won't report as a virus
but the scanner can lock it and then policy propagation won't occur and
you'll get errors in your event log.

N

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

 

[Nick Finco [MSFT]]

No, if the setting currently exists in the GPO, it isn't a tattooed setting.
Only settings that existed in policy and then were subsequently undefined
from policy cause tattooed values.

Legal notice caption is a tricky setting. You don't want to generate a
security template for this setting manually unless you really know what you
are doing because you won't receive the desired effect. Use the security
templates mmc snapin to edit this option. Also, check
%windir%\security\logs\winlogon.log (after turning on logging and
propagating policy,
http://support.microsoft.com/default.aspx?scid=kb;en-us;245422). That will
tell you if the setting was set properly or if there was an error when
setting. Also, you can create a security template using the snapin which
contains only that setting and use secedit.exe to configure it on the
computer manually and check the generated log file for errors. If there
aren't any errors and the setting still doesn't appear in the registry,
something is wrong. You'll want to be at the latest service pack. If that
wasn't the issue, you'd likely need to call PSS to debug the issue further.
If the setting does appear in the registry though, it might require a reboot
before it takes effect.

Sorry to hear this was your Sunday.

N

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

 

[Graham Turner]

Nick, thanks for your time on this as I think i have pretty much got there !

the issue with the non-production server i established was i think
attributable to a "runaway" folder on the DC - i was noticing 100's of *.inf
/ *.dom files which was getting longer with every security policy refresh -
in c:\winnt\security\templates\policies

i got this from winlogon.log

obvioulsy the scecli.dll on the DC was spending forever processing all these
security settings

don't know where they come though !!??

anyway moved from out of here leaving gpttmpl.inf / and the two inf files
(gptxxxxx.inf) from the two GPO's that the DC processes and all seems well

i am now able to see the affect of clear database before importing both on
or off - ie the gpttmpl.inf is added to or overwritten - i am happy to use
as the change procedure to clear database before importing each time - have
wanted to understand clearly the impact of doing so before giving
instruction to the administrators

QU - given that as a general note the GPO editors are at best clumsy ( i
know this is improved by GPMC) but is manual edit of the gpttmpl.inf in the
GPO folder structure a supported operation;

the only issue it would seem to me is the increment of the version value of
the GPT.ini file for the GPO ?

not a major deal though !

haven't yet worked out that the tmpgptfl.inf file plays on the client side
c:\winnt\security\templates\polices plays - is this a temp file used in the
import of the values into secedit.sdb which presumably is the
"running-config" ?

i can see that when security policy is refreshed secedit /refreshpolicy ..
it is the same as the last one to be processed

duly noted on the priority of the GPO's and the naming of GPT*.inf files -
how though does the scecli.dll know which one has the highest priority - it
would seem to need to be written as an attribute of the container to which
they are linked ??

final point - THIS HAS BEEN A MOST HELPFUL INSTRUCTION FROM YOURSELF - Ta
v.much ~!!!

GT

 

[Nick Finco [MSFT]]

Nick, thanks for your time on this as I think i have pretty much got there

!

Glad to hear it.

the issue with the non-production server i established was i think
attributable to a "runaway" folder on the DC - i was noticing 100's of *.inf
/ *.dom files which was getting longer with every security policy refresh -
in c:\winnt\security\templates\policies

If you don't have 100s of GPOs with security policy affecting this client
that shouldn't happen. There should only be one template per GPO in that
folder. There was an issue at one point where those files couldn't be
deleted because of a virus scanner. When policy propagated it would just
keep incrementing the number and adding to the number of files there.

QU - given that as a general note the GPO editors are at best clumsy ( i
know this is improved by GPMC) but is manual edit of the gpttmpl.inf in the
GPO folder structure a supported operation;

It's not supported. Basically, what the UI can generate in a security
template is supported. If you can generate it from the UI, feel free to
type it into the template. Some settings are tricky to get right though
when you are editing by hand. And as you pointed out the UI will increment
the version number for the GPO which is very important so clients know that
the policy changed and will update their settings sooner. By default, they
will force a propagation every 16 hours though so the settings will take
effect eventually.

haven't yet worked out that the tmpgptfl.inf file plays on the client side
c:\winnt\security\templates\polices plays - is this a temp file used in the
import of the values into secedit.sdb which presumably is the
"running-config" ?

It's a temporary file used while copying the GPOs down to the client. It's
values aren't factored into the final merge of the security settings when
they are applied to the system. secedit.sdb is basically a scratch pad in
which to do the setting merge and a place to store local security policy on
Win2k.

duly noted on the priority of the GPO's and the naming of GPT*.inf files -
how though does the scecli.dll know which one has the highest priority - it
would seem to need to be written as an attribute of the container to which
they are linked ??

The Group Policy infrastructure tells each extension the priority and
location of each GPO when policy propagation is triggered. This is based
upon what OU the policy is defined within and what the GPO priority is
within that OU. When you use the UI, you can move GPOs up or down in the
list. That changes them to a higher or lower priority respectively. As for
as OU priority, local policy always has the lowest priority, then domain
level policy, and then drilling down through the OU structure to the
computer's OU, each OU gets higher and higher in priority until the OU that
contains the computer has the highest priority. How was that for a run-on?

final point - THIS HAS BEEN A MOST HELPFUL INSTRUCTION FROM YOURSELF - Ta
v.much ~!!!

Yup, you're welcome. I'm glad that I could help you to better understand
this process.

N

 

[Graham Turner]

Nick, one final and very specific issue on security / GPO.

the observed behaviour when using an imported security template is that we
are observing truncation in the legal caption text.

the admins are able to set it ok using a GPO linked to a workstations
container for all the desktops but for the DC's we are using an imported
security template.

are there any "known issues" in this respect. ??

GT

 

[Nick Finco [MSFT]]

Legal notice text has been a finicky setting. You have to have at least SP4
on your Win2k machines, otherwise you will be limited to 511 characters.
This applies to the administration computer, the DCs, and the clients which
have the policy propagating to them. Once you have the SP level right, your
length is limited to something like 4k (I can't remember the number
offhand). Oddities can arise though even then. I've previously recommended
to someone to have a comma at least every 500 characters and that fixed
their issue. In your case though, it sounds like you just aren't at the
right SP level.

N