Friday, 8 June 2012
Why does the package go for Self Healing first time the user launches the Application?
If the package is containing some HKCU entries then the package will always go for self healing for the first time. This happens because the HKCU keys are only installed for the current user present while installing the package and not all the users as it is the property of the HKCU. So, if other user logs in then there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), then the related feature is re-installed. This is called the Self Healing.
Which one will execute first is Run or Active setup?
The answer is “Active setup”.
Because, Activesetup is using to configure the userprofile settings if no entry points exists in the package and this will be running only once for a specific user.
Where as RUN key will execute everytime when user login the machine.
Where as RUN key will execute everytime when user login the machine.
These settings are configured with different sequence , in order to speedup to get access to windows desktop\user level settings.
SetACL Commands
SetACL is a tool for manipulating permissions, or, to be more exact, security descriptors (SDs). SDs are used on operating systems based on Windows NT to control access to securable objects.
SetACL is a tool for manipulating permissions.
SetACL is relatively feature complete and bug free. SetACL has been fast and stable from the very beginning!
SetACL can set permissions on:
SetACL is relatively feature complete and bug free. SetACL has been fast and stable from the very beginning!
SetACL can set permissions on:
• Local or remote directories
• Local or remote files
• Local or remote printers
• Local or remote registry keys
• Local or remote Win32 services
• Local or remote network shares
The following special features distinguish SetACL from similar programs:
• Use all special permissions of Windows 2000 in the file system and in the registry.
• Block the inheritance from the parent object while copying the ACL from the parent object or clearing it.
• Specify how permissions are inherited to child objects: container, object or container + object.
• Set permissions for any type of user or local / domain local / global / universal group.
• Set permissions on any machine; it does not matter whether the target machine is in a trusted domain, an independent domain or a workgroup.
• Use wildcards in object names (only works in the file system).
• Recursively set permissions on any sub-object in the file system and in the registry.
• Set, grant, deny or revoke permissions.
OPTIONS
-on ObjectName
-ot ObjectType
-actn Action
-ace “n:Trustee;p:Permission;s:IsSID;i:Inheritance;m:Mode;w:Where”
-trst “n1:Trustee;n2:Trustee;s1:IsSID;s2:IsSID;ta:TrusteeAction;w:Where”
-silent –on “c:\windows\inf\USBSTOR.INF” -ot FILE -actn trustee -trst
“n1:everyone;ta:remtrst;w:dacl”
-dom “n1:Domain;n2:Domain;da:DomainAction;w:Where”
-ownr “n:Trustee;s:IsSID”
-grp “n:Trustee;s:IsSID”
-rec Recursion
-op “dacl:Protection;sacl:Protection”
-rst Where
-lst “f:Format;w:What;i:ListInherited;s:DisplaySID”
-bckp Filename
-log Filename
-fltr Keyword
-clr Where
-silent
-ignoreerr
-on ObjectName
-ot ObjectType
-actn Action
-ace “n:Trustee;p:Permission;s:IsSID;i:Inheritance;m:Mode;w:Where”
-trst “n1:Trustee;n2:Trustee;s1:IsSID;s2:IsSID;ta:TrusteeAction;w:Where”
-silent –on “c:\windows\inf\USBSTOR.INF” -ot FILE -actn trustee -trst
“n1:everyone;ta:remtrst;w:dacl”
-dom “n1:Domain;n2:Domain;da:DomainAction;w:Where”
-ownr “n:Trustee;s:IsSID”
-grp “n:Trustee;s:IsSID”
-rec Recursion
-op “dacl:Protection;sacl:Protection”
-rst Where
-lst “f:Format;w:What;i:ListInherited;s:DisplaySID”
-bckp Filename
-log Filename
-fltr Keyword
-clr Where
-silent
-ignoreerr
Parameters:
Object Name: Name of the object to process (e.g. ‘c:\mydir’)
ObjectType:
Type of object:
file: Directory/file
reg: Registry key
srv: Service
prn: Printer
shr: Network share
Action:
Action(s) to perform:
ace: Process ACEs specified by parameter(s) ‘-ace’
trustee: Process trustee(s) specified by parameter(s) ‘-trst’.
domain: Process domain(s) specified by parameter(s) ‘-dom’.
list: List permissions. A backup file can be specified by parameter ‘-bckp’.Controlled by parameter ‘-lst’.
restore: Restore entire security descriptors backed up using the list function. A file containing the backup has to be specified using the parameter ‘-bckp’. The listing has to be in SDDL format.
Action(s) to perform:
ace: Process ACEs specified by parameter(s) ‘-ace’
trustee: Process trustee(s) specified by parameter(s) ‘-trst’.
domain: Process domain(s) specified by parameter(s) ‘-dom’.
list: List permissions. A backup file can be specified by parameter ‘-bckp’.Controlled by parameter ‘-lst’.
restore: Restore entire security descriptors backed up using the list function. A file containing the backup has to be specified using the parameter ‘-bckp’. The listing has to be in SDDL format.
setowner: Set the owner to trustee specified by parameter ‘-ownr’.
setgroup: Set the primary group to trustee specified by parameter ‘-grp’.
clear: Clear the ACL of any non-inherited ACEs. The parameter ‘-clr’ controls whether to do this for the DACL, the SACL, or both.
setprot: Set the flag ‘allow inheritable permissions from the parent object to propagate to this object’ to the value specified by parameter ‘-op’.
rstchldrn: Reset permissions on all sub-objects and enable propagation of inherited permissions. The parameter ‘-rst’ controls whether to do this forthe DACL, the SACL, or both.
setgroup: Set the primary group to trustee specified by parameter ‘-grp’.
clear: Clear the ACL of any non-inherited ACEs. The parameter ‘-clr’ controls whether to do this for the DACL, the SACL, or both.
setprot: Set the flag ‘allow inheritable permissions from the parent object to propagate to this object’ to the value specified by parameter ‘-op’.
rstchldrn: Reset permissions on all sub-objects and enable propagation of inherited permissions. The parameter ‘-rst’ controls whether to do this forthe DACL, the SACL, or both.
TrusteeAction: Action to perform on trustee specified:
remtrst: Remove all ACEs belonging to trustee specified.
repltrst: Replace trustee ‘n1′ by ‘n2′ in all ACEs.
cpytrst: Copy the permissions for trustee ‘n1′ to ‘n2′.
repltrst: Replace trustee ‘n1′ by ‘n2′ in all ACEs.
cpytrst: Copy the permissions for trustee ‘n1′ to ‘n2′.
DomainAction: Action to perform on domain specified:
remdom: Remove all ACEs belonging to trustees of domain specified.
repldom: Replace trustees from domain ‘n1′ by trustees with same name from domain ‘n2′ in all ACEs.
cpydom: Copy permissions from trustees from domain ‘n1′ to trustees with same name from domain ‘n2′ in all ACEs.
Trustee: Name or SID of trustee (user or group). Format:
a) [(computer | domain)\]name Where:
computer: DNS or NetBIOS name of a computer -> ‘name’ must be a local account on that computer.
domain: DNS or NetBIOS name of a domain -> ‘name’ must be a domain user or group.
name: user or group name
computer: DNS or NetBIOS name of a computer -> ‘name’ must be a local account on that computer.
domain: DNS or NetBIOS name of a domain -> ‘name’ must be a domain user or group.
name: user or group name
If no computer or domain name is given, SetACL tries to find a SID for ‘name’ in the following order:
1. built-in accounts and well-known SIDs
2. local accounts
3. primary domain
4. trusted domains
2. local accounts
3. primary domain
4. trusted domains
b) SID string
Domain: Name of a domain (NetBIOS or DNS name).
Permission: Permission to set. Validity of permissions depends on the object type (see below). Comma separated list.
Example: ‘read,write_ea,write_dacl’
IsSID:
Is the trustee name a SID?
y: Yes
n: No
DisplaySID:
Display trustee names as SIDs?
y: Yes
n: No
b: Both (names and SIDs)
Inheritance:
Inheritance flags for the ACE. This may be a comma separated list containing the following:
so: sub-objects
sc: sub-containers
np: no propagation
io: inherit only
Example: ‘io,so’
sc: sub-containers
np: no propagation
io: inherit only
Example: ‘io,so’
Mode:
Access mode of this ACE:
a) DACL:
set: Replace all permissions for given trustee by those specified.
grant: Add permissions specified to existing permissions for given trustee.
deny: Deny permissions specified.
revoke: Remove permissions specified from existing permissions for given trustee.
b) SACL:
aud_succ: Add an audit success ACE.
aud_fail: Add an audit failure ACE.
revoke: Remove permissions specified from existing permissions for given trustee.
Where:
Apply settings to DACL, SACL, or both (comma separated list):
Dacl
sacl
dacl,sacl
Apply settings to DACL, SACL, or both (comma separated list):
Dacl
sacl
dacl,sacl
Recursion:
Recursion settings, depends on object type:
a) file:
no: No recursion.
cont: Recurse, and process directories only.
obj: Recurse, and process files only.
cont_obj: Recurse, and process directories and files.
b) reg:
no: Do not recurse.
yes: Do Recurse.
Protection:
Controls the flag ‘allow inheritable permissions from the parent object to propagate to this object’:
nc: Do not change the current setting.
np: Object is not protected, i.e. inherits from parent.
p_c: Object is protected, ACEs from parent are copied.
p_nc: Object is protected, ACEs from parent are not copied.
Format:
Which list format to use:
sddl: Standardized SDDL format. Only listings in this format can be restored.
csv: SetACL’s csv format.
tab: SetACL’s tabular format
What:
Which components of security descriptors to include in the listing. (Comma separated list):
d: DACL
s: SACL
o: Owner
g: Primary group
Example: ‘d,s’
ListInherited:
List inherited permissions?
y: Yes
n: No
Filename:
Name of a (unicode) file used for list/backup/restore operations or logging.
Keyword:
Keyword to filter object names by. Names containing this keyword are not processed.
Keyword to filter object names by. Names containing this keyword are not processed.
REMARKS
Required parameters (all others are optional):
-on (Object name)
-ot (Object type)
Parameters that may be specified more than once:
-actn (Action)
-ace (Access control entry)
-trst (Trustee)
-dom (Domain)
-fltr (Filter keyword)
-actn (Action)
-ace (Access control entry)
-trst (Trustee)
-dom (Domain)
-fltr (Filter keyword)
Only actions specified by parameter(s) ‘-actn’ are actually performed, regardless of the other options set.
Order in which multiple actions are processed:
1. restore
2. Clear
3. Trustee
4. Domain
5. ace, setowner, setgroup, setprot
6. Rstchldrn
7. list
1. restore
2. Clear
3. Trustee
4. Domain
5. ace, setowner, setgroup, setprot
6. Rstchldrn
7. list
VALID PERMISSIONS
a) Standard permission sets (combinations of specific permissions)
a) Standard permission sets (combinations of specific permissions)
Files / Directories:
read: Read
write: Write
list_folder: List folder
read_ex: Read, execute
change: Change
profile: = change + write_dacl
full: Full access
Printers:
print: Print
man_printer: Manage printer
man_docs: Manage documents
full: Full access
Registry:
read: Read
full: Full access
Service:
read: Read
start_stop: Start / Stop
full: Full access
Share:
read: Read
change: Change
full: Full access
b) Specific permissions
Files / Directories:
traverse: Traverse folder / execute file
list_dir: List folder / read data
read_attr: Read attributes
read_ea: Read extended attributes
add_file: Create files / write data
add_subdir: Create folders / append data
write_attr: Write attributes
write_ea: Write extended attributes
del_child: Delete subfolders and files
delete: Delete
read_dacl: Read permissions
write_dacl: Write permissions
write_owner: Take ownership
Registry: query_val: Query value
set_val: Set value
create_subkey: Create subkeys
enum_subkeys: Enumerate subkeys
notify: Notify
create_link: Create link
delete: Delete
write_dacl: Write permissions
write_owner: Take ownership
read_access: Read control
USAGE ::
<object name> = Any valid path to local or remote object
<object type> = {/file | /dir | /printer | /registry | /service | /share}
<action> = {/deny | /grant | /set | /revoke}
<trustee> = User/group to grant/deny permissions for, ie. ‘machine\user’
<permissions>
/file = {/read | /write | /read_ex | /change | /full | /traverse |
/list_dir | /read_attributes | /read_ea | /add_file |
/add_subdir | /write_attributes | /write_ea |
/delete_child | /delete | /read_dacl | /write_dacl |
/write_owner}
read: Read
write: Write
list_folder: List folder
read_ex: Read, execute
change: Change
profile: = change + write_dacl
full: Full access
Printers:
print: Print
man_printer: Manage printer
man_docs: Manage documents
full: Full access
Registry:
read: Read
full: Full access
Service:
read: Read
start_stop: Start / Stop
full: Full access
Share:
read: Read
change: Change
full: Full access
b) Specific permissions
Files / Directories:
traverse: Traverse folder / execute file
list_dir: List folder / read data
read_attr: Read attributes
read_ea: Read extended attributes
add_file: Create files / write data
add_subdir: Create folders / append data
write_attr: Write attributes
write_ea: Write extended attributes
del_child: Delete subfolders and files
delete: Delete
read_dacl: Read permissions
write_dacl: Write permissions
write_owner: Take ownership
Registry: query_val: Query value
set_val: Set value
create_subkey: Create subkeys
enum_subkeys: Enumerate subkeys
notify: Notify
create_link: Create link
delete: Delete
write_dacl: Write permissions
write_owner: Take ownership
read_access: Read control
USAGE ::
<object name> = Any valid path to local or remote object
<object type> = {/file | /dir | /printer | /registry | /service | /share}
<action> = {/deny | /grant | /set | /revoke}
<trustee> = User/group to grant/deny permissions for, ie. ‘machine\user’
<permissions>
/file = {/read | /write | /read_ex | /change | /full | /traverse |
/list_dir | /read_attributes | /read_ea | /add_file |
/add_subdir | /write_attributes | /write_ea |
/delete_child | /delete | /read_dacl | /write_dacl |
/write_owner}
/dir = {/read | /write | /list_folder | /read_ex | /change |
/profile | /full | /traverse | /list_dir |
/read_attributes | /read_ea | /add_file | /add_subdir |
/write_attributes | /write_ea | /delete_child |/delete |
/read_dacl | /write_dacl | /write_owner}
/printer = {/print | /man_printer | /man_docs | /full}
/profile | /full | /traverse | /list_dir |
/read_attributes | /read_ea | /add_file | /add_subdir |
/write_attributes | /write_ea | /delete_child |/delete |
/read_dacl | /write_dacl | /write_owner}
/printer = {/print | /man_printer | /man_docs | /full}
/registry = {/read | /full | /query_val | /set_val | /create_subkey |
/enum_subkeys | /notify | /create_link | /delete |
/write_dacl | /write_owner | /read_access}
/service = {/read | /start_stop | /full}
/share = {/read | /change | /full}
<inheritance> = {cont_obj_inh | cont_inh | obj_inh | no_prop_inh |
inh_only_obj | inh_only_cont | inh_only_cont_obj}
/enum_subkeys | /notify | /create_link | /delete |
/write_dacl | /write_owner | /read_access}
/service = {/read | /start_stop | /full}
/share = {/read | /change | /full}
<inheritance> = {cont_obj_inh | cont_inh | obj_inh | no_prop_inh |
inh_only_obj | inh_only_cont | inh_only_cont_obj}
<inh. from parent>
= {yes | no_copy | no_dont_copy}
<recursion> = {cont_obj | cont | obj}
/sid : <trustee> parameter is a SID, not an account/group name.
Well-known SIDs can be used.
/silent : No output whatsoever is displayed if the number of
parameters passed is correct.
Remarks
The “object name” parameter:
= {yes | no_copy | no_dont_copy}
<recursion> = {cont_obj | cont | obj}
/sid : <trustee> parameter is a SID, not an account/group name.
Well-known SIDs can be used.
/silent : No output whatsoever is displayed if the number of
parameters passed is correct.
Remarks
The “object name” parameter:
• Files/directories: Can be a relative path (“filename”), absolute path (“c:\dirname”) or a UNC name (“\\machine\share\dirname“).
• Printers: Can be a local (“printername”) or a remote printer (“\\machine\printername“)
• Registry key: Can be a local (“MACHINE\MyKey”) or a remote registry key (“\\machine\MACHINE\MyKey”).The hive keys must be specified like this: “CLASSES_ROOT”, “CURRENT_USER”, “MACHINE”, “USERS”.
• Service: Can be a local (“servicename”) or a remote service (“\\machine\servicename“).
• Share: Can be a local or remote network share. Always specify: “\\machine\share“. The “action” parameter:
• ”/grant”: Creates a new access-allowed ACE that combines the specified rights with any existing rights of the trustee. The new ACE replaces any existing access-allowed ACE for the trustee. The program also modifies or deletes any existing access-denied ACE for the trustee that denies the specified rights.
• ”/set”: Similar to /grant except that the new access-allowed ACE allows only the specified rights, discarding any existing rights. This flag also removes any existing access-denied ACE for the trustee.
• ”/deny”: Creates a new access-denied ACE that replaces any existing access-denied ACE for the trustee. The new ACE denies the specified rights in addition to any currently denied rights of the trustee. The program also modifies or deletes any existing access-allowed ACE for the trustee that allows the specified rights.
• ”/revoke”: Removes any existing ACEs for the specified trustee. The program ignores the rights specified.
• The action parameters can be abbreviated by using only the first letter, ie. “/g” instead of “/grant”. The “trustee” parameter:
• This is the user or group you want to set the permission for.
• It can be a any type of local or domain user or group (local/domain user, local group, domain local group, global group or universal group).
• Always use the format ‘machine\user’ or ‘domain\user’. If you want to set permissions for a local group on your local machine, please omit the ‘machine\’ part.
• You can use predefined groups, like “EVERYONE” or “GUEST”. If you do this, a machine name should not be specified.
• The following special names can be used:
o ”CREATOR GROUP”: This is used in conjunction with inheritance. When a new object is created, the system replaces this SID with the primary group SID of the user who created the object.
o ”CREATOR OWNER”: This is used in conjunction with inheritance. When a new object is created, the system replaces this SID with the SID of the user who created the object.
o ”CURRENT_USER”: Indicates the owner of the calling thread or process.
o ”CREATOR OWNER”: This is used in conjunction with inheritance. When a new object is created, the system replaces this SID with the SID of the user who created the object.
o ”CURRENT_USER”: Indicates the owner of the calling thread or process.
• If the optional parameter “/sid” is used the trustee is expected to be a SID (security ID). This can be very useful if you want to set permissions for generic (built-in) users or groups in a language independent way. Example: on an english machine the administrators group is called “Administrators”; on a german machine it is called “Administratoren”. Hint: the SIDs of generic users/groups are always the same, regardless of OS type or language. A list of generic SIDs can be found here.
The “permissions” parameter:
The “permissions” parameter:
• The permissions you can set on files, directories and registry keys correspond to the standard and special permissions of Windows 2000.
• I added a set of permissions of my own, “/profile”, which sets the permissions needed for a user profile folder on Windows 2000, which are “change” + “set permissions”.
• The permissions you can set on printers, network shares, services and correspond to the standard permissions of Windows 2000.
The “inheritance” parameter:
The “inheritance” parameter:
• Use this with extreme caution, especially on production machines!
• The correct (standard) inheritance flags are always set for you. If you need to, you can use this parameter to specify special, non-standard inheritance flags.
• If you set permissions on a container (for example, a directory) that contains sub-containers and/or objects, permissions are propagated down the tree.
• The following flags can be used:
o ”/cont_obj_inh”: Both container and noncontainer objects that are contained by the specified container inherit the ACE in addition to the container specified.
o ”/cont_inh”: Other containers that are contained by the specified container inherit the ACE in addition to the container specified.
o ”/obj_inh”: Noncontainer objects contained by the specified container inherit the ACE in addition to the container specified.
o ”/inh_only_obj”: The ACE does not apply to the specified container to which the ACL is applied, but objects contained by the specified container inherit the ACE.
o ”/inh_only_cont”: The ACE does not apply to the specified container to which the ACL is applied, but containers contained by the specified container inherit the ACE.
o ”/inh_only_cont_obj”: The ACE does not apply to the specified container to which the ACL is applied, but containers and objects contained by the specified container inherit the ACE.
o ”/no_prop_inh”: The ACE is not propagated down to lower level objects/containers.
The “inherit from parent” parameter:
o ”/cont_obj_inh”: Both container and noncontainer objects that are contained by the specified container inherit the ACE in addition to the container specified.
o ”/cont_inh”: Other containers that are contained by the specified container inherit the ACE in addition to the container specified.
o ”/obj_inh”: Noncontainer objects contained by the specified container inherit the ACE in addition to the container specified.
o ”/inh_only_obj”: The ACE does not apply to the specified container to which the ACL is applied, but objects contained by the specified container inherit the ACE.
o ”/inh_only_cont”: The ACE does not apply to the specified container to which the ACL is applied, but containers contained by the specified container inherit the ACE.
o ”/inh_only_cont_obj”: The ACE does not apply to the specified container to which the ACL is applied, but containers and objects contained by the specified container inherit the ACE.
o ”/no_prop_inh”: The ACE is not propagated down to lower level objects/containers.
The “inherit from parent” parameter:
• ”yes”: This object inherits permissions from its parent objects. This is the normal setting for any type of object. If you do not specify this optional argument, “yes” is always assumed.
• ”no_copy”: This object blocks permissions from its parent objects. The permissions from the parent object are copied to the object specified and then the permissions are set.
• ”no_dont_copy”: This object blocks permissions from its parent objects. The permissions from the parent object are NOT copied to the object specified which results in an ACL that contains only the permissions set with SetACL.
The “recursion” parameter:
The “recursion” parameter:
• (Only for registry keys and directories) Walk down the tree and set permissions on every key/directory/file. This is only needed on NT4 and in special cases since Windows 2000 progagates permissions down the tree all by itself.
• ”cont_obj”: Recursively set permissions on every container (registry keys and directories) and object (files).
• ”cont”: Recursively set permissions ONLY on containers (registry keys and directories).
• ”obj”: Recursively set permissions ONLY on objects (files).
The “/sid” parameter:
The “/sid” parameter:
• If the optional parameter “/sid” is used the trustee is expected to be a SID (security ID). This can be very useful if you want to set permissions for generic (built-in) users or groups in a language independent way. Example: on an english machine the administrators group is called “Administrators”; on a german machine it is called “Administratoren”. Hint: the SIDs of generic users/groups are always the same, regardless of OS type or language. A list of generic SIDs can be found here.
The “/silent” parameter:
The “/silent” parameter:
• If the optional parameter “/silent” is used no output will be generated if the number of parameters passed to the program is correct. This can be useful if SetACL is used in batch files or from scripts. Successful execution can be checked using the return value which is always set.
Difference between Run Runonce and ActiveSetup
Active Setup:
It is used when your application requires installation of components such as files or registry keys on a per-user basis, but application has no advertised entry points or other triggers to initiate the installation process.
Run:
The Run key is processed after every logon, either by the Explorer shell, if it is present, or by First Boot Agent (FBA), if a custom shell, Command shell, or Task Manager Shell is used. If FBA processes this key, it does so after every logon, not during first boot as it normally would. Typically, this flag is used to load Systray applications, launch services in executables, hide autostart applications, or hide background processes
Run Once:
The RunOnce key is processed only once, by FBA, after Plug and Play device enumeration and DLL registration processing have completed. The values of this registry key are deleted from the registry after it is processed, so that it will not run again. Typically, this flag is used when a reboot is required, such as for a DLL or OCX registration, or for cleaning up a setup or an uninstall.
What is ALLUSERS=1
ALLUSERS =1 -> Per machine installation
ALLUSERS=0 -> Per User Installation, application will be installed only to user who is installing application
ALLUSERS=2 -> Depending upon user rights application will be installed.
If the user is Administrator then app will be installed as ALLUSERS=1
If the user is non-admin then app will be installed as ALLUSERS=2
ALLUSERS=0 -> Per User Installation, application will be installed only to user who is installing application
ALLUSERS=2 -> Depending upon user rights application will be installed.
If the user is Administrator then app will be installed as ALLUSERS=1
If the user is non-admin then app will be installed as ALLUSERS=2
Why multiple MSIExec.exe processes run during an installation?
A number of MSIExec processes can be running during an installation. The reason for this is that Windows Installer uses a client-server model for performing installations. Additionally for security reasons, Windows Installer hosts DLL and script custom actions in a “sandbox” process. Depending on how the install was initiated, one of the MSIExec processes can be the client process. Another MSIExec process is Windows Installer service. Any remaining MSIExec processes are usually sandbox processes for hosting custom actions. The determination as to which MSIExec process will serve as the sandbox process for a script or DLL custom action depends in part on whether the custom action will run elevated or impersonated and whether the custom action is 32-bit or 64-bit.
Subscribe to:
Posts (Atom)