Hi,
In order to help set up https protected scripts for LDAP activities, I
did the following:
1. a2enmod ssl
2. Added the following to /etc/apache2/sites-enabled/000-default:
<VirtualHost 140.211.15.66:443>
SSLEngine on
ServerName www2.osgeo.org
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLCertificateFile /etc/ssl/certs/STAR_osgeo_org.crt
SSLCertificateKeyFile /etc/ssl/private/osgeo.key
SSLCACertificateFile /etc/ssl/certs/COMODOHigh-AssuranceSecureServerCA.crt
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
</VirtualHost>
This seems to have enabled URLs like:
https://www2.osgeo.org/cgi-bin/auth/ldap_group.py
to work.
Prior to that, I had done:
$ a2enmod ldap
$ a2enmod authnz_ldap
These allowed for LDAP auth configurations like on the tracsvn server to work correctly.
-- Chris
On 11-05-24 07:41 PM, christopher.schmidt@nokia.com wrote:
Hi,
In order to help set up https protected scripts for LDAP activities, I
did the following:
...
Folks,
As additional steps I have added rewrite rules (in
/etc/httpd/conf.d/rewrite.conf and /etc/httpd/conf.d/ssl.conf) on osgeo1
to forward /cgi-bin/ldap* and /cgi-bin/auth/ldap* urls to www2.osgeo.org
which is the web VM. This means that old urls for creating and managing
LDAP ids and groups should now work by redirection.
I have made minor updates to the wiki topic about LDAP to identify where
these scripts live now.
http://wiki.osgeo.org/wiki/SAC:LDAP#LDAP
I have also added the very very very brief "web vm" information available
at the following url to note the LDAP admin scripts.
http://wiki.osgeo.org/wiki/SAC_Service_Status#Web
I notice that the Service Status page above does not reflect the fact that
the secure vm is now in use as the LDAP server. I updated SAC:LDAP to
note that the ldap server is actually now on the secure vm, but it would be
nice to have an actual wiki page about the secure vm.
Martin - I'd appreciate it if you could review the SAC:LDAP page section at:
http://wiki.osgeo.org/wiki/SAC:LDAP#OpenLDAP
to ensure it is current with regard to how to administer things.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
It seems something is affecting the way drupal does it's LDAP authentication. Should I point it to a different server or parameters? Guess I'm just wondering may have changed and which settings I'll have to update.
Tyler
On 2011-05-24, at 7:47 PM, Frank Warmerdam wrote:
On 11-05-24 07:41 PM, christopher.schmidt@nokia.com wrote:
Hi,
In order to help set up https protected scripts for LDAP activities, I
did the following:
...
Folks,
As additional steps I have added rewrite rules (in
/etc/httpd/conf.d/rewrite.conf and /etc/httpd/conf.d/ssl.conf) on osgeo1
to forward /cgi-bin/ldap* and /cgi-bin/auth/ldap* urls to www2.osgeo.org
which is the web VM. This means that old urls for creating and managing
LDAP ids and groups should now work by redirection.
I have made minor updates to the wiki topic about LDAP to identify where
these scripts live now.
http://wiki.osgeo.org/wiki/SAC:LDAP#LDAP
I have also added the very very very brief "web vm" information available
at the following url to note the LDAP admin scripts.
http://wiki.osgeo.org/wiki/SAC_Service_Status#Web
I notice that the Service Status page above does not reflect the fact that
the secure vm is now in use as the LDAP server. I updated SAC:LDAP to
note that the ldap server is actually now on the secure vm, but it would be
nice to have an actual wiki page about the secure vm.
Martin - I'd appreciate it if you could review the SAC:LDAP page section at:
http://wiki.osgeo.org/wiki/SAC:LDAP#OpenLDAP
to ensure it is current with regard to how to administer things.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
On 11-05-25 03:58 AM, Tyler Mitchell wrote:
It seems something is affecting the way drupal does it's LDAP
authentication. Should I point it to a different server or parameters?
Guess I'm just wondering may have changed and which settings I'll have to
update.
Tyler,
Is this a question related to problems logging on to Drupal on osgeo1 or
on the web vm? My first assumption was that your question related to the
topic of the email (ie. drupal on the web vm), but on second thought I
suspect it is really the user login to drupal on osgeo1 problem that Jeff
reported. Is that right?
I can confirm I also can't login to Drupal on osgeo1 - presumably a result
of the LDAP server move and it's restrictions to ldaps, etc. So I think
this question is between you as drupal guy and Martin as ldap guy.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
Hi folks,
I'm sorry about responding that late. I had been absorbed almost
completely (and pretty much unexpectedly) by some other stuff over the
past days.
On Wed, May 25, 2011 at 08:24:36AM -0400, Frank Warmerdam wrote:
I can confirm I also can't login to Drupal on osgeo1 - presumably a result
of the LDAP server move and it's restrictions to ldaps, etc. So I think
this question is between you as drupal guy and Martin as ldap guy.
Actually among the tests I did after the LDAP server migration was to
log into Trac at:
https://trac.osgeo.org/grass/login
.... as well as into the main web site via:
https://www.osgeo.org/user
I'm not certain if we're talking about the same login but I'll assure
you that both of the above tests completed successfully with my user ID
.... aaah, wait, now my login doesn't work any more on the main web
site, while the Trac login is still functional.
Very strange, that's certainly something to look after .... :-/
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
Very strange, that's certainly something to look after .... :-/
Thanks Martin, Frank, yes I was thinking of the main osgeo1 drupal instance. Thanks for testing that Martin. I'll try to get into it and see what the current LDAP settings are and get your feedback on how to improve them.
Tyler
ldap.osgeo.org is still where it should be pointing, right?
On 2011-05-25, at 5:52 AM, Martin Spott wrote:
Hi folks,
I'm sorry about responding that late. I had been absorbed almost
completely (and pretty much unexpectedly) by some other stuff over the
past days.
On Wed, May 25, 2011 at 08:24:36AM -0400, Frank Warmerdam wrote:
I can confirm I also can't login to Drupal on osgeo1 - presumably a result
of the LDAP server move and it's restrictions to ldaps, etc. So I think
this question is between you as drupal guy and Martin as ldap guy.
Actually among the tests I did after the LDAP server migration was to
log into Trac at:
https://trac.osgeo.org/grass/login
.... as well as into the main web site via:
https://www.osgeo.org/user
I'm not certain if we're talking about the same login but I'll assure
you that both of the above tests completed successfully with my user ID
.... aaah, wait, now my login doesn't work any more on the main web
site, while the Trac login is still functional.
Very strange, that's certainly something to look after .... :-/
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
I've tried all permutations of port numbers 389 or 636, with/without StartTLS option and having no luck.
I checked my connection data with those in Frank's scripts to confirm I had the same user/pass for non-anonymous searches.
It used to run using port 389 but that connection is rejected by ldap.osgeo.org when trying from osgeo1. I get a response at least on 636 but drupal doesn't get through.
Do we have an anonymous search uid available?
Any thoughts?
Tyler
On 2011-05-25, at 10:38 AM, Tyler Mitchell wrote:
ldap.osgeo.org is still where it should be pointing, right?
On 2011-05-25, at 5:52 AM, Martin Spott wrote:
Hi folks,
I'm sorry about responding that late. I had been absorbed almost
completely (and pretty much unexpectedly) by some other stuff over the
past days.
On Wed, May 25, 2011 at 08:24:36AM -0400, Frank Warmerdam wrote:
I can confirm I also can't login to Drupal on osgeo1 - presumably a result
of the LDAP server move and it's restrictions to ldaps, etc. So I think
this question is between you as drupal guy and Martin as ldap guy.
Actually among the tests I did after the LDAP server migration was to
log into Trac at:
https://trac.osgeo.org/grass/login
.... as well as into the main web site via:
https://www.osgeo.org/user
I'm not certain if we're talking about the same login but I'll assure
you that both of the above tests completed successfully with my user ID
.... aaah, wait, now my login doesn't work any more on the main web
site, while the Trac login is still functional.
Very strange, that's certainly something to look after .... :-/
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
On Wed, May 25, 2011 at 10:38:10AM -0700, Tyler Mitchell wrote:
ldap.osgeo.org is still where it should be pointing, right?
The DNS entry for 'ldap.osgeo.org' should point to the same IP number
as 'secure.osgeo.osuosl.org' - from my perspective it does.
Note, the old LDAP server on 'osgeo1' is still running for test reasons
but it's set non-writeable and should not be referred to anymore for
regular service. Anyhow it's been helpful for debugging LDAP client
configuration on 'hyperquad'.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On 2011-05-25, at 11:19 AM, Martin Spott wrote:
The DNS entry for 'ldap.osgeo.org' should point to the same IP number
as 'secure.osgeo.osuosl.org' - from my perspective it does.
It looks right to me too.
Note, the old LDAP server on 'osgeo1' is still running for test reasons
I can still connect to localhost fine on 389. Not on 636 though.
On Wed, May 25, 2011 at 11:19:05AM -0700, Tyler Mitchell wrote:
It used to run using port 389 but that connection is rejected by
ldap.osgeo.org when trying from osgeo1. I get a response at least on
636 but drupal doesn't get through.
Unencrypted LDAP on port 389 is not available anymore on the new LDAP
server - simply for security reasons. I don't want every password hash
to go over non-local connections without encryption.
Do we have an anonymous search uid available?
On Unix LDAP we don't need any particular UID for anonymous search - in
contrary to M$ ADS 
But to me it looks like you're having a point - at least this is the
track I'm following: Whereas anonymous search works quite well from all
the new VM's as well as a couple more 'standalone' machines (note:
different distros involved !), it's getting a "certificate verify
failed" response when trying to connect from 'osgeo1'. If this is the
right track, then we'll have a solution very soon ....
Yet I wonder why this had been working perfectly on the first tests I
did immediately after migrating the LDAP server.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On 2011-05-25, at 11:36 AM, Martin Spott wrote:
But to me it looks like you're having a point - at least this is the
track I'm following: Whereas anonymous search works quite well from all
the new VM's as well as a couple more 'standalone' machines (note:
different distros involved !), it's getting a "certificate verify
failed" response when trying to connect from 'osgeo1'. If this is the
right track, then we'll have a solution very soon ....
I think you're on to something there. I will also try to get the drupal instance on www3.osgeo.org (web vm) to authenticate with LDAP - so far no luck. I'm not sure if the LDAP module for drupal just sucks or not, but I wonder if we need some certificate stuff done on there too.
Thanks for looking into it!
Tyler
On Wed, May 25, 2011 at 02:52:15PM +0200, Martin Spott wrote:
Very strange, that's certainly something to look after .... :-/
osgeo1: 15:58:44 ~> /usr/bin/ldapsearch -d1 -H ldaps://ldap.osgeo.org/ -b dc=osgeo,dc=org -x
[...]
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, err: 2, subject: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO High-Assurance Secure Server CA, issuer: /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
TLS certificate verification: Error, unable to get issuer certificate
TLS trace: SSL3 alert write:fatal:unknown CA
As far as I remember, this tastes similar to my attempts of getting the
LDAP server on the new "secure" VM running with the old OSGeo SSL
certificate. Maybe I'm now just looking into the opposite direction.
BTW, this posting looks terribly encouraging ....:
http://www.mail-archive.com/ldap@listserver.itd.umich.edu/msg00377.html
Ok, now I managed to get 'ldapsearch' working by configuring the LDAP
client lib on 'osgeo1' to "not request or check any server
certificate". This doesn't sound convincing, but might serve as an
interim solution.
Drupal authentication is still not working as expected.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
Could anyone please tell me if there's some OSGeo-specific LDAP
configuration inside Drupal - aside from the general LDAP config at
Apache level - and where I can have a closer look at it ?
Thanks,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Tue, May 24, 2011 at 10:47:07PM -0400, Frank Warmerdam wrote:
Martin - I'd appreciate it if you could review the SAC:LDAP page section at:
http://wiki.osgeo.org/wiki/SAC:LDAP#OpenLDAP
to ensure it is current with regard to how to administer things.
Will do after the transition trouble is over and the server on 'osgeo1'
has been shut down.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Wed, May 25, 2011 at 10:18:30PM +0200, Martin Spott wrote:
Could anyone please tell me if there's some OSGeo-specific LDAP
configuration inside Drupal - aside from the general LDAP config at
Apache level - and where I can have a closer look at it ?
# ~> find /var/www/html/ -type f -exec grep -l "dc=osgeo" {} \;
.... didn't return a single hit,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
Could anyone please tell me if there's some OSGeo-specific LDAP
configuration inside Drupal - aside from the general LDAP config at
Apache level - and where I can have a closer look at it ?
It's all in the drupal database, accessible if you log in as the "admin" user, then goto:
https://www.osgeo.org/admin/settings/ldapauth
Optionally it's directly accessible in the db table ldapauth in db drupal_osgeo.
Let me know if you need more help.
On Wed, May 25, 2011 at 02:47:52PM -0700, Tyler Mitchell wrote:
It's all in the drupal database, accessible if you log in as the "admin" user, then goto:
https://www.osgeo.org/admin/settings/ldapauth
Ah, I see. It looks like this module allows to enable TLS on the
default LDAP port, but it doesn't do regular SSL-encrypted connections.
In the long term it would be highly preferrable to let Drupal do LDAP
over regular SSL, as an interim solution I'll try to enforce TLS on the
default LDAP port on the server.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On 2011-05-25, at 3:39 PM, Martin Spott wrote:
Ah, I see. It looks like this module allows to enable TLS on the
default LDAP port, but it doesn't do regular SSL-encrypted connections.
In the long term it would be highly preferrable to let Drupal do LDAP
over regular SSL, as an interim solution I'll try to enforce TLS on the
default LDAP port on the server.
It's encouraging to meet someone who knows the difference between SSL and TLS.. because I sure don't 
Sounds like you have a good plan. Let me know if you need me to test anything.
Tyler
On Wed, May 25, 2011 at 03:43:50PM -0700, Tyler Mitchell wrote:
It's encouraging to meet someone who knows the difference between SSL
and TLS.. because I sure don't
To put it simple, "TLS" means: Establish the network connection without
encryption, typically on the standard port for unencrypted connections,
and switch over to encryption during application level handshake, at
least before authentication. This is pretty common for encrypted SMTP
connections, BTW.
"SSL" in contrast establishes an encrypted connection right from the
beginning.
Sounds like you have a good plan. Let me know if you need me to test anything.
I'll be able to do the testing myself, as I can reproduce the Drupal
login failure with my own account.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------