Create-Group-Policy

Create-Group-Policy

Make the policies:

• Computer: Block logon by AuthLite 1-Factor Session Tag

• Computer: Allow Network Access by AuthLite 1-Factor Session Tag (override Deny)

AuthLite policy never blocks non-AuthLite users. In almost all cases you should apply the policy at the domain root, even if you are only testing a limited scope of users.  AuthLite never blocks non-AuthLite users, the policy only directs computers to enforce the AuthLite users.

The Block policy is applied to the root, so all computers in the domain will know to block 1-factor logon by AuthLite users.  This has no impact on any other users. If you want AuthLite users to do 1-factor logon everywhere except certain locations, you can remove the group policy link from the root and apply it in a more limited location.

Beware allowing 1-factor logons by AuthLite users. If computer A is enforced but B is not, an attacker with the password could log in at B to get a kerberos ticket, then use that ticket to attack A.  It is almost always best practice to prevent 1-factor logon of AuthLite users as broadly as possible.

The Domain Controllers OU gets a slight exception, allowing 1-factor network access even by AuthLite users.  Because normal users are not privileged on DCs, and as long as you protect Domain Admins with group switching, this is not a security issue. It is required for LDAP authentication, group policy processing, and password changes to work as normal.

In some cases this command makes changes to the Default Domain Controllers Policy, so a backup is made in the user's home directory before proceeding.  Any blank (defined, but empty) Deny items are removed (except Network, see above).