Some Active Directory users cannot log in to DPA after upgrading from DPA 12.0 or earlier to DPA 12.1 or later

8/21/2020 9:37 PM

9/21/2023 11:50 AM

After upgrading from DPA 12.0 or earlier to DPA 12.1 or later, some AD users are getting one of the following messages when they attempt to log in with their domain account:

• Domain user is locked. 
• Domain has no permissions in DPA.

Database Performance Analyzer

The strategy for fetching attributes changed in DPA 12.1 due to a Spring Security LDAP upgrade. Previously, Spring fetched attributes both during the user search operation and also after user bind operation. It no longer fetches attributes after the bind operation. The change in how Spring fetches attributes resulted in this issue for some DPA users.

Two possible fixes exist. 

Resolution 1: Adjust permissions.

Adjust the permission for DPA service account to allow this account to fetch attributes when searching for users who are supposed to access DPA. You can either:

• Run a script to verify the permissions of the user that is unable to log in, and then adjust those permissions as needed.
• Use the ADSI Edit tool to verify group permissions.

Run a script to verify user permissions

Note: If possible, connect to the AD server before executing the following PowerShell commands, because remote execution could be blocked.

1. Edit the following script for your environment:

   • In the first command, change ldap_user to the LDAP user used for DPA/LDAP integration.
   • In the third command, change login_user to the user that is not able to log in to DPA.

   -- Scripts are not supported under any SolarWinds support program or service.
   -- Scripts are provided AS IS without warranty of any kind. SolarWinds further
   -- disclaims all warranties including, without limitation, any implied warranties
   -- of merchantability or of fitness for a particular purpose. The risk arising
   -- out of the use or performance of the scripts and documentation stays with you.
   -- In no event shall SolarWinds or anyone else involved in the creation,
   -- production, or delivery of the scripts be liable for any damages whatsoever
   -- (including, without limitation, damages for loss of business profits, business
   -- interruption, loss of business information, or other pecuniary loss) arising
   -- out of the use of or inability to use the scripts or documentation.
   
   Enter-PSSession -ComputerName localhost -Credential (Get-Credential -UserName ignite.local\ldap_user -Message "enter password")
   
   Import-Module ActiveDirectory
   $ou = "AD:CN=login_user,OU=Lab Users,DC=ignite,DC=local"
   $acl = Get-Acl $ou
   
   # list all attributes Rights for user
   $acl.access | Out-File -FilePath c:\logs\user_privilege1.txt
   
   # list attributes Rights based on ObjectType
   $obj = @(
   'BC0AC240-79A9-11D0-9020-00C04FC2D4CF', # Group-Membership
   '4828cc14-1437-45bc-9b07-ad6f015e5f28', # Allowed-To-Authenticate
   '3e0abfd0-126a-11d0-a060-00aa006c33ed', # sAMAccountName
   '28630ebb-41d5-11d1-a9c1-0000f80367c1', # userPrincipalName
   'bf9679c0-0de6-11d0-a285-00aa003049e2', # Member
   'bf967a68-0de6-11d0-a285-00aa003049e2', # userAccountControl
   'bf967a00-0de6-11d0-a285-00aa003049e2', # primaryGroupID
   'bf9679e8-0de6-11d0-a285-00aa003049e2', # objectSid
   'b7c69e6d-2cc7-11d2-854e-00a0c983f608'  # Token-Groups
   )
   $acl.access | Where-Object { $obj -contains $_.ObjectType} `
   | Out-File -FilePath c:\logs\user_privilege.txt

2. Run the script on your DPA server to output a file listing user permissions.
3. Run the script again to output the permissions of a user who can log in to DPA.
4. Compare the permission sets, and update the permissions of the first user as needed.

Use the ADSI Edit tool

1. Open the ADSI Edit tool and connect to your LDAP server.
2. Find the user who is not able to log in to DPA in the AD hierarchy.
3. Right-click the user name and choose Properties to show details about that user.
4. On the Security tab, find the group to which the ldap_user (the user used for DPA/LDAP integration) is assigned.
5. Make sure that the group has the right to read user attributes.

Resolution 2: Revert to the original attribute fetching strategy.

Upgrade to DPA 2020.2.1 and add the following option to the system.properties file. To add the option:

1. Stop the DPA Service.
2. Open the file <dpa_directory>/iwc/tomcat/ignite_config/idc/system.properties in a text editor.
3. Add the following to the end of the file: com.confio.security.ldap.authPopulator.fetchAttributesAfterBind=true
4. Start DPA.