Emmanuel,
thank you for the swift reply. Remarks below:
On 06.01.2010 15:46 PM, Emmanuel Lcharny wrote:
Beat Burgener | NetSuccess GmbH a écrit :
Stefan,
thank you for pointing this out.
BTW: I just found out that I still have 1.5.4 ;-(
BTW2: I personally do not suggest storing the certificate data within
the LDAP directory itself, although there are fields available.
If you have a certificate used for "ssl.xyz.com", used for web, ldap
and so on, compromising the LDAP account or
ApacheDS through LDAP protocol might reveal the private key - or am I
wrong on this?
I know that more and more directories start storing PKI data within
the storage engine (Microsoft ADS does this too),
but somehow I don't feel comfortable with this ...
The question here is much more about giving people a direct access to
LDAP. I'm not sure it should be considered a good idea to expose your
LDAP server to the world.
True, I do not intend to do so, but for example if you use LDAP to
validate "basic authentication" in web sites, there is a chance for
brute force attacks,
as web servers are not able to lock accounts (AFAIK) - this was a recent
question of another user... PHP with it's security issues might be an
option to get access to an LDAP,
and if not well protected by ACI, this might be dangerous ...
That's why I'm also looking into SSO and Kerberos solutions for
Authentication ...
There was also a POST regarding Kerberos and ApacheDS, but AFAIR, it was
that Kerberos is not fully supported yet?
In many case, you will use your LDAP server as a NIS, requested ony by
IT services, like FTP, DNS, etc.
If you are to use LDAP to store user data, then eiher you protect the
critical data (certificates) by adding ACI (good luck ...), or you
install a second LDAP server (probably a better idea).
I'm currently have ACI in use and I like it ... I came from M$, so ACL /
ACI is crucial to me .. ,-)
The only thing that is a little bit "uncomfortable" is the requirement
to restart the server after changes ... But changes are rare,
fortunately ...
M$ has it wrong at the beginning, when they start telling their user
that AD was a LDAP server and that you should use it for your
applications, until they realized how dangerous it was, and they
created AD/AM (of course, there were other reasons like if you FU with
AD, you have little option but reinstaling your domain server ... :/).
But M$ AD is really a NIS server, not a LDAP server, with all the
access control needed to protect such private data as the users
certificates.
Well, M$ AD at least exports a more or less compliant LDAP / LDAPS
infrastructure ... and if that is possible, "attacks" available against
LDAP might be possible against AD too, I assume ...
I don't know what you reference NIS to, but I only know NIS as of Unix
.... and this is a entire infrastructure on it's own far away from
Kerberos and LDAP ...
;o)
BTW3: Is there a way to force StartTLS an LDAP connection using port
389 via the ApacheDS configuration?
It's an extended operation, so yes, you can send such a resquest to
the server prior to any operation, on port 389. That's the way
everyone should use LDAP, btw. LDAPS is considered as obsolete.
That's why I use LDAPS, which does not support plain text connections
AFAIK. For LDAP, I don't feel in the position to control that
as the client use StartTLS or not ...
I don't remember is there is a way to tell ADS not to accept plain
text requests when not using LDAPS (Stefan ? Stefan (Z)? )
Linus van Geuns just replied that the LDAP protocol does not force to
use the use of TLS, so if the client is configured the wrong way,
there is a risk that the LDAP Admin password is exposed ... Okey, you
can limit access to connections using IPSec/SSL, though ...
As of Wikipedia:
A common alternate method of securing LDAP communication is using an SSL
tunnel
<http://en.wikipedia.org/w/index.php?title=Secure_Socket_Layer_Tunnel&action=edit&redlink=1>.
This is denoted in LDAP URLs by using the URL scheme "ldaps". The
default port for LDAP over SSL
<http://en.wikipedia.org/wiki/Secure_Socket_Layer> is 636. The use of
LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never
standardized in any formal specification. This usage has been deprecated
along with LDAPv2, which was officially retired in 2003
<http://tools.ietf.org/html/draft-zeilenga-ldapv2-04>.
Hmmm, I see, the IT world is far from being mature ...
Thank you all for shading some light on this!
Best regards
Beat
