[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="" read continue
  by peername.ip="" read continue
  by peername.ip="" read continue
  by peername.ip="" 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
  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

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:// dn
Insufficient access (50)

# ldapsearch -x -LLL -H ldap:// 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