Bug 114938

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
jeffrey.hatfield.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> 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.