[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Slapd Security based on port
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