AD LDAP user can no longer login to IM or Admin Console or Operator Console in the DEV environment
search cancel

AD LDAP user can no longer login to IM or Admin Console or Operator Console in the DEV environment


Article ID: 272500


Updated On:


DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM)


Had UIM 20.3 & noticed that LDAP stopped working (it was working about a month ago when I last logged into UIM Dev). I'm having to use the IM Administrator account for everything.

I just upgraded to 20.4 CU5 & LDAP is still not working.

The Test works & it's configured exactly the same as UIM Prod but the AD user cannot login.

The user name or password is incorrect. Letters must be typed using the correct case, Make sure the Caps Lock is not accidentally on.


  • Release: 20.3 or higher
  • DX UIM 20.4
  • hub v9.33, 9.39


This problem existed in UIM 20.3 with hub v9.33.

It worked for a year and then it started failing for instance about a week or so ago in the UIM 20.4 DEV environment.

We checked the earlier logs at loglevel 5 but there were no errors indicating-> 'no ACL found for user...' at least not at first...

Prod and DEV cfgs were made identical (hub.cfg and ldap template) after one change to the format of username to match PROD (from $username@$domain)

hub ldap_server_login callback for login to ldap server still fails with login failed even though the hub ldap Test connection succeeds.

1. We adjusted DEV to match Prod regarding the format = $username

      <Active Directory>
         tag = ad
         filter_group = (objectClass=group)
         filter_user = (&(objectClass=person)(|(userPrincipalName=$loginname)(sAMAccountName=$loginname)))
         exclude_regexp = /(@)|(\\)|(^(C|c)(N|n)=)/
         ldap_dn_regexp = /^(C|c)(N|n)=/
         attr_grp_name = name
         attr_grp_member_name = member
         attr_usr_firstname = givenName
         attr_usr_lastname = sn
         attr_usr_mail = mail
         attr_usr_cellphone = mobile
         attr_usr_phone = telephoneNumber
         attr_usr_www = wWWHomePage
         attr_usr_office = physicalDeliveryOfficeName
         attr_usr_company = company
         attr_usr_title = title
         attr_usr_department = department
         attr_usr_description = description
         attr_usr_name = displayName
         attr_usr_id = userPrincipalName
         attr_usr_member_of = memberOf
         attr_usr_restrict_view = restrictViewToUserAssets
         format = $username
         lookup = no
         paging = yes
         member_lookup_reverse = yes
      </Active Directory>

2. To be safe from hub propagation (since there are no firewalls preventing communicatrion bewteen hubs and broadcast was set to on, we isolated the DEV Primary hub from propagation by other hubs.

On the Primary hub, in the Infrastructure Manager, highlight the hub probe and press CTRL+P to open the probe utility.
Locate the callback: hubsec_setup_put
For the "key" parameter enter: secure_callbacks_from_primary_hub_only
For the "value" parameter enter: yes
Click the green "Play" button to execute the callback.
On each secondary hub in the environment:

We did not perform the 2nd part:

Edit the hub.cfg using Raw Configure or edit the file directly
In the main <hub> section add:
security_config_propagation = no

3. To rule out hub security.cfg corruption we stopped the Primary hub robot and set aside the security.* files and reinitialized security.

Then we tested again and saw the 'no ACL found for user' error.

Aug 28 16:53:33:264 [7316] 0 hub: access [LDAP] - no ACL found for user=CN=xxxxxxx1,OU=Information XXXXXXXXXX and Services,OU=XXXXX,OU=Employees,OU=XXXXXX_System,OU=_Users,DC=XXXXXXX,DC=net

When we checked the LDAP Groups in the IM GUI, the same exact LDAP groups were present in both PROD and DEV.

But, for the Administrator and Operator ACLs, No LDAP Group was selected, only 'none' was selected.

Most likely the deselection was either accidental or simply temporary or mistaken selection but it wasn't reselected for each ACL afterwards - this is just a theory.

Once the proper LDAP Groups were reselected, under Manage Access Control List->Set LDAP Group, and saved, the AD user could then login again.