Why is this a really bad combination, unless you make a critical change to a policy you probably didn't know about... Also, don't be fooled, SmartCard is only feasible for interactive logons--at CrowdStrike, we fixed that and added MFA to programmatic/non-interactive logons. Another post will be made here, which will also show relevance to SUNBURST.
‘Smart card is required for interactive logon’ was created back when the major threat to your Identity-plane was plaintext brute-force attacks. That is, we didn’t want adversaries to guess our plaintext passwords, so we literally built random-256-byte-length hashes, so that no one would even know the plaintext password.
This was a great capability when it was released, and for what it was created for, it was quite successful.
However, today we live in a world of credential theft. That is, now, we must defend the Kerberos TGTs and NTLM hashes that are exposed to our machines after we perform certain logon events. This is a very different problem space.
Thanks to things like Windows Credential Editor (WCE) and Mimikatz, research around this area made everyone know this was a real issue. Credential theft became something that not just advanced adversaries were doing, but eventually script kiddies. These capabilities found themselves in open-source software, readily available to the masses for all to consume and use.
This is where smartcard implementations actually exacerbated the issue, leaving anyone who used it, at more risk. If your using a Smart card, you literally do not know your password, on purpose! However, if an adversary ever harvested your credentials, they could be and act and access any resource you can… your password never changes, so neither does the NTLM Hash. This means, had your credentials been harvested, and even if you received 20 different smart cards and reset your PIN for 100 times each, your password actually never changes.
Here is another risk… even if your using SCRIL (smart card required for interactive logon), it’s only useful during those logon events, “interactive logon”. This could be local interactive or remote interactive (i.e. RDP). But what about network logon? What about batch logon?
Unless your organization is not allowing SCRIL users to perform logons that are not interactive (I’ve yet to see a customer ever do this), this means an adversary could compromise your credential and still use your credential to access resources… just not via an interactive logon. To normal users, this might not much, but for administrators who manage Exchange and network infrastructure, this could mean quite a lot.
So, what can we do about that?
Well, besides moving to hardware backed authentication methods, such as Windows Hello, we can roll our accounts.
Some will give you links on scripts that manually reset these bits. I would never use that, as we’ve seen operational impact, such as users getting locked out and current logon sessions being reset, leading to unhappy (if not locked out) users.
A more graceful way of doing this reset is using a Domain Functional Level 2016 feature. This allows you to roll the behind-the-scenes NTLM hash as the user logons. During logon, Active Directory would see how old the NTLM hash is, and if it is older than the set policy, it would roll the NTLM hash and then enable them to logon.
This is probably the most overlooked feature in both Active Directory. It’s free.
This doesn’t solve harvested credentials. In fact, nothing does. The best we can do is tie credentials to an individual machine (based on hardware/TPM binding), and there for the harvested credentials can only be used from a machine.
On a monitoring side, products like Azure Advanced Threat Protection can further help by detecting anomalous activity as well as other Identity-based attacks.
But the best thing you can do, for free, is at least force the adversary to have to re-compromise your credentials if they want to become you. Don’t let a compromise of 20-years ago still impact you and your organization.