Sets LSA (Local Security Authority) policy information.
wntLsaPolSet( server-name, class, element, value)
(s) server-name: the UNC name of the server on which the function will execute (eg, "\\MYSERVER"), or a blank string ("") to indicate the current machine.
(s) class: is one of the following:
"AuditEvents"
"PrimaryDomain"
"AccountDomain"
"LsaServerRole"
"DnsDomain" (Windows 2000 only)
(i) element: For each class, the possible elements are shown below.
(i) value: depends on which element is to be set.
(i) Returns 1
For each class, the possible elements are:
"AuditEvents"
-1 Auditing mode (1 - enable event auditing, 0 - Do not audit)
Audit Category:
1 Restart, Shutdown & System
2 Logon and Logoff
3 File and Object Access
4 Use of User Rights
5 Process Tracking
6 Security Policy Changes
7 User and Group Management
8 DirectoryServiceAccess (Windows 2000)
9 AccountLogon (Windows 2000)
Each 'audit category' requires an integer indicating the auditing options for that category:
0 None
1 Success
2 Failure
3 Success and Failure
"PrimaryDomain"
1 Name
2 Sid
"AccountDomain"
1 Domain Name
2 Domain Sid
"LsaServerRole"
1 Server Role (2=backup, 3=primary)
"DnsDomain" (Windows 2000 only)
1 Name
2 Dns Domain Name
3 Dns Forest Name
(4 Domain Guid) *** not yet implemented
5 Sid
"PrivateData"
(s) registry-key Name of the registry key under which the data is stored. The "value" parameter should contain the unencrypted text that will be encrypted and stored under the specified key. To delete a LSA Private Data Object, specify a value of "*NULL*" for the "value" parameter.
There are 3 basic types of LSA Private Data Objects that can be manipulated, namely Local, Global and non-specific.
Local objects always have the prefix "L$" on their names [e.g. "L$MyPrivateData"]; they can only be accessed from the system on which they are located.
Global objects always have the prefix "G$" on their names [e.g. "G$GlobalPrivateData"]; they can be accessed both remotely and locally. Global objects will be replicated between all domain controllers in a domain whenever they are created [e.g. SET with wntLsaPolSet()] on a domain controller. However, creating a global object on a workstation or a member server will not result in the data object being replicated to any other computers.
The non-specific type of objects do not have any special prefix on their names and can be accessed both locally and remotely, but their values will not be replicated among domain controllers even if they are created on a domain controller.
The Service Control Manager uses LSA Private Data Objects to store the credentials of user accounts when a service is configured to logon as a particular user instead of as the Local System account.
Note: Any account that attempts to get/set LSA Private Data Object values must be a member of the "Administrators" group. This somewhat limits the scope of usefulness of these objects, but still they may be of some value to an administrator who wants to have a script use the wntRunAsUser() function and they don't want to hard code any user credentials into the script itself. Careful use of global objects on domain controllers could make the stored credentials accessible to the script, regardless of what computer it actually runs on in the domain.
The location in the registry under which this information is stored is "HKLM\SECURITY\Policy\Secrets". Under normal circumstances even members of the "Administrators" group do not have any access to this branch of the registry. However, certain system recovery utilities that can be used to access the registry files of a crashed NT/2K system do allow access to this branch of the registry. This means that although it is feasible to store user credentials [e.g. account names & passwords] as LSA Private Data Objects w/o leaving this data open for casual perusal, it is still not possible to make this data 100% safe. The key used to encrypt the data is also stored in this branch of the registry, so anybody who does gain illicit access to this branch of the registry can actually decrypt the contents of the various private data objects.
Notes:
Group Policies, when enabled, take precedence over local settings. Thus, workstations that are part of a domain may have a group policy applied that effectively negates whatever local settings were made with wntLsaPolSet().
Domain controllers only apply changes to audit policy at 5 minute intervals, so making a change of any sort to the audit settings may require as much as 5 minutes to pass before the policy changes take effect.
If wntLsaPolSet() settings are not reflected in its display. You may need to enable the overall auditing setting by calling wntLsaPolSet("","AuditEvents",-1,1).
; Load Appropriate Extender AddExtender('wwwnt34i.dll',0,'wwwnt64i.dll')
flag=wntLsaPolGet("","AuditEvents",1) Message("Before",flag) wntLsaPolSet("","AuditEvents",1,1) flag=wntLsaPolGet("","AuditEvents",1) Message("After",flag) Exit