@Rocky [42000][5206] Access denied; User user1's group[] is not in the group_allowed_login_list

The error message

[42000][5206] Access denied; User user1's group[] is not in the group_allowed_login_list

indicates that you have a Security Integration (likely LDAP or similar) configured with a restricted list of allowed groups, but the system could not find any groups for your user or the user's groups do not match the allowed list. This feature is part of the Group Provider functionality (introduced in StarRocks v3.5). Why this happens 1. Restricted Login: Your Security Integration has the

permitted_groups

parameter set. When this is set, StarRocks only allows users belonging to those specific groups to log in. 2. Missing Groups: The

group[]

part of the error message shows that StarRocks retrieved no groups for

user1

from your Group Provider. Even if the user exists in LDAP, the mapping to their groups is failing or empty. How to Resolve 1. Check the Security Integration configuration Verify which groups are allowed to log in. Use the following to check your configuration:

sql
-- Replace 'LDAP_INTEGRATION' with your actual integration name
SHOW SECURITY INTEGRATIONS;

If you need to update or remove the restriction, you can use:

sql
ALTER SECURITY INTEGRATION <integration_name> SET (
    "permitted_groups" = "group1,group2" -- Ensure these match exactly what the provider returns
);

2. Verify the Group Provider configuration The most common cause is that the Group Provider is not correctly extracting group membership. Check your

CREATE GROUP PROVIDER

statement: *

ldap_group_member_attr

: Ensure this matches your LDAP schema (usually

member

or

memberUid

). *

ldap_user_search_attr

: If your LDAP stores members as full DNs (like in Microsoft AD), you might need to leave this unset or configure it to match how the user identifier is extracted. *

ldap_group_filter

: Ensure this filter is broad enough to include the groups you intend to use. 3. Test Group Retrieval You can verify if StarRocks is seeing the groups for a user by checking the internal metadata or logs, but generally, if

group[]

is empty in the error, it means the

ldap_group_filter

or

ldap_group_member_attr

is not returning a match for that specific user's DN/UID. Reference: * Authenticate User Groups * Security Integration Parameters References • administration/user_privs/group_provider.md • administration/user_privs/authorization/privilege_faq.md • faq/resource_isolation_faq.md • administration/user_privs/authentication/security_integration.md

@Rocky I have added that group in permitted group as well

Even if the group is in your

permitted_groups

list, the error

user1's group[]

shows that StarRocks is retrieving zero groups for your user. This usually means the Group Provider configuration is failing to link your LDAP user to their LDAP groups. To fix this, check the following in your

CREATE GROUP PROVIDER

statement: 1. The DN Matching Mechanism The most common cause is a mismatch between how your user is identified and how they are listed in the group's member attribute. * If you ARE using

ldap_user_search_attr

: Ensure the regex or attribute (like

uid

or

cn

) correctly extracts a value from the group's

member

list that matches your login username. _ _Example:* If the group member is

uid=user1,ou=people...

and your login is

user1

, you need

"ldap_user_search_attr" = "uid=([^,]+)"

. * If you ARE NOT using

ldap_user_search_attr

: StarRocks compares the user's full DN (captured during login) against the group's member list. If your LDAP authentication and Group Provider use different base DNs or formats, the match will fail. _ _Note for Microsoft AD:* It is often recommended not to set

ldap_user_search_attr

, allowing StarRocks to match based on the complete DN. 2. Group Filter and Attributes *

ldap_group_filter

: Ensure this filter is broad enough. If it is too specific (e.g.,

(cn=specific_group)

), StarRocks will only ever check that one group. If your user belongs to other groups, they won't be seen unless the filter includes them. *

ldap_group_member_attr

: Verify if your LDAP uses

member

(common in AD/OpenLDAP) or

memberUid

(common in POSIX/RFC2307). *

ldap_group_identifier_attr

: Ensure this matches the attribute used in your

permitted_groups

list (usually

cn

). 3. Check FE Logs If the configuration looks correct, check the

fe.warn.log

or

fe.log

on your leader FE. Look for messages from

LdapGroupProvider

. It will often log the specific LDAP search query it is running, which helps you see if it's searching in the wrong path or using the wrong filter. Summary Checklist Property | Check

ldap_group_member_attr

| Is it

member

or

memberUid

?

ldap_user_search_attr

| Try removing this if using Active Directory (AD).

ldap_group_filter

| Does it return the group you expect for this user?

ldap_bind_base_dn

| Is this high enough in the tree to see both the user and the group? Example of a working AD configuration (matching by full DN):

sql
CREATE GROUP PROVIDER ad_provider PROPERTIES(
    "type" = "ldap",
    "ldap_conn_url" = "<ldap://your_host:389>",
    "ldap_bind_root_dn" = "CN=admin,CN=Users,DC=example,DC=com",
    "ldap_bind_root_pwd" = "password",
    "ldap_bind_base_dn" = "DC=example,DC=com",
    "ldap_group_filter" = "(objectClass=group)",
    "ldap_group_identifier_attr" = "cn",
    "ldap_group_member_attr" = "member"
    -- No ldap_user_search_attr: matches user DN exactly
);

References • administration/user_privs/group_provider.md