How many levels of nested groups can the Proxy learn from Windows upon authentication

I need a solution


When a user authenticate let’s say to an IWA realm, and his/her group memberships are provided by the Domain Controller, since his/her membership of nested groups is also reported, is there a limit for the depth of “nesting” that can be reported and learnt by the Proxy SG? If so, what is this limit?





How BCAAA contributes in NTLM user authentication

I need a solution

Hi All,

in this link from microsoft “”, there is way called Noninteractive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server

it BCAAA works the same way as above?

if yes, can anyone provide more details?

if no, then how it works

thanks in advnace,





  • No Related Posts

Domain Replication NTP (Firewall)

I need a solution

Good Morrning,

I’ve deployed NTP on our Domain Controller, whereby only the Microsoft defined Active Directory ports are allowed. This works great for our workstations, but I noticed our secondary Domain Controller is now failing replication. So as a result, I created a new rule to allow All traffic from all ports, inbound and outbound, to the Secondary Domain Controller IP Address. Through the SEPM I can see this rule is allowing some types of traffic between Primary and Secondary DC- yet replication still fails. 

I know this is NTP related, because if I disable the firewall on the primary DC, then the secondary DC (which has no firewall) replication is a success.

So my question is, what other NTP feature would cause replication to fail despite explicitly having a rule to allow All between these two servers? I’ve attached a screenshot of the rule which applies to the Primary Domain Controller, whereby the IP of the secondary DC is added under “Hosts”.

The rules below that one just go on to allow specific AD ports for all hosts, as well as some prohibitive rules which should not apply to the Secondary DC since this is the first rule in the sequence, above all else. 

Any guidance would be appreciated, I’ve been struggling with this for days now.



Workspace Environment Management (WEM): Active Directory search improvements in WEM 4.6


The Active Directory (AD) system built into the WEM Administration Console and WEM Infrastructure Server has been refactored in WEM 4.6 to improve performance and stability.

Although AD searches performed by the WEM Console and WEM Infrastructure server in previous WEM versions have typically returned results quickly, many customer environments consist of multiple AD forests or AD domains. The Active Directory improvements introduced in WEM 4.6 are designed to improve performance and stability; particularly for multi-forest/domain environments.

Active Directory improvements in WEM 4.6

Global Catalog (GC) mechanism: AD searches are initiated against the AD forest’s Global Catalogue Server (GC) instead of searching against each of the forest’s Domain Controllers in turn.

Asynchronous search mechanism: AD searches are performed on all forests (GC servers or domains) at the same time, instead of searching one by one.

AD search timeout mechanism: If the AD User or Machine object lookup points to a forest or domain that is currently unavailable, a configurable timeout been introduced to prevent prolonged searching. The timeout value is set through the WEM Administration Console (Active Directory Objects => Advanced => Active Directory search timeout (msec)), as shown below:

User-added image

The default value is 1 second (1000 msec). The value set here affects AD searches for both the WEM Administration Console and the WEM Infrastructure Server. If an AD search time exceeds the value specified in this field, AD searching will stop.

This can be configured with a preferred value based on real environment conditions. In large environments or in cases where there are dead forest entries, having a higher value, could also cause issues such as an unresponsive/black screen when logging in, since the AD search will continue to run depending on the timeout value set. It is recommended to remove the dead forest’s trust relationship with current forest to avoid the time consuming queries. If this cannot be done, there will be an enhancement coming soon which will greatly decrease the query frequency and made blacklist for dead forests in codes automatically.

NOTE: Citrix recommends using a timeout value of at least 1000 msec to avoid a timeout before the AD search completes.

Troubleshooting Active Directory searches in WEM

If AD searches are failing:

  • Check that the Active Directory search timeout (msec) is appropriate for the environment. This means that there is no specific value to recommend. Consideration needs to be given if the environment includes multiple AD forests or AD domains.
  • Generate WEM Administration Console and WEM Infrastructure Server debug logs that capture the failed AD search occurrences. In the logs, Active Directory-related entries are marked as AD: in the header of the body, right after the function name:

User-added image


Domain Change

I need a solution

Dear ALL

recently I have been enfected by ransome ware any haw my Domain controller have been enfected so I changed the windows but i forget to demote the symanted server from the domain and now 

i cant access the symantec endpoint protection manager and also i cant istall the endpoint with is member of the new Domain 



NTP not synchronized on Advanced Threat Protection

I need a solution

HI Team,

After running the “status_check” command in Symantec ATP’s CLI i am getting following message:

NTP                                             NOT synchronized!
                                                Please fix NTP configuration, else
                                                the appliance may not function properly.

We are using  Domain Controller (DC) as NTP server. 

As per the symantec KB article:…

if the time servers is a DC, change


LocalClockDispersion from 10 to 0.

I have cheked the same with DC team but they informed me that only Symantec ATP team only reported the error.

No other applications or services team has reported the issue.

DC team can not do the aforementioned changes in their DC server cause it might impact many applications,services and servers in environment.

Can you guys help me with workaround to fix this issue??

Quick response will be appreciated. 



MCS created pooled Windows 10 machines get the wrong logon server

Under certain conditions, when you create MCS pooled random Windows 10 machines, they might point to wrong domain controller as the logon server. This will lead to delayed user logon and GPO applications might take longer than expected.

On further investigation, you would observe the following registry key being created on MCS provisioned machines.



Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part II

EMC logo

Virtualized Active Directory is ready for Primetime, Part II!

In the first of this two-part blog series, I discussed how virtualization-first is the new normal and fully supported; and elaborated on best practices for Active Directory availability, achieving integrity in virtual environments, and making AD confidential and tamper-proof.

In this second installment, I’ll discuss the elements of time in Active Directory, touch on replication, latency and convergence; the preventing and mediating lingering objects, cloning and of much relevance, preparedness for Disaster Recovery.

Proper Time with Virtualized Active Directory Domain Controllers (AD DC)

Time in virtual machines can easily drift if they are not receiving constant and consistent time cycles. Windows operating systems keep time based on interrupt timers set by CPU clock cycles. In a VMware ESXi host with multiple virtual machines, CPU cycles are not allocated to idle virtual machines.

To plan for an Active Directory implementation, you must carefully consider the most effective way of providing accurate time to domain controllers and understand the relationship between the time source used by clients, member servers, and domain controllers.

The Domain Controller with the PDC Emulator role for the forest root domain ultimately becomes the “master” timeserver for the forest – the root time server for synchronizing the clocks of all Windows computers in the forest. You can configure the PDC to use an external source to set its time. By modifying the defaults of this domain controller’s role to synchronize with an alternative external stratum 1 time source, you can ensure that all other DCs and workstations within the domain are accurate.

Why Time Synchronization Is Important in Active Directory

Every domain-joined device is affected by time!

Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer. Many factors can affect time synchronization on a network. The following factors often affect the accuracy of synchronization in AD DS:

  • Network conditions
  • The accuracy of the computer’s hardware clock
  • The amount of CPU and network resources available to the Windows Time service

Prior to Windows Server 2016, the W32Time service was not designed to meet time-sensitive application needs. Updates to Windows Server 2016 allow you to implement a solution for 1ms accuracy in your domain.

Figure 1: How Time Synchronization Works in Virtualized Environments

See Microsoft’s How the Windows Time Service Works for more information.

How Synchronization Works in Virtualized Environments

An AD DS forest has a predetermined time synchronization hierarchy. The Windows Time service synchronizes time between computers within the hierarchy, with the most accurate reference clocks at the top. If more than one time source is configured on a computer, Windows Time uses NTP algorithms to select the best time source from the configured sources based on the computer’s ability to synchronize with that time source. The Windows Time service does not support network synchronization from broadcast or multicast peers.

Replication, Latency and Convergence

Eventually, changes must converge in a multi-master replication model…

The Active Directory database is replicated between domain controllers. The data replicated between controllers called ‘data’ are also called ‘naming context.’ Only the changes are replicated, once a domain controller has been established. Active Directory uses a multi-master model; changes can be made on any controller and the changes are sent to all other controllers. The replication path in Active Directory forms a ring which adds reliability to the replication.

Latency is the required time for all updates to be completed throughout all domain controllers on the network domain or forest.

Convergence is the state at which all domain controllers have the same replica contents of the Active Directory database.

Figure 2: How Active Directory Replication Works

For more information on Replication, Latency and Convergence, see Microsoft’s Detecting and Avoiding Replication Latency.”

Preventing and Remediating Lingering Objects

Don’t revert to snapshot or restore backups beyond the TSL.

Lingering objects are objects in Active Directory that have been created, replicated, deleted, and then garbage collected on at least the Domain Controller that originated the deletion but still exist as live objects on one or more DCs in the same forest. Lingering object removal has traditionally required lengthy cleanup sessions using various tools, such as the Lingering Objects Liquidator (LoL).

Dominant Causes of Lingering Objects

  1. Long-term replication failures

While knowledge of creates and modifies are persisted in Active Directory forever, replication partners must inbound replicate knowledge of deleted objects within a rolling Tombstone Lifetime (TSL) # of days (default 60 or 180 days depending on what OS version created your AD forest). For this reason, it’s important to keep your DCs online and replicating all partitions between all partners within a rolling TSL # of days. Tools like REPADMIN /SHOWREPL * /CSV, REPADMIN /REPLSUM and AD Replication Status should be used to continually identify and resolve replication errors in your AD forest.

  1. Time jumps

System time jump more than TSL # of days in the past or future can cause deleted objects to be prematurely garbage collected before all DCs have inbound replicated knowledge of all deletes. The protection against this is to ensure that:

  • The forest root PDC is continually configured with a reference time source (including following FSMO transfers).
  • All other DCs in the forest are configured to use NT5DS hierarchy.
  • Time rollback and roll-forward protection has been enabled via the maxnegphasecorrection and maxposphasecorrection registry settings or their policy-based equivalents.
  • The importance of configuring safeguards can’t be stressed enough.
  1. USN rollbacks

USN rollbacks are caused when the contents of an Active Directory database move back in time via an unsupported restore. Root causes for USN Rollbacks include:

  • Manually copying previous version of the database into place when the DC is offline.
  • P2V conversions in multi-domain forests.
  • Snapshot restores of physical and especially virtual DCs. For virtual environments, both the virtual host environment AND the underlying guest DCs should be compatible with VM Generation ID. Windows Server 2012 or later, and vSphere 5.0 Update 2 or later, support this feature.
  • Events, errors and symptoms that indicate you have lingering objects.

Figure 3: USN Rollbacks – How Snapshots Can Wreak Havoc on Active Directory


You should always use a test environment before deploying the clones to your organization’s network.

DC Cloning enables fast, safer Domain Controller provisioning through clone operation.

When you create the first domain controller in your organization, you are also creating the first domain, the first forest, and the first site. It is the domain controller, through group policy, that manages the collection of resources, computers, and user accounts in your organization.

Active Directory Disaster Recovery Plan: It’s a Must

Build, test, and maintain an Active Directory Disaster Recovery Plan!

AD is indisputably one of an organization’s most critical pieces of software plumbing and in the event of a catastrophe – the loss of a domain or forest – its recovery is a monumental task. You can use Site Recovery to create a disaster recovery plan for Active Directory.

Microsoft Active Directory Disaster Recovery Plan is an extensive document; a set of high-level procedures and guidelines that must be extensively customized for your environment and serves as a vital point of reference when determining root cause and how to proceed with recovery with Microsoft Support.


There are several excellent reasons for virtualizing Windows Active Directory. The release of Windows Server 2012 and its virtualization-safe features and support for rapid domain controller deployment alleviates many of the legitimate concerns that administrators have about virtualizing AD DS. VMware® vSphere® and our recommended best practices also help achieve 100 percent virtualization of AD DS.

Please reach out to your Dell EMC representative or checkout Dell EMC Consulting Services to learn how we can help you with virtualizing AD DS or leave me a comment below and I’ll be happy to respond back to you.


Virtualizing a Windows Active Directory Domain Infrastructure

Related Blog

Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part I

The post Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part II appeared first on InFocus Blog | Dell EMC Services.

Update your feed preferences





submit to reddit


  • No Related Posts

Virtual Desktops Appear as “Not Registered” in the Console

To resolve the issue, grant the logon right, Access this computer from the network to the Delivery Controller machine account(s).

This can be modified directly on the VDA (recommended for testing):

  1. To edit the policy directly on the VDA, use Local Computer Policy editor (MMC, then add the Snap-In Local Computer Policy.)
  2. The policy is located in Computer Configuration –>Windows Settings –>Security Settings –>Local Policies –>User Rights Assignment
  3. Locate “Access this computer from the network”
  4. Click ‘Add User or Group’. Change the Object Types to include “Computers”.
  5. Type the names of the Delivery Controller(s). Click ‘Check Names’. Click OK to save the change. There will be several warnings.

Once this is determined to resolve the OU-based registration issue, policy can be applied to all the VDA’s by completing one of the following tasks:

  • Apply a group policy from the domain controller either to the domain as a whole or to an Organizational Unit containing the Virtual Desktops for the XenDesktop farm.

User-added image


7018092: Active Directory Password Checkout – LDAP modify failed, error 53 (Server is unwilling to perform)

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


NetIQ Privileged Account Manager

Microsoft Active Directory LDAP


Unable to check-in password with Microsoft Active Directory (AD) LDAP

Password Checkout for Active Directory Application over LDAP is not working

Using the checked-out password reports invalid credentials, account name / password

MyAccess reports Failed Check-in to user

The following appears in the Debug unifid.log when attempting check-in:

Warning, LDAP modify failed, error 53 (Server is unwilling to perform)

Error, LDAP modify failed – 182553


Microsoft Active Directory (AD) may have requirements that are preventing the password change from taking place. This error means the destination LDAP server is not allowing this password change to go through. While there might several reasons for this error to be returned from the LDAP server, here are some common Microsoft Active Directory explanations / requirements:

  1. Microsoft AD may impose some strength requirements on the password. In order to conform to these requirements, a password policy must be created and assigned to the application account domain in the Enterprise Credential Vault. For more details about this process, please refer to documentation:
  • Microsoft AD may only accept password changes over secure connections (SSL, ldap port 636). Verify the Active Directory Application Account Domain in the Enterprise Credential Vault has been configured to have SSL enabled and to use the correct port.

    Note: By default, LDAPS://connections use port 636 for SSL.

  • Microsoft AD requires that the client must bind as a user with sufficient permissions to modify another user’s password. In this case, the proxy credential provided to PAM in the AD LDAP Account Domain of the Enterprise Credential Vault must have sufficient permissions to modify another user’s password. According to Microsoft, “the password is stored in the AD and LDS database on a user object in the unicodePwd attribute.”

  • Cause

    Microsoft Active Directory (AD) is denying the LDAP modify request because the request violates certain requirements / criteria determined by the Microsoft AD Domain Controller.

    Additional Information

    For more information from Microsoft on these certain restrictions, please refer to How to change a Windows Active Directory and LDS user password through LDAP.


    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.