Most enterprises expend significant effort to ensure that when employees leave the firm, all computer access has been disabled by the time they make their final exit. When IT staff members leave the firm, some enterprises might even change the Administrator account passwords for the domains to prevent unauthorized access through a shared account. Unfortunately, those same IT staff members are likely to have set up Microsoft Systems Management Server (SMS), Microsoft Exchange Server, and other applications that require an administrative account in the domain. But few enterprises modify the service account passwords when IT staff members leave.
Adding to the security risk that service accounts pose, consider that setting the Password Never Expires flag for service accounts is typically considered good practice. Although setting this flag typically reduces the probability of a service logon failure, it provides password hash-comparison utilities such as L0phtCrack an infinite amount of time to obtain the password for a privileged account.
The solution to mitigate both these risks seems quite simple in theory: Change the service account passwords regularly to an unknown value. In practice, however, most IT shops are unwilling to do so because of the potential risk of compromising the functionality of their core infrastructure services. However, you can automate the process of managing service account passwords. By writing a service-account-password management script, you not only reduce the security risk that privileged accounts pose but also reduce the risk of incurring downtime as a result of changing service account passwords.
To automate the process for managing service account passwords, you can use Active Directory Service Interfaces (ADSI) to write a script that
- Enumerates machines in a domain to find the services that use domain accounts
- Binds to a specific service for further management
- Changes the service logon password
- Changes the account password in the namespace
- Cycles the service to activate changes
Enumerating Machines
Like many ADSI code segments, the code to find services with domain accounts begins with an enumeration function. As Listing 1 shows, you enumerate a Windows NT domain to determine the accounts that support various enterprise services. First, you enumerate the namespace ("WinNT://TargetDomain", where TargetDomain is your domain's name) and establish bindings to each computer in the domain. Then, you enumerate each service and query whether a domain account has been assigned to the IADsService::ServiceAccountName property.
Binding to a Service
If you know the ADsPath for the service to which you want to bind, you can use the direct binding method, which Listing 2 shows. To use this code, you need to customize the TargetDomain, TargetComputer, and ServiceProgrammaticName entries in the ADsPath that VBScript's GetObject function uses to bind to the service.
When you customize the ServiceProgrammaticName entry, make sure you use the service's programmatic name and not its display name. Typically, systems administrators are most familiar with the display name, which appears in the Control Panel Services applet (in NT) or the Microsoft Management Console (MMC) Computer Management snap-in (in Windows 2000). Unfortunately, you can't use a display name to bind to a service. Instead, you must use the service's programmatic name. Quite often, this name matches the relative name of the executable (without the extension) in the host computer's file system. However, this isn't always the case, so you might want to use an alternative way to find the programmatic name. A fail-safe approach is to bind to the computer, enumerate all services, and display the IADs::Name and IADsService::DisplayName properties for each service. The IADs::Name property contains the programmatic name.