Looking into responder_common.c, the function client_recv logs "Invalid data from
client, closing connection" if sss_packet_recv returned EINVAL.
Looking into sss_packet_recv, EINVAL is returned if the packet is too large.
Decoding the packet, the first four bytes are the packet length which is 1905; the second
four are the command type which is 0xfb or SSS_GSSAPI_SEC_CTX. After the eight
status/reserved bytes are the first 1520 bytes of the packet body. The rest of the packet
body is never read because after the first recvfrom call (into a buffer of 1536 bytes),
the connection is closed.
I can see the definition of SSS_PACKET_MAX_RECV_SIZE is 1024. And I can see some code in
sss_packet_recv that handles two types of packet known to be larger (SSS_NSS_GETNAMEBYCERT
and SSS_NSS_GETLISTBYCERT, which are allowed to be up to SSS_CERT_PACKET_MAX_RECV_SIZE
bytes or 10240 bytes long).
So maybe the SSS_GSSAPI_SEC_CTX command needs similar handling of longer packets so that
it can deal with large kerberos tickets (which Windows users will have if they are in lots
of groups; a quick Google suggests the PAC may grow up to 48 KiB as of Windows Server
2012).
--
Sam Morris <
https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9