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
