Bug 1066000

Summary: Please backport SPNEGO fixes from upstream
Product: [Fedora] Fedora Reporter: Simo Sorce <ssorce>
Component: krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: nalin, nathaniel, negativo17
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: krb5-1.11.3-21.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1066002 (view as bug list) Environment:
Last Closed: 2014-03-13 05:06:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1066002    

Description Simo Sorce 2014-02-17 13:33:56 UTC
Upstream recently got a few patches to fix a SPNEGO iussue:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=7858

This issue causes failures as reported, for exaemple here:
http://bugs.centos.org/view.php?id=6526

Without these patches BIND cannot properly reply to GSS-TSIG requests sent by Windows Clients causing them to fail to perform a signed updayte at all.

This is causing issues to people that have to rebuild BIND to use the internal SPENGO implementation.

These fixes have been indepndently tested on both Fedora 19 and Fedora 20 by two people with a custom build of krb5 libraries (F20 + the patch in the MIT report) and the original BIND packages.

Comment 1 Simone Caronni 2014-02-19 17:43:52 UTC
I've tested the Fedora 19 builds on my Samba 4 deployment [1].

Everything is working fine with the stock Bind; I can now dynamically update records from Windows 7 clients attached to a Samba 4 Active Directory installation [2].

Can these builds be pushed to the official updates?

* krb5-1.12.1-5.fc21
* krb5-1.11.5-4.fc20
* krb5-1.11.3-21.fc19

Thanks & regards,
--Simone

[1] http://negativo17.org/samba-4-active-directory-with-bind-dlz-zones-dynamic-dns-updates-windows-static-rpc/

[2] http://negativo17.org/samba-4-active-directory-with-bind-dlz-zones-dynamic-dns-updates-windows-static-rpc-update/

Comment 2 Fedora Update System 2014-02-19 18:48:36 UTC
krb5-1.11.5-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2014-2579/krb5-1.11.5-4.fc20

Comment 3 Nalin Dahyabhai 2014-02-19 18:49:34 UTC
I'd like to avoid resetting the clock on the current F19 update, so I'm thinking of holding off there.  The current in-progress F20 update is holding to synchronize with a freeipa update, so I guess we might as well revise it to include the newer build.  The Raw Hide build should show up in the next compose if it hasn't already.  Thanks!

Comment 4 Simone Caronni 2014-02-19 21:49:15 UTC
Thanks.

If you want to push the Fedora 19 update quickly without waiting days, you can still create an update with Karma = 1, so I can send a positive comment and it gets pushed directly to the stable repository.

Comment 5 Fedora Update System 2014-02-24 21:48:49 UTC
krb5-1.11.3-21.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/krb5-1.11.3-21.fc19

Comment 6 Fedora Update System 2014-02-26 14:04:18 UTC
Package krb5-1.11.3-21.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing krb5-1.11.3-21.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-3134/krb5-1.11.3-21.fc19
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2014-02-28 18:39:26 UTC
krb5-1.11.5-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2014-03-13 05:06:15 UTC
krb5-1.11.3-21.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.