DRA Server hangs on AD Password Set

  • 7018008
  • 01-Sep-2016
  • 19-Oct-2016


NetIQ Directory and Resource Administrator 9.0.x
Windows Server 2012 / 2012 R2
Windows AD Domain 2012 / 2012 R2
Windows Domain Controller 2012 / 2012 R2


In Network environments configured to use a PIN based smart card for two factor authentication, the NetIQ Directory Resource Administrator service may appear to be in a unresponsive state. This state will coincide with AD password set or change operations performed with DRA. This can also include creating a new Active Directory user object.


Use the Microsoft Certificate Services MMC snap-in for both the Local Machine account of the DRA Sever AND the AD account running the NetIQ Services. The personal certificate store for both accounts should not contain any certificates specific to AD user accounts. The personal store can contain a machine specific certificate used for IIS and DRA Rest Services.

When using a Windows RDP connection to the remote OS hosting DRA, the host workstation's smart card certificates will copy over to the personal store of the OS hosting DRA. This can be disabled using the RDP client options. This will prevent the host workstation's user certificates from being added to the DRA Server's OS personal certificate store.


As of at least Microsoft Active Directory version 2012 or Windows Sever 2012, AD password operations require the use of LDAP-S. This is a secure LDAP connection between the requesting client, which in this case is the Server running DRA; and the Windows Domain Controller. In order to maintain a secure connection the Windows OS hosting DRA Server will attempt to use an SSL Certificate. When an AD environment is configured to use a PIN based Smart Card , there is an additional certificate stored on the DRA Server OS. When this certificate is stored under the personal certificate store of the DRA Service account; but is tied to another AD user, the SSL transaction will prompt for a smart card pin. If the transaction requiring security is running as an Application Programing Interface (API) the additional Smart Card prompt is not exposed to the end user. Until the prompt is validated or canceled the AD transaction can't be completed. This prevents the DRA Service from receiving any acknowledgement of it's password set request from AD. The lack of response from AD causes the DRA service to become unresponsive until the service is restarted.