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