Is it possible to prevent anonymous and unauthenticated binds to ldaps:// 636 but allow them on ldap:// 389?
I want to allow staff to query my ldaps:// outside of my network while requiring them to login to do so but allow anyone to bind (anonymous, unauthenticated, or authenticated) internally on ldaps//: 389.
I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports. I want to stop it just on ldaps://.
Chris Jackson
I want to apologize in advance for the forthcoming duplicated messages. My original question wasnt very clear and neither of them were getting to the list and I didnt know why. Maybe a 24hr lock out for new posters.
Chris Jackson
On Feb 11, 2011, at 9:50 AM, Chris Jackson wrote:
Is it possible to prevent anonymous and unauthenticated binds to ldaps:// 636 but allow them on ldap:// 389?
I want to allow staff to query my ldaps:// outside of my network while requiring them to login to do so but allow anyone to bind (anonymous, unauthenticated, or authenticated) internally on ldaps//: 389.
I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports. I want to stop it just on ldaps://.
Chris Jackson
Le 11/02/2011 18:58, Chris Jackson a écrit :
I want to apologize in advance for the forthcoming duplicated messages. My original question wasnt very clear and neither of them were getting to the list and I didnt know why. Maybe a 24hr lock out for new posters.
Not exactly - new subscriber's posts are subjected to human moderation, which takes a variable amount of time, as explained on the OpenLDAP.org mailing list page (http://www.openldap.org/lists/):
Each of our lists operates under a charter (published on the "list info" page referenced above). In is expected that each participant to stay within that charter. Submissions, especially those from new subscribers, may be subjected to review by a human moderator. Acceptable submissions are generally approved in less than one day, while unacceptable submissions are generally returned in 1-2 days.
Jonathan
Stopping users that are "unauthenticated" makes no sense; everything's unauthenticated at time=0. You might as well stop slapd if you want a 100% inability to serve data.
You can deny anonymous users that aren't plaintext, including any ldaps:/// connections, with something like:
access to * by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break by anonymous none
early on in your ACL stanzas. I'm pretty sure this'll deny anonymous StartTLS users on 389, though; not sure if that's what you want. I can't think of any way to use the slapd access language to differentiate based on listeners, which would probably be the most elegant way to handle what you asked. To be fair, this entire exercise seems really odd from where I sit -- are you positive that this will have the desired effect? (If somebody out in Peru is permitted to connect in unencrypted and make anonymous queries, why not allow them to make those same queries encrypted? What's the difference?)
On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
Is it possible to prevent anonymous and unauthenticated binds to ldaps:// 636 but allow them on ldap:// 389?
I want to allow staff to query my ldaps:// outside of my network while requiring them to login to do so but allow anyone to bind (anonymous, unauthenticated, or authenticated) internally on ldaps//: 389.
I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports. I want to stop it just on ldaps://.
Chris Jackson
On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
Stopping users that are "unauthenticated" makes no sense; everything's unauthenticated at time=0. You might as well stop slapd if you want a 100% inability to serve data.
You can deny anonymous users that aren't plaintext, including any ldaps:/// connections, with something like:
access to * by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break by anonymous none
early on in your ACL stanzas. I'm pretty sure this'll deny anonymous StartTLS users on 389, though; not sure if that's what you want. I can't think of any way to use the slapd access language to differentiate based on listeners, which would probably be the most elegant way to handle what you asked. To be fair, this entire exercise seems really odd from where I sit -- are you positive that this will have the desired effect? (If somebody out in Peru is permitted to connect in unencrypted and make anonymous queries, why not allow them to make those same queries encrypted? What's the difference?)
here is a scenario:
Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall.
Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap.
---Is the only option for them to setup two separate ldap servers? One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon".
Chris Jackson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/14/2011 08:49 PM, Chris Jackson wrote:
here is a scenario:
Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall.
Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap.
---Is the only option for them to setup two separate ldap servers? One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon".
Another option than ACL magic: Wouldn't the x-mod= option to the listening socket, as described in the slapd manpage, help? (slapd -h ldap:/// ldaps:///????x-mod=-rw-------) I have never used it, though, and the manpage says you have to explicitly enable it at compile time.
Ondra
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/14/2011 08:49 PM, Chris Jackson wrote:
here is a scenario:
Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall.
Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap.
---Is the only option for them to setup two separate ldap servers? One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon".
Another option than ACL magic: Wouldn't the x-mod= option to the listening socket, as described in the slapd manpage, help? (slapd -h ldap:/// ldaps:///????x-mod=-rw-------) I have never used it, though, and the manpage says you have to explicitly enable it at compile time.
Don't muck with that, it shouldn't even be mentioned in the man page (my fault).
p.
Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/14/2011 08:49 PM, Chris Jackson wrote:
here is a scenario:
Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall.
Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap.
---Is the only option for them to setup two separate ldap servers? One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon".
Another option than ACL magic: Wouldn't the x-mod= option to the listening socket, as described in the slapd manpage, help? (slapd -h ldap:/// ldaps:///????x-mod=-rw-------) I have never used it, though, and the manpage says you have to explicitly enable it at compile time.
Internet sockets don't have Unix permission bits. The x-mod extension is only for ldapi:// (Unix domain) sockets.
Howard Chu wrote:
Ondrej Kuznik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/14/2011 08:49 PM, Chris Jackson wrote:
here is a scenario:
Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall.
Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap.
---Is the only option for them to setup two separate ldap servers? One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon".
Another option than ACL magic: Wouldn't the x-mod= option to the listening socket, as described in the slapd manpage, help? (slapd -h ldap:/// ldaps:///????x-mod=-rw-------) I have never used it, though, and the manpage says you have to explicitly enable it at compile time.
Internet sockets don't have Unix permission bits. The x-mod extension is only for ldapi:// (Unix domain) sockets.
Actually, if compiled with SLAP_X_LISTENER_MOD, slapd honors Unix-like permissions at the backend selection level, much like otherwise enforced backend restrictions, on a listener basis. Probably, a unified feature exploitation configuration would allow to restrict to listeners in a more configurable manner (right now, listener permissions modifications require to restart the server).
p.
p.
On Mon, Feb 14, 2011 at 07:49:10PM +0000, Chris Jackson wrote:
I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports. I want to stop it just on ldaps://.
Maybe you should stop thinking about ports and start thinking about *where* the LDAP clients are. You can then permit anon access to clients within your own network (by IP range) and permit access by any authenticated user, before denying all other cases. Remember to allow enough access for the external users to connect and bind in the first place!
Note that it is almost impossible to hide the *existance* of an entry, so if DNs are guessable it is possible that a determined outsider could work out who is in your directory.
If some of the data is very sensitive you may prefer to set up an 'outside' server and replicate just a subset of the data to it.
Andrew
Andrew Findlay wrote:
On Mon, Feb 14, 2011 at 07:49:10PM +0000, Chris Jackson wrote:
I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated
bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports. I want to stop it just on ldaps://.
Maybe you should stop thinking about ports and start thinking about *where* the LDAP clients are. You can then permit anon access to clients within your own network (by IP range) and permit access by any authenticated user, before denying all other cases. Remember to allow enough access for the external users to connect and bind in the first place!
Note that it is almost impossible to hide the *existance* of an entry, so if DNs are guessable it is possible that a determined outsider could work out who is in your directory.
See the "disclose" ACL privilege - you can hide the existence if you really want to.
slapd's security mechanisms will support just about any conceivable security policy.
If some of the data is very sensitive you may prefer to set up an 'outside' server and replicate just a subset of the data to it.
Chris Jackson wrote:
On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
Is it possible to prevent anonymous and unauthenticated binds to ldaps:// 636 but allow them on ldap:// 389?
I want to allow staff to query my ldaps:// outside of my network while requiring them to login to do so but allow anyone to bind (anonymous, unauthenticated, or authenticated) internally on ldaps//: 389.
I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports.
Sure, this are global directives.
I want to stop it just on ldaps://.
You don't need ldaps:// in your local network? May be. I think a easier solution is to identify your Internet Gateway by IP.
Chris Jackson
On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
Stopping users that are "unauthenticated" makes no sense; everything's unauthenticated at time=0. You might as well stop slapd if you want a 100% inability to serve data.
You can deny anonymous users that aren't plaintext, including any ldaps:/// connections, with something like:
access to * by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break by anonymous none
early on in your ACL stanzas. I'm pretty sure this'll deny anonymous StartTLS users on 389, though; not sure if that's what you want. I can't think of any way to use the slapd access language to differentiate based on listeners, which would probably be the most elegant way to handle what you asked. To be fair, this entire exercise seems really odd from where I sit -- are you positive that this will have the desired effect? (If somebody out in Peru is permitted to connect in unencrypted and make anonymous queries, why not allow them to make those same queries encrypted? What's the difference?)
here is a scenario:
Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall.
Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap.
---Is the only option for them to setup two separate ldap servers?
No. You should use ACLs to solve this problem. Read man slapd.access an/or search the openldap archives.
Assuming you have a NAT gatway as Firewall machine.
Replace all "by anonymous" statements with these 6 statements:
by anonymous auth continue by peername.ip="127.0.0.1" read continue by peername.ip="10.0.0.0%255.0.0.0" read continue by peername.ip="172.16.0.0%255.240.0.0" read continue by peername.ip="192.168.0.0%255.255.0.0" read continue by peername.ip="gateway-ip" auth
One may write these statements more effective, but in general they will do.
Replace "gateway-ip" with yours.
Put the above statements also in every ACL just before the by * when this ACL do NOT have an "by anonymous" statement.
Maybe the last line could/should be: by ssf=56 peername.ip="gateway-ip" auth
Caveats: Your gateway can no longer access your LDAP Server with the "gateway-ip". But this is a Firewall Design Question.
I've tested this only with unencrypted sessions; anoymous and authenticated. But TLS or SSL will not grant more rights, if you do not tell the ACLs to do so.
Here the output from the two searches:
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn Insufficient access (50)
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D cn=admin,dc=kronprinz,dc=xx -W dn: dc=kronprinz,dc=xx
dn: cn=admin,dc=kronprinz,dc=xx
One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon".
Chris Jackson
On Feb 16, 2011, at 3:46 AM, harry.jede@arcor.de harry.jede@arcor.de wrote:
Chris Jackson wrote:
On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
Is it possible to prevent anonymous and unauthenticated binds to ldaps:// 636 but allow them on ldap:// 389?
I want to allow staff to query my ldaps:// outside of my network while requiring them to login to do so but allow anyone to bind (anonymous, unauthenticated, or authenticated) internally on ldaps//: 389.
I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports.
Sure, this are global directives.
I want to stop it just on ldaps://.
You don't need ldaps:// in your local network? May be. I think a easier solution is to identify your Internet Gateway by IP.
Chris Jackson
On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
Stopping users that are "unauthenticated" makes no sense; everything's unauthenticated at time=0. You might as well stop slapd if you want a 100% inability to serve data.
You can deny anonymous users that aren't plaintext, including any ldaps:/// connections, with something like:
access to * by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break by anonymous none
early on in your ACL stanzas. I'm pretty sure this'll deny anonymous StartTLS users on 389, though; not sure if that's what you want. I can't think of any way to use the slapd access language to differentiate based on listeners, which would probably be the most elegant way to handle what you asked. To be fair, this entire exercise seems really odd from where I sit -- are you positive that this will have the desired effect? (If somebody out in Peru is permitted to connect in unencrypted and make anonymous queries, why not allow them to make those same queries encrypted? What's the difference?)
here is a scenario:
Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall.
Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap.
---Is the only option for them to setup two separate ldap servers?
No. You should use ACLs to solve this problem. Read man slapd.access an/or search the openldap archives.
Assuming you have a NAT gatway as Firewall machine.
Replace all "by anonymous" statements with these 6 statements:
by anonymous auth continue by peername.ip="127.0.0.1" read continue by peername.ip="10.0.0.0%255.0.0.0" read continue by peername.ip="172.16.0.0%255.240.0.0" read continue by peername.ip="192.168.0.0%255.255.0.0" read continue by peername.ip="gateway-ip" auth
One may write these statements more effective, but in general they will do.
Replace "gateway-ip" with yours.
Put the above statements also in every ACL just before the by * when this ACL do NOT have an "by anonymous" statement.
Maybe the last line could/should be: by ssf=56 peername.ip="gateway-ip" auth
Caveats: Your gateway can no longer access your LDAP Server with the "gateway-ip". But this is a Firewall Design Question.
I've tested this only with unencrypted sessions; anoymous and authenticated. But TLS or SSL will not grant more rights, if you do not tell the ACLs to do so.
Here the output from the two searches:
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn Insufficient access (50)
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D cn=admin,dc=kronprinz,dc=xx -W dn: dc=kronprinz,dc=xx
dn: cn=admin,dc=kronprinz,dc=xx
One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon".
Chris Jackson
--
Harry Jede
The above example got me started in the right direction. Everything appears to be doing exactly what I wanted to do. I did notice that the anonymous bind users from ip addresses not 10, give an error 32. Anyone see any flaws in this?
The below ACL should be allowing anon binds when ip address is 10.*.*.* or allow authenticated binds from any ip address.
access to attrs=userpassword by anonymous auth by self read by * none
access to * by anonymous auth continue by users read by peername.ip="10.0.0.0%255.0.0.0" read by * none
Chris
Chris Jackson wrote:
On Feb 16, 2011, at 3:46 AM, harry.jede@arcor.de
harry.jede@arcor.de wrote:
Chris Jackson wrote:
On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
Is it possible to prevent anonymous and unauthenticated binds to ldaps:// 636 but allow them on ldap:// 389?
I want to allow staff to query my ldaps:// outside of my network while requiring them to login to do so but allow anyone to bind (anonymous, unauthenticated, or authenticated) internally on ldaps//: 389.
I know: Anonymous bind can be disabled by "disallow bind_anon" and Unauthenticated bind mechanism is disabled by default. But if I use "disallow bind_anon it stops in on both ports.
Sure, this are global directives.
I want to stop it just on ldaps://.
You don't need ldaps:// in your local network? May be. I think a easier solution is to identify your Internet Gateway by IP.
Chris Jackson
On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
Stopping users that are "unauthenticated" makes no sense; everything's unauthenticated at time=0. You might as well stop slapd if you want a 100% inability to serve data.
You can deny anonymous users that aren't plaintext, including any ldaps:/// connections, with something like:
access to * by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break by anonymous none
early on in your ACL stanzas. I'm pretty sure this'll deny anonymous StartTLS users on 389, though; not sure if that's what you want. I can't think of any way to use the slapd access language to differentiate based on listeners, which would probably be the most elegant way to handle what you asked. To be fair, this entire exercise seems really odd from where I sit -- are you positive that this will have the desired effect? (If somebody out in Peru is permitted to connect in unencrypted and make anonymous queries, why not allow them to make those same queries encrypted? What's the difference?)
here is a scenario:
Site has a ldap server on ldap://389. Firewall blocks access to 389 from internet. Everyone queries the ldap via anonymous binds. Site would like to allow staff the ability to query the ldap from outside the firewall. This would be done via ldaps:// 636 to users who have authenticated via username/password. They do not want to allow anonymous queries outside the firewall.
Using the "disallow bind_anon" would prevent anon binds on both ldap:// and ldaps://. This would break the inside machines ability to query. If we dont use "disallow bind_anon" then machines outside of the firewall could query the ldap.
---Is the only option for them to setup two separate ldap servers?
No. You should use ACLs to solve this problem. Read man slapd.access an/or search the openldap archives.
Assuming you have a NAT gatway as Firewall machine.
Replace all "by anonymous" statements with these 6 statements:
by anonymous auth continue by peername.ip="127.0.0.1" read continue by peername.ip="10.0.0.0%255.0.0.0" read continue by peername.ip="172.16.0.0%255.240.0.0" read continue by peername.ip="192.168.0.0%255.255.0.0" read continue by peername.ip="gateway-ip" auth
One may write these statements more effective, but in general they will do.
Replace "gateway-ip" with yours.
Put the above statements also in every ACL just before the by * when this ACL do NOT have an "by anonymous" statement.
Maybe the last line could/should be: by ssf=56 peername.ip="gateway-ip" auth
Caveats: Your gateway can no longer access your LDAP Server with the "gateway-ip". But this is a Firewall Design Question.
I've tested this only with unencrypted sessions; anoymous and authenticated. But TLS or SSL will not grant more rights, if you do not tell the ACLs to do so.
Here the output from the two searches:
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn Insufficient access (50)
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D cn=admin,dc=kronprinz,dc=xx -W dn: dc=kronprinz,dc=xx
dn: cn=admin,dc=kronprinz,dc=xx
One with "disallow bind_anon" and one without. Then only open the firewall for port 636 to the ldap server which has "disallow bind_anon".
Chris Jackson
--
Harry Jede
The above example got me started in the right direction.
fine, but have you read "man slapd.access"?
Everything appears to be doing exactly what I wanted to do.
I can not believe.
I did notice that the anonymous bind users from ip addresses not 10, give an error 32. Anyone see any flaws in this?
When you got errors, then something must be wrong.
The below ACL should be allowing anon binds when ip address is 10.*.*.* or allow authenticated binds from any ip address.
access to attrs=userpassword by anonymous auth by self read by * none
access to * by anonymous auth continue by peername.ip="10.0.0.0%255.0.0.0" read by users read by * none
This looks better. ACLs are evaluated in order. The continue clause extends the current line with the folloing line. So both are just one ACL statement.
This is OK: by anonymous auth continue by peername.ip="10.0.0.0%255.0.0.0" read
This is bad: by anonymous auth continue by users read
Here you try to extend anonymous with users; which will not work.
BTW These ACLs does not allow any user to change his password by himself.
Chris
openldap-technical@openldap.org
-
Aaron Richton -
Andrew Findlay -
Chris Jackson -
harry.jede＠arcor.de -
Howard Chu -
Jonathan Clarke -
Ondrej Kuznik -
Pierangelo Masarati