[Freeipa-users] A couple of quick questions about FreeIPA
Hello 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 2) Can I configure it not to store the Kerberos data in the LDAP server. 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. 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. 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. 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, ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] A couple of quick questions about FreeIPA
On 04/26/2012 12:57 PM, Paul Robert Marino wrote: Hello 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 your case? 2) Can I configure it not to store the Kerberos data in the LDAP server. This defeats the purpose of the solution. The whole point is to make them integrated. If you do not want this you can get any LDAP server and Kerberos and do it yourself. 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 simple bind. 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 Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] A couple of quick questions about FreeIPA
On Thu, 2012-04-26 at 12:57 -0400, Paul Robert Marino wrote: Hello 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 No. Our install scripts support setting up the KDC only locally on the same box for various reasons of simplicity and performance. 2) Can I configure it not to store the Kerberos data in the LDAP server. 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. 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. No, KDC data is in LDAP, but there is no chicken/egg issue, plus we do not expose userPassword nor any of the krb5 keys to users (keys are exposed to the KDC process of course). You have to use LDAP simple binds or SASL/GSSAPI binds to authenticate when you use IPA. 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. Plans for what goes in various MIT Kerberos releases are generally available on http://k5wiki.kerberos.org/, but the changelog is the authoritative source of info for what is fixed in current releases. 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, MIT Kerberos libraries are thread safe, this has been the case for a long while now. If you have specific questions or doubts feel free to ask. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] A couple of quick questions about FreeIPA
Thank You every one for answering so quickly On Thu, Apr 26, 2012 at 1:20 PM, Simo Sorce s...@redhat.com wrote: On Thu, 2012-04-26 at 12:57 -0400, Paul Robert Marino wrote: Hello 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 No. Our install scripts support setting up the KDC only locally on the same box for various reasons of simplicity and performance. I understand the reasoning I just don't like sub components to be too dependent on each other, especially when talking about distributed authentication infrastructures. Ive had instances where a bug in a piece of software (or just a poorly written piece of software) has opened a ridiculous number of connections and caused cascading failures of LDAP servers due to exceeding the max file handle limit on the boxes usually its web apps that do it. In those instances the only thing that bought me enough time to deal with the issues before it caused a serious outage was the fact that my Kerberos servers were not effected and the fact that I had properly tuned nscd on the boxes. I know ssd and pam_nss are planed to completely replace it but I still find nscd very useful, and every place I've seen it cause problems it was because it was never properly tuned e.g. if you have a web server that accepts 1000 or more connections the maximum number of threads being limited to default of 32 is obviously far too low and results in the Apache processes DOSing it. that's how it winds up in states where it eats an entire cpu core and never seems to answer any queries essentially its still working through its backlog of expired queries, and eventually crashes if the problem persists. I also tend to double the deceptively named suggested size for passwd, group, and hosts as i find it significantly improves the hit rate and max number of cached values. 2) Can I configure it not to store the Kerberos data in the LDAP server. 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. 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. No, KDC data is in LDAP, but there is no chicken/egg issue, plus we do not expose userPassword nor any of the krb5 keys to users (keys are exposed to the KDC process of course). You have to use LDAP simple binds or SASL/GSSAPI binds to authenticate when you use IPA. glad to hear the userPassword is not exposed however many poorly written applications expect to login as a user that can see the field and than do the authentication themselves rather than doing a bind for each user who logs in. even Apaches LDAP auth modules do this, personally I think the idea behind Auth MemCache Cookie sounds close to the ideal way web apps should handle authentication for this kind of thing even for non LDAP auth because it avoids doing a full login for every file downloaded although admittedly I haven't tried that module yet. 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. Plans for what goes in various MIT Kerberos releases are generally available on http://k5wiki.kerberos.org/, but the changelog is the authoritative source of info for what is fixed in current releases. 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, MIT Kerberos libraries are thread safe, this has been the case for a long while now. If you have specific questions or doubts feel free to ask.
Re: [Freeipa-users] A couple of quick questions about FreeIPA
On Thu, 2012-04-26 at 16:52 -0400, Paul Robert Marino wrote: Thank You every one for answering so quickly I understand the reasoning I just don't like sub components to be too dependent on each other, especially when talking about distributed authentication infrastructures. Ive had instances where a bug in a piece of software (or just a poorly written piece of software) has opened a ridiculous number of connections and caused cascading failures of LDAP servers due to exceeding the max file handle limit on the boxes usually its web apps that do it. In those instances the only thing that bought me enough time to deal with the issues before it caused a serious outage was the fact that my Kerberos servers were not effected and the fact that I had properly tuned nscd on the boxes. Use replicas with forntend servers, that way you will at most bring down a replica but not the core infrastructure. I know ssd and pam_nss are planed to completely replace it but I still find nscd very useful, and every place I've seen it cause problems it was because it was never properly tuned e.g. if you have a web server that accepts 1000 or more connections the maximum number of threads being limited to default of 32 is obviously far too low and results in the Apache processes DOSing it. that's how it winds up in states where it eats an entire cpu core and never seems to answer any queries essentially its still working through its backlog of expired queries, and eventually crashes if the problem persists. I also tend to double the deceptively named suggested size for passwd, group, and hosts as i find it significantly improves the hit rate and max number of cached values. Yes, tuning is always important when dealing with network facing services, you will be required to tune your installations in all cases. With sssd we replace nscd simply because it knows better when it make sense to make a query, how to pool queries, and when servers are not reachable and it can immediately answer back. Also we added a shmem bases cache to pam_sss in master that brings performance on par with nscd for the cases where it matters most. glad to hear the userPassword is not exposed however many poorly written applications expect to login as a user that can see the field and than do the authentication themselves rather than doing a bind for each user who logs in. Well we have no magic wand here do we :-) If you have those applications you will have to decide if it is a good idea to relax permissions on userPassword or if it is possible to modify the application or use alternatives. even Apaches LDAP auth modules do this, personally I think the idea behind Auth MemCache Cookie sounds close to the ideal way web apps should handle authentication for this kind of thing even for non LDAP auth because it avoids doing a full login for every file downloaded although admittedly I haven't tried that module yet. Yes, we are planning to eventually extend this method to a usable method for third party apps on other servers through standard APIs, but we are not there yet. Glad to hear that the thread safety was fixed it has been a few years since i looked to that.it use to be quite a serious problem and not just for Samba, FWIW all of samba except libsmbclient is not multi-threaded and is largely non multi-thread safe, so I am not really sure why that would have been an issue there, but it is fixed, and we are all happy now :) for those of you who were familiar with it. it was a libkrb5 issue that was caused usually when a multi-threaded app would try to simultaneously via local socket instead of the network. These condition usually resulted the Kerberos server crashing. A few other samba libraries cough*nss_winbindd*cough were also not thread safe until relatively recently ... this things happen, and they get fixed. I still have to think about it because there are still a few separation things I would like to do that I would still be prohibited from doing on one set of servers like have a second realm and OU just for my network gear. but ill definitely do some experiments before i make my final decision. We are working on cross realm trust as the next big feature, that will allow you to have a separate infrastructure for network gear if you like and still be able to authenticate from one realm to the other. IPA-IPA cross realm is not fully tabled yet, it will come after our first stab at AD-IPA cross realm trust support. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
