On 06.01.2010 16:55 PM, Emmanuel Lcharny 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
