AFAIK Cisco switches base their forwarding decisions based on MAC; regardless of what authentication occurred first.
You can use port-security to enforce MAC auth, but as discussed that is easy to spoof.
A better option is 802.1X (Cisco just refers to it as dot1x);
whereby as a port comes up it asks the client to authenticate, back-hauls that auth to a radius/TACACS server, and based on the response enables traffic forwarding on that port (on server defined VLAN)
This can also be used for NAC -- if a legitimate host doesn't pass health checks (up2date AV/Windows updates) it can be quarantined to a remediation VLAN to update itself before being allowed to join the main network.
Ultimately, however, if a host has passed dot1X authentication, any frames sourced on that port, with the expected MAC address will be forwarded without further authentication.
A much more resilient option ( which also covers remote Layer3 traffic ) is IPSEC; My main experience with this is Windows, though Linux is capable (Racoon? - though more complex to administer) you can enforce IPSEC traffic policies whereby the individual IP packets have an authentication header to prove the identity of the sender (computer, user, or both); and if the receiver cannot validate that info the packet is dropped even before passing up the stack to (possibly vulnerable) application.
It does by definition cause inter-operability problems with external or non-domain devices (eg. printers)- which can be addressed with domain trusts (given similar IPSEC policy) or device certificates (from trusted chain)
You can configure IPSEC policy not only to authenticate connections, but to encrypt the data; which renders most MitM attacks useless.
You could identify attempts at non-IPSEC secured connections (or those that fail authentication) in event logs.