[keycloak-user] can't resolve groups from multiple group mappers
Marek Posolda
mposolda at redhat.com
Mon Oct 9 06:52:21 EDT 2017
I see.
Are you ok with this or you also still need the proper stuff in the
'Groups' -> 'User Groups' ? Feel free to create a JIRA if yes and add
the component "User Federation - LDAP" and the steps (The fact that
you're using MSAD with the LOAD_GROUPS_BY_MEMBER_ATTRIBUTE_RECURSIVELY
MSAD extension). But I can't promise when exactly we do it, if ever...
Marek
On 09/10/17 12:30, Tiemen Ruiten wrote:
> I finally got around to testing this with TRACE logging and found out
> that I was looking in the wrong place: the 'Groups' -> 'User Groups'
> section of the dashboard. Only direct members of the group would be
> shown there.
>
> The groups for the user are showing correctly in the 'Groups' tab of
> the particular user in the 'Users' setting in my test realm.
>
> On 29 September 2017 at 16:56, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
>
> Maybe if you can enable TRACE logging for the
> "org.keycloak.storage.ldap" it may help. It shows the
> configuration at startup, but also it shows the LDAP queries.
> Maybe this can show why the roles can't be retrieved.
>
> Marek
>
>
> On 29/09/17 16:35, Tiemen Ruiten wrote:
>> Marek, thanks for your answer. I had already tried that and it
>> didn't work. I set up an AD federation and a role mapper in a
>> clean testing realm with the same results. If you are interested,
>> I can share the realm configuration with you for reproducing.
>>
>> On 29 September 2017 at 15:06, Marek Posolda <mposolda at redhat.com
>> <mailto:mposolda at redhat.com>> wrote:
>>
>> In configuration of your LDAP Group mapper, you can select
>> "User Roles Retrieve Strategy" to be
>> "LOAD_GROUPS_BY_MEMBER_ATTRIBUTE_RECURSIVELY" . Then it
>> should be possible to recursively retrieve the memberships,
>> hence user will be treated as member of "access" group too.
>>
>> This is specific to Active Directory, but since you're using
>> it, it should work fine.
>>
>> Marek
>>
>> On 28/09/17 10:28, Tiemen Ruiten wrote:
>>> Hm, I wrote this down the wrong way, apologies. What I meant
>>> to say was that the /access/ groups don't have any members,
>>> which they should have from the user groups. Looks like my
>>> issue is https://issues.jboss.org/browse/KEYCLOAK-1797
>>> <https://issues.jboss.org/browse/KEYCLOAK-1797>. Nested
>>> groups are quite common in Active Directory, it would be
>>> nice if this issue could receive some attention.
>>>
>>>
>>> On 28 September 2017 at 09:41, Marek Posolda
>>> <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>
>>> Not expected. It should work and our tests are passing.
>>> Looks like some mis-configuration or something. We have
>>> an example in keycloak-examples distribution called
>>> "ldap" . Here you can see some example how can LDAP role
>>> be configured (no example for group-mapper yet, but it's
>>> quite similar to role mapper)
>>>
>>> Marek
>>>
>>>
>>> On 26/09/17 12:04, Tiemen Ruiten wrote:
>>>
>>> Hello,
>>>
>>> I'm testing with the following setup:
>>>
>>> In our Active Directory, which is federated to
>>> Keycloak, we have a
>>> container with 'access' groups (groups that are used
>>> to give access to
>>> certain applications, akin to Keycloak roles) and a
>>> container for 'user'
>>> groups (eg. sales, it, marketing etc.). Users are
>>> always only direct
>>> members of a user group. The access groups can only
>>> have user groups as
>>> members, never users.
>>>
>>> In Keycloak, I have created two LDAP-group-mappers
>>> for both containers, but
>>> unfortunately, none of the user groups show any
>>> members. Is this expected?
>>>
>>> Using Keycloak 3.2.1 Final.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Tiemen Ruiten
>>> Systems Engineer
>>> R&D Media
>>
>>
>>
>>
>>
>> --
>> Tiemen Ruiten
>> Systems Engineer
>> R&D Media
>
>
>
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
More information about the keycloak-user
mailing list