Virtual Apps and Desktop : Studio fails to load with error- “re-enter controller address” when any of the studio admin/s from different domain are unreachable

Studio fails to load with error- “re-enter controller address” when any of the studio admin/s from different domain are unreachable.

In CDF traces we see following errors:-

The trust relationship between the primary domain and the trusted domain failed.

TranslateToNTAccounts someFailed

CheckGlobalAccess failed


Workaround :-

We can fix the issue by deleting the unreachable Admin SID from DAS.Administrators table inside the site database (Take a backup before making changes inside the database) and you would be able to launch the studio again.

Related:

  • No Related Posts

Can ICT be deployed in multi-forest environment

I need a solution

Hello All,

Can we deploy ICT 15.5 in a multi-forested environment ?
I have a customer who has separate management domain and user domain, which are under different forests
The ICT Server is deployed in the management domain, and we can only search the users who are in the management domain, but not in the user domain

Is this kind of ICT deployment possible ?

Regards
Fawaz

0

Related:

SEP Manager Installation fails in Windows Server SetupMode

I need a solution

Hello,

i am trying to automatically install SEP Manager 14.2 on Windows Server 2016 using the SetupMode, but the installation fails.

Installation environment:

  • Windows Server 2016 VM with SetupMode enabled
  • Installation runs in context of a special domain user, used for the installation (not NTAuthoritySystem). This user is both local admin on the SEP VM and domain admin
  • SEP is installed by use of a script that installs the SEPM msi through msiexec.exe without the use of any special parameters (same script works perfectly in Server 2012/2012R2 environments where SetupMode is not used)

Error log:

  • The installation fails with the following error log
    • Beginning Windows group policy check.
      Policy check result: 0, Message: Symantec Endpoint Protection Manager cannot read the required user rights that are specified in the Windows domain security policies on this computer. The management console cannot run if user rights are not assigned to Symantec Endpoint Protection Manager services.
      Check the user rights in your domain security policies manually. For user rights requirements and more information, see: http://entced.symantec.com/sep/14.2.1031.0100/mscw...
      Non-interactive installation, cancelling.
  • The installation returns Exit Code 1602 to the original script
  • WindowsPolicyReview.log provides the following information​​​
    • WindowsPolicyUtil> reviewWindowsSecurityPolicies>> Retrieving domain policy information...
      GroupPolicyXMLDataRetriever> readDomainGroupPolicies>> Generating and reading domain policies. executionCount: 1
      GroupPolicyXMLDataRetriever> readDomainGroupPolicies>> Gpresult command returns error: 1
      GroupPolicyXMLDataRetriever> readDomainGroupPolicies>> XML file not found. Domain policy status will remain UNKNOWN.
      GroupPolicyXMLDataRetriever> readDomainGroupPolicies>> Generating and reading domain policies done! Total executionCount: 2
      WindowsPolicyUtil> reviewWindowsSecurityPolicies>> Domain policy information retrieved
      WindowsPolicyUtil> reviewWindowsSecurityPolicies>> Applied Policies = []
      WindowsPolicyUtil> reviewWindowsSecurityPolicies>> Applied policy list retrieved is not valid. User alert to be displayed
  • gpresult /H C:GPReport.html command in the same user context works perfectly

What else could i do to find the problem?

Many thanks in advance

0

Related:

7023292: How to use DRA when remote access to the Windows DC SAM is restricted

This document (7023292) is provided subject to the disclaimer at the end of this document.

Environment

NetIQ Directory and Resource Administrator 9.1.x

NetIQ Directory and Resource Administrator 9.2.x

Microsoft Windows Domain Controller 2016

Situation

Microsoft Windows GPO settings provide the option of restricting remote access to any member server, or domain controller’s Security Account Manager’s (SAM) database. This database contains security details for users and groups within the local Windows OS or Domain Controller. Through the use of a GPO setting, remote access into the database can be restricted.

If this security lock down is in place, the DRA server might return an error when attempting to set a domain access account. DRA will fail to determine if the access account has the necessary AD rights.

Resolution

Modify the Security Descriptor to include the AD account used for the Domain Access account within the managed domain properties of DRA. Enabling this setting will allow the account(s) listed within the Security descriptor field the ability to make remote queries to the SAM. This ability is not restricted by remote client.

Cause

NetIQ Directory and Resource Administrator (DRA) requires some level of Administrative access to each Active Directory Domain or Member Server managed by DRA. The DRA Server will validate this access by checking the SAM of the Member Server or AD Domain Controller. If there are no security details returned back to DRA, the DRA Server will report an error. This access check occurs at multiple times within the regular operation of DRA. The most common occurrences are:

Adding a new managed domain

Accounts Cache Refresh

Domain Configuration Refresh

When the Microsoft GPO setting for: Network access: Restrict clients allowed to make remote calls to SAM, the default value used the Security descriptor field is set to Built-InAdministrators. When the DRA Domain Access account is not a direct or indirect member of the Built-InAdministrators group, requests made to the SAM will fail. This failure will cause DRA to fail as well.

Additional Information

More information on this GPO setting can be found at: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls .

The most common use of this GPO is with Windows 2016 AD Domains. Other domain functional levels can still apply the GPO as well. Specific details about the Domain and Computer requirements for the GPO application can be found within the Microsoft Documentation listed above.

This GPO setting will not affect a Domain Access account within membership in the AD Domain Admins group. This group is a member of the built-in Administrators group within AD.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

7021821: Troubleshooting Reflection X Advantage Domain Connections

There are many reasons why a connection attempt may fail. After a failure occurs, a related message is shown in the bottom of the X Manager for Domains user-interface that may help identify the problem. For example:

Use the guidelines in the sections below to troubleshoot the failed connection. This note is organized into the following troubleshooting topics:

Additional detail regarding the problem may be available in log files created by both the X Manager for Domains and the Reflection X Advantage domain controller. For more information, see the Logging section below.

Network Firewall

Note: Beginning in Reflection X Advantage 4.0, predefined ports are used. If your environment has a network firewall, you need to upgrade to 4.0.

A network firewall cannot be running between any Reflection X Advantage 3.x or earlier domain nodes, including those running the X Manager for Domains and those running a Reflection X Advantage domain controller. This is because in domain mode, Reflection X Advantage uses random, ephemeral ports for communication between all of its components. If a network firewall is running, you may see one of the following messages:

  • “Failed to establish bidirectional communication with the domain controller.”

This message appears when the Reflection X Advantage domain controller cannot connect to the X Manager for Domains.

  • “Failed to connect to host <hostname>.”

This message appears when the X Manager for Domains cannot connect to the Reflection X Advantage domain controller. Besides checking for a firewall, ensure that the RX Service is running on the Reflection X Advantage domain controller.

Resolution: Upgrade to Reflection X Advantage 4.0 or disable the network firewall between the Reflection X Advantage domain nodes.

Note: Personal firewalls can be used if they work at the application level, as the Microsoft Windows Firewall does. For information about configuring Reflection X Advantage for use with the Windows Firewall, see Technical Note 2240.

Network Address Translation

Note: Beginning in version 4.0, you can configure Reflection X Advantage to work in a NAT environment.

Network Address Translation (NAT) must not exist between nodes running Reflection X Advantage 3.x or earlier. This is because Reflection X Advantage components provide IP address information to other Reflection components for communication, which would not be updated by the NAT tables. You may see the following error message:

“Failed to establish bidirectional communication with the domain controller.”

Resolution: Upgrade to Reflection X Advantage 4.0 or disable the Network Address Translation between nodes that run Reflection X Advantage.

Logging into a Reflection X Domain

When the X Manager for Domains is launched, the following login window displays.

2466_2.gif

User name and password fields

The input required depends on how the applicable Reflection X Advantage domain controller was set up. Multiple authentication mechanisms are supported and the default mechanism varies based on operating system.

For example, if the domain controller is running on a UNIX or Linux operating system, Pluggable Authentication Modules (PAM) is the default authentication mechanism, so your UNIX or Linux user name and password would likely be required. If the domain controller is running on a Windows operating system, Windows Domain (or Windows local) is the default authentication mechanism, so your Windows domain (or Windows local) credentials would likely be required. There are other authentication mechanisms as well, such as LDAP. If you are unsure which credentials to use, check with the domain administrator.

Domain field

The name or IP address of the host running the Reflection X Advantage domain controller should be entered here.

Note: Do not enter your Windows domain in this field.

Resolution: Follow these examples.

Example 1: Logging into a Reflection X Advantage domain controller running on a UNIX host

2466_3.gif

Example 2: Logging into a Reflection X Advantage domain controller running on a Windows host

2466_4.gif

Windows Domain and Local Authentications

When Reflection X Advantage is installed on a Windows operating system and a Reflection X Advantage domain controller is created, the default authentication mechanism is a Windows domain. The Windows domain configured by default will depend on how the Windows session was logged into before installing Reflection X Advantage.

For example, if the Windows session was logged into with a user from a domain (such as ‘attachmate’), the domain configured by the Reflection X Advantage domain controller will be ‘attachmate’. If the Windows session was logged into with an account local to the Windows machine, and the PC name is ‘rxa-dc.attachmate.com’, the domain configured by the Reflection X Advantage domain controller will be ‘RXA-DC’.

Understanding which domain has been configured for a Reflection X Advantage domain controller on Windows enables users to input the appropriate credentials.

Resolution: If you are unsure which domain has been configured, check with the host or Reflection X Advantage administrator.

Mixing Versions of Reflection X Advantage

All components in a Reflection X Advantage domain must be running the same version. If attempting to use the X Manager for Domains to log into a Reflection X Advantage domain running a different version, then you may see the following message:

“Version mismatch: Local version=<build number>, Remote version=<build number>.”

Resolution: Upgrade the earlier version of Reflection X Advantage to match the newer installation.

Machines with Multiple Network Adapters

If the Reflection X Advantage domain controller has more than one network adapter, there is a chance the wrong one may be utilized by the domain controller. The correct adapter can be configured by editing the rxs.conf file on the domain controller. In that file, there will be a few entries like the following:

wrapper.java.additional.1=<keyword=value>

wrapper.java.additional.2=<keyword=value>

wrapper.java.additional.3=<keyword=value>

Resolution: Add another entry, using the next number in sequence, and the keyword and value combination below:

wrapper.java.additional.4=-Djava.rmi.server.hostname=<IP address of correct network adapter>

After making this change, restart the RX service.

Domains on Linux

Note: This information in this section does not apply to version 4.0 or higher.

When you try to log on to a Reflection X Advantage domain, you receive a “Permission Denied,” “Failed to connect to domain,” or “Domain communication error” message.

Machines used with Reflection X Advantage must have a host name that is resolvable either through DNS or by an entry in a hosts file. Some Linux distributions place an entry in /etc/hosts that maps the machine’s host name to an address in the local loopback space (127.0.0.2 or 127.0.1.1, for example); using a local loopback address causes communication issues in Reflection X Advantage.

Resolution: Upgrade to Reflection X Advantage version 4.0, or remove entries in /etc/hosts that map the host name to a local loopback address, or add an entry containing the machine’s true IP address and host name to the hosts file.

Connections to Domain Nodes

You may be able to log into the domain, but when you try to start a session, a message like the following displays:

Failed to connect to node:127.0.0.2:22002

This message may display if there is a firewall blocking access to the node, or if there is a problem resolving the IP address (for example, in a NAT environment). If the problem is due to an incorrect or unusable IP address, starting in version 4.0, an alternate address can be configured as a fallback. The alternate address can be created using the rxsconfig command line utility or the X Administrative Console.

Request Technical Support

If you have worked through this technical note and are still unable to connect, contact Attachmate Technical Support. For information about contacting Attachmate technical support, see http://support.attachmate.com/contact/.

If you are asked to send in a log file, follow the steps below.

Logging

Logs are generated for the X Manager for Domains, the Reflection X Advantage domain controller, and the Reflection X Advantage domain nodes. See the log locations below, along with information about how to increase logging if needed..

Note: All log files in version 3.0 and earlier are named output.txt. Beginning with version 4.0 loging information has been broken down into a larger number of files, each with a descriptive name such as “xmanager.log” and “domain.log”.

X Manager for Domains:

Windows:%USERSPROFILE%attachmaterxlogs

UNIX:~/attachmate/rx/logs

Reflection X Advantage domain controller:

Windows:%ALLUSERSPROFILE%attachmaterxlogs

UNIX:/opt/rxadvantage/logs

Sometimes a higher level of logging is required than what is provided by default. You can enable debug logging by using the file provided here for download from the Attachmate Download Library: log.xml.

To use the log.xml file, follow the steps below.

  1. Download and save the file into the appropriate directory on each system running Reflection X Advantage that you want to increase debugging on.

Windows – Reflection X Advantage standalone installation:

C:Program FilesAttachmateReflection X Advantage

Windows – Installed with Reflection X 2011:

C:Program FilesAttachmateReflection

UNIX:/opt/rxadvantage

  1. Edit this file entry to specify the location and name for the debug log:
<param name="file" value="path/file_name"/>

Windows Example:

<param name="file" value="c:/path/rxa.log"/>

UNIX Example:

<param name="file" value="path/rxa.log"/>
  1. Restart the X Manager for Domains and RX Service on the domain controller so that the new logging will take effect.

Note: All Reflection X Advantage logging will be redirected to the files specified. Once the debug log has been taken or the connection problem resolved, we recommend you remove the log.xml file and restart the appropriate Reflection X Advantage component(s).

Uploading

To upload the log file, see https://upload.attachmate.com/.

Related:

VNXe NAS Server causing security errors on domain controller

Hi all,



I have a VNXe3200, and created a NAS Server named Saturn and joined it to my Active Directory domain, which has two Windows Server 2003 domain controllers. In the Security Event log on both DCs, I see errors every five minutes or so (all day and night) that look like this:



Source: Security Category: Account Logon Type: Failure Audit Event ID: 680 User: NT AUTHORITYSYSTEM Description: Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon account: SATURN$ Source Workstation: SATURN Error Code: 0xC0000199



Sometimes there is also an extra character after the $ in Logon account (e.g. SATURN$G or SATURN$u or sometimes a special character).



I opened a support case,and the technicians looked at my VNXe config, and since it looks good, they are quick to brush this off as a Microsoft issue. And the resolution very well may be a setting on the domain controller, but I need a VNXe specialist to tell me what that setting is. Specifically, what do I need to do to make the VNXe CIFS server talk to my domain controller without errors?



I should note, domain authentication is working, as I can access the CIFS server and its shares, and ACLs are properly applied, but there is something amiss with the communication between the VNXe CIFS Server and my Windows domain controllers that is producing all these errors. I can’t believe I’m the only one having this issue, as creating a NAS Server on the VNXe is a very straightforward process.

Is anyone else having this issue, or does anyone know what I need to do to fix this? Thanks!

Related:

What need to be done when I want to use a second WIndows domain within FileNet P8 5.2.0?

We are using one (1) Windows domain within FileNet P8 5.2.0 for authentication and autorization and this domain is configured as directory server (within ACCE/FEM) and initial authentication realm within FileNet Configuration Manager.
But now we want to use a second Windows domein (which is connected to the first domain by using a trust). We want to use accounts from this 2nd domain to be able to login to FileNet and make these account member of autorization groups within the initial domain.
I have read the documentation (KC) about this and know that I have to add this 2nd domain within ACCE/FEM as a 2nd directory server and within Confifguration Manager as a 2nd realm.
I want to be sure that this is all that I need to do.
Can somebody confirm that these are the steps to accomplish this?

Related:

Event ID 1055 — Group Policy Preprocessing (Security)

Event ID 1055 — Group Policy Preprocessing (Security)

Updated: September 21, 2007

Applies To: Windows Server 2008

Group Policy preprocessing uses security to act on behalf of the computer or user. Incorrect permissions or security failures can prevent Group Policy from applying to the computer or user.

Event Details

Product: Windows Operating System
ID: 1055
Source: Microsoft-Windows-GroupPolicy
Version: 6.0
Symbolic Name: gpEvent_FAILED_MACHINENAME
Message: The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following: a) Name Resolution failure on the current domain controller. b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

Resolve
Determine computer name

The Group Policy service logs the name of the domain controller and the error code. This information appears on the Details tab of the error message in Event Viewer. The error code (displayed as a decimal) and error description fields further identify the reason for the failure. Evaluate the error code with the list below:

  • Error code 14
  • Error code 525
  • Error code 1355
  • Error code 1727

Error code 14 (Not enough storage is available to complete this operation)

This error code might indicate that Windows does not have enough memory to complete the task. Investigate the system event log for any other memory specific issues.

Error code 525 (The specified user does not exist)

This error code might indicate incorrect permissions on the organizational unit. The user requires read access to the organizational unit that contains the user object. Similarly, computers require read access to the organizational unit that contains the computer object.

Error code 1355 (The specified domain either does not exist or could not be contacted)

This error code might indicate a fault or improper configuration with name resolution (DNS). Use nslookup to confirm you can resolve addresses of the domain controllers in the user domain. Use Networking troubleshooting procedures to further diagnose the problem (http://go.microsoft.com/fwlink/?LinkId=92706 ).

Error code 1727 (The remote procedure call failed and did not execute)

This error code might indicate firewall rules are preventing communication with a domain controller. If you have third-party firewall software installed, check the configuration of the firewall or try temporarily disabling it and verifying Group Policy processes successfully. Use Networking troubleshooting procedures or procedures from your third-party firewall software to further diagnose the problem (http://go.microsoft.com/fwlink/?LinkId=92706).

Verify

Group Policy applies during computer startup and user logon. Afterward, Group Policy applies every 90 to 120 minutes. Events appearing in the event log may not reflect the most current state of Group Policy. Therefore, you should always refresh Group Policy to determine if Group Policy is working correctly.

To refresh Group Policy on a specific computer:

  1. Open the Start menu. Click All Programs and then click Accessories.
  2. Click Command Prompt.
  3. In the command prompt window, type gpupdate and then press ENTER.
  4. When the gpupdate command completes, open the Event Viewer.

Group Policy is working correctly if the last Group Policy event to appear in the System event log has one of the following event IDs:

  • 1500
  • 1501
  • 1502
  • 1503

Related Management Information

Group Policy Preprocessing (Security)

Group Policy Infrastructure

Related: