It sounds like 802.1x over WPA2 is the way to go. I won't say that this is necessarily easy to configure, but it may fit your requirements.
You'll need a CA. This could be your AD server for simplicity, you're enterprise might have one already, or you could designate any server you trust sufficiently to be an internal CA (if you're really a martyr, you could even use a public CA so long as you don't mind it taking weeks to add new clients and racking up thousands of dollars in fees). This will need to sign certificates for your RADIUS server and clients.
You'll need a RADIUS server. This can be the NPS service in Windows Server, FreeRADIUS on RHEL, pfsense, even some routers can do it (But if you make your router into a RADIUS server, I wouldn't admit it on the InfoSec Stack Exchange). This will need a signed cert to validate its identity to your clients. This will serve to authenticate your clients, it can be configured to do so by username/password, or it could do so by validating the client possesses a valid, signed cert. In some cases, you can configure the RADIUS server to check an LDAP directory (such as AD, IPA, openLDAP, etc.) which associates each identity (certificate in this case) with a set of groups. These groups could control which networks the user is authorized to connect to.
Your APs will need to be set to use WPA2 Enterprise, and configured to route authentication requests to the RADIUS server. Configuration varies wildly based on the make of your AP.
Your clients will need to have a signed cert loaded onto their system and configured to provide that cert as 802.1x authentication for the WiFi connection to your AP(s). Again this varies wildly depending on the device and configuration is left as an exercise to the reader. This is using client-authentication TLS over EAP and is thus usually decorated as the EAP-TLS option in many configs that I've seen.
The issues with this depend on your environment and risk-acceptance. But these concerns should be addressed.
Getting certs to the client
You'll need a way to get certificates onto the client device. In a passwordless environment, that certificate allows network access and must be protected like a password and thus a secure method of transmission must be devised (in this regard, it might undermine the whole reason you're considering this option).
For laptops, if you can wire it into the network, do some automated validation (MAC Address, Active Directory credentials, or whatever you devise), then you could load a signed cert onto the system (or have the system generate the cert and send a CSR to your CA).
But if your environment has phones/tablets, the problem becomes trickier. Options might be transferring certs by USB flash drives connected to OTG connectors (make sure you sanitize that drive after each time you connect it to a yucky user device). Perhaps you could provide an easier-to-access WiFi network on its own isolated network/VLAN, this could use a single PSK that you rotate as needed, and on this network all you can do is validate your device and be issued a cert. These options come with their tradeoffs, send them through your own risk analysis.
The other concern is that certificates get compromised. Most likely this would only happen if a user's system is owned, but there could be a few other scenarios where a valid certificate is leaked. If you can identify this compromise early, you can have your RADIUS server validate against OCSP or a CRL. To combat against unknown compromises, you could set the certificates to expire quickly, but you have to have an infrastructure set up to automatically renew and install users certificates and ensure that most users connect at least once before their certificates expire. The best idea is probably a little bit of both and locking down network resources so that being on the network doesn't necessarily give you access to anything (i.e. don't use the same client certificates to authenticate to other network resources).
This is not a quick and easy set-up, but it can be a robust one if you find a good level of trade-offs between providing access to users and protecting access from attackers. And it can allow you opportunities to expand and add additional functionality once you become more comfortable with your implementation.