Red Hat Bugzilla – Bug 114938
RFE: Upgrade to krb 1.3.x (required for MS AD 2003 integration)
Last modified: 2012-06-20 12:14:31 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: (Quoted from a mailing list) """ MIT Kerberos 1.3 adds support for communicating with the KDC on 88/tcp instead of just 88/udp. On Windows, a proprietary "PAC " is embedded in the ticket containing SID information about the user and any groups the user is a member of. If the PAC is large enough, the ticket can get big enough that the KDC won 't send it using UDP. So it asks the client to retry using 88/tcp, which MIT Kerberos 1.2 can 't do. """ This is causing all of our kerberized services running on RH(9/EL3) to fail for users which have a large PAC (i.e., they're in a bunch of AD groups) Version-Release number of selected component (if applicable): krb5-<anything>-1.2.* How reproducible: Always Steps to Reproduce: 1. configure /etc/krb5.conf to point to a MS AD server 2. run "kinit <username>", where <username> is a user with a large PAC Actual Results: [ccweis@a-lnx000 ccweis]$ kinit Password for ccweis@<REALM-NAME>: kinit(v5): KRB5 error code 52 while getting initial credentials [ccweis@a-lnx000 ccweis]$ Expected Results: No errors should be reported, and the TGT should show up in a "klist". Additional info: This is a known issue and has been fixed in MIT Kerbos v1.3. (See http://web.mit.edu/kerberos/www/krb5-1.3/README-1.3.txt) This is an enhancement request, but it's a very important one, as it basically disallows RH clients to work in existing AD environments (correspondingly, disallowing samba3 to run in "ads" mode)
1.3's ABI differs from 1.2's, but does not change sonames, so changing which version is used is going to be difficult to impossible if we want to avoid breaking third-party apps which link with those libraries. As a result, I may have to wontfix this one.
Any way to install them in parallel, or would we be better off pulling the packages from Fedora and hoping for the best? This is a show-stopper for almost our entire University (BTW, MS AD wasn't my choice), so any advice is welcome. Thanks.
That the sonames don't change is the big problem here -- you have two libraries which the run-time linker can't distinguish from each other. If that wasn't a problem, I like to think we'd have had 1.2 compatibility libraries in Fedora already. In a conversation I had with Brian Howson, he pointed me at Microsoft's Knowledge Base, specifically at article(?) 244474, which describes how to increase or decrease the response size at which the server will request that clients retry with TCP. If your network can handle packets larger than the default threshold, then increasing this value on the server may "fix" this for some of your users. I'm leaving this one open in case we come up with something better.
Internal RFE bug #115482 entered. May consider for future releases.
It is essential that our enterprise UNIX servers can be integrated into our ADS tree. Unfortunately our EL3 servers are proving problematic as most ADS user accounts are affected by this ADS/Kerberos TCP issue. As most of our boxes will be running only Oracle products, SSH and SAMBA it would be nice if there was a kerberos 1.3.x option, however first we would need a list of what will break upon upgrade. NB: Not what depends on kerberos 1.2.x, but what will not work with 1.3.x
We are in the process of integrating our Linux Samba shares (RHE 3.0) and our MS AD Domain (1600+ users) so we can make use of one authentication method under AD. I see this issue was raised back in February 2004 and here it is June 2004 and I'm wondering if we are any closer to a solution? I have this working under SuSE 9.1 and find it extremely frustrating that our PAID subscription of RHE 3.0 does not support this functionality. Can anyone tell us if MIT Kerberos 1.3 will be added to the RHE 3.0 ES distribution anytime in the near future? Thanks.
This is for John Ridge: How did you get it working? I keep getting this error <<<< kinit: krb5_get_init_creds: Response too big for UDP, retry with TCP >>>> when attempting to get authentication. I too am using SuSE 9.1 ... please reply here - and my email if possible. Please be as specific as possible.....I really need this working. Thanks, Jeff Hatfield - aka nomasteryoda jeff@mgalug.org jeffrey.hatfield@robins.af.mil
This is also a show stopper at our campus with an impending upgrade to AD 2003 this month, none of our RedHat clients will be able to authenticate. We hope to avoid having to to rebuild the libraries ourselves, and recompiling and packaging relevant applications. This will cause major disruption and is the kind of effort we hoped to avoid by buying into the subscription service. Hoping to hear that this will be prioritised as an enhancement.
Changing the summary to mark as an enhancement request. It is unlikely that this feature request will be considered for RHEL3, as upgrading to the newer version would break binary compatibility. The feature will however be considered for RHEL4. Regards
Perhaps not everyone is aware of this, so I'll mention it. After harassing Microsoft for quite some time about this, one of their engineers offered us this solution: <snip> PROBLEM: ======== UDP Kerberos traffic not working correctly for MIT 1.2 clients with large PAC. RESOLUTION: ============ Increase the allowed size of Kerberos UDP: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc MaxDatagramReplySize 4000 (decimal) reg_dword </snip> Several months ago, we deployed this campus-wide and it solved all of our problems (essentially by keeping it everything as UDP). I've since left the university, but AFAIK, this fix is still in place and still works well. FYI, last I checked, there is still _no_ working fix in MSFT's knowledge base, and few, maybe only one, of their support engineers actually understood the issue and had enough knowledge of the OS and registry to provide us with a fix. He also voiced an opinion about why this fix is not being posted in the knowledge base. (read: it's not a technical issue.) Please post if this fix works (or doesn't work.) Thanks, and good luck.
We are also getting bitten by this bug as we upgrade to RHEL3, but we have not been having the same problems with older versions such as RH7.3, so I am not convinced that the only fix is to upgrade to the (binary-incompatible) krb5-1.3.x. I have opened bug #128067 with more details about the possibility that this is a bug that krept in between RH7.3 and RHEL3.
The MIT people claim that 1.3.x doesn't break ABI compatibility. Have a look at this thread: http://mailman.mit.edu/pipermail/kerberos/2004-July/005775.html From what they say it's RH that broke the ABI.....
We at the University of Illinois are also in trouble with this one. The entire campus group authentication scheme is based upon the AD (2003). Without this fix we are stuck with keeping around an ancient NT domain which only exists for samba authentication. We moved to RHEL with the expectation that it would help us integrate with the Windows world. We do not relish having to move to a different Linux vendor.
We have had some success with the Reg Key hack for KdcMaxDatagramReplySize, and are doing further tests, however we think we will have to isolate the Domain Controller with this setting applied so that Windows clients do not interact with it, as we believe that this setting should be applied on Windows clients also to avoid problems. It does seem to solve the Auth problem for RHEL 3 howeer.
We're actively using RHEL 3WS with krb-1.2.7-24 and 2003 AD servers successfully so far, but maybe we just haven't heard about or encountered a user in enough groups to bump the PAC size over the edge. Either way, it is something that is very likely to happen with many thousands of users logging in per semester. The registry fix is somewhat reassuring, however the implementation of krb-1.3 is the correct and I believe required fix. In my opinion, this is not an enhancement. Real organizations live and breathe on AD integration and I'm sure would not consider it an enhancement when some or all of their users can no longer log in. If in fact vanilla krb 1.3 does not break the ABI as MIT claims, and it was a RedHat problem, RedHat's nonchalant response to this is disturbing to me. This is something that needs to enter primetime yesterday.
I build 1.3.4 rpms without using libcom_err from e2fsprogs. I didn't had the time to test them properly yet so don't try them in a production system but everything seems to work ok so far. I used the fedora spec file so libs go in /usr/lib instead of /usr/kerberos/lib etc. (i'll fix that when i get some free time) You can get the rpms at http://www.hep.ph.ic.ac.uk/~georgiou/krb5
As far as i can see krb5 1.3.4 works as expected, the compatibility problems were caused by linking with the e2fsprogs libcomm_err. I think than an upgrade to 1.3.x should be easy for RHEL3. IMHO Fedora 3 should get a fixed version of 1.3.x as well even it breaks compatibily with Fedora 2 which had the "bad" version of 1.3.x.
Here at Hertz we found new AD accounts worked in RHEL2.1 and RHEL3. However, accounts migratted from domain controlers to AD only worked in Fedora core 1 and above. ;-)We fixed RHEL3 by back porting pam_krb5 from Fedora 1 to RHEL3. Thisonly required a rpmbuild --rebuild. We have not found a fix for RHEL2.1 yet.
Re: Kostas Georgiou's 1.3.4 version rpms. I installed them on a test box and was immediately unable to su to root or other local accounts. Accounts that got their authentication from outside sources (kerberos, ssh keypairs) continued to work. Not only was I unable to su to root, I was also unable to sudo su. Going back to the version supplied by Red Hat fixed this problem. That said, we at Yale would very much like to be able to join our Linux machines to the Active Directory too. We run a heterogenous environment where we can expect server connections from Windows, Mac and Linux and having a single point of authentication would be terrific. So here's our "me too" request for supported 1.3.x kerberos rpms.
With over 40 ES30 and AS21 systems currently in operation Belo Corp. has a great interest in seeeing this resolved. Our 2003 migration has effectively stalled in an effort to remain in an supported configuration i.e. using official RH packages.
Btw An additional work around is to force tcp usage: ie. PROG.MYSITE.ORG = { kdc = tcp/aterm1.prog.mysite.org:88 kdc = tcp/aterm2.prog.mysite.org:88 kdc = tcp/hsterm.prog.mysite.org:88 } MYS.MYSITE.ORG = { kdc = tcp/fiscalsrvr.mys.mysite.org:88 kdc = tcp/terminal.mys.mysite.org:88 }
krb5-libs-1.2.7-42 for EL3 (U4) appears to fix this issue for me. I was getting the ASN.1 error with pam_krb5 until I found this bug and checked for a new version of krb5. After installing it and restarting the problem daemon (jabberd/c2s), it worked fine. From the package changelog: * Fri Mar 04 2005 Nalin Dahyabhai <nalin@redhat.com> 1.2.7-40 - read-with-retry on TCP sockets when we're receiving a reply from the KDC (possible fix for #143084)
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.