http://starrocks.io logo
Join Slack
Powered by
This message was deleted.
# questions-and-troubleshooting
s
This message was deleted.
r
The issue you're encountering is likely caused by the malformed LDAP filter and potentially a broad base DN. Here is how to fix it: 1. Fix the Filter Syntax Your filter contains 
&
, which is an HTML-encoded entity. In the SQL command for creating a Group Provider, you must use the literal 
&
character. LDAP servers do not recognize 
&
as a logical operator. Corrected Property:
Copy code
sql
"ldap_group_filter" = "(&(objectClass=group)(cn=DP-Dev-DataAnalysts))"
If the LDAP server receives 
&
, it may treat the filter as invalid or fail to filter correctly, leading the system to either search more broadly or log errors for every entry it attempts to process. 2. Use 
ldap_group_dn
for a Single Group If you only need to sync one specific group, it is more efficient to use 
ldap_group_dn
instead of 
ldap_group_filter
. This allows StarRocks to query the group object directly by its Distinguished Name (DN) without performing a search across the directory. Example:
Copy code
sql
"ldap_group_dn" = "cn=DP-Dev-DataAnalysts,ou=Groups,dc=example,dc=com"
_Note: You cannot specify both 
ldap_group_dn
and 
ldap_group_filter
._ 3. Narrow the 
ldap_bind_base_dn
 Check your 
ldap_bind_base_dn
setting. If it is set to the root of your domain (e.g., 
dc=company,dc=com
), StarRocks will search the entire directory. If your filter is failing or returning too many results, this causes the FE to iterate through a massive number of entries, resulting in the "huge logs" you are seeing. Point the 
ldap_bind_base_dn
to the specific Organizational Unit (OU) where your groups are located to limit the search scope. 4. Verify Identifier and Member Attributes Ensure your other mapping properties match your LDAP schema: • 
ldap_group_identifier_attr
: Should usually be 
cn
if you want the StarRocks group name to match the LDAP Common Name. • 
ldap_group_member_attr
: For Microsoft AD, this is typically 
member
. • 
ldap_user_search_attr
: • In v3.5.0+, if you are using Microsoft AD, it is recommended to not configure this parameter so StarRocks can match users by their full DN. • If you are using a traditional LDAP where group members are simple UIDs, set it to something like 
uid=([^,]+)
. Summary Checklist • ☐ Replace 
&
with 
&
in the filter. • ☐ Ensure the filter is wrapped in parentheses 
(...)
. • ☐ Check 
fe.log
for specific LDAP search errors. If the logs persist, verify if the "huge logs" are actually 
DEBUG
level logs (which can be reduced by setting 
sys_log_level = INFO
in 
fe.conf
). References • administration/user_privs/group_provider.md • administration/user_privs/authentication/ldap_authentication.md • best_practices/authentication_authorization.md
z
@Rocky ok give me full correct ddl
r
To fix the issues with excessive logging and incorrect filtering, use the following DDL. Note the correction of 
&
to 
&
and the recommendation for Microsoft AD environments. Recommended DDL (Optimized for Microsoft AD) If you only need to sync this one specific group, it is highly recommended to use 
ldap_group_dn
 instead of a filter. This prevents StarRocks from searching the entire directory, which is likely causing your "huge logs."
Copy code
sql
CREATE GROUP PROVIDER ad_data_analysts
PROPERTIES (
    "type" = "ldap",
    -- Connection Info
    "ldap_conn_url" = "<ldap://your-ldap-host:389>",
    "ldap_bind_root_dn" = "CN=ServiceAccount,OU=Users,DC=example,DC=com",
    "ldap_bind_root_pwd" = "your_password",
    
    -- Narrow this to the OU where your groups/users reside to prevent full-tree scans
    "ldap_bind_base_dn" = "OU=Groups,DC=example,DC=com",
    
    -- Option A: Direct DN (Most efficient for a single group)
    "ldap_group_dn" = "CN=DP-Dev-DataAnalysts,OU=Groups,DC=example,DC=com",
    
    -- Option B: Filter (Only use if DN is unknown; fix & here)
    -- "ldap_group_filter" = "(&(objectClass=group)(cn=DP-Dev-DataAnalysts))",
    
    "ldap_group_identifier_attr" = "cn",
    "ldap_group_member_attr" = "member"
    
    -- IMPORTANT: For Microsoft AD, do NOT set ldap_user_search_attr.
    -- StarRocks will use the full DN to match users authenticated via LDAP.
);
Key Corrections Made: 1. Filter Syntax: Replaced 
&
with 
&
. LDAP servers do not understand HTML entities. 2. 
ldap_group_dn
: Switched to using the explicit Distinguished Name of the group. This is the "fast path" that avoids the search-and-iterate logic that triggers heavy logging. 3. 
ldap_bind_base_dn
: Ensure this points to the specific OU containing your groups, not the root of the domain (
DC=com
). 4. AD Compatibility: For Microsoft AD, omitting 
ldap_user_search_attr
is the standard practice. It allows StarRocks to match the user's login DN directly against the 
member
list in the group, which is significantly faster and more reliable than extracting UIDs. How to Apply: 1. If you already created a provider with the same name, you must 
DROP GROUP PROVIDER <name>;
first. 2. Run the DDL above with your specific server details. 3. Check the FE logs (
fe.log
). If you still see "huge logs," verify that your 
ldap_bind_base_dn
is as specific as possible. References • administration/user_privs/group_provider.md • administration/user_privs/authentication/security_integration.md
z
@Rocky no it still gets all the cns
r
If the system is still "reading all CNs" and producing massive logs, it typically means the LDAP search scope is too wide or the group members themselves are causing the log volume. Even with a filter, StarRocks performs a search starting from the 
ldap_bind_base_dn
. If that base is the root of your domain (e.g., 
DC=company,DC=com
), the LDAP server may still evaluate thousands of entries. To stop the full scan and the huge logs, use this Strict DDL which bypasses the search mechanism entirely: 1. Use 
ldap_group_dn
(The "No-Search" Method) Instead of asking StarRocks to "search for a group that matches this filter," tell it exactly where the group is. This is the most efficient method and prevents StarRocks from scanning other CNs.
Copy code
sql
CREATE GROUP PROVIDER ad_data_analysts
PROPERTIES (
    "type" = "ldap",
    "ldap_conn_url" = "<ldap://your-server:389>",
    "ldap_bind_root_dn" = "CN=ServiceAccount,OU=Users,DC=example,DC=com",
    "ldap_bind_root_pwd" = "your_password",
    
    -- Point this specifically to the OU where the group lives
    "ldap_bind_base_dn" = "OU=Groups,DC=example,DC=com",
    
    -- BYPASS SEARCH: Use the exact DN of the group
    "ldap_group_dn" = "CN=DP-Dev-DataAnalysts,OU=Groups,DC=example,DC=com",
    
    "ldap_group_identifier_attr" = "cn",
    "ldap_group_member_attr" = "member"
    
    -- DO NOT set ldap_user_search_attr if using Microsoft AD.
    -- This stops StarRocks from trying to resolve/extract every member's UID via a separate search.
);
2. Why the logs are still "huge" If you have already narrowed the group to just one, but the logs are still massive, the "huge logs" are likely coming from Member Synchronization: * The Problem: If 
DP-Dev-DataAnalysts
has 1,000+ members, StarRocks logs an entry for every single user it finds in that group during the cache refresh (default every 15 minutes). * The Fix: 1. Check your 
fe.conf
. If you have 
sys_log_level = DEBUG
or have enabled LDAP-specific debug logging, the FE will log every single LDAP entry it touches. Set 
sys_log_level = INFO
to quiet this down. 2. Increase the refresh interval to reduce frequency: 
"ldap_cache_refresh_interval" = "3600"
(1 hour). 3. Verify the 
ldap_bind_base_dn
 Ensure 
ldap_bind_base_dn
is not set to the root (e.g., 
DC=com
). If it is, StarRocks may still attempt a subtree search across your entire global catalog to resolve member DNs. Point it specifically to the OU containing your users or groups. Summary of Changes: 1. Delete the provider: 
DROP GROUP PROVIDER ad_data_analysts;
2. Re-create using 
ldap_group_dn
 instead of 
ldap_group_filter
. 3. Ensure 
ldap_user_search_attr
is omitted if you are on AD, as StarRocks v3.5.0+ handles DN-based matching much more efficiently without it. If you continue to see "Syncing group" or "Found entry" logs for groups you didn't specify, please check if there is another Group Provider or Security Integration active that is using a broader filter. References • administration/user_privs/group_provider.md • administration/user_privs/authentication/ldap_authentication.md • administration/management/monitoring/metrics.md
z
@Rocky in root_dn we have just email
r
If you are using an email address (UPN) for the 
ldap_bind_root_dn
, that is generally supported by Microsoft AD. However, for the sync to be efficient and stop "reading all CNs," the rest of the configuration must be precise. The "huge logs" and the "reading all CNs" behavior happen because StarRocks is likely performing a subtree search starting from a base that is too broad, or it is trying to resolve every member of a group individually. Here is the corrected DDL using an email for the root DN and the "No-Search" optimization: Corrected DDL
Copy code
sql
CREATE GROUP PROVIDER ad_data_analysts
PROPERTIES (
    "type" = "ldap",
    "ldap_conn_url" = "<ldap://your-ad-server:389>",
    
    -- It is fine to use an email/UPN here if your AD supports it
    "ldap_bind_root_dn" = "<mailto:service-account@example.com|service-account@example.com>",
    "ldap_bind_root_pwd" = "your_password",
    
    -- 1. MUST BE A FULL DN: Point this to the specific OU where the group is.
    -- If this is set to "DC=example,DC=com", StarRocks scans the whole domain.
    "ldap_bind_base_dn" = "OU=Groups,DC=example,DC=com",
    
    -- 2. USE DN INSTEAD OF FILTER: This stops StarRocks from "searching" 
    -- and tells it to "look up" this exact object.
    "ldap_group_dn" = "CN=DP-Dev-DataAnalysts,OU=Groups,DC=example,DC=com",
    
    "ldap_group_identifier_attr" = "cn",
    "ldap_group_member_attr" = "member"
    
    -- 3. REMOVE ldap_user_search_attr (For v3.5.0+ AD users)
    -- This prevents StarRocks from trying to 'extract' and 'verify' 
    -- every single user CN, which is what usually causes the huge logs.
);
Why this fixes the "Reading all CNs" and "Huge Logs": 1. 
ldap_group_dn
vs 
ldap_group_filter
: Using a filter triggers a search across the 
ldap_bind_base_dn
. If the base is broad, the LDAP server iterates through many objects. Using 
ldap_group_dn
performs a direct lookup of that one object. 2. 
ldap_bind_base_dn
: This must be a Distinguished Name (DN), not an email. Even if your 
root_dn
is an email, the 
base_dn
must be the LDAP path where the search starts. 3. The "Huge Logs" (Crucial): • If you are on StarRocks v3.5.0 or newer, do not set 
ldap_user_search_attr
. • When this is set, StarRocks tries to parse every member's DN to find a specific attribute (like 
uid
). This process often triggers additional searches or massive "Processing member..." log entries for every user in the group. • When omitted, StarRocks simply stores the member's full DN, which is much faster and quieter. If you still see logs: * Check log levels: In your 
fe.conf
, ensure 
sys_log_level = INFO
. If it is 
DEBUG
, StarRocks will log every LDAP interaction. * Check Refresh Interval: By default, it syncs every 15 minutes. You can slow this down with 
"ldap_cache_refresh_interval" = "3600"
. Note: If you get an "Object not found" error after using 
ldap_group_dn
, it means the DN string is slightly off (e.g., a missing space or incorrect OU). Copy the DN exactly from an LDAP browser or 
dsquery
. References • administration/user_privs/group_provider.md • administration/user_privs/authentication/ldap_authentication.md • administration/management/logs.md
z
@Rocky here is the ddl:
Copy code
CREATE GROUP PROVIDER `gp_ldaps_tbcuz` PROPERTIES (
"ldap_bind_root_pwd" = "***", "ldap_group_member_attr" = "member", "ldap_conn_url" = "***", "ldap_bind_root_dn" = "***", "ldap_bind_base_dn" = "DC=company,DC=loc", "ldap_group_dn" = "CN=DP-Dev-DataAnalysts,DC=company,DC=loc", "type" = "ldap", "ldap_group_identifier_attr" = "cn"
)
r
The DDL you provided is close, but the "reading all CNs" and "huge logs" behavior typically happens because StarRocks is performing a subtree search starting from your 
ldap_bind_base_dn
(
DC=company,DC=loc
), which is the root of your domain. Even though you specified 
ldap_group_dn
, StarRocks may still be using the 
base_dn
to resolve or validate objects. To stop the full-domain scan and the massive logs, you should make two specific changes: 1. Narrow the 
ldap_bind_base_dn
 Change the base DN from the root (
DC=company,DC=loc
) to the specific OU where your group (and ideally your users) resides. This restricts the "search area" for the LDAP connector. 2. Verify 
ldap_user_search_attr
is Omitted As seen in your DDL, you have correctly omitted 
ldap_user_search_attr
. This is vital for AD because it tells StarRocks to use the Full DN for matching rather than performing a separate search/extraction for every single member of the group. Corrected DDL
Copy code
sql
CREATE GROUP PROVIDER `gp_ldaps_tbcuz` PROPERTIES (
    "type" = "ldap",
    "ldap_conn_url" = "<ldap://your-host:389>",
    "ldap_bind_root_dn" = "<mailto:service-account@company.com|service-account@company.com>", 
    "ldap_bind_root_pwd" = "your_password",
    
    -- 1. FIX: Narrow this to the specific OU. 
    -- Do not use the root DC=company,DC=loc if you want to avoid full scans.
    "ldap_bind_base_dn" = "OU=Groups,DC=company,DC=loc", 
    
    -- 2. DIRECT LOOKUP: This bypasses the filter-search logic.
    "ldap_group_dn" = "CN=DP-Dev-DataAnalysts,OU=Groups,DC=company,DC=loc",
    
    "ldap_group_identifier_attr" = "cn",
    "ldap_group_member_attr" = "member"
    
    -- Note: Keep ldap_user_search_attr omitted for AD.
);
Why the logs are still huge (Troubleshooting): * Member Count: If 
DP-Dev-DataAnalysts
contains thousands of members, StarRocks logs the synchronization of each member. Since the default refresh is every 15 minutes, this creates a constant stream of logs. _ _Solution:* Add 
"ldap_cache_refresh_interval" = "3600"
(1 hour) to the PROPERTIES to reduce frequency. * Log Level: If your 
fe.conf
has 
sys_log_level = DEBUG
, every LDAP packet is logged. Ensure it is set to 
INFO
. * Nested Groups: If your group has many "sub-groups," AD may be expanding these, leading to more processing. Summary: The most effective way to stop the "reading all CNs" behavior is to move the 
ldap_bind_base_dn
away from the domain root and into the specific Organizational Unit (OU) where your target group is located. References • administration/user_privs/group_provider.md • administration/user_privs/authentication/ldap_authentication.md • administration/management/FE_configuration.md References • administration/management/FE_configuration.md • administration/user_privs/group_provider.md • administration/user_privs/authentication/ldap_authentication.md
z
@Rocky may be after changing params in group provider I need to restart or somethig? because it still reads via the same frequency
r
No, a restart is typically not required for changes made to a Group Provider if you are dropping and recreating it. However, because 
Group Provider
is a relatively new feature (v3.5.0+), here is why it might feel like nothing has changed: 1. There is no 
ALTER GROUP PROVIDER
 If you tried to change the parameters using an 
ALTER
statement, it likely didn't work because StarRocks does not currently support 
ALTER GROUP PROVIDER
. To apply new parameters (like a longer refresh interval or a specific DN), you must follow this sequence: 1. 
DROP GROUP PROVIDER gp_ldaps_tbcuz;
2. 
CREATE GROUP PROVIDER gp_ldaps_tbcuz PROPERTIES (...);
2. Synchronization vs. Authentication Logs If you successfully recreated the provider with a longer 
ldap_cache_refresh_interval
(e.g., 
3600
for 1 hour) but still see frequent logs, you may be looking at Authentication logs rather than Sync logs: * Synchronization (Background Task): Happens every X seconds based on 
ldap_cache_refresh_interval
. This is what scans the group members into the FE cache. * Authentication (User Login): Happens every time a user or a tool (like Grafana, DBeaver, or a script) attempts to connect. StarRocks must verify the user's credentials and check their group membership against the provider at that moment. * The Fix: If the logs are caused by frequent logins, changing the sync interval won't help. You would need to check if a service account is hammering the FE or lower the 
sys_log_level
in 
fe.conf
to 
INFO
. 3. Are there multiple providers? Run this command to ensure you don't have a second provider running with the old "root" configuration:
Copy code
sql
SHOW GROUP PROVIDERS;
If you see more than one LDAP provider, they might both be triggering searches. 4. When to Restart While recreating the object should reset the background task, if you've tried everything and the FE is still behaving as if the old "root" search is active, a rolling restart of the FEs will force the internal task scheduler to clear all stale LDAP handles and restart the refresh timers with the new configuration. Checklist to stop the "Reading all CNs" behavior: 1. Drop and Recreate: Ensure you actually dropped the old one. 2. Verify Base DN: Ensure 
ldap_bind_base_dn
is a specific OU, not 
DC=company,DC=loc
. 3. Check Sync Interval: Use 
"ldap_cache_refresh_interval" = "3600"
. 4. Confirm logs: If the log says 
[LDAP] sync group...
, it's the background task. If it says 
[LDAP] authenticate user...
, it's a login event. References • administration/user_privs/group_provider.md • administration/management/FE_configuration.md • administration/user_privs/authentication/ldap_authentication.md References • administration/user_privs/authentication/ldap_authentication.md • administration/user_privs/group_provider.md • administration/management/FE_configuration.md • administration/user_privs/authorization/ranger_plugin.md
z
@Rocky LDAPGroupProvider.matchUserAndUpdateGroups():205
r
The log entry 
LDAPGroupProvider.matchUserAndUpdateGroups():205
confirms that the logs you are seeing are coming from the matching logic (authentication/authorization flow), not the background refresh task. This explains why changing the 
ldap_cache_refresh_interval
did not stop the frequency; that parameter only controls how often StarRocks queries your LDAP server to update its local cache of group members. The logs you are seeing happen every time a user (or a tool) interacts with StarRocks and the system needs to verify which groups that user belongs to. Why this is happening 1. On-Demand Matching: 
matchUserAndUpdateGroups
is called whenever a user authenticates or when their session privileges need to be resolved. If you have a tool (like Grafana, DBeaver, or a monitoring script) that opens a new connection or executes queries frequently, this method runs every time. 2. Iterative Search: At line 205, StarRocks is likely iterating through the cached members of your group (
CN=DP-Dev-DataAnalysts...
) to see if the logging-in user's DN matches any of them. If the group is large, this "Reading all CNs" behavior is simply the code looping through the list in memory. 3. Multiple Providers: If you have multiple Group Providers defined, StarRocks will run this match logic for every provider for every login, which multiplies the log volume. How to fix the "High Frequency" logs 1. Check for "Login Storms" Check your FE audit log (
fe.audit.log
). If you see a high frequency of 
Connect
or 
Login
events from the same user/IP, a tool is likely not using a connection pool. Each new connection triggers the LDAP group matching logic. 2. Adjust Log Levels If the system is working correctly but the logs are simply too noisy, you can suppress them by adjusting the log level for that specific class without restarting the whole FE. Run this in your MySQL client:
Copy code
sql
-- This will set the LDAP Group Provider logs to WARN, 
-- silencing the INFO/DEBUG logs at line 205.
ADMIN SET FRONTEND CONFIG ("sys_log_level" = "WARN");
-- Note: This affects all logs. 
-- To target only the LDAP class, you usually need to edit fe.conf 
-- and restart, or use the logging API if available.
3. Consolidate Providers Run 
SHOW GROUP PROVIDERS;
. If you have old or duplicate providers (e.g., one pointing to the root 
DC=company,DC=loc
and one pointing to a specific OU), drop the ones you don't need. StarRocks evaluates all of them. 4. Verify v3.5.0+ Optimization If you are on a version earlier than v3.5.0, the LDAP Group Provider was more "expensive" and noisier. In v3.5.0, StarRocks introduced the "DN Matching" optimization (which your DDL is already set up to use by omitting 
ldap_user_search_attr
). If you are on an older version, upgrading to v3.5.x is the primary way to reduce this overhead. Summary * The "Reading all CNs" is the in-memory matching of the user against the group list. * The "Frequency" is driven by user activity/logins, not the refresh interval. * The solution is to either reduce login frequency from your client tools or set 
sys_log_level
to 
WARN
to hide these specific log lines. References • administration/user_privs/group_provider.md • administration/management/FE_configuration.md • administration/user_privs/authentication/ldap_authentication.md • administration/management/logs.md • administration/user_privs/authorization/ranger_plugin.md References • administration/user_privs/group_provider.md
z
@Rocky so I guess I need to narrow down security integrations base_dn as well?
r
Yes, absolutely. To fully resolve the "reading all CNs" behavior and stop the excessive logs during logins, you should narrow down the Security Integration 
base_dn
as well. Why this is necessary While the Group Provider controls how StarRocks syncs group members, the Security Integration controls how StarRocks finds the user when they first connect. * Group Provider: "Where do I look for group 
DP-Dev-DataAnalysts
and its members?" * Security Integration: "Where do I look for the user 
john_doe
who is trying to log in right now?" If your Security Integration's 
authentication_ldap_simple_bind_base_dn
is still set to the root (
DC=company,DC=loc
), StarRocks will perform a subtree search of your entire domain every time a user or a service (like Grafana/DBeaver) attempts to connect. This is exactly what causes the high-frequency logs at the 
matchUserAndUpdateGroups
step. How to narrow it down You can update your existing Security Integration without dropping it using the 
ALTER
statement:
Copy code
sql
ALTER SECURITY INTEGRATION `your_integration_name` SET (
    -- Narrow this to the specific OU where your users are located
    "authentication_ldap_simple_bind_base_dn" = "OU=DataDept,OU=Users,DC=company,DC=loc"
);
Additional Tips to stop the "Login Storm" If you still see many logs after narrowing the DN, check these two things: 1. Check `authentication_chain`: Ensure you don't have multiple LDAP integrations in your chain that are both searching the same tree.
Copy code
sql
    ADMIN SHOW FRONTEND CONFIG LIKE 'authentication_chain';
2. Verify the User Search Attribute: Ensure 
authentication_ldap_simple_user_search_attr
is set to the specific attribute your users log in with (usually 
sAMAccountName
for AD or 
uid
for OpenLDAP). This allows the LDAP server to find the user immediately rather than scanning multiple attributes. Summary: By narrowing the 
base_dn
in both the Group Provider and the Security Integration, you restrict StarRocks to specific "containers" in your AD, which drastically reduces the search scope, speeds up logins, and stops the massive log output. References • administration/user_privs/authentication/security_integration.md • administration/user_privs/group_provider.md • administration/user_privs/authentication/ldap_authentication.md References • administration/user_privs/authentication/security_integration.md • administration/user_privs/group_provider.md
z
@Rocky give me ddls for bot security integration and group provicder
r
To narrow down the search scope and stop the "reading all CNs" behavior, you should use specific OUs in your 
base_dn
for both the Security Integration and the Group Provider. Here are the DDLs designed for a high-performance, narrow-scope setup (standard for Microsoft AD). 1. The Security Integration DDL This handles the user login. By narrowing the 
base_dn
to the specific OU where your users are located, you prevent StarRocks from searching your entire company directory during every login.
Copy code
sql
CREATE SECURITY INTEGRATION ldap_login_integration
PROPERTIES (
    "type" = "authentication_ldap_simple",
    "authentication_ldap_simple_server_host" = "<http://ldap.company.com|ldap.company.com>",
    "authentication_ldap_simple_server_port" = "389",
    -- NARROW SCOPE: Point directly to the Users OU
    "authentication_ldap_simple_bind_base_dn" = "OU=DataUsers,DC=company,DC=loc",
    "authentication_ldap_simple_user_search_attr" = "sAMAccountName",
    "authentication_ldap_simple_bind_root_dn" = "CN=ServiceAccount,OU=ServiceAccounts,DC=company,DC=loc",
    "authentication_ldap_simple_bind_root_pwd" = "your_password",
    -- LINK TO PROVIDER: This triggers the group matching on login
    "group_provider" = "ad_group_provider"
);
2. The Group Provider DDL This handles the permission mapping. By narrowing the 
ldap_bind_base_dn
to your Groups OU and using a specific 
ldap_group_filter
, the background sync task only processes what is necessary.
Copy code
sql
CREATE GROUP PROVIDER ad_group_provider 
PROPERTIES(
    "type" = "ldap", 
    "ldap_conn_url" = "<ldap://ldap.company.com:389>",
    "ldap_bind_root_dn" = "CN=ServiceAccount,OU=ServiceAccounts,DC=company,DC=loc",
    "ldap_bind_root_pwd" = "your_password",
    -- NARROW SCOPE: Point directly to the Groups OU
    "ldap_bind_base_dn" = "OU=DataGroups,DC=company,DC=loc",
    -- TARGETED FILTER: Only look for the specific group needed
    "ldap_group_filter" = "(&(objectClass=group)(cn=DP-Dev-DataAnalysts))",
    "ldap_group_identifier_attr" = "cn",
    "ldap_group_member_attr" = "member",
    -- OPTIMIZATION: Omit ldap_user_search_attr to use "DN Matching" (recommended for AD)
    "ldap_cache_refresh_interval" = "3600"
);
3. Final Step: Enable the Integration Once these are created, you must tell StarRocks to actually use the Security Integration for incoming connections by updating the FE configuration:
Copy code
sql
ADMIN SET FRONTEND CONFIG ("authentication_chain" = "ldap_login_integration, native");
Why this setup stops the "Reading all CNs" logs: 1. Security Integration narrow DN: During login, StarRocks only looks inside 
OU=DataUsers
instead of the root 
DC=company
. 2. Group Provider narrow DN: During the background refresh, StarRocks only looks inside 
OU=DataGroups
. 3. DN Matching: By omitting 
ldap_user_search_attr
in the Group Provider, StarRocks matches the user's Distinguished Name directly. It doesn't have to perform additional LDAP queries or string parsing to figure out who "John Doe" is once he is authenticated. 4. Linked Execution: The 
group_provider
property in the Security Integration ensures that the matching only happens for that specific provider's cached data. References • administration/user_privs/authentication/security_integration.md • administration/user_privs/group_provider.md • administration/user_privs/authentication/ldap_authentication.md References • administration/user_privs/group_provider.md • administration/user_privs/authentication/security_integration.md
4 Views
Open in Slack
PreviousNext
Powered by