How to create LDAP users authorisation based on sub groups

@sscarduzio,
Waiting for your response. Is there any mistake in configuration.  

- name: "ABC GROUP BUISSNESS"
      ldap_authentication:
        name: "ldap1"  
        cache_ttl_in_sec: 60
      #ldap_authorization:
       # name: "ldap1"
        #groups: ["Technology"]
        #cache_ttl_in_sec: 60
      #indices: [".kibana","index1","logstash-*"]
      
    - name: "ABC GROUP DEVELOPMENT"
      ldap_authentication:
        name: "ldap2"  
        cache_ttl_in_sec: 60
      #ldap_authorization:
       # name: "ldap2"
        #groups: ["Development"]
        #cache_ttl_in_sec: 60
      #indices: [".kibana","index2","logstash-*"]

Uncommented code is working fine. But we need authorisation also. As told @ld57 we have removed  cache_ttl_in_sec.
Also we have added all OU groups in groups section array. Like below also tried.
groups: ["Technology","Corporate Technology","Corporate Group","Mumbai abcHouse"]
@sscarduzio,
Extra logs.
   [2018-06-25T17:03:05,713][DEBUG][t.b.r.a.d.l.l.AuthenticationLdapClientLoggingDecorator] Trying to fetch user with identifier [c-ajitb] from LDAP [ldap2]
[2018-06-25T17:03:05,713][DEBUG][t.b.r.a.d.l.l.AuthenticationLdapClientLoggingDecorator] User with identifier [c-ajitb] found [dn = CN=c-AjitB,OU=Development,OU=XYZ – Corporate functions,OU=XYZ,OU=Mumbai Airoli XYZ,DC=ad,DC=ABC,DC=com]
[2018-06-25T17:03:05,713][DEBUG][t.b.r.a.d.l.l.GroupsProviderLdapClientLoggingDecorator] Trying to fetch user [id=c-ajitb, dnCN=c-AjitB,OU=Development,OU=XYZ – Corporate functions,OU=XYZ,OU=Mumbai Airoli XYZ,DC=ad,DC=ABC,DC=com] groups from LDAP [ldap2]
[2018-06-25T17:03:05,713][DEBUG][t.b.r.a.d.l.l.GroupsProviderLdapClientLoggingDecorator] LDAP [ldap2] returned for user [c-ajitb] following groups: []
[2018-06-25T17:03:05,713][DEBUG][t.b.r.a.b.Block          ] e[33m[RULE2] the request matches no rules in this block: { ID:1410670628-1923610630#16229, TYP:NodesInfoRequest, CGR:N/A, USR:c-ajitb, BRS:false, KDX:null, ACT:cluster:monitor/nodes/info, OA:172.21.153.176, DA:172.21.153.176, IDX:<N/A>, MET:GET, PTH:/_nodes/_local, CNT:<N/A>, HDR:{authorization=Basic Yy1haml0YjpwYXNzIzEyMzQ=, Connection=close, content-length=0, Host=mumchelk01:9200}, HIS:[::admin::->[auth_key->false]], [::LOGSTASH::->[auth_key->false]], [::KIBANA-SRV::->[auth_key->false]], [RULE1->[ldap_authentication->false]], [RULE2->[ldap_authorization->false, ldap_authentication->true, indices->true, actions->true]] }e[0m
[2018-06-25T17:03:05,714][DEBUG][r.suppressed             ] path: /_nodes/_local, params: {settings_filter=transport.profiles.*.xpack.security.ssl.trust_restrictions,xpack.notification.email.account.*.smtp.password,xpack.notification.jira.account.*.secure_user,xpack.security.transport.ssl.key,xpack.ssl.trust_restrictions.path,xpack.ssl.keystore.password,xpack.security.transport.ssl.truststore.algorithm,xpack.security.http.ssl.truststore.password,xpack.security.http.ssl.keystore.password,xpack.http.ssl.certificate,xpack.security.transport.ssl.truststore.password,xpack.security.authc.realms.*.certificate_authorities,xpack.http.ssl.truststore.algorithm,transport.profiles.*.xpack.security.ssl.certificate_authorities,xpack.security.http.ssl.supported_protocols,xpack.security.authc.realms.*.ssl.key_passphrase,xpack.ssl.keystore.path,xpack.security.transport.ssl.supported_protocols,xpack.notification.jira.account.*.user,xpack.security.http.ssl.truststore.algorithm,xpack.notification.jira.account.*.secure_password,xpack.ssl.certificate_authorities,transport.profiles.*.xpack.security.ssl.keystore.password,xpack.ssl.truststore.path,xpack.security.transport.ssl.keystore.key_password,xpack.notification.jira.account.*.url,xpack.security.http.ssl.key,xpack.security.http.ssl.keystore.type,xpack.security.http.ssl.verification_mode,xpack.security.authc.realms.*.ssl.trust_restrictions.path,xpack.ssl.certificate,xpack.security.authc.realms.*.ssl.keystore.type,transport.profiles.*.xpack.security.ssl.supported_protocols,xpack.security.authc.realms.*.ssl.keystore.path,xpack.ssl.verification_mode,xpack.security.authc.realms.*.ssl.certificate,xpack.security.transport.ssl.cipher_suites,transport.profiles.*.xpack.security.ssl.truststore.path,xpack.security.http.ssl.certificate,xpack.ssl.truststore.type,xpack.security.authc.realms.*.ssl.keystore.algorithm,xpack.ssl.cipher_suites,xpack.http.ssl.keystore.type,xpack.security.http.ssl.certificate_authorities,xpack.http.ssl.keystore.algorithm,transport.profiles.*.xpack.security.ssl.truststore.type,xpack.ssl.truststore.algorithm,transport.profiles.*.xpack.security.ssl.cipher_suites,xpack.http.ssl.supported_protocols,xpack.http.ssl.keystore.path,xpack.security.authc.realms.*.encryption.keystore.algorithm,xpack.security.authc.realms.*.ssl.keystore.key_password,xpack.notification.hipchat.account.*.secure_auth_token,xpack.security.http.ssl.truststore.path,xpack.security.authc.realms.*.encryption.keystore.path,xpack.http.ssl.truststore.password,xpack.security.authc.realms.*.ssl.truststore.algorithm,xpack.security.authc.realms.*.ssl.truststore.type,xpack.security.transport.ssl.verification_mode,xpack.security.authc.realms.*.signing.keystore.type,xpack.notification.pagerduty.account.*.secure_service_api_key,xpack.security.transport.ssl.certificate,xpack.security.authc.realms.*.encryption.keystore.type,xpack.monitoring.exporters.*.auth.*,xpack.ssl.keystore.type,xpack.http.ssl.key,xpack.security.authc.realms.*.bind_dn,xpack.security.authc.realms.*.ssl.truststore.password,xpack.http.ssl.keystore.key_password,xpack.security.authc.realms.*.signing.key,xpack.ssl.keystore.key_password,transport.profiles.*.xpack.security.ssl.truststore.password,xpack.http.ssl.verification_mode,transport.profiles.*.xpack.security.ssl.certificate,transport.profiles.*.xpack.security.ssl.verification_mode,xpack.security.http.ssl.keystore.key_password,transport.profiles.*.xpack.security.*,xpack.security.authc.realms.*.ssl.keystore.password,xpack.security.authc.realms.*.ssl.cipher_suites,transport.profiles.*.xpack.security.ssl.keystore.key_password,xpack.monitoring.exporters.*.ssl,xpack.http.ssl.truststore.path,xpack.http.ssl.key_passphrase,xpack.security.http.ssl.cipher_suites,xpack.notification.pagerduty.account.*.service_api_key,xpack.security.authc.realms.*.hostname_verification,transport.profiles.*.xpack.security.ssl.truststore.algorithm,xpack.security.transport.ssl.truststore.type,xpack.security.authc.realms.*.truststore.algorithm,xpack.security.transport.ssl.certificate_authorities,xpack.http.ssl.keystore.password,xpack.security.transport.ssl.keystore.path,xpack.security.authc.realms.*.encryption.key,xpack.http.ssl.trust_restrictions.path,xpack.security.authc.realms.*.bind_password,xpack.security.authc.realms.*.ssl.supported_protocols,xpack.security.transport.ssl.truststore.path,xpack.security.transport.ssl.trust_restrictions.path,xpack.security.http.ssl.truststore.type,xpack.security.http.ssl.key_passphrase,xpack.ssl.truststore.password,xpack.http.ssl.certificate_authorities,xpack.security.http.ssl.trust_restrictions.path,xpack.security.authc.realms.*.ssl.key,xpack.security.authc.realms.*.ssl.verification_mode,xpack.http.ssl.truststore.type,xpack.security.transport.ssl.keystore.type,transport.profiles.*.xpack.security.ssl.keystore.algorithm,xpack.security.http.ssl.keystore.algorithm,xpack.notification.slack.account.*.url,xpack.notification.jira.account.*.secure_url,xpack.security.authc.realms.*.ssl.truststore.path,xpack.ssl.key_passphrase,xpack.security.authc.realms.*.signing.keystore.path,xpack.security.transport.ssl.client_authentication,xpack.notification.hipchat.account.*.auth_token,xpack.notification.jira.account.*.password,transport.profiles.*.xpack.security.ssl.key,xpack.security.transport.ssl.keystore.password,xpack.http.ssl.client_authentication,xpack.security.transport.ssl.key_passphrase,xpack.monitoring.exporters.*.auth.password,xpack.security.transport.ssl.keystore.algorithm,transport.profiles.*.xpack.security.ssl.keystore.type,xpack.monitoring.exporters.*.ssl.*,xpack.security.hide_settings,xpack.ssl.key,xpack.security.authc.realms.*.ssl.certificate_authorities,xpack.notification.slack.account.*.secure_url,transport.profiles.*.xpack.security.ssl.client_authentication,xpack.security.authc.realms.*.truststore.password,transport.profiles.*.xpack.security.ssl.keystore.path,xpack.security.http.ssl.keystore.path,xpack.ssl.supported_protocols,xpack.http.ssl.cipher_suites,xpack.security.authc.realms.*.ssl.client_authentication,xpack.security.authc.realms.*.signing.certificate,xpack.security.authc.realms.*.encryption.certificate,xpack.monitoring.exporters.*.auth.username,xpack.security.authc.realms.*.truststore.path,xpack.security.http.ssl.client_authentication,xpack.security.authc.accept_default_password,xpack.security.authc.realms.*.signing.keystore.algorithm,xpack.ssl.client_authentication,xpack.ssl.keystore.algorithm,transport.profiles.*.xpack.security.ssl.key_passphrase, nodeId=_local}
tech.beshu.ror.es.IndexLevelActionFilter$1$1: forbidden
Hi @sscarduzio,

Are you checking logs. Or are we doing something wrong in configuration.? Please reply ASAP.
We are stuck in authorisation now. Please help us to authorise users (LDAP) users.

I’m working on a proof of concept to show you a similar configuration to what you want. That would be more efficient than going back and forth with settings.

    Hi Simone Scarduzio,

    ok,we are waiting for new Configuration for proceeding further work process.
    May we know the Approx time,when we will get new configuration.
    is our requirement possible with previous Configuration Or not??

   are you giving new build or we have to change the configuration in existing build? 
   if you are going to give us new build then how much time it will take??
   please reply us ASAP.

@Akhilesh, give me one, max two days.

Hi @sscarduzio,

      bind_dn: "CN=c-ajitb,OU=Development,OU=Mercator – Corporate functions,OU=Mercator,OU=Mumbai Airoli Mercator,DC=ad,DC=crisil,DC=com"                   
      bind_password: "abc1234"                               
      search_user_base_DN: "OU=Development,OU=Mercator – Corporate functions,OU=Mercator,OU=Mumbai Airoli Mercator,DC=ad,DC=crisil,DC=com"
      search_groups_base_DN: "OU=Development,OU=Mercator – Corporate functions,OU=Mercator,OU=Mumbai Airoli Mercator,DC=ad,DC=crisil,DC=com"
      user_id_attribute: "sAMAccountName"               
      unique_member_attribute: "uniqueMember"       

In this Bind DN all Development team is able to login by using his/her LDAP Credentials because they are belongs to the same LDAP Group (CN=c-ajitb,OU=Development,OU=Mercator – Corporate functions,OU=Mercator,OU=Mumbai Airoli Mercator,DC=ad,DC=crisil,DC=com), but I want to give login access to some(One or Two) specific users. please let us know how it is possible?
In above configuration suppose,in bind_dn I have given c-ajitb user But I want to restrict c-amitkum user. Currently All users in this group are able to login.

Note: Access of index to a particular group is a different scenario and this requirement is different.
please don’t confuse Both are our requirement.

Hi @sscarduzio,

Please let us know when we will get new build for configuration. We have another requirement.
1. multiple ldap with multiple groups and with different index access for per group. As discussed with you earlier, you are working on the same.

2.  We have another requirement as @Akhilesh told you above. We need specific user access only. Currently in one group all users accessible kibana and index. But we want to restrict some users from same group.
e.g. 
CN=c-ajitb,OU=Development,OU=XYZ – Corporate functions,OU=XYZ,OU=Mumbai Airoli XYZ,DC=ad,DC=example,DC=com  

CN=c-amitkum,OU=Development,OU=XYZ – Corporate functions,OU=XYZ,OU=Mumbai Airoli XYZ,DC=ad,DC=example,DC=com  
 
These two users are from same group but I want to restrict one user i.e. c-ajitb and only c-amitkum user should be accessible.

I have tried group_search_filter but its not working for me.

So some update: I just committed some enhancements that enables ROR to mix local groups and LDAP authorization without ambiguity.

I shall release a pre build tonight, so you can test configurations like such:

  access_control_rules:
    - name: "CONTAINER ADMIN"
      type: allow
      auth_key: admin:container

    - name: "::Tweets::" #allowed to cartman
      indices: ["twitter"]
      groups: ["local_group1"]
      ldap_authorization:
        name: "ldap1"
        groups: ["group1"]

    - name: "::Facebook posts::" #allowed to morgan
      indices: ["facebook"]
      ldap_authorization:
        name: "ldap1"
        groups: ["group3"]
      groups: ["local_group3"]


    users:
    - username: cartman
      groups: ["local_group1"]
      ldap_authentication: "ldap1"

    - username: morgan
      groups: ["local_group3"]
      ldap_authentication: "ldap1"


    ldaps:
    ######### LDAP1 SERVER CONFIGURATION ########################
    # group1: cartman, bong
    # group2: morgan
    # group3: morgan, cartman, bong
    #############################################################
    - name: ldap1
      host: 127.0.0.1
      port: 32770                                                 # default 389
      ssl_enabled: false
      ssl_trust_all_certs: true                                 # default false
      bind_dn: "cn=admin,dc=example,dc=com"                     # skip for anonymous bind
      bind_password: "password"                                 # skip for anonymous bind
      search_user_base_DN: "ou=People,dc=example,dc=com"
      search_groups_base_DN: "ou=Groups,dc=example,dc=com"
      user_id_attribute: "uid"                                  # default "uid"
      unique_member_attribute: "uniqueMember"                   # default "uniqueMember"
      connection_pool_size: 10                                  # default 30
      connection_timeout_in_sec: 10                             # default 1
      request_timeout_in_sec: 10                                # default 1
      cache_ttl_in_sec: 0                                      # default 0 - cache disabled

@ajit, @Akhilesh in the meanwhile please take the time to observe how the above satisfies your requirements:

  1. Users are authenticated via LDAP
  2. You can associate each user to a different LDAP server/preset
  3. You can associate an indices rule to a group
  4. You can associate an indices rule to a single user too if required (ask me how to do this, if necessary).

Hi @sscarduzio,

In this Configuration given by you,we have to add the entry of users for login one by one and users is Authenticate but not Authorized so it is not working.
suppose if we have 6-8 LDAP Groups and each group contains 300-400 users then adding of users is a complicated task.

Please Understand the Requirements-

1) users should be login in Kibana using his LDAP Credentials,we don’t want to add users one by one in Configuration file.

2) if one LDAP Group having 300 users and we want to restrict some users of that group then how it is possible? Actually we have already tried few concepts like “user_search_filter” and “group_search_filter” but we have not got success.

3) Specific index should be Authorized for Specific LDAP Groups.

readonlyrest:

    ssl:
      enable: true
      keystore_file: "/opt/READONLYREST/elasticsearch-6.3.0/config/keystore.jks"
      keystore_pass: readonlyrest
      key_pass: readonlyrest
      key_alias: elk01    #This is needed only when the keystore has multiple entries
    audit_collector: true

    access_control_rules:

    - name: "::admin::"
      auth_key: admin:admin

    - name: "::LOGSTASH::"
      auth_key: logstash:logstash
      actions: ["indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create"]
      indices: ["logstash-*"]

    - name: "::KIBANA-SRV::"
      auth_key: kibana:kibana
      verbosity: error

    - name: "ABC GROUP BUISSNESS"
      ldap_authentication:
        name: "ldap1"  
        cache_ttl_in_sec: 60
      #ldap_authorization:
       # name: "ldap1"
        #groups: ["Technology"]
        #cache_ttl_in_sec: 60
      #indices: [".kibana","index1","logstash-*"]
      
    - name: "ABC GROUP DEVELOPMENT"
      ldap_authentication:
        name: "ldap2"  
        cache_ttl_in_sec: 60
      #ldap_authorization:
       # name: "ldap2"
        #groups: ["Development"]
        #cache_ttl_in_sec: 60
      #indices: [".kibana","index2","logstash-*"]
    
 
    ldaps:
    
    - name: ldap1
      host: "ad.abc.com"
      port: 389                                                 
      ssl_enabled: false                                        
      ssl_trust_all_certs: true                                
      bind_dn: "CN=c-abcd,OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"                    
      bind_password: "abc@2018"                                 
      search_user_base_DN: "OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"
      search_groups_base_DN: "OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"
      user_id_attribute: "sAMAccountName"                                  
      unique_member_attribute: "uniqueMember"                   
      connection_pool_size: 10                                  
      connection_timeout_in_sec: 10                             
      request_timeout_in_sec: 10                                
      cache_ttl_in_sec: 60
      
      
    - name: ldap2
      host: "ad.abc.com"
      port: 389                                                 
      ssl_enabled: false                                        
      ssl_trust_all_certs: true                                 
      bind_dn: "CN=c-ajitb,OU=Development,OU=abc – Corporate functions,OU=Mercator,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"                    
      bind_password: "pass#1234"                                 
      search_user_base_DN: "OU=Development,OU=abc – Corporate functions,OU=abc,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"
      search_groups_base_DN: "OU=Development,OU=abc – Corporate functions,OU=abc,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"
      user_id_attribute: "sAMAccountName"                                  
      unique_member_attribute: "uniqueMember"                   
      connection_pool_size: 10                                  
      connection_timeout_in_sec: 10                           
      request_timeout_in_sec: 10                                
      cache_ttl_in_sec: 60

Please Note that:
1. using this Configuration we have Achieved Our “First Requirement” (No need to add user one by one) but problem is in the index Authorization.

2. This configuration is working fine for Authentication with different ldap groups but if we uncomment these lines from our above file-

               #ldap_authorization:
                    # name: "ldap1"
                    #groups: ["Technology"]
                    #cache_ttl_in_sec: 60
                #indices: [".kibana","index1","logstash-*"]
                  
              
                  #ldap_authorization:
                      # name: "ldap2"
                      #groups: ["Development"]
                      #cache_ttl_in_sec: 60
                  #indices: [".kibana","index2","logstash-*"]

Then we are getting unauthorized exception on login screen.

so please Focus on LDAP Group wise index Authorization and Restrictions of user in a specific group for login.

Yes as I told you, you need the new code. So here is the version of theElasticsearch 6.3.0 plugin 1.16.22-pre1 with the latest changes.

Remember that what I gave you is a proof of concept to demonstrate that “per LDAP user” permission granularity is possible.
If you have 300 users, I suppose those 300 users don’t need a different indices permission policy for each and every one of them. Then it’s easy. You can configure them like all other ROR customers. For example:

 - name: 'Grant RO Kibana access to a LDAP group of my 300 users'
   kibana_access: ro
   indices: [".kibana", "logstash_stuff_theycansee-*"]
   ldap_authentication: "ldap1"  
   ldap_authorization:
     name: "ldap1"                                       # ldap name from 'ldaps' section
     groups: ["ldap_group_with_300_users"]

What’s the problem?

Hi,

which configuration we can use for new build:

access_control_rules:
    - name: "CONTAINER ADMIN"
      type: allow
      auth_key: admin:container

    - name: "::Tweets::" #allowed to cartman
      indices: ["twitter"]
      groups: ["local_group1"]
      ldap_authorization:
        name: "ldap1"
        groups: ["group1"]

    - name: "::Facebook posts::" #allowed to morgan
      indices: ["facebook"]
      ldap_authorization:
        name: "ldap1"
        groups: ["group3"]
      groups: ["local_group3"]


    users:
    - username: cartman
      groups: ["local_group1"]
      ldap_authentication: "ldap1"

    - username: morgan
      groups: ["local_group3"]
      ldap_authentication: "ldap1"


    ldaps:
    ######### LDAP1 SERVER CONFIGURATION ########################
    # group1: cartman, bong
    # group2: morgan
    # group3: morgan, cartman, bong
    #############################################################
    - name: ldap1
      host: 127.0.0.1
      port: 32770                                                 # default 389
      ssl_enabled: false
      ssl_trust_all_certs: true                                 # default false
      bind_dn: "cn=admin,dc=example,dc=com"                     # skip for anonymous bind
      bind_password: "password"                                 # skip for anonymous bind
      search_user_base_DN: "ou=People,dc=example,dc=com"
      search_groups_base_DN: "ou=Groups,dc=example,dc=com"
      user_id_attribute: "uid"                                  # default "uid"
      unique_member_attribute: "uniqueMember"                   # default "uniqueMember"
      connection_pool_size: 10                                  # default 30
      connection_timeout_in_sec: 10                             # default 1
      request_timeout_in_sec: 10                                # default 1
      cache_ttl_in_sec: 0        

This One OR

    ssl:
      enable: true
      keystore_file: "/opt/READONLYREST/elasticsearch-6.3.0/config/keystore.jks"
      keystore_pass: readonlyrest
      key_pass: readonlyrest
      key_alias: elk01    #This is needed only when the keystore has multiple entries
    audit_collector: true

    access_control_rules:

    - name: "::admin::"
      auth_key: admin:admin

    - name: "::LOGSTASH::"
      auth_key: logstash:logstash
      actions: ["indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create"]
      indices: ["logstash-*"]

    - name: "::KIBANA-SRV::"
      auth_key: kibana:kibana
      verbosity: error

    - name: "ABC GROUP BUISSNESS"
      ldap_authentication:
        name: "ldap1"  
        cache_ttl_in_sec: 60
      #ldap_authorization:
       # name: "ldap1"
        #groups: ["Technology"]
        #cache_ttl_in_sec: 60
      #indices: [".kibana","index1","logstash-*"]
      
    - name: "ABC GROUP DEVELOPMENT"
      ldap_authentication:
        name: "ldap2"  
        cache_ttl_in_sec: 60
      #ldap_authorization:
       # name: "ldap2"
        #groups: ["Development"]
        #cache_ttl_in_sec: 60
      #indices: [".kibana","index2","logstash-*"]
    
 
    ldaps:
    
    - name: ldap1
      host: "ad.abc.com"
      port: 389                                                 
      ssl_enabled: false                                        
      ssl_trust_all_certs: true                                
      bind_dn: "CN=c-abcd,OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"                    
      bind_password: "abc@2018"                                 
      search_user_base_DN: "OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"
      search_groups_base_DN: "OU=Technology,OU=Corporate Technology,OU=Corporate Group,OU=Mumbai abc House,DC=ad,DC=abc,DC=com"
      user_id_attribute: "sAMAccountName"                                  
      unique_member_attribute: "uniqueMember"                   
      connection_pool_size: 10                                  
      connection_timeout_in_sec: 10                             
      request_timeout_in_sec: 10                                
      cache_ttl_in_sec: 60
      
      
    - name: ldap2
      host: "ad.abc.com"
      port: 389                                                 
      ssl_enabled: false                                        
      ssl_trust_all_certs: true                                 
      bind_dn: "CN=c-ajitb,OU=Development,OU=abc – Corporate functions,OU=Mercator,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"                    
      bind_password: "pass#1234"                                 
      search_user_base_DN: "OU=Development,OU=abc – Corporate functions,OU=abc,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"
      search_groups_base_DN: "OU=Development,OU=abc – Corporate functions,OU=abc,OU=Mumbai Airoli abc,DC=ad,DC=abc,DC=com"
      user_id_attribute: "sAMAccountName"                                  
      unique_member_attribute: "uniqueMember"                   
      connection_pool_size: 10                                  
      connection_timeout_in_sec: 10                           
      request_timeout_in_sec: 10                                
      cache_ttl_in_sec: 60

This One

Hi @sscarduzio,

What about Restriction of users.
how to restrict the user for login in a specific LDAP group?

suppose, if one LDAP Group having 300 users and we want to restrict some users of that group then how it is possible? Actually we have already tried few concepts like “user_search_filter” and “group_search_filter” but we have not got success.
if we are not apply any Search_Filters then we have to give the entry in our configuration file for that user which i want to give access for login.

Please Note That:
I am talking about restriction for Login not the indices Permission to the particular user.

AFAIK being very specific on what users to authenticate or not sounds very much what LDAP groups (within an LDAP Server) were designed for, right? No offence, but why ROR should solve an LDAP (well solved) problem?

Maybe it’s worth having a meeting with the LDAP administrators?

Anyways, I’m not an LDAP guru, but there might be a way to specify a LDAP query that includes an explicit list of “authenticatable” users. Maybe this can be the output of the above mentioned meeting?

Hi @Akhilesh ,

why not simply defining a security group dedicated for each rule blocks you would like to define ?
I mean instead of using an existing one.

also on my side, someone who is member of the domain is able to authenticate, but as not being in a group matching in rule blocks, then he gets forbidden ( 403)

of course , it is with Pro and Enterprise ed.

Regards,

Ld

1 Like

@ld57 yeah they have PRO, so makes sense.

Hi @sscarduzio,
we have tried the configuration given by you with new build and added content according to our requirements but its not working.
Here is my Config File:

- name: 'Development users'
   kibana_access: ro
   indices: [".kibana", "logstash_stuff_theycansee-*"]
   ldap_authentication: "ldap1"  
   ldap_authorization:
     name: "ldap1"                                     
     groups: ["Development"]
  1. that’s only a snippet.
  2. what does it mean it doesn’t work?

You know the drill: ES in debug mode, do a single simple curl test with credentials, show ES logs.

In LDAP configuration I am giving bind_dn e.g.

bind_dn: "CN=c-ajitb,OU=Development,OU=Mercator – Corporate functions,OU=Mercator,OU=Mumbai Airoli Mercator,DC=ad,DC=example,DC=com"
bind_password: "pass@1234"
search_user_base_DN: "OU=Development,OU=Mercator – Corporate functions,OU=Mercator,OU=Mumbai Airoli Mercator,DC=ad,DC=example,DC=com"
search_groups_base_DN: "OU=Development,OU=Mercator – Corporate functions,OU=Mercator,OU=Mumbai Airoli Mercator,DC=ad,DC=example,DC=com"

In this case all users having

OU=Development,OU=Mercator – Corporate functions,OU=Mercator,OU=Mumbai Airoli Mercator,DC=ad,DC=example,DC=com 

are able to login. I have to restrict few users from same group. Could you please provide configuration for avoid few users from same group. This is final requirement. Where I can put entries of users they can login.?

@ajit I had a look and I found an LDAP connector option that might work just right for your case:

group_search_filter: "(objectClass=group)(cn=application*)

Please see this and other extra options described here.