[Geoserver-users] ldap security issues in 2.16/17

Richard_Duivenvoord1 · May 29, 2020, 12:48pm

Hi List,

We have/had a working setup to secure layers based on LDAP/AD groups.
All works fine in 2.13.1 java8 (Windows machines, all java from
adoptopenjdk)

Then we got a new server (Windows0) and installed 2.16 (also tried 2.17)
and jdk11 and with identical setup I NEVER receive my 'groups'...

I'm aware of caches etc etc, so have restarted both
tomcat/browser/etcetc 1000 times. I keep seeing:

DEBUG [org.geoserver.security.ldap.BindingLdapAuthoritiesPopulator] -
Roles from search:

This logline looks 100% the same between the two versions:

[org.geoserver.security.ldap.BindingLdapAuthoritiesPopulator] -
Searching for roles for user 'n3704', DN = 'CN=Duivenvoorde\,
Richard,OU=Users,OU=Xendesktop,OU=XXXX,dc=nieuwegein,dc=nl', with filter
(member={0}) in search base 'OU=Security Groups,OU=Groups,OU=XXXX'

Except that 2.13 returns my groups

I even installed a fresh 2.13.1 with java8 on that machine, got a fresh
data_dir from the war, and put succesfully ldap security on sf.roads
layer...

But then going back to 2.16 (even reusing the succesfull data-dir) fails
again.

This is very hard to debug (I cannot see what is logged at the Active
Directory end, as that is corporate stuff there).

Anybody a clue? Only thing that changes is java (and I cannot test that
because 2.13 does not work with java11, and 2.16 not with java8 (mmm
THAT I did test).

Anybody has a recent succesfull LDAP setup?

Or hints on how to debug this (all Windows there, and not able to setup
a full debug setup there).

Any help appreciated

Regards,

Richard Duivenvoorde

ianturton · May 29, 2020, 4:22pm

I’d suggest running 2.16 or 2.17 with Java 8 - to rule out a java change. If it continues to be an issue then we’ll need to look to see if there were any changes in the LDAP authentication code.

Ian

···

Ian Turton

Andrea_Aime4 · May 29, 2020, 5:01pm

Mind, in my company we run 2.16.x and 2.17.x with Java 8 exclusively, without issues.
We either use the official distribution repositories, if they provide a recent Java 8 build,
or just get it from AdoptOpenJDK otherwise.

Cheers
Andrea

···

== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.

Richard_Duivenvoord1 · May 31, 2020, 2:43pm

On 5/29/20 7:01 PM, Andrea Aime wrote:

On Fri, May 29, 2020 at 2:56 PM Richard Duivenvoorde
<rdmailings@anonymised.com <mailto:rdmailings@anonymised.com>> wrote:

    Anybody a clue? Only thing that changes is java (and I cannot test that
    because 2.13 does not work with java11, and 2.16 not with java8 (mmm
    THAT I did test).

Mind, in my company we run 2.16.x and 2.17.x with Java 8 exclusively,
without issues.
We either use the official distribution repositories, if they provide a
recent Java 8 build,
or just get it from AdoptOpenJDK otherwise.

Ok, further testing 2.16 and 2.17 with jdk8(!): NOT working either
(using the datadir from de working 2.13).

So I downloaded 2.15: not working
then downloaded 2.14: working (!) (both with 2.13 datadir)

So... it seems not jdk related?

Then I remembered this tutorial there was a testing ldap jar mentioned in:
https://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html

Note that the download url is not working anymore:

http://files.opengeo.org/geoserver/acme-ldap.jar <== not working

But I had an acme-ldap.jar somewhere on an old working station.

THAT was working fine .. for 2.13 till 2.17 so...
(using the exact setup from tutorial and again sf:roads as layer).

It is apparently something ActiveDirectory related?
OR a local problem ...

Anybody else authentication against AD in a recent geoserver?
Or anybody else is able to test against a local AD?
My test result is 2.13 and 2.14 working fine
2.15 and up not working.

Next step would be to setup an AD in a VM now [1,2]... but I'm not a
windows AD admin so not eager to try this out

Regards,

Richard Duivenvoorde

[1]
https://www.freeipa.org/page/Setting_up_Active_Directory_domain_for_testing_purposes
[2] https://www.microsoft.com/en-us/windows-server/trial

Overkamp_Stefan · June 1, 2020, 6:39am

Hi list,

we are running geoserver 2.17.0 in a docker container with
tomcat:9.0.31-jdk11-openjdk
and have no problems.

I took a look into our ticket system and found an issue 2 month ago with
ldap
I had to change geoserver/security/role/[ourroleservicename]/config.xml
from

|<useTLS>true</useTLS> |

to

|<useTLS>false</useTLS> |

Maybe there ist the same server configuration change on Richards ldap site.

Stefan

Am 31.05.2020 um 16:43 schrieb Richard Duivenvoorde:

On 5/29/20 7:01 PM, Andrea Aime wrote:

On Fri, May 29, 2020 at 2:56 PM Richard Duivenvoorde
<rdmailings@anonymised.com <mailto:rdmailings@anonymised.com>> wrote:

    Anybody a clue? Only thing that changes is java (and I cannot test that
    because 2.13 does not work with java11, and 2.16 not with java8 (mmm
    THAT I did test).

Mind, in my company we run 2.16.x and 2.17.x with Java 8 exclusively,
without issues.
We either use the official distribution repositories, if they provide a
recent Java 8 build,
or just get it from AdoptOpenJDK otherwise.

Ok, further testing 2.16 and 2.17 with jdk8(!): NOT working either
(using the datadir from de working 2.13).

So I downloaded 2.15: not working
then downloaded 2.14: working (!) (both with 2.13 datadir)

So... it seems not jdk related?

Then I remembered this tutorial there was a testing ldap jar mentioned in:
https://docs.geoserver.org/latest/en/user/security/tutorials/ldap/index.html

Note that the download url is not working anymore:

http://files.opengeo.org/geoserver/acme-ldap.jar <== not working

But I had an acme-ldap.jar somewhere on an old working station.

THAT was working fine .. for 2.13 till 2.17 so...
(using the exact setup from tutorial and again sf:roads as layer).

It is apparently something ActiveDirectory related?
OR a local problem ...

Anybody else authentication against AD in a recent geoserver?
Or anybody else is able to test against a local AD?
My test result is 2.13 and 2.14 working fine
2.15 and up not working.

Next step would be to setup an AD in a VM now [1,2]... but I'm not a
windows AD admin so not eager to try this out

Regards,

Richard Duivenvoorde

[1]
https://www.freeipa.org/page/Setting_up_Active_Directory_domain_for_testing_purposes
[2] https://www.microsoft.com/en-us/windows-server/trial

_______________________________________________
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

--
Dipl. Ing. Stefan Overkamp
Laakmannsbusch 44, 42555 Velbert
tel.: 0177 / 79 76 159
overkamp@anonymised.com

Richard_Duivenvoord1 · June 1, 2020, 11:23am

Hi Stefan,

Thank, for the check! I was eager to see if it fitted, but we already
did not configure TLS ... I tested both, but without success
Are you authenticating against an Active Directory, or ldap?

Pretty frustrating this. There is so much to configure with magic terms
like (member={0}) etc etc, and 'Group Search base' on different config
pages.

There has to be some difference. I even swapped the spring-ldap jars in
the versions (without success).
Tried the 'group search' thingie etc etc

There is (to me) no way to see what is sended/received (LDAP-wise)
because only the abstract filter and outcome are logged (and THOSE are
exactly the same, except that 2.13 is returning a set and >2.15 is not)?

Regards,
Richard Duivenvoorde

On 6/1/20 8:39 AM, Stefan Overkamp wrote:

Hi list,

we are running geoserver 2.17.0 in a docker container with
tomcat:9.0.31-jdk11-openjdk
and have no problems.

I took a look into our ticket system and found an issue 2 month ago with
ldap
I had to change geoserver/security/role/[ourroleservicename]/config.xml
from

|<useTLS>true</useTLS> |

to

|<useTLS>false</useTLS> |

Maybe there ist the same server configuration change on Richards ldap site.

Stefan

Overkamp_Stefan · June 1, 2020, 3:33pm

Hi Richard,

we are using LDAP.
LDAp was already running fine 2 years ago with Geoserver 2.13 when I
joined my new employer.
Our role service confguration (german ui) is approximately as follows:

Administrator Role: ROLE_ADMIN
Group administrator role: ROLE_GRUPPEN_ADMIN
Server-URL: ldap://****.de:389/dc=huhu,dc=de
No TLS
search base for groups; ou=ogc_dienste
Suchfilter für Gruppenzugehörigkeit von Benutzern:
member=cn={0},ou=user,dc=huhu,dc=de
Suchfilter für alle Gruppen: cn=*
verwendeter Filter für Benutzersuche: member=cn={0},ou=user,dc=huhu,dc=de
authentification credentials
and not Enable Hierarchical groups search

Stefan

Am 01.06.2020 um 13:23 schrieb Richard Duivenvoorde:

Hi Stefan,

Thank, for the check! I was eager to see if it fitted, but we already
did not configure TLS ... I tested both, but without success
Are you authenticating against an Active Directory, or ldap?

Pretty frustrating this. There is so much to configure with magic terms
like (member={0}) etc etc, and 'Group Search base' on different config
pages.

There has to be some difference. I even swapped the spring-ldap jars in
the versions (without success).
Tried the 'group search' thingie etc etc

There is (to me) no way to see what is sended/received (LDAP-wise)
because only the abstract filter and outcome are logged (and THOSE are
exactly the same, except that 2.13 is returning a set and >2.15 is not)?

Regards,
Richard Duivenvoorde

On 6/1/20 8:39 AM, Stefan Overkamp wrote:

Hi list,

we are running geoserver 2.17.0 in a docker container with
tomcat:9.0.31-jdk11-openjdk
and have no problems.

I took a look into our ticket system and found an issue 2 month ago with
ldap
I had to change geoserver/security/role/[ourroleservicename]/config.xml
from

|<useTLS>true</useTLS> |

to

|<useTLS>false</useTLS> |

Maybe there ist the same server configuration change on Richards ldap site.

Stefan

--
Dipl. Ing. Stefan Overkamp
Laakmannsbusch 44, 42555 Velbert
tel.: 0177 / 79 76 159
overkamp@anonymised.com

Humphries_Graham · June 1, 2020, 9:40pm

As I understand it not using TLS in your LDAP configuration means your authentication details are being passed as plain text. This is a serious security problem.

-----Original Message-----
From: Stefan Overkamp [mailto:overkamp@…9782…]
Sent: Tuesday, 2 June 2020 1:34 AM
To: rdmailings@...5924...
Cc: GeoServer Mailing List List <geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] ldap security issues in 2.16/17

Hi Richard,

we are using LDAP.
LDAp was already running fine 2 years ago with Geoserver 2.13 when I joined my new employer.
Our role service confguration (german ui) is approximately as follows:

Administrator Role: ROLE_ADMIN
Group administrator role: ROLE_GRUPPEN_ADMIN
Server-URL: ldap://****.de:389/dc=huhu,dc=de No TLS search base for groups; ou=ogc_dienste Suchfilter für Gruppenzugehörigkeit von Benutzern:
member=cn={0},ou=user,dc=huhu,dc=de
Suchfilter für alle Gruppen: cn=*
verwendeter Filter für Benutzersuche: member=cn={0},ou=user,dc=huhu,dc=de
authentification credentials
and not Enable Hierarchical groups search

Stefan

Am 01.06.2020 um 13:23 schrieb Richard Duivenvoorde:

Hi Stefan,

Thank, for the check! I was eager to see if it fitted, but we already
did not configure TLS ... I tested both, but without success Are you
authenticating against an Active Directory, or ldap?

Pretty frustrating this. There is so much to configure with magic
terms like (member={0}) etc etc, and 'Group Search base' on different
config pages.

There has to be some difference. I even swapped the spring-ldap jars
in the versions (without success).
Tried the 'group search' thingie etc etc

There is (to me) no way to see what is sended/received (LDAP-wise)
because only the abstract filter and outcome are logged (and THOSE are
exactly the same, except that 2.13 is returning a set and >2.15 is not)?

Regards,
Richard Duivenvoorde

On 6/1/20 8:39 AM, Stefan Overkamp wrote:

Hi list,

we are running geoserver 2.17.0 in a docker container with
tomcat:9.0.31-jdk11-openjdk and have no problems.

I took a look into our ticket system and found an issue 2 month ago
with ldap I had to change
geoserver/security/role/[ourroleservicename]/config.xml
from

|<useTLS>true</useTLS> |

to

|<useTLS>false</useTLS> |

Maybe there ist the same server configuration change on Richards ldap site.

Stefan

--
Dipl. Ing. Stefan Overkamp
Laakmannsbusch 44, 42555 Velbert
tel.: 0177 / 79 76 159
overkamp@...9782...

_______________________________________________
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: https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ianturton.com%2Ftalks%2Ffoss4g.html%23%2F&data=02|01|graham.humphries%40stategrowth.tas.gov.au|de3c33fccca34354482f08d806419501|64ebab8accf44b5ca2d32b4e972d96b2|0|0|637266226036263956&sdata=WDd6z6MDyajMQDijd3kTvInztAgGrQBpEPEUzugiwhg%3D&reserved=0
- The GeoServer user list posting guidelines: https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeoserver.org%2Fcomm%2Fuserlist-guidelines.html&data=02|01|graham.humphries%40stategrowth.tas.gov.au|de3c33fccca34354482f08d806419501|64ebab8accf44b5ca2d32b4e972d96b2|0|0|637266226036263956&sdata=rN6BMyi7mWPh9YD5uumcXez%2BGms1EteQBd0l8Oq4Dtk%3D&reserved=0

If you want to request a feature or an improvement, also see this: https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgeoserver%2Fgeoserver%2Fwiki%2FSuccessfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer&data=02|01|graham.humphries%40stategrowth.tas.gov.au|de3c33fccca34354482f08d806419501|64ebab8accf44b5ca2d32b4e972d96b2|0|0|637266226036263956&sdata=gf12fKL9X4B7oV5NmDbeyoukHAsXmdRQKdwmHUlnevo%3D&reserved=0

Geoserver-users@lists.sourceforge.net
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fgeoserver-users&data=02|01|graham.humphries%40stategrowth.tas.gov.au|de3c33fccca34354482f08d806419501|64ebab8accf44b5ca2d32b4e972d96b2|0|0|637266226036263956&sdata=TntSFrRTX8E7xSnvSxNaCW99gKOymfQoTX4t88NjJvc%3D&reserved=0

________________________________

CONFIDENTIALITY NOTICE AND DISCLAIMER
The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.

Overkamp_Stefan · June 2, 2020, 6:15am

Not, when Geoserver and the ldap service are in the same private
network. Or?

Stefan

Am 01.06.2020 um 23:40 schrieb Humphries, Graham:

As I understand it not using TLS in your LDAP configuration means your authentication details are being passed as plain text. This is a serious security problem.

-----Original Message-----
From: Stefan Overkamp [mailto:overkamp@anonymised.com]
Sent: Tuesday, 2 June 2020 1:34 AM
To: rdmailings@anonymised.com
Cc: GeoServer Mailing List List <geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] ldap security issues in 2.16/17

Hi Richard,

we are using LDAP.
LDAp was already running fine 2 years ago with Geoserver 2.13 when I joined my new employer.
Our role service confguration (german ui) is approximately as follows:

Administrator Role: ROLE_ADMIN
Group administrator role: ROLE_GRUPPEN_ADMIN
Server-URL: ldap://****.de:389/dc=huhu,dc=de No TLS search base for groups; ou=ogc_dienste Suchfilter für Gruppenzugehörigkeit von Benutzern:
member=cn={0},ou=user,dc=huhu,dc=de
Suchfilter für alle Gruppen: cn=*
verwendeter Filter für Benutzersuche: member=cn={0},ou=user,dc=huhu,dc=de
authentification credentials
and not Enable Hierarchical groups search

Stefan

Am 01.06.2020 um 13:23 schrieb Richard Duivenvoorde:

Hi Stefan,

Thank, for the check! I was eager to see if it fitted, but we already
did not configure TLS ... I tested both, but without success Are you
authenticating against an Active Directory, or ldap?

Pretty frustrating this. There is so much to configure with magic
terms like (member={0}) etc etc, and 'Group Search base' on different
config pages.

There has to be some difference. I even swapped the spring-ldap jars
in the versions (without success).
Tried the 'group search' thingie etc etc

There is (to me) no way to see what is sended/received (LDAP-wise)
because only the abstract filter and outcome are logged (and THOSE are
exactly the same, except that 2.13 is returning a set and >2.15 is not)?

Regards,
Richard Duivenvoorde

On 6/1/20 8:39 AM, Stefan Overkamp wrote:

Hi list,

we are running geoserver 2.17.0 in a docker container with
tomcat:9.0.31-jdk11-openjdk and have no problems.

I took a look into our ticket system and found an issue 2 month ago
with ldap I had to change
geoserver/security/role/[ourroleservicename]/config.xml
from

|<useTLS>true</useTLS> |

to

|<useTLS>false</useTLS> |

Maybe there ist the same server configuration change on Richards ldap site.

Stefan

--
Dipl. Ing. Stefan Overkamp
Laakmannsbusch 44, 42555 Velbert
tel.: 0177 / 79 76 159
overkamp@anonymised.com

_______________________________________________
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: https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ianturton.com%2Ftalks%2Ffoss4g.html%23%2F&data=02|01|graham.humphries%40stategrowth.tas.gov.au|de3c33fccca34354482f08d806419501|64ebab8accf44b5ca2d32b4e972d96b2|0|0|637266226036263956&sdata=WDd6z6MDyajMQDijd3kTvInztAgGrQBpEPEUzugiwhg%3D&reserved=0
- The GeoServer user list posting guidelines: https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeoserver.org%2Fcomm%2Fuserlist-guidelines.html&data=02|01|graham.humphries%40stategrowth.tas.gov.au|de3c33fccca34354482f08d806419501|64ebab8accf44b5ca2d32b4e972d96b2|0|0|637266226036263956&sdata=rN6BMyi7mWPh9YD5uumcXez%2BGms1EteQBd0l8Oq4Dtk%3D&reserved=0

If you want to request a feature or an improvement, also see this: https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgeoserver%2Fgeoserver%2Fwiki%2FSuccessfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer&data=02|01|graham.humphries%40stategrowth.tas.gov.au|de3c33fccca34354482f08d806419501|64ebab8accf44b5ca2d32b4e972d96b2|0|0|637266226036263956&sdata=gf12fKL9X4B7oV5NmDbeyoukHAsXmdRQKdwmHUlnevo%3D&reserved=0

Geoserver-users@lists.sourceforge.net
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fgeoserver-users&data=02|01|graham.humphries%40stategrowth.tas.gov.au|de3c33fccca34354482f08d806419501|64ebab8accf44b5ca2d32b4e972d96b2|0|0|637266226036263956&sdata=TntSFrRTX8E7xSnvSxNaCW99gKOymfQoTX4t88NjJvc%3D&reserved=0

________________________________

CONFIDENTIALITY NOTICE AND DISCLAIMER
The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.

--
Dipl. Ing. Stefan Overkamp
Laakmannsbusch 44, 42555 Velbert
tel.: 0177 / 79 76 159
overkamp@anonymised.com

Richard_Duivenvoord1 · June 2, 2020, 6:41am

On 6/2/20 8:15 AM, Stefan Overkamp wrote:

Not, when Geoserver and the ldap service are in the same private
network. Or?

Yes this is a private Windows Office environment
(and not LDAP, but an Active Directory server).
Not sure what the standard is in the AD world.

I'm just an user of a running setup, but if you tell me that the rest of
the world is using AD over SSL I will pass it on.

Regards,
Richard Duivenvoorde

Humphries_Graham · June 2, 2020, 9:47pm

It is still passed as plain text, but it would not be visible to anyone outside your network.

-----Original Message-----
From: Stefan Overkamp [mailto:overkamp@…9782…]
Sent: Tuesday, 2 June 2020 4:15 PM
To: Humphries, Graham <Graham.Humphries@...9749...>; rdmailings@...5924...
Cc: GeoServer Mailing List List <geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] ldap security issues in 2.16/17

Not, when Geoserver and the ldap service are in the same private network. Or?

Stefan

Am 01.06.2020 um 23:40 schrieb Humphries, Graham:

As I understand it not using TLS in your LDAP configuration means your authentication details are being passed as plain text. This is a serious security problem.

-----Original Message-----
From: Stefan Overkamp [mailto:overkamp@…9782…]
Sent: Tuesday, 2 June 2020 1:34 AM
To: rdmailings@...5924...
Cc: GeoServer Mailing List List
<geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] ldap security issues in 2.16/17

Hi Richard,

we are using LDAP.
LDAp was already running fine 2 years ago with Geoserver 2.13 when I joined my new employer.
Our role service confguration (german ui) is approximately as follows:

Administrator Role: ROLE_ADMIN
Group administrator role: ROLE_GRUPPEN_ADMIN
Server-URL: ldap://****.de:389/dc=huhu,dc=de No TLS search base for groups; ou=ogc_dienste Suchfilter für Gruppenzugehörigkeit von Benutzern:
member=cn={0},ou=user,dc=huhu,dc=de
Suchfilter für alle Gruppen: cn=*
verwendeter Filter für Benutzersuche:
member=cn={0},ou=user,dc=huhu,dc=de
authentification credentials
and not Enable Hierarchical groups search

Stefan

Am 01.06.2020 um 13:23 schrieb Richard Duivenvoorde:

Hi Stefan,

Thank, for the check! I was eager to see if it fitted, but we already
did not configure TLS ... I tested both, but without success Are you
authenticating against an Active Directory, or ldap?

Pretty frustrating this. There is so much to configure with magic
terms like (member={0}) etc etc, and 'Group Search base' on different
config pages.

There has to be some difference. I even swapped the spring-ldap jars
in the versions (without success).
Tried the 'group search' thingie etc etc

There is (to me) no way to see what is sended/received (LDAP-wise)
because only the abstract filter and outcome are logged (and THOSE
are exactly the same, except that 2.13 is returning a set and >2.15 is not)?

Regards,
Richard Duivenvoorde

On 6/1/20 8:39 AM, Stefan Overkamp wrote:

Hi list,

we are running geoserver 2.17.0 in a docker container with
tomcat:9.0.31-jdk11-openjdk and have no problems.

I took a look into our ticket system and found an issue 2 month ago
with ldap I had to change
geoserver/security/role/[ourroleservicename]/config.xml
from

|<useTLS>true</useTLS> |

to

|<useTLS>false</useTLS> |

Maybe there ist the same server configuration change on Richards ldap site.

Stefan

--
Dipl. Ing. Stefan Overkamp
Laakmannsbusch 44, 42555 Velbert
tel.: 0177 / 79 76 159
overkamp@...9782...

_______________________________________________
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:
https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.i
anturton.com%2Ftalks%2Ffoss4g.html%23%2F&data=02%7C01%7CGraham.Hum
phries%40stategrowth.tas.gov.au%7C6258323bb8224c6a976b08d806bc4ddd%7C6
4ebab8accf44b5ca2d32b4e972d96b2%7C0%7C0%7C637266753130159290&sdata
=k5uszMbW1kBLv8j9hLXL96Gf7kr6HfMJHOHNCXdD%2FWI%3D&reserved=0
- The GeoServer user list posting guidelines:
https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeose
rver.org%2Fcomm%2Fuserlist-guidelines.html&data=02%7C01%7CGraham.H
umphries%40stategrowth.tas.gov.au%7C6258323bb8224c6a976b08d806bc4ddd%7
C64ebab8accf44b5ca2d32b4e972d96b2%7C0%7C0%7C637266753130159290&sda
ta=aWM7EKRzkxFGcHi91zQkj9FOeM6EcNUjQ6nz77Va%2F14%3D&reserved=0

If you want to request a feature or an improvement, also see this:
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2Fgeoserver%2Fgeoserver%2Fwiki%2FSuccessfully-requesting-and-in
tegrating-new-features-and-improvements-in-GeoServer&data=02%7C01%
7CGraham.Humphries%40stategrowth.tas.gov.au%7C6258323bb8224c6a976b08d8
06bc4ddd%7C64ebab8accf44b5ca2d32b4e972d96b2%7C0%7C0%7C6372667531301592
90&sdata=k4%2FtOVO3593UF9gTkFAWQ64yfqB76BcxlD2fwbGGT5I%3D&rese
rved=0

Geoserver-users@lists.sourceforge.net
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
s.sourceforge.net%2Flists%2Flistinfo%2Fgeoserver-users&data=02%7C0
1%7CGraham.Humphries%40stategrowth.tas.gov.au%7C6258323bb8224c6a976b08
d806bc4ddd%7C64ebab8accf44b5ca2d32b4e972d96b2%7C0%7C0%7C63726675313015
9290&sdata=L%2BRSllgh%2BYcttaYwp7uCv%2FUlPnDvxUSa26kd0G%2BAj%2FU%3
D&reserved=0

________________________________

CONFIDENTIALITY NOTICE AND DISCLAIMER
The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.

--
Dipl. Ing. Stefan Overkamp
Laakmannsbusch 44, 42555 Velbert
tel.: 0177 / 79 76 159
overkamp@...9782...

________________________________

CONFIDENTIALITY NOTICE AND DISCLAIMER
The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.