As far as i understand, unless you do some kind of security posture assessment (which requires expensive apex licenses for both anyconnect and ISE and some custom development), VPN framework itself doesn't really have any mechanism to verify computer identity unless you do machine authentication.
You could just issue certificates to machines, but the catch is that in this case AnyGonnect GUI must run "as administrator" (so use UAC elevation) in addition to the user having local admin rights as such.
By default AnyConnect GUI will run under user context and will not have access to machine certificate store. Close it, they right click and 'run as administrator', and it should be able to use machine cert. Probably this could be fixed with custom anyconnect deployment somehow, i didn't really look into it.
I eventually gave up trying to make it work with machine certificate auth as there are no real benefits from it (in my case at least) since AnyConnect SBL seems to be unusable with machine auth anyway. I.e. computer will not be able to start VPN before user logs in even if you use machine cert, which means that some things might not work quite well(some apps trying to authenticate with AD during startup or logon scripts for example). If SBL could work totally transparent for a user before login it would make perfect sense. Would be happy to be wrong here.
What i ended up doing is using a single auth with user certificates issued via AD for VPN authentication and AD authorization. Though not impossible, it is not technically easy for a user to get a new cert from Windows PKI from a non-domain machine due to access restrictions (certificate provisioning via GP). Or at least it could be set up that way, to a reasonable degree of assurance. Exporting of private key should also be disabled as otherwise a cert can easily be transferred to a 3rd party device (assuming it could also be done with export restrictions, just not so easily).
As for dual authentication, it seems that second auth must be aaa, thus no certs. I haven't personally tried, but from the looks of it AnyConnect cannot automatically use logged in user's credentials so they must be typed it. It makes more sense with RSA tokens actually, not in AD computer certificate + user u\p.
Suitability of my approach will depend on your security and functional requirements. In my case, I was trying to make it seamless and transparent for users to get as close as possible to Microsoft Direct Access without sacrificing security to much, and there was no need in differentiated access. If you just want to restrict access to domain computers (totally valid security requirement) then this might work for you as well. If you require some sort of two-factor auth, a user\machine cert for first auth and u\p for second auth might work, but would not be seamless. However, i would not consider a cert stored on a laptop as a proper second factor (something I have) as a laptop can be compromised and used remotely (including the cert) while proper second factor would require a physical action that needs to be done by a user (see a token code - one can't do it remotely).
You might want to do certificate authorization via AD or LDAP as well as validity of a certificate itself shouldn't automatically mean that a user (or computer) is allowed in. Account might be disabled already, but cert not revoked.
