Centrify® Server Suite 2016 Windows Agent 3.3.0 Release Notes

© 2007-2016 Centrify Corporation.

This software is protected by international copyright laws.

All Rights Reserved.

Table of Contents

1.  About Centrify Windows Agent

2. Supported platforms and system requirements

3.  Feature Changes

3.1 Feature Changes in Windows Agent 3.3.0 (Suite 2016)

3.1.1 Centrify Windows Agent – Access

3.1.2 Centrify Windows Agent – Audit

3.2 Feature Changes in Windows Agent 3.2.3 (Suite 2015.1)

3.2.1 Centrify Windows Agent – Access

3.2.2 Centrify Windows Agent – Audit

3.3 Feature Changes in Windows Agent 3.2.2 (Suite 2015)

3.3.1 Centrify Windows Agent – Access

3.4 Feature Changes in Windows Agent 3.2.1 (Suite 2014.1)

3.5 Feature Changes in Windows Agent 3.2.0 (Suite 2014)

3.5.1 Centrify Windows Agent – Audit

3.5.2 Centrify Windows Agent – Access

4. Bugs Fixed

4.1 Bugs Fixed in Windows Agent 3.3.0 (Suite 2016)

4.1.1 Centrify Windows Agent - Audit

4.2 Bugs Fixed in Windows Agent 3.2.3 (Suite 2015.1)

Centrify Windows Agent – Access

4.3 Bugs Fixed in Windows Agent 3.2.2 (Suite 2015)

4.3.1 Centrify Windows Agent – Access

4.3.2 Centrify Windows Agent - Audit

4.4 Bugs Fixed in Windows Agent 3.2.1 (Suite 2014.1)

4.5 Bugs Fixed in Windows Agent 3.2.0 (Suite 2014)

5. Known Issues

5.1. Installation and Uninstall

5.2. Centrify Windows Agent - Audit

5.3 Centrify Windows Agent - Access

5.3.1 Configuration

5.3.2 Environment

5.3.3 RunAsRole

5.3.4 Desktop with Elevated Privileges

5.3.5 Roles and Rights

5.3.6 Compatibility With 3rd Party Products

6. Additional information and support

 

1.  About Centrify Windows Agent

The Centrify Windows Agent package contains software to support auditing, access control, and privilege management on Windows computers. The Audit and Access features can be installed together or separately on the Windows computers you want to manage.

For auditing, the Centrify Windows Agent requires the Centrify DirectAudit feature set, which is available in Centrify Server Suite Enterprise Edition. DirectAudit enables detailed auditing of user activity on a wide range of UNIX, Linux and Windows computers. With DirectAudit, you can perform immediate, in-depth troubleshooting by replaying user activity that may have contributed to system failures, spot suspicious activity by monitoring current user sessions, and improve regulatory compliance and accountability by capturing and storing detailed information about the applications used and the commands executed. If you enable auditing, the Centrify Windows Agent records user activity on the Windows computer when it is installed. For a complete list of the platforms supported, see DirectAudit Supported Platforms.

For access control and privilege management, the Centrify Windows Agent requires the Centrify DirectManage and DirectAuthorize feature sets, which are available in Centrify Server Suite Standard Edition. With DirectManage and DirectAuthorize, you can configure and manage role-based access controls for Windows servers. The Centrify Windows Agent extends the access control and privilege management features available for Linux and UNIX computers, so that you can use a single console to manage multiple platforms. You can deploy the Centrify Windows Agent in a Windows-only environment or as part of a mixed environment that includes, Windows, Linux, and UNIX computers. For a complete list of the platforms supported, see Centrify Server Suite Standard Edition in the document in www.centrify.com/platforms.

You can obtain information about previous releases from the Centrify Support Portal, in the Documentation & Application Notes page.

Centrify software is protected by U.S. Patent No. 7,591,005, 8,024,360, 8,321,523, 9,015,103 B2 and 9,112,846. (Ref: 82245)

 

2. Supported platforms and system requirements

For information about setting up a test environment for the Centrify Windows Agent, see the Centrify Server Suite Evaluation Guide for Windows. The Centrify Server Suite Evaluation Guide for Windows includes common tasks and usage scenarios.

The Centrify Windows Agent supports the following operating Windows 64-bit operating systems:

 

o    Windows 7 SP1 and above

o    Windows 8 or 8.1

o    Windows Server 2008 R2 SP1

o    Windows 10

o    Windows Server 2012

o    Windows Server 2012 R2

Support has been removed in Centrify Windows Agent for the following operating systems:

o    All 32-bit Windows platforms

o    Windows Server 2008 64-bit

Note: Centrify Windows Agent 3.3.0 does not have full support on Windows 10.  Access feature is not available on Windows 10.  Only Audit feature is available on Windows 10. (Ref: CS-39218, CS-39149)

3.  Feature Changes

3.1 Feature Changes in Windows Agent 3.3.0 (Suite 2016)

3.1.1 Centrify Windows Agent – Access

3.1.2 Centrify Windows Agent – Audit

·         Added two new Group Policy settings, "Set maximum size of the offline data file" and "Set maximum recorded color quality" in "Centrify DirectAudit Settings / Windows Agent Settings" to control the agent's spool file size and video capture color quality. (Ref: CS-6967)

·         Video capture for Metro UI and tile applications in Windows 8 and Windows Server 2012 works correctly in Suite 2016. (Ref: CS-5241)

·         Added two new Group Policy settings, "Set maximum size of the offline data file" and "Set maximum recorded color quality" in "Centrify DirectAudit Settings / Windows Agent Settings" to control the agent's spool file size and video capture color quality. (Ref: CS-6967)

·         Added a new Centrify Group Policy setting: "Use the host name specified by the agent" in "Centrify DirectAudit Settings/Common Settings". This option is used to enable audited sessions to display the host name specified by the agent on audited computers instead of the host name resolved by the collector through DNS. This policy is useful in configurations where the DNS server(s) used by the collectors cannot reliably resolve host names from IP addresses. Common scenarios are when the agents are in a NAT and/or DMZ environments. (Ref: CS-6730, CS-7086)

·         Added a new option checkbox "Agents must prefer collectors in the same site as the agent" in the Audit Manager Console / Audit Store / Advanced Properties page. When this option is checked, all agents in this audit store will establish connections to collectors in the local site before connecting to other collectors for the agent's Audit Store. (Ref: CS-7040)

·         The Suite 2016 ISO now bundles the 64-bit installer of Microsoft SQL Server 2008 R2 SP 2 Express with Advanced Services. (Ref: CS-6740)

·         Improved Audit Trail despooling performance. (Ref. CS-5914)

 

 

3.2 Feature Changes in Windows Agent 3.2.3 (Suite 2015.1)

3.2.1 Centrify Windows Agent – Access

New group policy template centrify_windows_settings.xml and centrify_windows_settings.adm have been added to Centrify Group Policy Management Editor Extension to support group policy enabling desktop right on Windows 8, Windows 8.1, Windows 2012 and Windows 2012 R2 installed with Centrify Windows Agent - Access. After installing CentrifyDC_GP_Extension.msi, template centrify_windows_settings.xml is installed in %Program Files%\Common Files\Centrify Shared\Group Policy Management Editor Extension\policy, template centrify_windows_settings.adm is installed in %Windir%\Inf.

After adding the new group policy template in Group Policy Management Editor via Add/Remove Templates under Computer Configuration > Policies > Centrify Settings, the new group policy can be found under Centrify Settings > Windows Settings > Enable desktop right on Windows 8, Windows 8.1, Windows 2012 and Windows 2012 R2. To enable the group policy, open Properties, select Enabled and click Apply to save the changes. (Ref: 77697)

3.2.2 Centrify Windows Agent – Audit

3.3 Feature Changes in Windows Agent 3.2.2 (Suite 2015)

3.3.1 Centrify Windows Agent – Access

3.4 Feature Changes in Windows Agent 3.2.1 (Suite 2014.1)

Note: Due to its reduced feature set in Windows Server Core, certain specific functions are not supported such as “Run as Role…” context menu, Centrify system tray, Centrify shortcut menus and privilege desktop. (Ref: 33467)

3.5 Feature Changes in Windows Agent 3.2.0 (Suite 2014)

3.5.1 Centrify Windows Agent – Audit

3.5.2 Centrify Windows Agent – Access

4. Bugs Fixed

4.1 Bugs Fixed in Windows Agent 3.3.0 (Suite 2016)

4.1.1 Centrify Windows Agent - Audit

·         Video capture for Metro UI and tile applications in Windows 8 and Windows Server 2012 works correctly in Suite 2016. (Ref: CS-5241)

·         If the DirectAudit Windows agent is installed by a user who is not a member of local administrator group, the Audit Notification window does not appear when user logs in.  This is fixed in Suite 2016. (Ref: CS-7157)

·         Fixed an issue where the Audit Notification message window could show unrecognizable characters if the source message text file contained Latin characters. (Ref: CS-6547)

 

4.2 Bugs Fixed in Windows Agent 3.2.3 (Suite 2015.1)

Centrify Windows Agent – Access

·         On Windows 8, Windows 8.1, Windows Server 2012 and Windows Server 2012 R2, the launching of Run as Role on the Control Panel and Windows Explorer may take a longer time than usual. This issue has been fixed in this release. (Ref: 68826, 76729)

·         Privileged desktop may not be launched successfully if desktop name contains Unicode characters. This issue has been fixed in this release. Unicode privileged desktop name is fully supported. (Ref: 75700)

·         Mapped network drive cannot be used in the process elevated by run as role or under privileged desktop. If a network drive is mapped in the default desktop, the drive won’t be available for either the elevated process or privileged desktop. This issue has been fixed in this release. User can enable network drives support via /netdrives option of RunAsRole command line or UI Advanced View. (Ref: 31108)

·         On a desktop with elevated privileges on Windows 8, 8.1, 2012 and 2012 R2, System tray -> “Customize...” -> “Always show all icons and notifications on the taskbar” did not function properly. This issue has been fixed in this release. The “Notification Area Icons” window shows properly, and the “DirectAuthorize System Tray” icon shows the correct desktop name. (Ref: 47308)

4.3 Bugs Fixed in Windows Agent 3.2.2 (Suite 2015)

4.3.1 Centrify Windows Agent – Access

·         Network right is not supported for local users. The authorization center in this release has been fixed not to show the network right for local users. (Ref: 58271)

·         File hash matching criteria in the Application right is not supported for a file larger than 100MB.  This is to make sure DirectAuthorize does not spend too much CPU and memory resources to calculate the file hash.  User trying to import a file with the size larger than 100MB will see an empty value for the file hash field. The file size limit has been increased to 500 MB in this release. (Ref: 56778)

·         Role assignment on local Windows group cannot take effect on Windows Agent from Centrify Server Suite 2014.  This issue has been fixed in this release. (Ref: 59537)

·         Although DirectAuthorize for Windows product can control which smart card users are allowed to logon, the re-authentication won’t work because the smart card user is expected to enter a PIN instead of a password and our re-authentication UI only asks for password. This issue has been fixed in this release. User can enter a PIN in re-authentication. (Ref: 65175)

·         Citrix XenApp is supported in this release. (Ref: 33786)

·         Network right does not take effect if there is a Windows computer with Centrify Windows Agent - Access installed and the computer’s dnsHostName attribute has not set any value in the AD forest. This issue has been fixed in this release. (Ref: 72967)

4.3.2 Centrify Windows Agent - Audit

·         Remote logon failure audit trail message on Windows 7/8, Windows 2008/2012 and Windows 2008/2012 R2 cannot be recorded. This issue has been fixed in this release. (Ref: 47232)

4.4 Bugs Fixed in Windows Agent 3.2.1 (Suite 2014.1)

·         There are some minor bug fixes.

4.5 Bugs Fixed in Windows Agent 3.2.0 (Suite 2014)

·         Windows Agent from Centrify Server Suite 2014 is improved to have smaller CPU footprint. (Ref: 56460)

·         Desktop background group policy cannot take effect when Centrify Windows Agent is installed with Access feature turned on.  This issue has been fixed in this Suite 2014. (Ref: 57539)

·         Some programs install and register a special shortcut called “advertised” shortcuts.  Run As Role context menu cannot be shown on those special shortcuts icon.  This issue has been fixed in this release. (Ref: 54274)

·         After installing Centrify Windows Agent, the desktop background set by group policy can no longer take effect.  This issue has been fixed in this release.  (Ref: 57539)

·         Centrify Windows Agent requires DirectAuthorize service to be always running.  Starting from this release, administrative user can no longer stop the DirectAuthorize service directly. (Ref: 33632)

5. Known Issues

5.1. Installation and Uninstall

·         The Centrify Common Component should be the last Centrify Server Suite component uninstalled. If the component is uninstalled before other component, it must be reinstalled by the uninstall process to complete its task. (Ref: 36226a)

·         If you intend to install the software on the desktop with elevated privilege, you should not check the “Run with UAC restrictions” option when creating the desktop. (Ref: 39725b)

·         When you double-click on the Centrify Windows Agent msi and select the “repair” option, the existing files are replaced irrespective of their version number, even when they are identical.  As a result, a prompt to restart the system is displayed as files that were in use were replaced. However, if you use the Easy Installer to do the repair and a file on the disk has the same version as the file that is part of the installer package, the installed file will not be replaced. Therefore, there will not be any prompt to restart the system. (Ref: 26561a)

·         When the Centrify Windows Agent is either installed or uninstalled and the prompt for a machine restart is deferred using the “restart later” option or ignored, other components of DirectManage may display errors due to an incomplete installation. A restart is mandatory if requested after install or uninstall operation. (Ref: 36307a)

·         The component selection page of the installer for the Centrify Windows Agent installer does not allow specifying separate installation locations for each individual component. All the components selected on this page get installed in the same location. Therefore, the Browse button remains disabled when user highlights individual components in the component selection tree. The Browse button is enabled only when the user highlights the top node of the component selection tree. (Ref: 34772a)

·         Users may notice a few “Side by side” configuration errors in the Event Viewer after installing the Centrify Windows Agent, if Microsoft KB945140 related components have been installed on the local machine previously. These errors will go away after you restart the computer and have no functional effect. (Ref: 35302a)

·         If you uninstall the Centrify Windows Agent while the DirectAudit Agent Control Panel is open, files needed by the uninstall process may be blocked. You should close the DirectAudit Agent Control Panel for a successful conclusion to the uninstall process. (Ref: 25753a)

·         If you have installed the Access feature of Centrify Windows Agent from Centrify Server Suite 2013 and are trying to upgrade the component to the latest version, you may see the following error during the installation process, “Service ‘DirectAuthorize Agent’ could not be installed. Verify that you have sufficient privileges to install system services.” If you see this error message, it typically indicates that the existing service is taking longer time to stop and hence the new service is not getting installed.  When you see this error, wait for some time (typically 30 seconds) and click on Retry button on the error message box. (Ref: 47270a)

·         Centrify Windows Agent and its installer are built on .NET 3.5.  Therefore, .NET 3.5 is always installed as a pre-requisite before the agent is installed. If .NET 3.5 is removed from the system later, Centrify Windows Agent will not run properly.  User will also experience problem when trying to remove Centrify Windows Agent from the system.  To properly uninstall Centrify Windows Agent, please make sure Centrify Windows Agent is uninstalled before .NET 3.5. (Ref: 39051a)

·         The list of rescue users is stored in different places in Suite 2013.3 (or previous releases) and Suite 2014 and this list is not automatically migrated to its new location when upgrading from Suite 2013.3 or a previous release to Suite 2014. Because of this, it’s highly recommended that Centrify Windows Agent should not be upgraded in disconnected mode (i.e. when the system cannot connect to the Active Directory). If a system is upgraded in disconnected mode, the list of rescue users will be lost and only local administrators will be able to login to the system after reboot. (Ref: 57622a )

·         If you install Access feature of Centrify Windows Agent without installing the Audit feature, the registry key value for HKEY_LOCAL_MACHINE\SOFTWARE\Centrify\AuditTrail\AuditTrailTargets is set to zero as expected, which means the audit trail is not sent to DirectAudit Audit Store database. However, if you try to change the installed features list of Centrify Windows Agent and add the Audit feature later, the change process does not automatically set the AuditTrailTargets value to the expected new value of 1, which means to send audit trail data to DirectAudit Audit Store database.  This is a known issue and workaround is to set this value manually to 1 after the installer finishes the process of adding new feature. (Ref: 59353b)

·         If you have installed the Access feature of Centrify Windows Agent from earlier version and then upgraded the component to the latest version while the Windows Agent is not currently connected to any Active Directory domain controller, only users who have been assigned a role with rescue rights will be able to log on to the computer until the connection to Active Directory is restored. (Ref: 58858b)

·         Windows would not be able to start up if protected mode is enabled for the Local Security Authority (LSA) process (which is available on Windows 8.1 and Windows Server 2012 R2 but disabled by default). (Ref: 80398c)

5.2. Centrify Windows Agent - Audit

·         The offline data location (and subdirectories below it) is expected to be a location dedicated to spooling, for example c:\spool. If the offline data location is changed, all files in the old location (including subdirectories and their contents) are moved to the new location. This may cause problems if the old location was not exclusively for spooling use. For example, choosing c:\ as the original spool location and d:\spool as the new location would cause all files on the c:\ drive to be copied to d:\spool. (Ref: 26592a)

·         The optional video capture feature requires both the Collector and the DirectAudit Agent to use 2013.2 or later. If any of collectors or agents are running an older version, video data may still be recorded even though you have turned it off in Suite 2013 Update 2 Audit Manager. (Ref: 44064a)

·         If Centrify Windows Agent is auditing a Windows 8 or Windows 2012 system, the Indexed Event List of the corresponding audited session will not show any events for the applications that are using the Metro User Interface. The Metro UI is not supported by Suite 2014. (Ref: 56556b)

·         Upon making changes to Group Policy “Centrify Audit Trail Setting” > “Centrify Common Setting” > “Send audit trail to log file”, it would require reboot of the client computer (agent) for this setting to be effective despite the Group Policy has already been refreshed on the client computer. (Ref: 73368b)

Some events related to the login script are not listed in the indexed events list. The login script cannot be audited for an initial few seconds because the DirectAudit Windows agent software has not completed its setup. (Ref: 26286a)

5.3 Centrify Windows Agent - Access

5.3.1 Configuration

·         Users with elevated privilege yet do not have sufficient permission to access “Security Settings” node in local group policy editor.  This issue happens on Windows 8.1 and Windows 2012 R2 only.  It will be fixed in future release. (Ref: 63609b)

·         Administrator should always leave the zone before joining the computer to a different domain.  Otherwise, DirectAuthorize may not function correctly after the computer is joined to a different domain. (Ref: 54278b)

·         In some large environment with multiple domain controllers, it may take up to one minute for the new zone setting in DirectAuthorize control panel to take effect. (Ref: 58128b)

·         If one of the Global Catalog servers is unavailable, user may not be able to configure the zone for Centrify Windows Agent. (Ref: 58621b)

5.3.2 Environment

·         One-way trust environments and selective two-way external trusts are not supported. Both Windows machines and Centrify zones are required to be in the same forest or different forests with a two-way forest trust established. (Ref: 40713b, 44644b, 44647b, 44657b, 40643b, 40650b, 45341b, 45372b)

·         Environment with no Global Catalog is not supported. (Ref: 46577a)

·         DirectAuthorize for Windows requires machine time to be synchronized with domain controller.  VMware virtual machine has a known issue that its time may not be synchronized with domain controller.  This problem occurs more often on a overloaded virtual machine host.  If the system clocks on the local Windows computer and the domain controller are not synchronized, DirectAuthorize for Windows does not allow any domain users to login.  You can try the following KB from VMware to fix the time synchronization issue.   http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1189 (Ref: 47795b)

5.3.3 RunAsRole

·         If you use the “RunAsRole.exe /wait” command to run a Python script, the input/output cannot be redirected for versions of Python below 3.0.0. (Ref: 45061a)

·         Run As Role menu is not available on the start screen in Windows 8 or Windows 2012 or later because Microsoft doesn’t support any custom context menu on the start screen.  User has to go to the Windows desktop in order to launch an application using Run As Role context menu. (Ref: 35487a)

·         On Windows 8, Windows 8.1, Windows Server 2012 and Windows Server 2012 R2, use “Run as role” with Local Administrators group privilege on Control Panel does not have sufficient permission to add printers if the printer drivers are not pre-installed on the computer. The workaround is to define a role run as a user with Local Administrator privilege or with a group as a member of Local Administrators group. (Ref: 68826a)

·         The “Run as role” for Windows Media Player is not recommended. Please use privilege desktop instead. (Ref: 55615a)

·         When running “RunAsRole.exe /wait sc.exe” with no argument provided to sc.exe, sc.exe will prompt

Would you like to see help for the QUERY and QUERYEX commands? [ y | n ]:

Typing ‘y’ or ‘n’ doesn’t do anything because the input cannot be successfully redirected to sc.exe. (Ref: 47016b)

·         It is not recommended to change zone via Run As Role since the role that is in use may no longer be available once after leaving from the previous zone during the change zone process. (Ref: 58043a)

5.3.4 Desktop with Elevated Privileges

·         On a desktop with elevated privileges, if you open the Task Manager and select “File > New Task” to run an application without selecting the “Create this task with administrative privileges” option, the application will be launched on the default desktop. This issue occurs when User Account Control (UAC) is enabled. (Ref: 32169a)

·         If the sAMAccountName attribute of an Active Directory account is changed while the old account name is still cached on the computer, you may see the following error message when creating a new desktop or using “Run as role” with a right configured to run as the modified user account:

“Failed to open new desktop. Right xxx references bad user account.”

The workaround is to restart the computer. (Ref: 35124a)

·         On a desktop with elevated privileges, if you use “Control Panel > Programs > Programs and Features” to uninstall a program, you may see the following warning message and cannot uninstall the software.

“The system administrator has set policies to prevent this installation.”

This issue happens when User Account Control (UAC) is enabled and when “Run with UAC restrictions” is selected when creating the new desktop. (Ref: 33384a)

·         When you open the Start menu “Help and Support” item on a desktop with elevated privileges, the Windows Help and Support is launched on the default desktop. Switch to the default desktop to view the information. (Ref: 32147a)

·         If you shut down, restart, or log off from a desktop with elevated privileges, all running applications are terminated forcibly without being prompted to save any open documents. (Ref: 40749a)

·         You cannot launch Windows Security Options using “Start menu -> Windows Security” on a privilege desktop with elevated privileges when using a remote desktop connection. You must switch back to the default desktop to continue. (Ref: 45995b)

·         Installation of IE9 on desktops with elevated privileges may cause the privileged desktop to become unusable. Use “RunAsRole” for installation of IE9 instead. (Ref: 44930a)

·         You cannot use the Start menu option “Switch User” while you are using a role-based, privileged desktop. To use the “Switch User” shortcut, change from the privileged desktop to your default Windows desktop. From the default desktop, you can then select Start > Switch User to log on as a different user. (Ref: 39011b)

·         On a DirectAuthorize desktop using a role with local administrator privilege, the Stand By option in the shutdown menu does not work.  This is a known issue and will be addressed in future release. (Ref: 58280a)

·         VMWare registers to run VMwareUser.exe on the guest operating system to enable user to copy and paste text between the guest and managed host operating systems. Creating multiple desktops with different user accounts causes multiple VMwareUser.exe are run in different user accounts in the same logon session.  VMwareUSer.exe cannot support this scenario and therefore an error message is displayed on the default desktop which blocks all the UI operation on the new desktop.  To workaround this problem, user can disable the VMWare user program on the guest machine by deleting the registry value name “VMware User Process” from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. (Ref: 49268a)

·         On a privileged desktop on Windows 8, Windows 8.1, Windows 2012 and Windows 2012 R2, you may not be able to access the VMware shared folder. (Ref: 40686c)

·         Windows logo key keyboard shortcuts are not supported on privileged desktop. Depends on the key and operation system, the shortcut could either have no effect or its effect is applied to the default desktop instead. (Ref: 47588b)

·         A Start menu on privileged desktop on Windows 8, Windows 8.1, Windows 2012 and Windows 2012 R2, to make up for a limitation of Windows 8, Windows 8.1, Windows 2012 and Windows 2012 R2. In addition, navigating to a Modern Start screen to use Modern-style apps from a privileged desktop is not possible from either the charm bar or using a Windows. Note: you must switch back to the default desktop in order to go to Modern Start screen. (Ref: 41245c)

 

5.3.5 Roles and Rights

·         Windows Network Access rights do not take effect on a Linux or UNIX machines. If you select a role to start a program or create a desktop that contains a Network Access right, you can only use that role to access Windows computers. The Windows computers you access over the network must be joined to a zone that honors the selected role. The selected role cannot be used to access any Linux or UNIX server computers on the network. (Ref: 32980a)

·         Network Access rights are not supported on the Windows 2008 R2 Terminal Server if “RDC Client Single Sign-On for Remote Desktop Services” is enabled on the client side. (Ref: 34368b)

·         To elevate privileges to the “Run as” account specified in a Windows right, the “run as” account must have local logon rights. If you have explicitly disallowed this right, you may receive an error such as “the user has not been granted the requested logon type at this computer” when attempting to use the right. (Ref: 34266a)

·         If your computer network is spread out geographically, there may be failures in NETBIOS name translation. If a NETBIOS name is used, Active Directory attempts to resolve the NETBIOS name based on the domain controller that the user belongs to, which in a multi-segment network might fail. Therefore, Network Access rights might not work as expected if the remote server is located using NETBIOS name. You may need to consult your network administrator to work around this issue. (Ref: 39087a)

·         File hash matching criteria in the Application right is not supported for a file larger than 500MB.  This is to make sure DirectAuthorize does not spend too much CPU and memory resources to calculate the file hash.  User trying to import a file with the size larger than 500MB will see an empty value for the file hash field. (Ref: 56778a)

·         For a small set of application, enabled matching criterion - “Product Name”, “Product version”, “Company”, “File Version” or “File Description” of a Windows Application Right may fail to match after upgrading agent under the following conditions: - Any value for the enabled matching criteria is defined by either import from a process or file - The matching criteria is defined by 5.1.3 or 5.2.0 DirectManage Access Manager since the number of affected application is expected to be relatively low, proactively updating the defined matching criteria of Windows Application Right is not necessary. (Ref: 60053a)

5.3.6 Compatibility With 3rd Party Products

·         The startup path for “SharePoint 2010 Management Shell” and “Exchange Management Shell” may set to C:\Windows instead of user home directory if it is launched via RunAsRole.exe or from a desktop with elevated privilege. (Ref: 38814b, 46943b)

·         On a desktop with elevated privileges, if you install McAfee Security Scan products and click “View Readme”, the Readme.html is shown on the default desktop. Similar issues may happen with other third party programs. The alternate way to view the Readme.html on the desktop of a managed computer is to open the Readme.html file directly. (Ref: 34642a)

·         Attempting to enable Kerberos authentication for Oracle databases will fail. This issue is being brought to the attention of Oracle Support for a resolution in upcoming releases. (Ref: 33835b)

·         The Microsoft Snipping Tool utility has a bug that prevents it from running on a desktop with elevated privileges. (Ref: 31931a)

·         Some applications do not use the process token to check the group membership. They check the user’s group membership on its own. Therefore, any Windows rights configured to use a privileged group will not take effect in these applications. The workaround is to use a privileged user account instead of a privileged group. Here is the list of known application with this issue:

1.  vCenter Server 5.1

2.  SQL Server

3.  Exchange 2010 or above 

4.  SCOM 2007

(Ref: 45318a, 45218a, 43779a, 38016a)

·         Privilege elevation using Windows Rights for Internet Explorer (IE) 7 is not supported. (Ref: 33425a)

·         Privilege elevation using Windows rights for “Remote Desktop” is not supported. (Ref: 45222b)

·         VirtualDesktop is not compatible with Centrify Windows Agent – Access. Users should use the Centrify system tray applet to create virtual desktop instead. (Ref: 44641b)

·         Privilege elevation using Windows rights for taskmgr.exe, explorer.exe, and cmd.exe are not recommended. A user granted privileges with Windows rights is implicitly granted to run any executable under the same privilege. (Ref: 45861a, 40525a)

·         Users may notice an error and cannot install ActivClient after installing Centrify Windows Agent. During the installation of ActivClient, it attempts to change the local security setting. However, there is a known issue for Centrify Windows Agent of blocking the local security setting (Ref: 63609b). Therefore, users may not be able to install ActivClient successfully after installing Centrify Windows Agent. We suggest installing ActivClient before installing Centrify Windows Agent. If Centrify Windows Agent has been installed, please uninstall it and follow the installation sequence suggested. This issue happens on Windows 8.1 and Windows 2012 R2 only. (Ref: 76016b)

6. Additional information and support

In addition to the documentation provided with this package, see the Centrify Knowledge Base for answers to common questions and other information (including any general or platform-specific known limitations), tips, or suggestions. You can also contact Centrify Support directly with your questions through the Centrify Web site, by email, or by telephone.

To contact Centrify Support or to get help with installing or using this version of Centrify Windows Agent software, send email to Support or call 1-669-444-5200, option 2.

For information about purchasing or evaluating Centrify products, send email to info.