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//:
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
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.
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
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
Replace "gateway-ip" with yours.
Put the above statements also in every ACL just before the
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
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
One with "disallow bind_anon" and one without. Then only
firewall for port 636 to the ldap server which has "disallow