On-prem IDE Services on Helm: LDAP admin-group not honored

Symptoms

A user authenticates successfully against LDAP on an on-prem IDE Services deployment, but on the Users page they appear with the Regular role even though their LDAP account is a member of a group that is configured to grant the Admin role.

The configured admin-groups block in the Helm values.yaml appears to be silently ignored — restarting and redeploying the chart does not change the user's role.

Environment

• Customer type: Personal and commercial customers
• Region affected: All regions
• Product affected: JetBrains IDE Services on-premises, deployed via the ide-services-helm chart (Helm or OpenShift). Confirmed on chart version 2025.6.4 with Active Directory and the memberOf group-membership attribute. The placement requirement applies to all chart versions that consume the configCustomization value.

Cause

The users.import block (and any other tbe.* block such as tbe.auth.ldap) must be placed under ides.configCustomization.tbe in the chart values. The chart does not read these blocks from any other location.

Common incorrect placements that cause the values to be silently ignored:

• Nesting under secrets.ides.users.import — secrets.* is reserved for SealedSecret-style data and is not consumed by the chart's main config rendering.
• Nesting under ides.config.configCustomization.tbe — configCustomization is a sibling of config, not a child. Some legacy doc references mix these up.
• Nesting under ides.config.tbe directly — bypasses configCustomization entirely.

When the block is at the wrong path, the auth.yaml ConfigMap rendered by the chart contains no users: section, so IDE Services has no admin-group mapping to apply at sync time. Users authenticate normally because the LDAP auth block lives elsewhere in the secret, but role assignment falls back to the default (Regular).

Resolution

1. Place the users.import block under ide-services-helm.ides.configCustomization.tbe.users.import in values.yaml. The configCustomization key is a sibling of config, not nested inside it. A working example for Active Directory using the memberOf attribute:

   ide-services-helm:
     ides:
       config:
         deploymentUrl: https://ide-services.example.com
         auth:
           secretName: "ides-auth-config-ldap"
         intellijPlugin:
           pluginRepositoryType: "TBE"
           cdnRedirectMode: "redirect_to_service"
       configCustomization:
         tbe:
           users:
             import:
               enabled: true
               provider: "ldap"
               schedule: "0 */15 * * * *"
               mapping:
                 groups:
                   - id: "CN=ides-users,OU=Groups,DC=example,DC=com"
                 admin-groups:
                   - id: "CN=ides-admins,OU=Groups,DC=example,DC=com"
   

   See LDAP authentication setup for the full users.import schema reference.

2. Verify the chart actually consumes the block before redeploying. Render the chart locally and confirm the auth.yaml ConfigMap contains the tbe.users.import section:

   helm template ide-services ide-services -f values.yaml | grep -A 20 "auth.yaml:"
   

   The rendered ConfigMap should show the full users: tree under tbe:. If it is missing, the placement is still wrong.

3. Redeploy the chart. The next user-import sync run (per the configured schedule) will reapply roles. Wait for at least one sync interval, or restart the IDE Services pod to trigger an immediate sync.

4. Confirm in the Users page that members of the configured admin-groups are now shown with the Admin role.

If a user logged in while the placement was wrong, the existing user record may carry the cached Regular role. Either wait for the next sync cycle (which updates existing records) or remove the user record from the Users page so it is recreated with the correct role on next login.

The same placement rule applies to other tbe.* blocks customers commonly need — including tbe.auth.ldap for the LDAP connection itself and tbe.auth.root-admin-emails for direct admin assignment by email. Verify each block ends up under ides.configCustomization.tbe rather than alongside the secrets: tree.