Beat Burgener | NetSuccess GmbH a écrit :
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...
Hopefully, Firewalls can deal with brute force attack at a upper layer,
like denying someone sending requests to your IT at a high rate !
I must be frak here : ADS (and probably all the LDAP server) aren't
ironed to support a brute force attack. At best, you'll get a DOS.
Now, for web apps using a LDAP server to do basic auth, I think it's not
safe to use something else than a dedicated server.
<snip/>
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?
Well, it is, but it's not mature :/ We *want* to improve the existing
Kerberos server, but we don't have time. At least, it works.
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 ...
AFAICT, ACI are dynamic in ADS. I mean, you define them and they are
immediately used.
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 ...
Don't get me wrong : when M$ decided to move to something close to LDAP
to manage W$ domain, and added kerberos support into it, they made a
fantastic move, with a double impact :
- suddenly, Kerberos was available without having to go through a
cryptic configuration and an painful installation
- LDAP became the de-facto solution for storing and managing users and
resources on a system
In fact, LDAP and Kerberos were quiletly sleeping, waiting for better
days, when M$ came and push it back to the front-stage. That was Good, tm.
