Secure Administrative Accounts with 2-factor Authentication
Properly securing Domain Admin credentials is an extra challenge: any attacker who gains a foothold as a domain admin might be able to alter any restrictions that have been placed onto their account.
Securing Domain Admin accounts
With AuthLite you can solve this problem by removing privileged groups from your domain admin accounts, and letting AuthLite grant the Domain Admins group SID temporarily when the user provides a 2-factor logon. The DA SID is only included within the logon session token, and the static membership of the user object remains unprivileged. See (Fig. 1) for a walk-through of changing Domain Admins to AuthLite-controlled "AuthLite Domain Admins".
Note: You should keep one Administrator account outside the control of AuthLite for emergency recovery purposes (see Fig. 2). Create and store a long random password for it and don't use that account (even for services).
Other administrative accounts
You can create additional group pairs and use the same strategy to control effective membership in other groups to which you've delegated power in the domain.
Services scheduled tasks are automated, and they must be able to log on without human interaction. Therefore by necessity they store the credentials used to log themselves on. If you have any service accounts that run as Domain Admin or other powerful group, that means any compromise of a system running that service can take over your whole domain! Run services and tasks as a lower privilege user if possible. Restrict allowed logon types and locations using group policy User Rights Assignment.
Auditing your power group membership
Through nested group membership, many organizations don't fully know which accounts have power over the domain. We created a powershell function within API.ps1 called PrintUsersInPowerGroups that will enumerate each powerful account in the domain, where it derives power, and some advice about mitigating risks.