We have a report of a user unable to get kerberos authentication working on RHEL 6 beta. This was working fine on RHEL 5.
The user has the setting allow_weak_crypto enabled in krb5.conf during testing. The NFS server was a Netapp Server which also servers to other RHEL 5 clients on the same network.
The tcpdump shows that each call to NULL which initialises the authentication mechanism is a malformed packet.
Possibly same problem as that reported here?:
(Unfortunately, no solution there.)
"The tcpdump shows that each call to NULL which initialises the authentication
mechanism is a malformed packet."
Yes, the NULL init_sec_context rpc call has a partial argument--the length field is there, but not the following contents. The length is 0x545 == 1349, which is probably larger than we're used to seeing. Hm.
Even if the original source of the problem is some misconfiguration, we should be catching the problem rather than sending a corrupt packet.
But I don't this is cause of this failure.... since I've seen this malformed
packets on system were the mount worked... I could be wrong... but I'm
thinking that malformed packet is a red herring...
Created attachment 435409 [details]
Wireshark Dump of kernel protocal error between RHEL6 and an AD
This attachment show that the AD is basically failing every
single request the RHEL box sends... its not a pretty sight
(In reply to comment #11)
> "The tcpdump shows that each call to NULL which initialises the authentication
> mechanism is a malformed packet."
> Yes, the NULL init_sec_context rpc call has a partial argument--the length
> field is there, but not the following contents. The length is 0x545 == 1349,
> which is probably larger than we're used to seeing. Hm.
I think you're onto something here. Ticket sizes from an AD server tend to be larger than those we get from Unix KDCs because an AD server defaults to including authorization data that Unix KDCs don't. Steve's traffic log shows an initial response-too-big error reply when the AS-REP was sent over UDP, which has historically been triggered by this (it wasn't worked-around at the krb5 level, by retrying KDC requests over TCP, until krb5 1.3.x).
Interesting... when gssd is compile without linking in
libtirpc (--disable-tirpc) the malformed NULL disappears,
as least using a Linux (RHEL5) KDC....
Looking at the capture. The thing wireshark seems to be complaining about is that there is an extra 4 bytes at the end of the NULL call packet. The earlier NULL calls that aren't malformed don't have any bytes after the verifier.
I also suspect that the malformed packet is a red herring. It's certainly a bug and probably one in libtirpc, but it's hard to imagine that the server would just drop it on the floor due to that. I may be wrong though.
Ahh sorry, didn't see Bruce's response in comment 11. Yeah, there does seem to be another problem there too.
Does the libtirpc you're testing have this patch?
Author: Jeff Layton <firstname.lastname@example.org>
Date: Fri Mar 5 14:27:13 2010 -0500
libtirpc: allow larger ticket sizes with RPCSEC_GSS
...that's definitely one you'll want if you're working with AD tickets.
Yep, great Jeff, I'd be almost positive that's the fix.
Note the init_sec_context NULL differs from the earlier NULLs in that it should actually have a payload--the payload contains the important cryptographic content--so the extra 4 bytes without the following opaque data is a real problem.
Ok its verified.... the
does in deed take care of the null... that's the good news..
The bad is I have been using that version of libtirpc
in my test bed when trying to get a ticket from the AD...
Created attachment 435607 [details]
Complete wireshark trace between a RHEL6 client and a RHEL6 server using the AD as the KDC
Created attachment 435608 [details]
Complete wireshark trace between a RHEL5 and a RHEL6 server using the AD as the KDC
*** Bug 619792 has been marked as a duplicate of this bug. ***
*** Bug 621238 has been marked as a duplicate of this bug. ***
all I can say is that the libtirpc patch is in place, but I cannot verify due
to bug #629304 ...
however, there are reports that it works for other people, see comment #25 and
the duplicate bugs
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
*** Bug 643528 has been marked as a duplicate of this bug. ***
*** Bug 629304 has been marked as a duplicate of this bug. ***