Hi!
Knowing that rootdn always bypasses ACLs, is there any other way to restrict BIND operations that use rootdn to certain source IP addresses for clients?
Only way to stop rootdn is to stop it from getting in in the first place: tcp wrappers/iptables/etc. Which of course do a lot more than rootdn, though...
On Mon, 19 Nov 2007, Aleksander Adamowski wrote:
Hi!
Knowing that rootdn always bypasses ACLs, is there any other way to restrict BIND operations that use rootdn to certain source IP addresses for clients?
-- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl
-- Aleksander Adamowski Administrator systemów korporacyjnych; Instruktor Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51 kom. 0-601-318-080
Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione. Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message.
I believe you can just not create a rootdn (or not define a password for it? Or maybe define a password like {crypt}*NOLOGIN* (or an md5/sha/ssha equivalent) that can't be used (not a valid hash)?), so you effectively disable the rootdn, but create a normal account that has full access to everything (except for the restrictions you want to implement) to do what you would otherwise have used the rootdn for. Not *quite* the same, but it may fit your needs?
Is there anything the rootdn can do that you can't grant via acls to a "normal" account (other than ignore acls)?
- Jeff
-----Original Message----- From: openldap-software-bounces+jeff_clowser=fanniemae.com@openldap.org [mailto:openldap-software-bounces+jeff_clowser=fanniemae.com@openldap.or g] On Behalf Of Aaron Richton Sent: Monday, November 19, 2007 11:48 AM To: Aleksander Adamowski Cc: openldap-software@openldap.org Subject: Re: restrict rootdn binds by connection source IP address?
Only way to stop rootdn is to stop it from getting in in the first place: tcp wrappers/iptables/etc. Which of course do a lot more than rootdn, though...
On Mon, 19 Nov 2007, Aleksander Adamowski wrote:
Hi!
Knowing that rootdn always bypasses ACLs, is there any other way to
restrict
BIND operations that use rootdn to certain source IP addresses for
clients?
--
On Nov 19, 2007, at 10:48 AM, Aaron Richton wrote:
Only way to stop rootdn is to stop it from getting in in the first place: tcp wrappers/iptables/etc. Which of course do a lot more than rootdn, though...
On Mon, 19 Nov 2007, Aleksander Adamowski wrote:
Hi!
Knowing that rootdn always bypasses ACLs, is there any other way to restrict BIND operations that use rootdn to certain source IP addresses for clients?
--
I'm new and stupid, but why not just put an admin account in ldap and ditch the rootdn?
I'm new and stupid, but why not just put an admin account in ldap and ditch the rootdn?
Many sites choose to do exactly this. It depends whether you consider an ACL override capability more useful (which it argubly is) or dangerous (which it argubly is).
One question I pose to the list in light of recent features: Let's say you use (2.4, ACL-aware) back-config and totally flub the ACL config. This should be correctable with the rootdn (which will trump the broken ACL config). If you choose to not configure a rootdn, do you find yourself in a mandatory restart situation that might otherwise be avoided?
Aaron Richton wrote:
I'm new and stupid, but why not just put an admin account in ldap and ditch the rootdn?
Many sites choose to do exactly this. It depends whether you consider an ACL override capability more useful (which it argubly is) or dangerous (which it argubly is).
One question I pose to the list in light of recent features: Let's say you use (2.4, ACL-aware) back-config and totally flub the ACL config. This should be correctable with the rootdn (which will trump the broken ACL config). If you choose to not configure a rootdn, do you find yourself in a mandatory restart situation that might otherwise be avoided?
That seems pretty obvious.
You can also lock yourself out by turning on the olcReadOnly attribute of the frontend DB. At that point, write operations are no longer accepted anywhere, so you cannot reset it without a manual edit and restart.
Aleksander Adamowski wrote:
Knowing that rootdn always bypasses ACLs, is there any other way to restrict BIND operations that use rootdn to certain source IP addresses for clients?
You can define a rootdn with no rootpw, and create an entry with the rootdn's DN. Then binding as the rootdn would require a regular bind to that DN, which in turn requires auth access to that entry's DN and userPassword, and this can be restricted via ACLs including ACLs on source IP address and so. As soon as that bind succeeds, that connection would have complete rootdn privileges and thus bypass further ACL checking.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati pisze:
Aleksander Adamowski wrote:
Knowing that rootdn always bypasses ACLs, is there any other way to restrict BIND operations that use rootdn to certain source IP addresses for clients?
You can define a rootdn with no rootpw, and create an entry with the rootdn's DN. Then binding as the rootdn would require a regular bind to that DN, which in turn requires auth access to that entry's DN and userPassword, and this can be restricted via ACLs including ACLs on source IP address and so. As soon as that bind succeeds, that connection would have complete rootdn privileges and thus bypass further ACL checking.
Perfect! It worked! Pierangelo, you're a real guru.
Thanks for the info.
BTW, I've submitted the recipe for this to FAQ-O-Matic. Until it's published, here's the recipe text for the record:
==========
Alternatively, you can specify rootdn in slapd.conf without specifying a rootpw. Then you have to add an actual directory entry with the same dn, e.g.:
dn: cn=Manager,o=MyOrganization cn: Manager sn: Manager objectClass: person objectClass: top userPassword: {SSHA}someSSHAdata
Then binding as the rootdn will require a regular bind to that DN, which in turn requires auth access to that entry's DN and userPassword, and this can be restricted via ACLs. E.g.:
access to dn.base="cn=Manager,o=MyOrganization" by peername.regex=127.0.0.1 auth by peername.regex=192.168.0..* auth by users none by anonymous none
The ACLs above will only allow binding using rootdn from localhost and 192.168.0.0/24.
openldap-software@openldap.org
-
Aaron Richton -
Aleksander Adamowski -
Clowser, Jeff (Contractor) -
Howard Chu -
Jonathan Dobbie -
Pierangelo Masarati