On 04/26/2012 12:57 PM, Paul Robert Marino wrote:
> I'm trying to figure out if free IPA is a good solution for my
> environment or if i should just construct a custom infrastructure with
> 389 server and i just have a couple of quick questions. I have a long
> history working with LDAPv3 and I'm currently planing a new
> infrastructure for my current employer. I've worked with OpenLDAP 389
> server and even 389 servers original incarnation when Netscape was
> still around
> 1) Can the Kerberos server be on an other box.
> I'm not a python programer so I haven't been able to test it my self
> but many of the Kerberos calls look like wrappers to the C libraries.
> if so than it might be possible
Currently no, since KDC uses local LDAP calls over ldapi.
Can you please explain why KDC on a separate box is a requirement in
> 2) Can I configure it not to store the Kerberos data in the LDAP
This defeats the purpose of the solution. The whole point is to make
If you do not want this you can get any LDAP server and Kerberos and do
> I don't like the chicken and the egg authentication conundrum
> this can cause, and I have no intention of allowing users to use
> LDAPv2 so I actually don't want the password field in the database or
> at least blocked by an ACL so it cant be used.
This is all taken care for you in IPA. It is unclear what problem you
are trying to solve.
LDAP will store userPassword with different strong hashes that can be
used for Kerberos auth and for LDAP auth.
You can close anonymous bind that we recommend. You can require TLS for
> I personally find the
> fact that applications still use this field for authentication
> appalling because it essentially turned back the clock to before
> shadow password files.
There are all sorts of ways to control what kind of authentication is
allowed and not expose weaker authentication methods if you do not want to.
> 3) This is the most important question, there has been a lot of talk
> about fixing the issues with MIT Kerberos. Is there someplace I can
> look To see what the status of these fixes are other than pouring
> through the change logs for MIT Kerberos.
Which bugs in particular?
> I don't want to get in to a Kerberos holy war but most of these are
> really old bugs in MIT Kerberos that made me abandon the Idea of ever
> using the MIT server in production over a decade ago. I know exactly
> the issues that lead to the Samba group choose to code only to Heimdal
> all too well because I first remember hitting them and reporting them
> back 2001 to the Samba group via usenet.
> The big thing for me is the thread safety because this often caused
> the MIT Kerberos server to crash then Samba was running in domain mode
> on the same box, Honestly I still don't trust MIT's implementation in
> a mission critical environment,
Are you talking libkrb5? I do not think it is used inside IPA server.
KDC is not threaded but LDAP driver (KDC glue to LDAP) is capable of
working with multithreaded DS. So far we have not seen any issues there
in the whole lifetime of the IPA which is more than 4 years.
Generally we have been actively working with MIT and if there are any
specific issues that you think are still there and worth solving we
would like to hear about them.
> Freeipa-users mailing list
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list