[Geoserver-users] LDAP authentication with group/role discovery still seems broken

hk.ihatemailinglists · February 28, 2024, 1:33pm

Hi everyone,

I am struggling with LDAP as GeoServer (2.24.2) does not manage to pick up groups/roles from it.

I did post on https://gis.stackexchange.com/questions/477658/geoserver-does-not-find-ldap-groups-of-user with no solution so far.

- LDAP users can log in.
- A LDAP User/Group Service does discover the users and groups.
- A LDAP Role Service does discover/create the roles (ROLE_GROUPNAME).

-----

There are several older inconclusive threads about probably the same issue, seemingly introduced after 2.15.2:
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/a799bca3-0741-5caf-1db1-ca017b35a78e@anonymised.com/
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/d2bb87fd-7a89-0aa5-7a3f-e975aaeba967@anonymised.com/
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/SJ0PR08MB6800C0E997D3CBD049D22B8ED71F9@anonymised.com/

https://osgeo-org.atlassian.net/browse/GEOS-10452 was closed with a commit that did not actually really related to the ticket.
The ticket is about role discovery for a user that is being authenticated. The commit was about the Role Service, a component that makes existing groups/roles visible in GeoServer. From all what I have found so far, the Role Service is *not* related to the role discovery during authentication.
So I think that ticket was wrongly closed.

-----

I have used the very same LDAP user, query etc in a Python script with success so the filters and whatnot seem correct.

I have tried using a 2.15.2 geoserver.war without success (but maybe using the same GeoServer data directory led to issues).

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and gs-web-sec-ldap-2.15.2.jar as suggested in https://sourceforge.net/p/geoserver/mailman/message/37633270/ without success.

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and gs-web-sec-ldap-2.15.2.jar PLUS (spring-ldap-core-2.0.2.RELEASE.jar and spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I have tried using the existing 2.24.2 with (spring-ldap-core-2.0.2.RELEASE.jar and spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I compiled GeoServer 2.25 using Maven and added some more logging in BindingLdapAuthoritiesPopulator.java#getGroupMembershipRoles to see the formattedFilter before and after the escaping, and also inspect the other variables.
They all look fine.

-----

Strangely it seems to work with the acme-ldap.jar from https://docs.geoserver.org/main/en/user/security/tutorials/ldap/index.html
bob gets ROLE_USER with it.
The group/role discovery seems to work differently with that setup though. There are no "security.ldap" lines in the log when using it, instead all I see is:

28 Feb 13:24:15 DEBUG [filter.GeoServerUserNamePasswordAuthenticationFilter$1] - Set SecurityContextHolder to UsernamePasswordAuthenticationToken [Principal=LdapUserDetailsImpl [Dn=uid=bob,ou=people,dc=acme,dc=org; Username=bob; Password=[PROTECTED]; Enabled=true; AccountNonExpired=true; CredentialsNonExpired=true; AccountNonLocked=true; Granted Authorities=[ROLE_USER]], Credentials=[PROTECTED], Authenticated=true, Details=GeoServerWebAuthenticationDetails [RemoteIpAddress=127.0.0.1, SessionId=A02D2978C7562773FF7F842FCF3B3E99], Granted Authorities=[ROLE_AUTHENTICATED, ROLE_USER]]

One small difference might be that this uses ou=groups, not cn=groups, but I have no clue if that is something meaningful or just text.

-----

Is anyone using a standard GeoServer 2.24 with working role discovery via LDAP?

Could this be something in Spring?

Cheers, Hannes

Cesar_Martinez_Izqui · February 28, 2024, 2:03pm

Hi Hannes,
I confirm that LDAP works properly in Geoserver 2.22. I have not tried
with 2.24 for the moment.
Maybe you can try 2.22 to see if it is really a problem in Geoserver
version or it is some other problem related with your settings or your
environment.

César

On Wed, 28 Feb 2024 at 14:50, <hk.ihatemailinglists@anonymised.com> wrote:

Hi everyone,

I am struggling with LDAP as GeoServer (2.24.2) does not manage to pick up groups/roles from it.

I did post on https://gis.stackexchange.com/questions/477658/geoserver-does-not-find-ldap-groups-of-user with no solution so far.

- LDAP users can log in.
- A LDAP User/Group Service does discover the users and groups.
- A LDAP Role Service does discover/create the roles (ROLE_GROUPNAME).

-----

There are several older inconclusive threads about probably the same issue, seemingly introduced after 2.15.2:
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/a799bca3-0741-5caf-1db1-ca017b35a78e@anonymised.com/
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/d2bb87fd-7a89-0aa5-7a3f-e975aaeba967@anonymised.com/
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/SJ0PR08MB6800C0E997D3CBD049D22B8ED71F9@anonymised.com/

https://osgeo-org.atlassian.net/browse/GEOS-10452 was closed with a commit that did not actually really related to the ticket.
The ticket is about role discovery for a user that is being authenticated. The commit was about the Role Service, a component that makes existing groups/roles visible in GeoServer. From all what I have found so far, the Role Service is *not* related to the role discovery during authentication.
So I think that ticket was wrongly closed.

-----

I have used the very same LDAP user, query etc in a Python script with success so the filters and whatnot seem correct.

I have tried using a 2.15.2 geoserver.war without success (but maybe using the same GeoServer data directory led to issues).

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and gs-web-sec-ldap-2.15.2.jar as suggested in https://sourceforge.net/p/geoserver/mailman/message/37633270/ without success.

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and gs-web-sec-ldap-2.15.2.jar PLUS (spring-ldap-core-2.0.2.RELEASE.jar and spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I have tried using the existing 2.24.2 with (spring-ldap-core-2.0.2.RELEASE.jar and spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I compiled GeoServer 2.25 using Maven and added some more logging in BindingLdapAuthoritiesPopulator.java#getGroupMembershipRoles to see the formattedFilter before and after the escaping, and also inspect the other variables.
They all look fine.

-----

Strangely it seems to work with the acme-ldap.jar from https://docs.geoserver.org/main/en/user/security/tutorials/ldap/index.html
bob gets ROLE_USER with it.
The group/role discovery seems to work differently with that setup though. There are no "security.ldap" lines in the log when using it, instead all I see is:

28 Feb 13:24:15 DEBUG [filter.GeoServerUserNamePasswordAuthenticationFilter$1] - Set SecurityContextHolder to UsernamePasswordAuthenticationToken [Principal=LdapUserDetailsImpl [Dn=uid=bob,ou=people,dc=acme,dc=org; Username=bob; Password=[PROTECTED]; Enabled=true; AccountNonExpired=true; CredentialsNonExpired=true; AccountNonLocked=true; Granted Authorities=[ROLE_USER]], Credentials=[PROTECTED], Authenticated=true, Details=GeoServerWebAuthenticationDetails [RemoteIpAddress=127.0.0.1, SessionId=A02D2978C7562773FF7F842FCF3B3E99], Granted Authorities=[ROLE_AUTHENTICATED, ROLE_USER]]

One small difference might be that this uses ou=groups, not cn=groups, but I have no clue if that is something meaningful or just text.

-----

Is anyone using a standard GeoServer 2.24 with working role discovery via LDAP?

Could this be something in Spring?

Cheers, Hannes

_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:
- Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   - - - - - - - - - - - - - - - - - - - -
   SCOLAB: http://www.scolab.es
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Carsten_Klein · February 28, 2024, 2:17pm

Hello everyone,

actually, this seems to be broken for a long time. I'm runnig GS version 2.22.2.

I was researching on this issue several years ago and, as far as I remember, the problem was that the actual LDAP query that gathers the newly authenticated user's roles is not correctly formed/encoded etc. I do no longer know the extact problem, but the query used some escaping (where it shouldn't) or did not escape some things (it better should have escaped).

Use a network analyzer (e.g. WireShark on Windows or tcpdump on Linux) and track the LDAP queries issued by GeoServer while logging in a user. Likley you should temporarily switch to non-ssl LDAP (use ldap:// and not ldaps://) in order to make packet analyzing easier.

Likely the "get this user's roles" query looks odd (in contrast to the other LDAP queries). That could be a starting point for finding the problem in GeoServer's LDAP libraries.

Cheers
Carsten

Am 28.02.2024 um 14:33 schrieb hk.ihatemailinglists@anonymised.com:

Hi everyone,

I am struggling with LDAP as GeoServer (2.24.2) does not manage to pick up groups/roles from it.

I did post on https://gis.stackexchange.com/questions/477658/geoserver-does-not-find-ldap-groups-of-user with no solution so far.

- LDAP users can log in.
- A LDAP User/Group Service does discover the users and groups.
- A LDAP Role Service does discover/create the roles (ROLE_GROUPNAME).

-----

There are several older inconclusive threads about probably the same issue, seemingly introduced after 2.15.2:
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/a799bca3-0741-5caf-1db1-ca017b35a78e@anonymised.com/
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/d2bb87fd-7a89-0aa5-7a3f-e975aaeba967@anonymised.com/
- https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/SJ0PR08MB6800C0E997D3CBD049D22B8ED71F9@anonymised.com/

https://osgeo-org.atlassian.net/browse/GEOS-10452 was closed with a commit that did not actually really related to the ticket.
The ticket is about role discovery for a user that is being authenticated. The commit was about the Role Service, a component that makes existing groups/roles visible in GeoServer. From all what I have found so far, the Role Service is *not* related to the role discovery during authentication.
So I think that ticket was wrongly closed.

-----

I have used the very same LDAP user, query etc in a Python script with success so the filters and whatnot seem correct.

I have tried using a 2.15.2 geoserver.war without success (but maybe using the same GeoServer data directory led to issues).

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and gs-web-sec-ldap-2.15.2.jar as suggested in https://sourceforge.net/p/geoserver/mailman/message/37633270/ without success.

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and gs-web-sec-ldap-2.15.2.jar PLUS (spring-ldap-core-2.0.2.RELEASE.jar and spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I have tried using the existing 2.24.2 with (spring-ldap-core-2.0.2.RELEASE.jar and spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I compiled GeoServer 2.25 using Maven and added some more logging in BindingLdapAuthoritiesPopulator.java#getGroupMembershipRoles to see the formattedFilter before and after the escaping, and also inspect the other variables.
They all look fine.

-----

Strangely it seems to work with the acme-ldap.jar from https://docs.geoserver.org/main/en/user/security/tutorials/ldap/index.html
bob gets ROLE_USER with it.
The group/role discovery seems to work differently with that setup though. There are no "security.ldap" lines in the log when using it, instead all I see is:

28 Feb 13:24:15 DEBUG [filter.GeoServerUserNamePasswordAuthenticationFilter$1] - Set SecurityContextHolder to UsernamePasswordAuthenticationToken [Principal=LdapUserDetailsImpl [Dn=uid=bob,ou=people,dc=acme,dc=org; Username=bob; Password=[PROTECTED]; Enabled=true; AccountNonExpired=true; CredentialsNonExpired=true; AccountNonLocked=true; Granted Authorities=[ROLE_USER]], Credentials=[PROTECTED], Authenticated=true, Details=GeoServerWebAuthenticationDetails [RemoteIpAddress=127.0.0.1, SessionId=A02D2978C7562773FF7F842FCF3B3E99], Granted Authorities=[ROLE_AUTHENTICATED, ROLE_USER]]

One small difference might be that this uses ou=groups, not cn=groups, but I have no clue if that is something meaningful or just text.

-----

Is anyone using a standard GeoServer 2.24 with working role discovery via LDAP?

Could this be something in Spring?

Cheers, Hannes

_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:
- Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

hk.ihatemailinglists · February 29, 2024, 9:22am

Thanks Carsten!

The escaping issue was probably https://github.com/geoserver/geoserver/pull/6189 (the Spring framework(?) changed so GeoServer had to adapt).
We do not have any commas or other special characters in our values though, both {0} and {1} are simple alphanumeric+"=" lowercase strings like "foo" or "uid=alice,cn=admins,cn=users,dc=foo,dc=bar,dc=baz,dc=com" (comma-delimited, no commas in the actual "values").
And I looked at the strings before and after escaping, they were always the same for me.

I have to take back that https://osgeo-org.atlassian.net/browse/GEOS-10452 was closed with a not-really-related PR (the #6189). The PR actually is titled in a misleading way as its changes to affect not only Role Services (and User/Group services) but the lookup during authentication as well.

Great idea about the logging. I won't be able to MITM the connection or switch the remote LDAP to non-ssl but maybe I can get them to check logs on the LDAP server end.

Cheers, Hannes

Carsten Klein schrieb am 28.02.2024 15:17 (GMT +01:00):

Hello everyone,

actually, this seems to be broken for a long time. I'm runnig GS version
2.22.2.

I was researching on this issue several years ago and, as far as I
remember, the problem was that the actual LDAP query that gathers the
newly authenticated user's roles is not correctly formed/encoded etc. I
do no longer know the extact problem, but the query used some escaping
(where it shouldn't) or did not escape some things (it better should
have escaped).

Use a network analyzer (e.g. WireShark on Windows or tcpdump on Linux)
and track the LDAP queries issued by GeoServer while logging in a user.
Likley you should temporarily switch to non-ssl LDAP (use ldap:// and
not ldaps://) in order to make packet analyzing easier.

Likely the "get this user's roles" query looks odd (in contrast to the
other LDAP queries). That could be a starting point for finding the
problem in GeoServer's LDAP libraries.

Cheers
Carsten

Am 28.02.2024 um 14:33 schrieb hk.ihatemailinglists@anonymised.com:

Hi everyone,

I am struggling with LDAP as GeoServer (2.24.2) does not manage to pick up
groups/roles from it.

I did post on
https://gis.stackexchange.com/questions/477658/geoserver-does-not-find-ldap-groups-of-user
with no solution so far.

- LDAP users can log in.
- A LDAP User/Group Service does discover the users and groups.
- A LDAP Role Service does discover/create the roles (ROLE_GROUPNAME).

-----

There are several older inconclusive threads about probably the same issue,
seemingly introduced after 2.15.2:
-
https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/a799bca3-0741-5caf-1db1-ca017b35a78e@anonymised.com/
-
https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/d2bb87fd-7a89-0aa5-7a3f-e975aaeba967@anonymised.com/
-
https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/SJ0PR08MB6800C0E997D3CBD049D22B8ED71F9@anonymised.com/

https://osgeo-org.atlassian.net/browse/GEOS-10452 was closed with a commit
that did not actually really related to the ticket.
The ticket is about role discovery for a user that is being authenticated. The
commit was about the Role Service, a component that makes existing
groups/roles visible in GeoServer. From all what I have found so far, the Role
Service is *not* related to the role discovery during authentication.
So I think that ticket was wrongly closed.

-----

I have used the very same LDAP user, query etc in a Python script with success
so the filters and whatnot seem correct.

I have tried using a 2.15.2 geoserver.war without success (but maybe using the
same GeoServer data directory led to issues).

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and
gs-web-sec-ldap-2.15.2.jar as suggested in
https://sourceforge.net/p/geoserver/mailman/message/37633270/ without success.

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and
gs-web-sec-ldap-2.15.2.jar PLUS (spring-ldap-core-2.0.2.RELEASE.jar and
spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar
and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I have tried using the existing 2.24.2 with
(spring-ldap-core-2.0.2.RELEASE.jar and
spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar
and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I compiled GeoServer 2.25 using Maven and added some more logging in
BindingLdapAuthoritiesPopulator.java#getGroupMembershipRoles to see the
formattedFilter before and after the escaping, and also inspect the other
variables.
They all look fine.

-----

Strangely it seems to work with the acme-ldap.jar from
https://docs.geoserver.org/main/en/user/security/tutorials/ldap/index.html
bob gets ROLE_USER with it.
The group/role discovery seems to work differently with that setup though.
There are no "security.ldap" lines in the log when using it, instead all I see
is:

28 Feb 13:24:15 DEBUG
[filter.GeoServerUserNamePasswordAuthenticationFilter$1] - Set
SecurityContextHolder to UsernamePasswordAuthenticationToken
[Principal=LdapUserDetailsImpl [Dn=uid=bob,ou=people,dc=acme,dc=org;
Username=bob; Password=[PROTECTED]; Enabled=true; AccountNonExpired=true;
CredentialsNonExpired=true; AccountNonLocked=true; Granted
Authorities=[ROLE_USER]], Credentials=[PROTECTED], Authenticated=true,
Details=GeoServerWebAuthenticationDetails [RemoteIpAddress=127.0.0.1,
SessionId=A02D2978C7562773FF7F842FCF3B3E99], Granted
Authorities=[ROLE_AUTHENTICATED, ROLE_USER]]

One small difference might be that this uses ou=groups, not cn=groups, but I
have no clue if that is something meaningful or just text.

-----

Is anyone using a standard GeoServer 2.24 with working role discovery via
LDAP?

Could this be something in Spring?

Cheers, Hannes

_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

hk.ihatemailinglists · February 29, 2024, 9:49am

Thank you César!

If it works for you, that is great news.

Thank you for sharing censored information with me in private. I spotted a small difference:

In your (working) case there is "ou=users" and "ou=groups" while in my case we have "cn=users" and "cn=groups".
The acme-ldap.jar from https://docs.geoserver.org/stable/en/user/security/tutorials/ldap/index.html#ldap-server-setup also uses "ou=groups" and worked in my tests.

I will try to recompile acme-ldap.jar and changing its structure to "cn=groups" to see if that still works.

Maybe Spring (or GeoServer in some hidden place) is really adamant on some specific CN structure? I looked around and the "group search base" always looks completely configurable even if it usually uses a "ou=..." thing in examples.
- https://docs.spring.io/spring-security/site/docs/4.0.x/reference/html/ldap.html#loading-authorities (4)
- https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/userdetails/DefaultLdapAuthoritiesPopulator.html (4)
- https://docs.spring.io/spring-security/site/docs/6.1.6-SNAPSHOT/api/org/springframework/security/ldap/userdetails/DefaultLdapAuthoritiesPopulator.html (6, identical to 4)

Cheers, Hannes

César Martínez Izquierdo schrieb am 28.02.2024 15:03 (GMT +01:00):

Hi Hannes,
I confirm that LDAP works properly in Geoserver 2.22. I have not tried
with 2.24 for the moment.
Maybe you can try 2.22 to see if it is really a problem in Geoserver
version or it is some other problem related with your settings or your
environment.

César

On Wed, 28 Feb 2024 at 14:50, <hk.ihatemailinglists@anonymised.com> wrote:

Hi everyone,

I am struggling with LDAP as GeoServer (2.24.2) does not manage to pick up
groups/roles from it.

I did post on
https://gis.stackexchange.com/questions/477658/geoserver-does-not-find-ldap-groups-of-user
with no solution so far.

- LDAP users can log in.
- A LDAP User/Group Service does discover the users and groups.
- A LDAP Role Service does discover/create the roles (ROLE_GROUPNAME).

-----

There are several older inconclusive threads about probably the same issue,
seemingly introduced after 2.15.2:
-
https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/a799bca3-0741-5caf-1db1-ca017b35a78e@anonymised.com/
-
https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/d2bb87fd-7a89-0aa5-7a3f-e975aaeba967@anonymised.com/
-
https://sourceforge.net/p/geoserver/mailman/geoserver-users/thread/SJ0PR08MB6800C0E997D3CBD049D22B8ED71F9@anonymised.com/

https://osgeo-org.atlassian.net/browse/GEOS-10452 was closed with a commit
that did not actually really related to the ticket.
The ticket is about role discovery for a user that is being authenticated. The
commit was about the Role Service, a component that makes existing
groups/roles visible in GeoServer. From all what I have found so far, the Role
Service is *not* related to the role discovery during authentication.
So I think that ticket was wrongly closed.

-----

I have used the very same LDAP user, query etc in a Python script with success
so the filters and whatnot seem correct.

I have tried using a 2.15.2 geoserver.war without success (but maybe using the
same GeoServer data directory led to issues).

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and
gs-web-sec-ldap-2.15.2.jar as suggested in
https://sourceforge.net/p/geoserver/mailman/message/37633270/ without success.

I have tried using the existing 2.24.2 with gs-sec-ldap-2.15.2.jar and
gs-web-sec-ldap-2.15.2.jar PLUS (spring-ldap-core-2.0.2.RELEASE.jar and
spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar
and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I have tried using the existing 2.24.2 with
(spring-ldap-core-2.0.2.RELEASE.jar and
spring-security-ldap-4.0.4.RELEASE.jar) or (spring-ldap-core-2.3.2.RELEASE.jar
and spring-security-ldap-5.1.5.RELEASE.jar) without success.

I compiled GeoServer 2.25 using Maven and added some more logging in
BindingLdapAuthoritiesPopulator.java#getGroupMembershipRoles to see the
formattedFilter before and after the escaping, and also inspect the other
variables.
They all look fine.

-----

Strangely it seems to work with the acme-ldap.jar from
https://docs.geoserver.org/main/en/user/security/tutorials/ldap/index.html
bob gets ROLE_USER with it.
The group/role discovery seems to work differently with that setup though.
There are no "security.ldap" lines in the log when using it, instead all I see
is:

28 Feb 13:24:15 DEBUG
[filter.GeoServerUserNamePasswordAuthenticationFilter$1] - Set
SecurityContextHolder to UsernamePasswordAuthenticationToken
[Principal=LdapUserDetailsImpl [Dn=uid=bob,ou=people,dc=acme,dc=org;
Username=bob; Password=[PROTECTED]; Enabled=true; AccountNonExpired=true;
CredentialsNonExpired=true; AccountNonLocked=true; Granted
Authorities=[ROLE_USER]], Credentials=[PROTECTED], Authenticated=true,
Details=GeoServerWebAuthenticationDetails [RemoteIpAddress=127.0.0.1,
SessionId=A02D2978C7562773FF7F842FCF3B3E99], Granted
Authorities=[ROLE_AUTHENTICATED, ROLE_USER]]

One small difference might be that this uses ou=groups, not cn=groups, but I
have no clue if that is something meaningful or just text.

-----

Is anyone using a standard GeoServer 2.24 with working role discovery via
LDAP?

Could this be something in Spring?

Cheers, Hannes

_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   - - - - - - - - - - - - - - - - - - - -
   SCOLAB: http://www.scolab.es
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

hk.ihatemailinglists · February 29, 2024, 11:47am

"I dont know what I am doing"-Chapter 23:

# "ou=" vs "cn="? Hardcoded "admin" lookup?
Because the acme-ldap.jar WORKS with role discovery (bill gets ROLE_ADMIN):
- I have changed the acme-ldap.jar to use "cn=users" and "cn=groups" instead of "ou=users" and "ou=groups". Works well just like before.
- I have renamed "cn=users" to "cn=users1" and "cn=admins" to "cn=admins2", the user bill now gets Granted Authorities=[ROLE_AUTHENTICATED, ROLE_ADMIN2]`.

So there is no hardcoded logic to look for "ou=" instead of "cn=" somewhere and neither something hardcoded on a specific "admin" group name.

# ACME structure vs our structure
Unfortunately I did not manage to reconstruct a minimal example of our structure using the code of acme-ldap.jar because it seems like our LDAP uses many "auxiliary" objectClass things and I am too stupid to add those in the code. :\ Otherwise I would gladly provide a acme-ldap.jar that reproduces our structure for debugging

## Our structure, as shown in Apache Directory Studio
- dc=argh,dc=org
  - cn=groups
    - cn=services
      - cn=thingiwantasrole with these attributes (and more):
        - objectClass=posixGroup
        - objectClas=univentionGroup
        - objectClass=...
        - cn=thingiwantasrole
        - memberUid=foo
        - memberUid=bar
        - uniqueMember=uid=foo,cn=...
        - uniqueMember=uid=bar,cn=...
        - ...
    - cn=...
  - cn=users
    - cn=admins
      - uid=foo with these attributes (and more):
      nd more):
        - objectClass=organizationalPerson
        - objectClass=person
        - objectClass=posixAccount
        - objectClass=top
        - objectClass=univentionObject
        - objectClass=...
        - cn=Foo Oof
        - uid=foo
        - displayName=Foo Off
        - ...
      - uid=bar
        - ...
      - uid=...
        - ...
  - cn=...

## Default acme-ldap.jar structure, as shown in Apache Directory Studio
- dc=acme,dc=org
  - ou=groups (objectClass=organizationalRole, objectClass=top)
    - cn=admin with these attributes:
      - objectClass=groupOfNames
      - objectClass=top
      - cn=admin
      - member=uid=bill,ou=people,dc=acme,dc=org
    - cn=user
      - objectClass=groupOfNames
      - objectClass=top
      - cn=user
      - member=uid=alice,ou=people,dc=acme,dc=org
      - member=uid=bob,ou=people,dc=acme,dc=org
  - ou=people
    - uid=alice with these attributes:
      - objectClass=inetOrgPerson
      - objectClass=organizationalPerson
      - objectClass=person
      - objectClass=top
      - cn=Alice
      - sn=Alice
      - displayName=Alice
      - givenName=Alice
      - uid=alice
      - userPassword=Plain text password
    - uid=bill
      - ...
    - uid=bob
      - ...

## Differences
- acme has all users in one directory, we have subdirectories
- acme has the groups directly below groups ("cn=admin,ou=groups"), we have an additional directory subtree ("cn=thingiwantasrole,cn=services,cn=groups")
- acme uses "member" as attribute name, we use "memberUid" or "uniqueMember" (one is the UID, the other the full DN(?) of the user)
- acme's groups are "objectClass=groupOfNames", while ours have various different attributes like "posixGroup" and "univentionGroup"

# More
- The `DEBUG [security.ldap] - Roles from search: ...` line does not appear with acme, yet bill gets ROLE_ADMIN! This seems like a great hint but I have not managed to find anything useful by tracing back the functions called before that.
- Using python-ldap I can use the same code and logic to discover the groups with the acme as well as our LDAP:

import ldap  # python-ldap, https://www.python-ldap.org

server = "ldap://localhost:10389/"
dn = "uid=bob,ou=people,dc=acme,dc=org"
password = "secret"

connection = ldap.initialize(server)
connection.simple_bind_s(dn, password)

result = connection.search_s(
  base="ou=groups,dc=acme,dc=org",
  scope=ldap.SCOPE_SUBTREE,
  filterstr="(&(objectClass=groupOfNames)(member=uid=bill,ou=people,dc=acme,dc=org))",
  attrlist=["cn"],
)
print([r[1] for r in result])

gives me `[{'cn': [b'admin']}]`.

Using our server host with
- dn = "uid=foo,cn=admins,cn=users,dc=argh,dc=org"
- base="cn=groups,dc=argh,dc=org",
- filterstr="(&(objectClass=univentionGroup)(uniqueMember=uid=foo,cn=admins,cn=users,dc=argh,dc=org))",

gives me `[{'cn': [b'thingiwantasrole']}, {'cn': [b'anothergroup']}]`.

-----

Thanks for reading! I hope the mailing list did not ruin the formatting too much.
Maybe someone has more or better ideas how to continue the search

Cheers, Hannes

hk.ihatemailinglists@anonymised.com schrieb am 29.02.2024 10:49 (GMT +01:00):

Thank you César!

If it works for you, that is great news.

Thank you for sharing censored information with me in private. I spotted a
small difference:

In your (working) case there is "ou=users" and "ou=groups" while in my case we
have "cn=users" and "cn=groups".
The acme-ldap.jar from
https://docs.geoserver.org/stable/en/user/security/tutorials/ldap/index.html#ldap-server-setup
also uses "ou=groups" and worked in my tests.

I will try to recompile acme-ldap.jar and changing its structure to "cn=groups"
to see if that still works.

Maybe Spring (or GeoServer in some hidden place) is really adamant on some
specific CN structure? I looked around and the "group search base" always looks
completely configurable even if it usually uses a "ou=..." thing in examples.
-
https://docs.spring.io/spring-security/site/docs/4.0.x/reference/html/ldap.html#loading-authorities
(4)
-
https://docs.spring.io/spring-security/site/docs/4.0.x/apidocs/org/springframework/security/ldap/userdetails/DefaultLdapAuthoritiesPopulator.html
(4)
-
https://docs.spring.io/spring-security/site/docs/6.1.6-SNAPSHOT/api/org/springframework/security/ldap/userdetails/DefaultLdapAuthoritiesPopulator.html
(6, identical to 4)

Cheers, Hannes

ianturton · February 29, 2024, 3:00pm

I’m sure that I made LDAP roles work with a more recent version of GeoServer at my previous job (unfortunately it’s behind a firewall so I can’t check) -

My LDAPUserGroupService config contained:

ou=groups,dc=galbraith,dc=co,dc=uk
cn
(objectClass=groupOfUniqueNames)
(uniqueMember=uid={0},ou=users,dc=galbraith,dc=co,dc=uk)
uniqueMember
ou=users,dc=galbraith,dc=co,dc=uk
uid
(objectClass=inetOrgPerson)
false
false
10
(uniqueMember={0})
true
ROLE_
true

and my LDAPRoleServiceConfig

included

ou=groups,dc=galbraith,dc=co,dc=uk
cn=*
uniqueMember=uid={0},ou=users,dc=galbraith,dc=co,dc=uk
false
false
10
(member={0})
true
ROLE_ADMINS
ROLE_ADMINS
ROLE_
true

My notes also include in bold You must make the new role service the active one by changing the drop down on the security->settings` page https://docs.geoserver.org/latest/en/user/security/webadmin/settings.html#active-role-service

I can highly recommend using a cli tool like ldapsearch to test out your queries to see what they should be, which is how I got to (uniqueMember=cn={0},ou=users,dc=galbraith,dc=co,dc=uk) for my group member search

Ian

···

Ian Turton

Cesar_Martinez_Izqui · February 29, 2024, 3:40pm

Hannes,
I see the group search filter you use is very complex compared to the
one Ian or I use.
Maybe your problem is there?

Best regards,
César Martínez

On Thu, 29 Feb 2024 at 16:03, Ian Turton <ijturton@anonymised.com> wrote:

I'm sure that I made LDAP roles work with a more recent version of GeoServer at my previous job (unfortunately it's behind a firewall so I can't check) -

My LDAPUserGroupService config contained:

<groupSearchBase>ou=groups,dc=galbraith,dc=co,dc=uk</groupSearchBase>
  <groupNameAttribute>cn</groupNameAttribute>
  <allGroupsSearchFilter>(objectClass=groupOfUniqueNames)</allGroupsSearchFilter>
  <groupSearchFilter>(uniqueMember=uid={0},ou=users,dc=galbraith,dc=co,dc=uk)</groupSearchFilter>
  <groupMembershipAttribute>uniqueMember</groupMembershipAttribute>
  <userSearchBase>ou=users,dc=galbraith,dc=co,dc=uk</userSearchBase>
  <userNameAttribute>uid</userNameAttribute>
  <allUsersSearchFilter>(objectClass=inetOrgPerson)</allUsersSearchFilter>
  <useTLS>false</useTLS>
  <useNestedParentGroups>false</useNestedParentGroups>
  <maxGroupSearchLevel>10</maxGroupSearchLevel>
  <nestedGroupSearchFilter>(uniqueMember={0})</nestedGroupSearchFilter>
  <bindBeforeGroupSearch>true</bindBeforeGroupSearch>
  <rolePrefix>ROLE_</rolePrefix>
  <convertToUpperCase>true</convertToUpperCase>

and my LDAPRoleServiceConfig

included

<groupSearchBase>ou=groups,dc=galbraith,dc=co,dc=uk</groupSearchBase>
  <allGroupsSearchFilter>cn=*</allGroupsSearchFilter>
  <groupSearchFilter>uniqueMember=uid={0},ou=users,dc=galbraith,dc=co,dc=uk</groupSearchFilter>
  <useTLS>false</useTLS>
  <useNestedParentGroups>false</useNestedParentGroups>
  <maxGroupSearchLevel>10</maxGroupSearchLevel>
  <nestedGroupSearchFilter>(member={0})</nestedGroupSearchFilter>
  <bindBeforeGroupSearch>true</bindBeforeGroupSearch>
  <adminGroup>ROLE_ADMINS</adminGroup>
  <groupAdminGroup>ROLE_ADMINS</groupAdminGroup>
  <rolePrefix>ROLE_</rolePrefix>
  <convertToUpperCase>true</convertToUpperCase>

My notes also include in bold `You must make the new role service the active one by changing the drop down on the `security->settings` page https://docs.geoserver.org/latest/en/user/security/webadmin/settings.html#active-role-service

I can highly recommend using a cli tool like ldapsearch to test out your queries to see what they should be, which is how I got to `(uniqueMember=cn={0},ou=users,dc=galbraith,dc=co,dc=uk)` for my group member search

Ian

On Thu, 29 Feb 2024 at 11:48, <hk.ihatemailinglists@anonymised.com> wrote:

"I dont know what I am doing"-Chapter 23:

--
Ian Turton
_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:
- Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   - - - - - - - - - - - - - - - - - - - -
   SCOLAB: http://www.scolab.es
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

hk.ihatemailinglists · March 1, 2024, 1:43pm

Ian, thank you so much! Your boldness saved the day/week/month

Ian Turton schrieb am 29.02.2024 16:00 (GMT +01:00):

My notes also include in bold `You must make the new role service the
active one by changing the drop down on the `security->settings` page
https://docs.geoserver.org/latest/en/user/security/webadmin/settings.html#active-role-service

This was it!

Interestingly the log still says "[security.ldap] - Roles from search: " but my test user DOES get its roles assigned properly now using our LDAP server:

01 Mar 08:29:05 DEBUG [security.ldap] - Getting authorities for user uid=foo,cn=admins,cn=users,dc=example,dc=com
01 Mar 08:29:05 DEBUG [security.ldap] - Searching for roles for user 'foo', DN = 'uid=foo,cn=admins,cn=users,dc=example,dc=com', with filter (&(objectClass=univentionGroup)(memberUid={1})) in search base 'cn=services,cn=groups,dc=example,dc=com'
01 Mar 08:29:05 DEBUG [security.ldap] - Roles from search:
01 Mar 08:29:05 DEBUG [ldap.LDAPSecurityProvider$1] - Authenticated user
01 Mar 08:29:05 DEBUG [filter.GeoServerUserNamePasswordAuthenticationFilter$1] - Set SecurityContextHolder to UsernamePasswordAuthenticationToken [Principal=LdapUserDetailsImpl [Dn=uid=foo,cn=admins,cn=users,dc=example,dc=com; Username=foo; Password=[PROTECTED]; Enabled=true; AccountNonExpired=true; CredentialsNonExpired=true; AccountNonLocked=true; Granted Authorities=], Credentials=[PROTECTED], Authenticated=true, Details=GeoServerWebAuthenticationDetails [RemoteIpAddress=127.0.0.1, SessionId=123123123], Granted Authorities=[ROLE_AUTHENTICATED, ROLE_GEOSERVER_GLOBAL_ADMINS, ROLE_BEWARE_OF_THE_LEOPARD]]

Phew!

This leaves me confused though.
- Are there two ways of group/role discovery for LDAP users, one in the Authentication Provider and one with a Role Service? What is the difference? Are they completely different things?
- From the logs and behaviour it seems like the three "[security.ldap]" lines come from the Authentication Provider while the Role Service discovers them silently? Why does one discovery log something and the other doesn't?

I'll update https://gis.stackexchange.com/questions/477658/geoserver-does-not-find-ldap-groups-of-user momentarily, including the minimal configuration I ended up with. There is better formatting and higher search engine discovery on that site so I hope you don't mind if I switch from the mailing list.

Cheers, Hannes

PS: Future reader, once you switch the Role Service your GeoServer user "admin" won't become a GeoServer admin anymore. Make sure you have access to the "root" user's master password or that your LDAP setup includes a user that will become GeoServer admin!

ianturton · March 2, 2024, 9:56am

As I said I updated the manual to try to make this clearer, if you can think of anything else that could be added please do edit it too.

Ian

On Fri, 1 Mar 2024, 13:43 , <hk.ihatemailinglists@anonymised.com> wrote:

Ian, thank you so much! Your boldness saved the day/week/month

Ian Turton schrieb am 29.02.2024 16:00 (GMT +01:00):

My notes also include in bold You must make the new role service the active one by changing the drop down on the security->settings` page
https://docs.geoserver.org/latest/en/user/security/webadmin/settings.html#active-role-service

This was it!

Interestingly the log still says “[security.ldap] - Roles from search: ” but my test user DOES get its roles assigned properly now using our LDAP server:

01 Mar 08:29:05 DEBUG [security.ldap] - Getting authorities for user uid=foo,cn=admins,cn=users,dc=example,dc=com
01 Mar 08:29:05 DEBUG [security.ldap] - Searching for roles for user ‘foo’, DN = ‘uid=foo,cn=admins,cn=users,dc=example,dc=com’, with filter (&(objectClass=univentionGroup)(memberUid={1})) in search base ‘cn=services,cn=groups,dc=example,dc=com’
01 Mar 08:29:05 DEBUG [security.ldap] - Roles from search:
01 Mar 08:29:05 DEBUG [ldap.LDAPSecurityProvider$1] - Authenticated user
01 Mar 08:29:05 DEBUG [filter.GeoServerUserNamePasswordAuthenticationFilter$1] - Set SecurityContextHolder to UsernamePasswordAuthenticationToken [Principal=LdapUserDetailsImpl [Dn=uid=foo,cn=admins,cn=users,dc=example,dc=com; Username=foo; Password=[PROTECTED]; Enabled=true; AccountNonExpired=true; CredentialsNonExpired=true; AccountNonLocked=true; Granted Authorities=], Credentials=[PROTECTED], Authenticated=true, Details=GeoServerWebAuthenticationDetails [RemoteIpAddress=127.0.0.1, SessionId=123123123], Granted Authorities=[ROLE_AUTHENTICATED, ROLE_GEOSERVER_GLOBAL_ADMINS, ROLE_BEWARE_OF_THE_LEOPARD]]

Phew!

This leaves me confused though.

Are there two ways of group/role discovery for LDAP users, one in the Authentication Provider and one with a Role Service? What is the difference? Are they completely different things?

From the logs and behaviour it seems like the three “[security.ldap]” lines come from the Authentication Provider while the Role Service discovers them silently? Why does one discovery log something and the other doesn’t?

I’ll update https://gis.stackexchange.com/questions/477658/geoserver-does-not-find-ldap-groups-of-user momentarily, including the minimal configuration I ended up with. There is better formatting and higher search engine discovery on that site so I hope you don’t mind if I switch from the mailing list.

Cheers, Hannes

PS: Future reader, once you switch the Role Service your GeoServer user “admin” won’t become a GeoServer admin anymore. Make sure you have access to the “root” user’s master password or that your LDAP setup includes a user that will become GeoServer admin!

Cesar_Martinez_Izqui · March 8, 2024, 10:19am

On Fri, 1 Mar 2024 at 14:46, <hk.ihatemailinglists@anonymised.com> wrote:
[...]

This leaves me confused though.
- Are there two ways of group/role discovery for LDAP users, one in the Authentication Provider and one with a Role Service? What is the difference? Are they completely different things?

This also puzzles me. There are mentions to group search in both the
Authentication Provider settings form and the Role Service settings
form.
Maybe one of them can be used to retrieve user groups and the other
one retrieves user roles? Only speculating, but I see Geoserver has
the concept of both groups and roles, so that might be the cause.

Best regards,
César Martínez

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   - - - - - - - - - - - - - - - - - - - -
   SCOLAB: http://www.scolab.es
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -