Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Service Accounts Can Be Secure Yet Have Non-Expiring Passwords
Here's a way to deny local logons with a service account yet still have that account use a password that doesn't expire.
Kevin Willenborg
November 17, 2010
2 Min Read
Deny logon locally is a Group Policy Object (GPO) setting that should be used for all service accounts because it shuts down one avenue of exploitation—an interactive logon (e.g., a logon using Ctrl+Alt+Del) to a system with that account. Most security teams frown on allowing accounts with non-expiring passwords to exist, but it's often near impossible to do without having some. One of the biggest concerns people have is the account could be used anywhere on the network, leading to abuse of it. To satisfy security teams and auditors, I came up with a simple way to comply with this security practice but still have service accounts with passwords that don't expire. Here's what you need to do:
In the Active Directory (AD) domain, create a security group named something like DenyLogonsLocal. In this new group, you'll want to include the IDs that you’re planning to run a service or a process with but don't need to be used to interactively log on to any machine in the domain.
From a machine on which Group Policy Management Console (GPMC) is installed, create a GPO. You can disable User Configuration because it's not needed.
Navigate to Windows SettingsSecurity SettingsLocal PoliciesUser Rights AssignmentsDeny logon locally. Enter the security group you created in step 1, and save the GPO.
Make sure the GPO is set to authenticated users. Because all the computers in the domain are part of authenticated users, it will apply to all workstations and servers.
Link this GPO at the domain level with no override (ensures someone doesn't undo your work at a lower-level organizational unit—OU) and with Computer Configuration enabled.
Allow time for the workstations and servers to apply the new GPO, then attempt to do an interactive logon from a workstation or server using one of the IDs you made a member of the security group created in step 1. The logon attempt should fail.
If you have more than one domain, you can put groups from the trusted domain in the GPO. However, you might want to make a GPO like this on both sides (in case of two-way trusts).
I recommend that you only grant the access an account needs rather than automatically giving it Administrator access, as the majority of services and processes can be run without Administrator access. For those accounts that need Administrator access, you can still add IDs in local administrator groups on servers or on workstations to support your process and know the IDs can't be used for interactive logons. In the end, both the IT and security teams are closer to a more secure environment.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
