directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Beat Burgener | NetSuccess GmbH <beat.burge...@netsuccess.ch>
Subject Re: [ApacheDS] Ceritficate for StartTLS
Date Wed, 06 Jan 2010 16:08:32 GMT
On 06.01.2010 16:55 PM, Emmanuel LŽcharny wrote:
> 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 !

Well, most firewalls to operate at OSI Layer 4 - so they don't know and 
don't care what the request itself was ... Application Layer FW's/Gateways
do such things, but are very expensive and very custom ...

Further, if an application (like Apache, PHP) is in between, the request 
are all from the same source, so you can't distinguish (Layer 4 FW assumed)
if there is 1 Client generating 1000 requests/second or if there are 500 
Clients logging in per second, depending on the load of the service/site ...
>
> 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.

Okey, good to know that you think like this about that matter, as I am 
suspicious to centralize everything that much ... however, easy to 
understand
user demands are there ...
>
>> <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.
Might be that I'll give it a try soon,  but I share the same faith - 
time ....
>>>
>>> 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.
I'll try again and will then report ....
>
>>>
>>> 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.
I fully agree!
>
>
Thank you for the responsive conversation

Beat

Mime
View raw message