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
Pierangelo,
Thanks for the information. Just what I needed.
Thanks for making OpenLDAP the best!
Kevin Burnett
On Nov 17, 2007 1:13 AM, Pierangelo Masarati [EMAIL PROTECTED] wrote:
Kevin Burnett wrote:
Quick question. In the ldap_attr_mappings table there is a column
called param_order. I
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
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
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
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
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
--On November 19, 2007 10:36:36 AM -0800 Keagle, Chuck
[EMAIL PROTECTED] wrote:
Be default, the SLES 9.3 slapd.conf defines the CA Cert like this:
TLSCACertificatePath /etc/ssl/certs
You didn't include that in your posted configuration, however. Always
provide all of the relevant
Be default, the SLES 9.3 slapd.conf defines the CA Cert like this:
TLSCACertificatePath /etc/ssl/certs
That directory has lots of pem files in it with x509 symbolic links:
ls -C /etc/ssl/certs
Password:
052eae11.0 6f5d9899.0 d4e39186.0 ICE-root.pemtimCA.pem
18d46017.0
Hello openldap community,
I have openldap 2.4.6 running on 2 machines.
one master server with a BDB database acting as the syncrepl provider (the
syncrep[l overlay has been added to the database configuration directive).
I now have set up a second machine also running openldap 2.4.6 and I've
Ok... after a bit of a struggle, I have gotten OpenLDAP 2.4.6 going with
MIT kerberos 1.6.3 with some small caveats...
1: (and you know this already), the documentation for the slapd.d
format is.. uhm.. bad. For example the slapd.ldif in the source isn't
even valid, the module section
David E. Cross wrote:
Ok... after a bit of a struggle, I have gotten OpenLDAP 2.4.6 going with
MIT kerberos 1.6.3 with some small caveats...
1: (and you know this already), the documentation for the slapd.d
format is.. uhm.. bad. For example the slapd.ldif in the source isn't
even valid, the
2:
Usually one would expect 3: to come after 2: ...
Heh, fair enough.
You haven't read the documentation. Section 13.2.4:
Note also that the realm part will be omitted if the default realm was used
in the authentication.
The SASL library always omits the realm if it matches the default
The 2.3 Admin Guide indicates in Section 12.2.1.2 that the
TLSCACertificateFile directive can be used instead of the hash links.
If I switch to using hash links, is it OK to just cat the crt and key
file together to create a pem file?
Not all who wander are lost.
System in SLES 9.3 running openldap 2.3.39
I tried to create the x509 hash and it still failed the same way.
I still think the TLSCA entries should allow the x509 hash to not have
to be there. Tried commenting out both TLSCertificate entries to no
avail. Tried commenting out the
15 matches
Mail list logo
