I'm at a Tier 1 PCI vendor. We have something like this in place, with a few differences.
The auditors are actually attempting to describe a very real problem, but doing an incredibly poor job explaining the implications and needs analysis.
It is now more effective to compromise a system by using a hash of a password or an existing token. Put plainly, your attacker no longer needs your username and password. There are now easier ways to attack a system. Under no circumstances should you assume or conclude that this type of attack is unlikely. Hash attacks are now the defacto attack vector.
Hash attacks are actually worse with smart card accounts, which is ironic, because most people expect that implementing smart cards would increase the security of a system.
If an account is compromised due to a pass-the-hash attack, the usual response is to change the account's password. This changes the hash that is used to authenticate. Also, a normal password expiration/change may surface an incursion, due to the attacker's hash would begin to fail. However, with smart cards, the password is 'system-managed' (the user never enters the password to authenticate), so the hash never changes. That means with smart card accounts, an incursion may go unnoticed for much longer than with an account that uses a password.
Here are mitigations I would consider:
For smartcard-enabled accounts, which many large companies use for
highly-privileged accounts, change the password of the account on a
frequent interval. This changes the hash. You can also change the
hash by un-smartcard enabling the account, then re-smartcard enabling
it. Microsoft does this every 24 hours, but you need to evaluate the
potential impact this may cause in your environment, and establish a
sane schedule so that you don't create additional problems.
For workstations, I would not use domain accounts for admin purposes at all, if
possible. We have a local account that can be used to elevate for UAC
type operations. This satisfies 99.9% of most elevation
requirements. Workstations tend to be hot attack vectors, due to the
lack of regimented change control, and the existence of Java JRE and Flash.
This approach works for us due
to we have a formal mechanism for managing and enforcing the password
for the local accounts and that the password is unique on each
system, and that a secure method exists for someone to request the
password. There are also commercial applications that can perform
If you cannot provide a local account solution for workstations, then yes, a
separate domain account should be used for administrative access to
workstations, and that account should not be used for administrative
access to servers. Another option may be to use remote, non-interactive support
management tools that use LocalSystem to perform activities, and an
authentication mechanism that is separate from Windows.
For the highest privileged accounts (Enterprise Admin, Domain Admin,
etc), use only a jump server. This server would be
subject to the most restrictive security, change control, and
auditing. For all other type of administrative type functions,
consider having a separate administrative account. The jump server
should be restarted daily restarts to clear the process tokens from the LSA process.
Do not perform administrative tasks from your workstation. Use a hardened server or a jump server.
Consider using easily resetting VMs as your jump boxes, which can be
reset to clear out memory after each session.
Microsoft Security Intelligence Report, Volume 13, January - June 2012
Read the section: "Defending against Pass-the-Hash attacks".
Defeat dreaded pass-the-hash attacks