directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel LŽcharny <>
Subject Re: [ApacheDS] Ceritficate for StartTLS
Date Wed, 06 Jan 2010 15:55:39 GMT
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 "", 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.

View raw message