Bug 114938 - RFE: Upgrade to krb 1.3.x (required for MS AD 2003 integration)
RFE: Upgrade to krb 1.3.x (required for MS AD 2003 integration)
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: krb5 (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
: FutureFeature
Depends On: 137611 137612 137613
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-04 12:52 EST by Christopher C. Weis
Modified: 2012-06-20 12:14 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 12:14:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christopher C. Weis 2004-02-04 12:52:56 EST
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)
Comment 1 Nalin Dahyabhai 2004-02-04 15:24:12 EST
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.
Comment 2 Christopher C. Weis 2004-02-04 15:46:20 EST
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.
Comment 3 Nalin Dahyabhai 2004-02-04 18:08:25 EST
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.
Comment 7 Suzanne Hillman 2004-02-12 16:25:29 EST
Internal RFE bug #115482 entered. May consider for future releases.
Comment 8 Chris COOPER 2004-05-23 21:49:42 EDT
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
Comment 9 John Ridge 2004-06-10 13:02:23 EDT
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.
Comment 10 Jeffrey W. Hatfield 2004-07-01 12:23:06 EDT
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
Comment 11 Sandy MacKenzie 2004-07-06 18:31:47 EDT
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.
Comment 12 Bastien Nocera 2004-07-07 05:03:05 EDT
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
Comment 13 Christopher C. Weis 2004-07-07 09:22:18 EDT
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.
Comment 14 Joshua Daniel Franklin 2004-07-16 18:48:45 EDT
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. 
Comment 15 Kostas Georgiou 2004-07-16 21:11:50 EDT
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.....
Comment 16 bugzilla macrotex 2004-07-19 12:15:09 EDT
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. 
Comment 17 Sandy MacKenzie 2004-07-19 12:45:39 EDT
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.
Comment 19 Brett L. Trotter 2004-08-04 11:49:19 EDT
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. 
Comment 20 Kostas Georgiou 2004-08-05 18:14:55 EDT
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
Comment 22 Kostas Georgiou 2004-08-07 20:25:47 EDT
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.
Comment 23 imwired 2004-08-18 18:23:29 EDT
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.
Comment 24 Michael Dunlap 2004-08-26 15:31:40 EDT
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. 
Comment 26 David Grimes 2004-10-08 12:22:54 EDT
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.
Comment 27 Joshua Schmidlkofer 2005-01-28 19:42:27 EST
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
 }
Comment 30 Al Tobey 2005-04-26 10:06:55 EDT
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)
Comment 31 Jiri Pallich 2012-06-20 12:14:31 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.