secedit : Local security seetings not taking effect

[ravi]

Hello,

I am trying to update local security settings using secedit tool. The
windows server 2000 (SP4) server is connected to domain. For example I
wanted to change local setting value for "Do not display last user
name in logon screen" from disabled to enabled (effective setting is
laready showing as enabled becuase of domain GPO). Secedit commnad is
running successfully, but when open secpol or other tools in windows
the local value still shows as disabled.

I even tried to make a copy of current secedit.sdb and merge settings
from inf file to local copy of the database and tried to apply the
local db using another secedit command as shwon here

1) Copy the c:\winnt\security\database\secedit.sdb to c:\tmp
\secedit_backup.sdb

The singleVal.inf will enable the "Do not display last user name in
logon screen" option. Please set it
to disabled, and then run the following commands in c:\tmp

1) cd \tmp
2) secedit /configure /db secedit_backup.sdb /cfg singleVal.inf
3) secedit /configure /db secedit_backup.sdb
4) secedit /refreshpolicy machine_policy /enforce


This stil does not work. Any ideas?

Thanks
Ravi

 

[Meinolf Weber]

Hello Ravi,

You wrote, the server is a domain member, so you have to change/set the policy
on the domain. The local policy will not be used for working, it is the lowest
level.

Group Policy objects are processed according to the following order:

1.
The local Group Policy object (LPGO) is applied.

2.
GPOs linked to sites.

3.
GPOs linked to domains

4.
GPOs linked to organizational units. In the case of nested organizational
units, GPOs associated with parent organizational units are processed prior
to GPOs associated with child organizational units.

http://technet2.microsoft.com/windo...11f4-465f-b243-73e542d06b2c1033.mspx?mfr=true

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

 

[Roger Abell [MVP]]

Why are you configuring settings in secedit_backup.sdb and expecting
them to be effective when it is security.sdb that is in use ?

 

[ravi]

Hello Ravi,

You wrote, the server is a domain member, so you have to change/set the policy
on the domain. The local policy will not be used for working, it is the lowest
level.

Group Policy objects are processed according to the following order:

1.
The local Group Policy object (LPGO) is applied.

2.
GPOs linked to sites.

3.
GPOs linked to domains

4.
GPOs linked to organizational units. In the case of nested organizational
units, GPOs associated with parent organizational units are processed prior
to GPOs associated with child organizational units.

http://technet2.microsoft.com/windowsserver/en/library/212eb1fd-11f4-...

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.









- Show quoted text -

I know they don't take effect. I want them to be set to right values,
when servers are taken out of domain for maintenance etc, we have
right settings there.
-ravi

 

[ravi]

Why are you configuring settings in secedit_backup.sdb and expecting
them to be effective when it is security.sdb that is in use ?













- Show quoted text -

I tried setting them directly into secedit.sdb. Those changes are not
taking effect and analysis tool shows them with red x mark. I tried
setting thm into temp db and transfering them to main db using another
secedit call. This works if the server is not connected to the domain.
If server is connected to domain there seems to no way to update local
values.

 

[Roger Abell [MVP]]

I tried setting them directly into secedit.sdb. Those changes are not
taking effect and analysis tool shows them with red x mark. I tried
setting thm into temp db and transfering them to main db using another
secedit call. This works if the server is not connected to the domain.
If server is connected to domain there seems to no way to update local
values.

Just hypothesis here Ravi, as I have not attempted ever what you
are doing, but as one is not allowed to set values of policies locally
when these conflict with ones delivered by GPO, perhaps your
experience is showing that one is not allowed via API to set any
value, conflicting or not, of a policy that is under AD-based GPO
control. In other words, if you were to take a test machine where
that specific policies you are wanting to set locally are not being
set by AD-based GPO, then see that your methods are able to set
the local policy values, you could then establish that this is so if
once placed back under the original AD-based GPO you are no
longer able to set the value.

Roger

 

[G Johansson]

Why on earth would you need to take out a server from the domain for
maintanence?