Hi Loic,
I see that you configured group search filter instead of user search
filter. For your case, can you try the below:
ranger.ldap.group.searchbase=OU=Tool,OU=Groupes,DC=blabla,DC=org,
ranger.ldap.group.searchfilter=cn*, ranger.ldap.group.roleattribute=cn,
ranger.ldap.user.searchfilter=(&(objectClass=person)(memberOf=CN=usr_tool_
prod,OU=Tool,OU=Groupes,DC=blabla,DC=org)(samaccountname={0})),
ranger.ldap.user.dnpattern=dc=example,dc=com, ranger.ldap.base.dn=
OU=Company,OU=Users,DC=cmb,DC=blabla,DC=org
Please note that I purposefully gave the wrong dnpattern (
ranger.ldap.user.dnpattern=dc=example,dc=com).
The reason is as stated above - For Ldap authentication, when DN is not
provided correctly, then we search the users with the user search filter
and retrieve the DN of the user. After that we search the groups based on
group search base, group search filter, and the role attribute and try to
match the retrieved DN of the user in the list of retrieved group
attributes. Hope this helps.
Thanks,
Sailaja
On Mon, Apr 29, 2024 at 1:00 AM Loïc CHANEL <loic.cha...@telecomnancy.net>
wrote:
> Vipin, Sailaja,
>
> Following-up on this issue : is there a workaround I could use, or do I
> have to wait for a fix ?
> Thanks,
>
>
> Loïc CHANEL
> Technical leader Big Data
> Capgemini (Lyon, France)
>
>
> Le ven. 19 avr. 2024 à 09:50, Loïc CHANEL <loic.cha...@telecomnancy.net>
> a écrit :
>
>> Hi guys,
>>
>> Thanks for your answers ! I created RANGER-4778
>> <https://issues.apache.org/jira/browse/RANGER-4778> to track that issue.
>> Now for the workaround, I'm not sure I can make it work. Here's my
>> situation.
>>
>> The users I'm trying to authenticate are objectClass=person, and they
>> are located :
>> - In OU=External,OU=Company,OU=Users,DC=cmb,DC=blabla,DC=org if they are
>> external users
>> - In OU=Internal,OU=Company,OU=Users,DC=cmb,DC=blabla,DC=org if they are
>> internal users
>>
>> Now the issue is that none of this is reflected in the 'memberOf'
>> section. But there is a filter I know I can use for these users, it's
>> memberOf=CN=usr_tool_prod,OU=Tool,OU=Groupes,DC=blabla,DC=org, so I
>> tried the following :
>> <name>ranger.ldap.user.dnpattern</name>
>> <value>DC=cmb,DC=blabla,DC=org</value>
>>
>> <name>ranger.ldap.group.searchfilter</name>
>>
>> <value>(&(objectClass=person)(memberOf=CN=usr_tool_prod,OU=Tool,OU=Groupes,DC=blabla,DC=org))</value>
>>
>> And it's still KO. What am I missing ? Is there a way I can make it work ?
>> Thanks,
>>
>>
>> Loïc CHANEL
>> Technical leader Big Data
>> Capgemini (Lyon, France)
>>
>>
>> Le ven. 19 avr. 2024 à 05:08, Vipin Rathor <v.rat...@gmail.com> a écrit :
>>
>>> Thank Sailaja for the reply. I was about to reply that
>>> Spring LDAP API does support multiple DN but you
>>> covered with complete analysis.
>>> IIRC I did fix (or circumvent?) this bug back in the days
>>> and I’m surprised to see that it still lingers around 😬
>>> Let’s fix it this time for good 👍🏻
>>>
>>> Regards,
>>> VR
>>>
>>> On Apr 19, 2024, at 03:45, Sailaja Polavarapu <spolavar...@cloudera.com>
>>> wrote:
>>>
>>>
>>> ranger.ldap.user.dnpattern currently takes only one pattern which seems
>>> to be a bug. Because the underlying spring security ldap library API
>>> supports array of patterns. For now, can you try filtering based on any
>>> other attributes? For example below config filters the users from group1 &
>>> group2
>>> ranger.ldap.group.searchbase=OU=groups,DC=rangerdev,DC=apache,DC=COM,
>>> ranger.ldap.group.searchfilter=cn*, ranger.ldap.group.roleattribute=cn,
>>> ranger.ldap.user.searchfilter=(&(objectclass=user)(memberOf=CN=group1,OU=groups,DC=rangerdev,DC=apache,DC=COM)(memberOf=CN=group2,OU=groups,DC=rangerdev,DC=apache,DC=COM)(samaccountname={0})),
>>> ranger.ldap.user.dnpattern=dc=example,dc=com,
>>> ranger.ldap.base.dn=cn=users,DC=rangerdev,DC=apache,DC=COM
>>>
>>> For Ldap authentication, when DN is not provided correctly, then we
>>> search the users with the user search filter and retrieve the DN of the
>>> user. After that we search the groups based on group search base, group
>>> search filter, and the role attribute and try to match the retrieved DN of
>>> the user in the list of retrieved group attributes. Hope this helps.
>>>
>>> For user dn pattern config to take multiple values, please file an
>>> apache jira so that it can be fixed for later versions.
>>>
>>> - Sailaja.
>>>
>>> On Thu, Apr 18, 2024 at 9:25 AM j km <alericmcke...@gmail.com> wrote:
>>>
>>>> This is really old, but this is what I found.
>>>>
>>>> "ranger.usersync.ldap.user.searchfilter":
>>>> "(|(samaaccountname=)(memberof=CN=)(...))
>>>>
>>>> On Thu, Apr 18, 2024 at 10:54 AM Loïc CHANEL <
>>>> loic.cha...@telecomnancy.net> wrote:
>>>>
>>>>> That's what I was hoping indeed, but unfortunately :
>>>>>
>>>>> 2024-04-18 14:39:39,400 [http-nio-6080-exec-7] DEBUG
>>>>> [RangerAuthenticationProvider.java:291] LDAP Authentication Failed:
>>>>> org.springframework.security.authentication.InternalAuthenticationServiceException:
>>>>> Failed to parse DN; nested exception is
>>>>> org.springframework.ldap.core.TokenMgrError: Lexical error at line 1,
>>>>> column 10. Encountered: "(" (40), after : ""
>>>>>
>>>>> I tried to escape the character with a backslash but got the exact
>>>>> same result. Any other ideas ?
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Loïc CHANEL
>>>>> Technical leader Big Data
>>>>> Capgemini (Lyon, France)
>>>>>
>>>>>
>>>>> Le jeu. 18 avr. 2024 à 16:24, j km <alericmcke...@gmail.com> a écrit :
>>>>>
>>>>>> I think it is just an or
>>>>>> & (&(filter1) (filter2)) AND — all conditions must be met
>>>>>> | (|(filter1) (filter2)) OR — any number of conditions can be met
>>>>>> ! (!(filter1)) NOT — the condition must not be met
>>>>>>
>>>>>> On Thu, Apr 18, 2024 at 10:06 AM Loïc CHANEL <
>>>>>> loic.cha...@telecomnancy.net> wrote:
>>>>>>
>>>>>>> Just a follow-up question though : is there a way to define several
>>>>>>> dnpattern
>>>>>>> values ? Because the users are located into two different sections
>>>>>>> of my LDAP, so I have the following patterns :
>>>>>>> CN={0},OU=External,OU=Users,DC=cmb,DC=blabla,DC=org and
>>>>>>> CN={0},OU=Internal,OU=Users,DC=cmb,DC=blabla,DC=org and I want LDAP
>>>>>>> authentication to work for both.
>>>>>>> Best regards,
>>>>>>>
>>>>>>>
>>>>>>> Loïc CHANEL
>>>>>>> Technical leader Big Data
>>>>>>> Capgemini (Lyon, France)
>>>>>>>
>>>>>>>
>>>>>>> Le jeu. 18 avr. 2024 à 13:39, Loïc CHANEL <
>>>>>>> loic.cha...@telecomnancy.net> a écrit :
>>>>>>>
>>>>>>>> Hi Vipin,
>>>>>>>>
>>>>>>>> Already did this but didn't see the file name as I was expecting
>>>>>>>> them to be before the properties but not after.
>>>>>>>> By finding the loaded file in the logs I've been able to
>>>>>>>> troubleshoot my issue.
>>>>>>>> Thanks a lot for your help,
>>>>>>>>
>>>>>>>>
>>>>>>>> Loïc CHANEL
>>>>>>>> Technical leader Big Data
>>>>>>>> Capgemini (Lyon, France)
>>>>>>>>
>>>>>>>>
>>>>>>>> Le jeu. 18 avr. 2024 à 13:11, Vipin Rathor <v.rat...@gmail.com> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>> Hi Loïc,
>>>>>>>>> If you turn on log4j debug for Apache Ranger, then the debug log
>>>>>>>>> will tell you where the congratulations are being loaded from.
>>>>>>>>>
>>>>>>>>> Also, please check if you aren’t making changes in a different
>>>>>>>>> copy of the actual config file (most probably you might have checked
>>>>>>>>> but
>>>>>>>>> wouldn’t hurt to double check).
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> VR
>>>>>>>>>
>>>>>>>>> On Apr 18, 2024, at 14:43, Loïc CHANEL <
>>>>>>>>> loic.cha...@telecomnancy.net> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> I'm trying to configure the LDAP authentication for UI access, so
>>>>>>>>> I edited the properties in ranger-admin-site.xml file and
>>>>>>>>> restarted, but I saw in the logs the properties I edited are not
>>>>>>>>> applied.
>>>>>>>>> For instance, the property ranger.ldap.url has the value ldap://
>>>>>>>>> cmb.mydomain.org:389 in the XML file, but when Ranger starts I
>>>>>>>>> can see in the logs that the default value ( ldap:// ) is loaded
>>>>>>>>> by Ranger instead of what I defined.
>>>>>>>>> Is there something I'm missing ? How can I see where the values
>>>>>>>>> are loaded from ?
>>>>>>>>> Thanks for your help,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Loïc CHANEL
>>>>>>>>> Technical leader Big Data
>>>>>>>>> Capgemini (Lyon, France)
>>>>>>>>>
>>>>>>>>>
