The error message:
---------------------------
Security Templates
---------------------------
The Group Policy security settings that apply to this machine could not be determined.
The error returned when trying to retreive these settings from the local security policy database (%windir%\security\database\secedit.sdb) was: The parameter is incorrect.
All local security settings will be displayed, but no indication will be given as to whether or not a given security setting is defined by Group Policy.
Any local security setting modified through this User Interface may subsequently be overriden by domain-level policies.
---------------------------
OK
---------------------------
lets start
Solution 1
“This problem occurs if specific Group Policy security settings are changed from their default settings. These security settings specify the minimum required security setting of server-side and client-side network connections for programs that use the NTLM security support provider (SSP).”
The solution was to edit the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Set the values of NtlmMinServerSec and NtlmMinClientSec to 0 (zero)
Wait about 15-30 minutes for the change to take effect and you should be able to view the Local Security Policy once again!
If you’re curious what these keys do, NtlmMinServerSec specifies the minimum required security setting of server-side network connections for applications using the NTLM security support provider (SSP).
NtlmMinClientSec specifies the minimum required security setting of client-side network connections for applications using the NTLM security support provider (SSP).
In my case both of these settings had previous values of 0×20080030 which enforces message integrity, confidentiality, use of NTLMv2 and 128-bit encryption.
Solution 2:
The security database might be corrupted.
Cause: A hardware problem if the computer is improperly shut down or a software error.
Run esentutl /g to check the integrity of the security database at %windir%\Security\Database\Secedit.sdb.
If the database is corrupt:
1. Attempt to recover it by running esentutl /r on the %windir%\Security folder.
goto at: C:\WINDOWS\security>
execute: esentutl /r
2. If this fails, attempt to repair it by running with esentutl /p on %windir%\Security\Database\Secedit.sdb.
goto at: C:\WINDOWS\security\Database>
execute: esentutl /p secedit.sdb
3. After that, delete the log files in %windir%\Security. esentutl /g
source: from Microsoft's place in... strange way
---------------------------
Security Templates
---------------------------
The Group Policy security settings that apply to this machine could not be determined.
The error returned when trying to retreive these settings from the local security policy database (%windir%\security\database\secedit.sdb) was: The parameter is incorrect.
All local security settings will be displayed, but no indication will be given as to whether or not a given security setting is defined by Group Policy.
Any local security setting modified through this User Interface may subsequently be overriden by domain-level policies.
---------------------------
OK
---------------------------
lets start
Solution 1
“This problem occurs if specific Group Policy security settings are changed from their default settings. These security settings specify the minimum required security setting of server-side and client-side network connections for programs that use the NTLM security support provider (SSP).”
The solution was to edit the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Set the values of NtlmMinServerSec and NtlmMinClientSec to 0 (zero)
Wait about 15-30 minutes for the change to take effect and you should be able to view the Local Security Policy once again!
If you’re curious what these keys do, NtlmMinServerSec specifies the minimum required security setting of server-side network connections for applications using the NTLM security support provider (SSP).
NtlmMinClientSec specifies the minimum required security setting of client-side network connections for applications using the NTLM security support provider (SSP).
In my case both of these settings had previous values of 0×20080030 which enforces message integrity, confidentiality, use of NTLMv2 and 128-bit encryption.
Solution 2:
The security database might be corrupted.
Cause: A hardware problem if the computer is improperly shut down or a software error.
Run esentutl /g to check the integrity of the security database at %windir%\Security\Database\Secedit.sdb.
If the database is corrupt:
1. Attempt to recover it by running esentutl /r on the %windir%\Security folder.
goto at: C:\WINDOWS\security>
execute: esentutl /r
2. If this fails, attempt to repair it by running with esentutl /p on %windir%\Security\Database\Secedit.sdb.
goto at: C:\WINDOWS\security\Database>
execute: esentutl /p secedit.sdb
3. After that, delete the log files in %windir%\Security. esentutl /g
source: from Microsoft's place in... strange way
No comments:
Post a Comment