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
sssd-users mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure