AD LDAP user can no longer login to IM or Admin Console or Operator Console in the DEV environment
Article ID: 272500
Updated On:
Products
Issue/Introduction
In DX UIM 20.3 we 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 and LDAP is still not working.
The Test works and 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.
Environment
- Release: 20.3 or higher
- DX UIM 20.4
- hub v9.33, 9.39
Cause
Checked the LDAP Groups in the IM GUI, and 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. This may have been changed/happened accidentally.
Resolution
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 error even though the hub ldap Test connection succeeds.
1. We adjusted DEV to match Prod regarding the format = $username
<templates>
<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 communication between 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 in the hub directory 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=XXXXXX1,OU=Information XXXXXXXXXX and Services,OU=XXXXX,OU=Employees,OU=XXXXXX_System,OU=_Users,DC=XXXXXXX,DC=XXX
When we checked the LDAP Groups in the IM GUI, and 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.
Feedback
