What filename extension is applied by default to custom console that are created for the MMC?

There are several ways to deploy a Privilege Management for Windows policy to your endpoints. This section discusses the various ways that this can be achieved.

Group Policy Management

Create Privilege Management for Windows Settings

Privilege Management for Windows is implemented as an extension to Group Policy, enabling policy settings to be managed through the standard Group Policy management tools. Privilege Management for Windows also supports Advanced Group Policy Management [AGPM ] from versions 2.5 to 4.0.

Group Policy Objects [GPOs] are usually managed through the Group Policy Management Console [GPMC]. GPMC is a scriptable Microsoft Management Console [MMC] snap-in, providing a single administrative tool for managing Group Policy across the enterprise. GPMC is the standard tool for managing Group Policy.

Privilege Management for Windows also supports Local Computer Policy, which can be edited in the Group Policy Editor, but this is only recommended for small environments or for test purposes.

You may add Privilege Management for Windows settings to existing GPOs or create new GPOs for this purpose.

To edit a GPO from the GPMC:

1. Launch the GPMC [gpmc.msc].
2. In the GPMC tree, double-click Group Policy Objects in the forest and domain containing the GPO you want to edit.
3. Right-click the GPO and click Edit.

The Group Policy Management Editor appears. Privilege Management Settings are available in both the Computer Configuration and the User Configuration nodes, which allow you to set either computer or user settings, respectively. Computer settings are updated when a computer starts up, whereas user settings are updated when a user logs on. In addition, a background refresh occurs every 90 minutes by default, which will update settings while the user is logged on.

Once a client updates its Privilege Management for Windows settings through Group Policy, the settings are applied dynamically. Any logged on users do not need to log off for the changes to take effect.

Privilege Management Settings will either appear directly under the Computer Configuration and User Configuration nodes, or under the Policies sub-node, if it exists.

To create Privilege Management for Windows settings for a GPO:

1. In the Group Policy Management Editor, select the Privilege Management Settings node for either the Computer Configuration or the User Configuration section, as appropriate.
2. On the Group Policy Management Editor Action menu, click Create Privilege Management Settings.
3. Right-click the Workstyles node and select Create Workstyle. Choose a controlling or a blank Workstyle. Click Finish to create a Workstyle based on your selection.

For information about Workstyles, please see Workstyles.

Privilege Management Settings Scope

When deploying Privilege Management for Windows settings with Active Directory Group Policy, there are two factors to consider: the management scope of the GPO you selected and the user or group accounts listed on the account filter section of a Privilege Management for Windows Workstyle.

When you create a new Privilege Management for Windows Workstyle, you are given the option of applying a filter that will either target Standard users only or Everyone, including administrators.

Subsequently, you can further refine a subset of users that the Workstyle will target by adding account filters. These are defined on the Filters tab of a Workstyle where you add groups and users [either domain or local] to the filter. Do not leave the account filters empty or the Workstyle will still apply to everyone.

Multiple account filters can be added to a Workstyle, if you need add AND logic to your filtering. For example, if you want to target a user who is a member of GroupA AND GroupB, then add two account filters to an account filter, and select the box All items below must match.

You can also use computer filters to apply the Workstyle to specific computers and connecting client devices. These can be used in combination with account filters to provide more specific targeting of user and computer combinations, if required.

For more information, please see Filters.

GPO Precedence and Inheritance Rules

Privilege Management for Windows settings are associated with an Active Directory GPO and are distributed to all the computers and users under the management scope of the GPO. As a result, Privilege Management for Windows settings are subject to the same Group Policy processing and precedence rules as standard Active Directory GPOs.

Order of Processing

Group Policy settings are processed in the following order:

1. Local Group Policy Object: Each computer has exactly one GPO that is stored locally. This applies to both computer and user Group Policy processing.
2. Site: Any GPOs that are linked to the site that the computer belongs to are processed next. Processing is in the order that is specified by the administrator, on the Linked Group Policy Objects tab for the site in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence.
3. Domain: Processing of multiple domain-linked GPOs is in the order specified by the administrator, on the Linked Group Policy Objects tab for the domain in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence.
4. Organizational Units: GPOs that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then GPOs that are linked to its child organizational unit, and so on. Finally, the GPOs that are linked to the organizational unit that contains the user or computer are processed.

At the level of each organizational unit in the Active Directory hierarchy, one, many, or no GPOs can be linked. If several GPOs are linked to an organizational unit, their processing is in the order that is specified by the administrator, on the Linked Group Policy Objects tab for the organizational unit in GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence.

This order means the local GPO is processed first, and GPOs that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites settings in the earlier GPOs if there are conflicts.

Privilege Management for Windows merges settings so settings with a higher precedence will be processed first. Once an application matches a Privilege Management for Windows Workstyle, no further Workstyles will be processed for that application, so it is important to keep this in mind when multiple GPOs are applied.

Exceptions to Default Order of Processing

The default order for processing settings is subject to the following exceptions:

• A GPO link may be enforced, or disabled, or both. By default, a GPO link is neither enforced nor disabled.
• A GPO may have its user settings disabled, its computer settings disabled, or all settings disabled. By default, neither user settings nor computer settings are disabled on a GPO.
• An organizational unit or a domain may have a Block Inheritance set. By default, Block Inheritance is not set.

For information about the above modifications to default behavior, please see Managing inheritance of Group Policy.

A computer that is a member of a Workgroup processes only the local GPO.

Privilege Management Settings Storage and Backup

Privilege Management for Windows stores its settings within Active Directory’s SYSVOL folder, within the storage area for the relevant GPOs, which are identified by their GUIDs. The settings are stored in an XML file and Active Directory is then used as the distribution mechanism.

Privilege Management for Windows settings can be backed up by one of the following methods:

1. Privilege Management for Windows settings files will be backed up as part of a standard System State backup, which organizations should be performing as part of their standard backup routines.
2. Perform a manual backup of a GPO from the GPMC, which will back up the GPO settings and Privilege Management for Windows’ XML files.
3. In addition, Privilege Management for Windows settings may be manually exported and saved to a location of your choice.

For more information on how to perform an export or import of policies, please see Export.

Disconnected Users

Disconnected users are fully supported by Privilege Management for Windows. When receiving its settings from a GPO, Privilege Management for Windows automatically caches all the information required to work offline, so the settings will still be applied if the client is not connected to the corporate network. Of course, any changes made to the policy will not propagate to the disconnected computer until it reconnects to the domain and receives a Group Policy refresh. This behavior is identical to most of the standard Microsoft Group Policy settings.

Privilege Management for Windows also supports a completely standalone configuration mode, where the settings are configured by a Local Group Policy for that machine, or deployed in a standalone XML configuration file. These settings contain all of the information required to apply these policies offline.

Standalone Management

Although the Privilege Management Policy Editor is implemented as a Group Policy extension, it also supports a standalone mode, which is independent of Group Policy.

Standalone mode allows you to deploy the Privilege Management for Windows settings with an XML file. You will need to employ a suitable deployment mechanism to distribute the XML file to your client computers.

To run the Privilege Management Policy Editor in standalone mode:

1. Launch mmc.exe.
2. Select Add/Remove Snap-in from the File menu.
3. Select Privilege Management Settings from the available snap-ins and click Add.
4. Click OK.

The Privilege Management Policy Editor is now running in standalone mode and is not connected to a Group Policy Object [GPO].

On Windows 7 onwards, the Privilege Management for Windows settings will be saved to the following local XML file:

%ALLUSERSPROFILE%\Avecto\Privilege Guard\PrivilegeGuardConfig.xml

If you installed Privilege Management for Windows when you installed the Privilege Management Policy Editor, then the client will automatically apply the policies in this XML file. For this reason we strongly recommend you do not install the client if you will use the policy editor in standalone mode, unless you want the settings to be applied to your management computer. This may be case if you are evaluating Privilege Management for Windows.

The Privilege Management for Windows settings are edited in the same way as when editing GPO based policies. To distribute the XML file to multiple clients, you will need to export the policies to an XML file and then deploy it to the location specified above. Privilege Management for Windows monitors this directory and will automatically load the XML file.

You must name the settings file PrivilegeGuardConfig.xml once it is deployed, otherwise Privilege Management for Windows will not load the settings. If you make changes to the Privilege Management for Windows settings, redeploy the modified XML file and Privilege Management for Windows will automatically reload the settings.

PowerShell Management

The BeyondTrust Privilege Management for Windows PowerShell API enables administrators to configure Privilege Management for Windows using PowerShell scripts. This enables integrations with external systems, and provides an alternative to using the BeyondTrust management consoles.

Through the PowerShell API, you can create and modify any Privilege Management for Windows configuration within Domain Group Policy, Local Group Policy, or any local configuration. The PowerShell API is available on any computer where the Privilege Management Policy Editor or Privilege Management for Windows is installed.

For information on scripting Privilege Management for Windows configurations, please see the BeyondTrustPrivilege Management for Windows PowerShell API document and the accompanying help file PowerShell API.chm. Both of these documents are installed with the Privilege Management Policy Editor, under C:\Program Files\Avecto\Privilege Guard Privilege Management Policy Editors\PowerShell\.

Windows PowerShell Execution Policy

The default PowerShell execution policy is Restricted, which stops any scripts running. To set the execution policy:

1. Open PowerShell as an elevated application.
2. Navigate to the Deployment folder in the PMC package.
3. Run Set-ExecutionPolicy unrestricted -scope CurrentUser -f

For information on how to configure the setting using Group Policy, please see the Microsoft document Set-ExecutionPolicy.

Execute PowerShell Configurations

PowerShell scripts and commands which use the Get-DefendpointSettings, Set-DefendpointSettings, and Get-DefendpointFileInformation cmdlets must be executed with admin rights on the target computer. If you are elevating scripts and commands with the Privilege Management for Windows Remote PowerShell Management feature, you must ensure an Add Administrator Rights Custom Token has been assigned, and includes the following Groups settings:

• Enable anti-tamper protection box is unchecked.
• Make sure the users is always the token owner box is checked.

When using PowerShell Management to apply changes to Privilege Management for Windows configurations stored in Active Directory Group Policy, you require domain level write access to the Group Policy Object.

Configurations created and edited with PowerShell are not backwards compatible with older Privilege Management for Windows versions, so we recommend only configurations targeting version 4.0 Clients are managed through PowerShell scripting.

Webserver Management

Deploy Workstyles using Web Services

For instances where Active Directory Group Policy is not suitable, such as for clients outside of the corporate network, Privilege Management for Windows configurations may be hosted on a webserver using HTTP or HTTPS. Privilege Management for Windows can be configured to download configurations on a schedule.

Webserver configurations should be implemented as a complement to other configuration deployment methods. Workstyle precedence can be customized so that webserver configurations are evaluated with the correct priority. For more information, please see Workstyle Precedence.

For information on how to create an XML configuration for deployment from a webserver, please see the following:

• Export
• Import

Privilege Management for Windows may be configured to pull an XML configuration from a webserver during the installation of the Client MSI or EXE, or for existing installations, can be configured using the Windows Registry.

Webserver Enabled Client Installation

To install Privilege Management for Windows with webserver configurations enabled, there are several command line arguments which can be used to configure the following settings:

ArgumentDescription

WEBSERVERMODE=	Enables webserver functionality [Required, 1 = Enabled]
WSP_URL=	Specifies the full URL [including XML filename] to the webserver configuration [required]
WSP_INTERVAL=	Refresh interval for new configuration check in minutes [optional, default 90 minutes]
WSP_LOGON=	Check for new configuration at user logon [optional, default 1 = Enabled]
WSP_CERT=	The Common Name for a webserver certificate. When added, restricts webserver downloads only if the common name matches the webserver certificate, and the certificate is valid.
WSP_CERTAUTHMODE=	The type of HTTPS authentication that is used: 0 = server authentication only [default] 1= client authentication and server authentication When client authentication is used, Privilege Management for Windows uses the FQDN of the machine to find the client certificate in the local machine certificate store.
DOWNLOADAUDITMODE=	Specifies the level of auditing for attempts to download webserver configurations; 0 = No auditing, 1 = Failures only, 2 = Successes only, 3 = audit both [default]
POLICYENABLED=	Specifies the policy deployment methods which are enabled. Add this value to allow a webserver policy to be used by the Privilege Management for Windows: WEBSERVER. For more information, please see Deployment Methods.

Example:

Msiexec.exe /i DefendpointClient_x86.msi /qn /norestart WEBSERVERMODE=1 WSP_URL="//MyWebServer.Internal/WebConfig.xml" WSP_INTERVAL=90 POLICYPRECEDENCE="WEBSERVER,GPO,LOCAL"DefendpointClient_x86.exe /s /v" WEBSERVERMODE=1 WSP_URL=\"//MyWebServer.Internal/WebConfig.xml\" WSP_INTERVAL=90 POLICYPRECEDENCE=\"WEBSERVER,GPO,LOCAL\""

Enable Webserver Policy Download Using the Registry

At any time after Privilege Management for Windows is installed, webserver configuration may be set using the Windows registry. The following registry entries are valid:

HKEY_LOCAL_MACHINE\Software\Avecto\Privilege Guard Client\

ValueDataData

WebServerPolicyUrl	REG_SZ	Specifies the full URL [including xml filename] to the webserver configuration [Required]
WebServerPolicyRefreshIntervalMins	DWORD	Refresh interval for new configuration check in minutes [Optional, default 90 minutes]
WebServerPolicyRefreshAtUserLogon	DWORD	Check for new configuration at user logon [Optional, default 1 = Enabled]
WebServerCertificateDisplayName	REG_SZ	The Common Name for a webserver certificate. When added, restricts webserver downloads only if the common name matches the webserver certificate, and the certificate is valid.
WebServerCertificateAuthMode	DWORD	The type of HTTPS authentication that is used: 0 = server authentication only [default] 1= client authentication and server authentication When client authentication is used, Privilege Management for Windows uses the FQDN of the machine to find the client certificate in the local machine certificate store.
WebServerClientCertificateIssuers	REG_MULTI_SZ	List of Common Names of certificates that issued a client authentication certificate. When added, the issuer is also checked when retrieving the client certificate in the local machine certificate store against the given Common Names, ordered top to bottom.
DownloadAuditMode	DWORD	Specifies the level of auditing for attempts to download webserver configurations [0 = No auditing, 1 = Failures only, 2 = Successes only, 3 = audit both [default]]
PolicyEnabled	REG_SZ	Specifies the policy deployment methods which are enabled. Add this value allow a webserver policy to be used by the Privilege Management for Windows: WEBSERVER. For more information, please see Deployment Methods.

Configuration Precedence

Privilege Management for Windows supports a variety of deployment methods, and can accept multiple simultaneous configurations from any combination of the following:

• Group Policy: Configurations that are stored in Group Policy Objects, configured with GPMC [Active Directory Group Policy] and GPEdit [Local Group Policy]. Group Policy based configurations are evaluated according to GPO precedence rules.
• Local Policy: A standalone configuration, which is stored locally, configured with MMC.
• Webserver Policy: A configuration located on a web server, accessible using HTTP, HTTPS, or FTP.
• McAfee ePO Policy: A configuration that is stored within McAfee ePO, configured with the ePO policy catalog.
• BeyondInsight: A web-based console where you configure and launch vulnerability assessment scans. As a scan completes, a report is automatically generated. Results can be navigated interactively in the console.

Privilege Management for Windows uses a logical precedence to evaluate each configuration for matching rules. By default, the client will apply the following precedence: ePO Policy > BeyondInsight > Webserver Policy > Group Policy > Local Policy.

Configuration precedence settings can be configured either as part of the client installation or with the Windows Registry, once the client is installed.

To modify configuration precedence at client installation, use one of the following command lines to install Privilege Management for Windows with a specific configuration precedence:

msiexec /i DefendpointClient_x[XX].msi POLICYPRECEDENCE="EPO,WEBSERVER,GPO,LOCAL"DefendpointClient_x[XX].exe /s /v" POLICYPRECEDENCE=\"EPO,WEBSERVER,GPO,LOCAL\""

In the command line arguments above, [XX] represents 86 or 64 in relation to the 32-bit or 64-bit installation respectively.

To modify configuration using the Registry, run regedit.exe with elevated privileges [ensuring you are using a Privilege Management for Windows token with anti-tamper disabled] and navigate to the following key:

HKEY_LOCAL_MACHINE\Software\Avecto\Privilege Guard Client

REG_SZ PolicyPrecedence = "EPO,WEBSERVER,GPO,LOCAL"

Deployment Methods

Certain types of deployment methods may be enabled or disabled. By default, all deployment types are enabled. To include or exclude a method of deployment from evaluation, edit the entries in the registry value below. If this key does not already exist, the default behavior is to include all methods:

HKEY_LOCAL_MACHINE\Software\Avecto\Privilege Guard Client

REG_SZ PolicyEnabled = "EPO,BeyondInsight,WEBSERVER,GPO,LOCAL"

In the entry above, EPO,BeyondInsight,WEBSERVER,GPO,LOCAL are the available deployment methods.

Registry settings may be deployed using the Advanced Agent Settings feature. For more information, see Advanced Agent Settings. In order to apply a configuration deployment method using Advanced Agent Settings, the setting must be applied to a type of configuration that is already part of the configuration precedence order. For more information, please see Configuration Precedence.

Automate the Update of Multiple GPOs

The PGUpdateGPO.exe command line utility allows you to automate the update of Privilege Management for Windows settings in multiple computer or user GPOs [Group Policy Objects].

The PGUPdateGPO.exe utility is used as follows:

PGUpdateGPO.exe COMPUTER GPODSPath [SourceXMLFile]PGUpdateGPO.exe USER GPODSPath [SourceXMLFile]

Where:

• GPODSPath is the LDAP path to the GPO
• SourceXMLFile is the location of the Privilege Management for Windows settings XML file on disk

The command line below demonstrates using this utility to copy an XML file from the current directory into the computer section of a GPO stored in BeyondTrust.test:

PGUpdateGPO.exe COMPUTER "LDAP://BeyondTrust.test/cn={97B1DB2E-D68B-45EA-98FF-D71F9971F44C},cn=policies,cn=system,DC=BeyondTrust,DC=test" PrivilegeGuardConfig.xml

Where:

• {97B1DB2E-D68B-45EA-98FF-D71F9971F44C} is the GUID of the GPO.

What file name extension is applied by default to custom consoles that are created for the MMC?

Which of the following statements is true regarding the built in Administrator account in Windows 7 *?

Which is the parameter of the WinMain Mcq?

Which of the following address belongs Class A?