Inside SharePointUpdating Security Account Credentials

Pav Cherny

Code download available at: ChernySharePoint2009_03.exe(821 KB)

Contents

Services and Security Accounts
Services and Security Accounts
One Command for all Services
Going the Full Distance
Deploying and Using the Solution
Conclusion

Microsoft Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 push security manageability to the limit with services and worker processes that rely on domain user accounts to support the discretionary access control (DAC)-based security model of Windows Server. In the role of security accounts, domain user accounts have always struggled to meet enterprise needs. This applies to any client/server environment and even more so to SharePoint server farms, as each service in a farm maintains its own account information and imposes its own specific update procedures, regardless of other services that might use the same credentials. The account in question might be the same account in Active Directory, but you still have to update each service individually after a password change.

Of course, you first must remember all of the services that use an account. It can be challenging to follow security recommendations that suggest using separate domain accounts for SQL Server services, Central Administration and SharePoint Timer services, Search service and crawler, Shared Services Providers (SSPs), Web app pools, Single Sign-On service, user profile import, and Excel Services accounts.

And, of course, there are different strong passwords for each account and frequent password changes to keep track of. Wouldn't it be great to master this challenge without incurring administrative overhead?

Security Resource

Windows SharePoint Services Passwords Web Site

In this the second installment of a two-part series, I discuss aspects of SharePoint security, specifically security account maintenance, and introduce a solution to automate password changes to achieve better security and lower the administrative burden.

The underlying idea is relatively simple: a custom solution can obtain all security account names and passwords by using the SharePoint administrative object model. The solution can use this information to log on to Active Directory, change the corresponding passwords via Active Directory Service Interfaces (ADSI), and update all affected services in the local server farm.

In this way, SharePoint administrators don't have to deal with security account passwords anymore. However, implementing the idea was not so simple. In the end, I found myself creating several components, including Stsadm.exe command extensions, application pages for the SharePoint 3.0 Central Administration site, a SharePoint-integrated Windows service, and a basic programming interface to normalize password changes across all types of SharePoint services.

I didn't have enough time to cover all MOSS services yet, but the current prototype supports WSS 3.0. I have created a Web site at sppwd.com that will, in the near future, provide the MOSS components and other updates as well as further documentation of features and programming interfaces.

The current prototype is for test purposes only and is not to be used in production environments. Not fully tested, it nevertheless demonstrates that SharePoint security account maintenance does not have to increase administrative overhead. The companion material for this column, available at 2009 TechNet Code Downloads, includes worksheets, compiled assemblies, and source code.

Services and Security Accounts

Have you ever wondered why you need to use so many different commands to update SharePoint security accounts after a password change in Active Directory? Then check out the article "How to Change Service Accounts and Service Account Passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0."

It describes five different commands (updateaccountpassword, spsearch/farmserviceaccount, spsearch/farmcontentaccessaccount, updatefarm­credentials, and editssp/ssplogin), and it still doesn't cover all aspects.

Moreover, the article's sample script, while useful as a template, showcases a weak security configuration because it assumes you use the same account and password for all services in the farm. Try adapting this script to a farm environment where each service and application pool uses a different user account and password, and you can experience a great scripting challenge. Maintaining system security through scripts isn't easy in a SharePoint farm.

The reason for the complexities is buried deep within the SharePoint security design. As you learn by using the stsadm -o enumservices command, SharePoint relies on a number of services, and each service has different security dependencies.

If you look up the type name that the enumservices command returns for each service in the WSS 3.0 SDK, you'll find that some of these services use no security accounts, while others may use a single security account or require multiple accounts. For example, messaging-related services and the diagnostics service are not associated with security account information, the SharePoint Timer service uses a single security account, the Search service has a service account as well as a crawler account, and the Web app service can have as many security accounts as there are application pools.

And there is more. The SharePoint Administration Service, for example, must use the local system account, so it doesn't require a domain security account even in a SharePoint farm. Some solutions can also introduce their own services, such as Microsoft Office Project Server (MOPS) 2007. The sky is the limit, considering that you can also have any number of custom solutions with varying security requirements.

Of course, there's no way to enforce common update procedures across such a diverse portfolio of services, so it's no surprise that SharePoint features a rich set of update commands. Essentially, every solution must provide its own individual tools and update procedures, increasing the administrative overhead in proportion to the number of services in the SharePoint environment. Figure 1 illustrates the relationship between SharePoint services and security accounts as well as the applicable update commands.

fig01.gif

Figure 1 Relationship between SharePoint services and security accounts

Services and Security Accounts

The arrangement of services and security accounts might seem confusing, but there is a hierarchical order enforced through the SharePoint object model, as illustrated in Figure 2. At the base of all SharePoint services is the SPService class. This class doesn't include a security account because, as mentioned earlier, not all services require credentials. Services that require credentials can inherit an identity from the SPWindowsService class or implement their own.

fig02.gif

Figure 2 Inheritance hierarchies of SharePoint services

The SPSearchService class, for example, inherits a process identity from the SPWindowsService class and also maintains its own crawler account. The SPWebService class, on the other hand, doesn't need an SPWindowsService­based process identity, so it inherits directly from the SPService class and maintains its own security accounts in the form of application pool identities.

There are many important facts to take away from the inheritance hierarchy. First and foremost, there aren't really that many different ways to deal with security accounts in a SharePoint farm. SharePoint services primarily use process identities or application pool identities. These identity types are very similar with respect to updating security information, because the SP­ApplicationPool class is derived from the SPProcessIdentity class.

Second, the identities of SharePoint services are available to custom scripts and administrative applications. It is possible to get to each individual SharePoint service through the SP­Service base class in order to access login names and passwords.

Third, the SharePoint object model already knows how to handle process identities and app pool identities. Among other things, the object model includes the logic to set and update passwords, so you don't need to reinvent the wheel when using custom tools. You only need to call the required methods, though this isn't without hurdles because the WSS SDK doesn't explain the dependencies very well.

Updating security accounts requires more than setting the Username and Password (or SecurePassword) properties of process identities (SPProcess­Identity) or application pool identities (SPApplicationPool) and calling the Update method. Doing so doesn't put the farm back into operational state. The Update method merely updates the password in the SharePoint configuration database, but it doesn't update the underlying services or app pools.

It is important to keep in mind that the affected resources exist outside of the SharePoint environment. Windows services maintain their security information in the database of the Service Control Manager (SCM), located in the registry on each server under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

Web apps, on the other hand, are resources of IIS. To update them, you must call the identity's Deploy method in addition to the Update method. The Deploy method triggers the SharePoint logic to update all servers in the farm by means of local API calls and SharePoint Timer jobs. It also changes the farm's credential key if your change happens to affect the password of the application pool for the Central Administration Web application (SPWebService.AdministrationService).

This password change also affects the SharePoint Timer service, which is tightly coupled with the administrative infrastructure, so you don't need to update the SharePoint Timer service directly. For details regarding the standard procedures to accomplish password changes in a farm environment with multiple servers, you should read my column from last month, "Maintaining Security Account Credentials."

One Command for all Services

Despite the complexities, the good news is that the SharePoint object model takes care of all the nitty-gritty update details in a server farm. We just need to take advantage of the existing capabilities in a custom Stsadm extension to implement a single update command for all services:

stsadm -o changepwd -user DOMAIN\Account -oldpwd old_p@ssw0rd
 -newpwd new_ p@ssw0rd

There is really no need for so many different update commands. After all, it is clear that you must change the password in all locations, including Active Directory, configuration database, Windows services database, IIS, and whatever other credential repositories a particular service might use.

It isn't an option to leave an outdated password behind. Having a command extension take care of all dependencies implies more consistent password changes across all affected resources and fewer password-related issues in the farm.

Besides, implementing an Stsadm extension is easy and fun. Just follow the steps outlined in the WSS SDK under the title "How to: Extend the STSADM Utility." I also recommend that you check out Gary Lapointe's blog for great examples and an impressive list of useful extensions that you might find helpful in your daily work as a SharePoint administrator.

With the Stsadm implementation details out of the way, we can concentrate our efforts on implementing the actual solution, which is difficult enough considering that SharePoint services can use any number of credentials. This can include process identities, application pool identities, and other accounts.

There is just no way to know the security dependencies of every SharePoint service up front. You can get away with the standard WSS and MOSS services, but a truly useful solution should also support custom services with varying requirements.

Dealing with variety is best accomplished through an API. The API decouples the command extension from the underlying services and in this way enables developers to plug in their own components that contain the logic to carry out password changes for their services.

I call these pluggable components service proxies. By relying on these proxy components, the command extension can accommodate any service, developers don't have to deliver additional password update tools anymore, and administrators don't have to deal with security complexities of underlying services any longer. Thus the administrative burden to maintain security accounts in a SharePoint environment decreases.

Our service proxy API must accomplish two basic things: it must enable the command extension to determine the security accounts of every supported service, and it must enable the command extension to update the associated passwords. Accordingly, the API requires two methods: Resolve­Identities and ChangePassword.

First, the command extension enumerates all services in the farm by using the SPFarm.Local.Services collection. For every service type, the command extension also dynamically loads a service proxy, registered for the service in an XML-based configuration file that follows the passwordproxies.*.xml naming convention (such as passwordproxies.WSSProxies.xml).

Then, the command extension calls the ResolveIdentities method of the registered service proxy, passing along a reference to the service object. The proxy component extracts the desired security accounts from the underlying service and returns this information to the command extension.

The result is an association between security accounts and services that is the reverse of the association established in the SharePoint object model. Instead of services being the parents of security accounts, security accounts are now the parents of services, as illustrated in Figure 3. This architecture reflects the actual relationship between services and security accounts better.

fig03.gif

Figure 3 Reversing the relationship between security accounts and SharePoint services

More important, the command extension can now update the security accounts in Active Directory and then iterate through all dependent service objects to call the ChangePassword method of the corresponding proxies to update the password.

Again, the proxy components contain the service-specific logic necessary to carry out the password changes. The command extension itself does not deal with service-specific implementation details.

If you are interested in the details, check out the SPPwdServiceProxy.cs file in the companion material. It defines the proxy API by means of an abstract SPPwdServiceProxy class with its two methods, ResolveIdentities and ChangePassword. For implementation examples, see the class definitions in the WSSProxies class library.

The WSSProxies library illustrates how to use the service proxy API to perform password changes for the standard WSS 3.0 services. It isn't complicated to change security account passwords programmatically. All you need are three lines of code for process identities and the same three lines for application pool identities. The SharePoint object model does the rest.

Only the crawl account of the SPSearchService class poses a challenge because Microsoft marked the crawl password write only, so you can't read it with ordinary methods. This makes it hard for solution developers to create security solutions.

Going the Full Distance

With a single command extension covering all services, let us focus our attention on a couple of additional improvement opportunities. The first one is to eliminate the necessity of specifying passwords in clear text at a command prompt, which is not a secure practice. Even the simplest password box in the graphical user interface would mask this information.

Another opportunity is to increase the complexity of passwords without increasing the administrative burden. Perhaps passwords with seven random alphanumeric characters were once considered secure, but that assumption was established a long time ago and probably does not hold true for security accounts now.

How about using 50 or more chars for important resources, such as SharePoint security accounts: 3ZK2AQUuqZ7/M7­NBIEvc{XKregSMaVmQgiZaZXik­hL8E{dQuwyQ for the farm account; TA3pIa7yUyJikc6FxTFl=K9EQcb8lBn­hp8ej03lt3+mA=7aqgKA for the default Web app; PXMzzAxrHvO/L9MZyd0SkVuMv9/co0ocluYCq/4TID/n+DLj­XYA for the Search service account; and qjoNlEvOX$7vbEjrnDd5lXLPYvZEFf­gRpij$8amSbEVpj2O474Q for the crawler account?

It strikes me as funny to imagine an admin entering these types of passwords manually. Another improvement opportunity relates to security checks. By default, SharePoint doesn't warn you about weak security configurations, such as application pools having access to the IIS metabase or using the farm account as their security identity. A custom solution can perform these checks on a regular basis.

And finally, why do SharePoint admins have to deal with these passwords for security accounts? Attackers are perhaps the only ones interested in knowing these passwords. Administrators generally don't need to use them.

Of course, SharePoint offers a lot of options to tackle these opportunities. You can use scripts, but scripts usually handle passwords in clear text. You can use custom Timer jobs, which the SharePoint Timer service processes in scheduled intervals, but the Timer service already takes care of many tasks, including credential deployments.

It would be difficult to coordinate credential deployment jobs with password change jobs. It seemed better to implement a separate SharePoint service that utilizes the farm account as its process identity to gain full access to the SharePoint administrative object model.

Among other things, you can stop this service at any time without affecting other processes, and you can disable this service if you prefer to change passwords manually. The solution includes several tools for this purpose, such as Stsadm command extensions, a Windows application, and custom Central Administration application pages, as displayed in Figure 4.

fig04.gif

Figure 4 SPPwd solution architecture

Essentially, all SPPwd apps rely on the same set of Stsadm extensions, so there is only one code path regardless of what tool you use. Through a layer of common business logic, the command extensions in conjunction with service proxies perform the actual processing, while the SPPwd applications use stub objects to load the command extensions dynamically at run time.

This loose coupling enables you to replace certain command extensions without having to modify the SPPwd applications. For example, if you prefer to use a different password generator, you can create a command extension, deploy it in the global assembly cache, and modify the genpwd command entry in the stsadmcommands.passwordmanagement.xml configuration file. The solution places it in the %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\12\Config folder according to Stsadm extensibility conventions.

The default generator creates those long passwords, which should be sufficient in most cases. Figure 5 lists the SPPwd command extensions with a short description of their purpose. You can also use the stsadm -help <extension> command to display further information about available parameters and command-line examples.

Figure 5 Stsadm command extensions for the SPPwd solution
Extension Code File Description
accesscheck SPPwdAccessCheck.cs Checks whether the current user or a specified account has read access to security-sensitive information in the IIS metabase and the local registry. The SPPwd service analyzes the results of these checks as well as the general security account configuration and writes warnings to the Application event log if it detects security weaknesses.
changepwd SPPwdChangePwd.cs Changes the password for the specified user account in Active Directory and all SharePoint services that use the account as a security identity.
genpwd SPPwdGenerator.cs Generates random passwords based on a cryptographic Random Number Generator (RNG) and hash algorithms that can be considered reasonably secure.
sppwdsetup SPPwdServiceSetup.cs Installs or uninstalls the Windows service on the local SharePoint server.
enumpoolaccounts SPPwdAppPoolAccounts.cs Lists the identities of the SharePoint Web applications as parents of their associated application pools. The SPPwd service uses this information to check for security weaknesses, such as application pools that share the same identity or that use the farm account.
enumserviceids SPPwdListServiceIds.cs Lists the identities of the services available in the SharePoint server farm as parents of their associated services. The SPPwd service uses this information to retrieve the login name and current password of each service in order to use this information for Active Directory logons and carrying out password changes.
enumproxies SPPwdServiceProxies.cs Lists the SPPwdServiceProxy objects registered and loaded on the server. This tool is useful for developers who want to verify the configuration of their service proxies.
enumsppwdservers SPPwdServerList.cs Lists the fully qualified domain name of the SharePoint servers in the local farm, configured to run the SPPwd service. This information is helpful when configuring security accounts for automated password changes.
sppwdacctcfg SPPwdAccountSettings.cs Configures SPPwd-related settings for the specified security account in Active Directory. The SPPwd service does not process security accounts unless the account's extensionAttribute10 is set to the fully qualified domain name of the computer running the SPPwd service. In addition, the security account's description attribute must contain the phrase "This account is used only in the SharePoint farm: <Name of Farm>."
sppwdsvccfg SPPwdConfig.cs Displays or changes the system configuration of the SPPwd service. Settings include the configuration check interval, the maximum password age for security accounts, the level of detail for events written to the Application event log, and a parameter to disable Whatif mode explicitly. By default, the SPPwd service runs in Whatif mode to prevent accidental password changes. In Whatif mode the service only pretends to change passwords and reports the outcome of the operation, but it actually does not commit any changes.
Heartbeat SPPwdCheckHeartbeat Manages SharePoint Timer heartbeat jobs in a SharePoint server farm. The SPPwd solution uses these heartbeats to detect offline servers and prevents password changes in this case.

Deploying and Using the Solution

The worksheets in the companion material outline in detail how to deploy and use the SPPwd solution in a single-server environment as well as in a server farm. You only need to deploy the solution on one SharePoint server by using the standard addsolution and deploysolution Stsadm commands.

SharePoint then distributes the solution to all servers in the farm through Timer jobs. As soon as these jobs are completed, you can activate the solution feature to extend the Central Administration site and install the Windows service by using the sppwdsetup command extension.

The companion material includes a DeployTo.bat file to automate these tasks. Among other things, the batch file demonstrates how to wait for Timer jobs to complete before proceeding with further deployment steps.

By default, the SPPwd service is only available on the server where you run the DeployTo.bat file. You can configure the service to run on multiple SharePoint servers, but there is only one instance of a security account in Active Directory, and it imposes the following two requirements: only one SPPwd service instance can be authoritative for a particular security account, and the security account must not be used in multiple farms.

Having multiple service instances process the same account can lead to concurrent access problems and isn't necessary since SharePoint propagates credential updates in the local farm automatically. Shared security accounts aren't supported because the SPPwd service can't update security account information across multiple farms.

The SPPwd service only updates security accounts that specify the server's fully qualified domain name in the adminDescription attribute and that confirm in their description attribute that they're only used in the local SharePoint farm, as indicated in Figure 6. See the companion material for more regarding the configuration of security accounts and the SPPwd service to automate password changes.

fig06.gif

Figure 6 SPPwd deployment and security account configuration

Conclusion

Security accounts are prime targets for attacks, because they can provide full access to all site collections and site data in a farm regardless of permissions and access controls defined at the SharePoint level. One basic strategy to prevent these attacks from succeeding is to use strong security account passwords and change them frequently.

This is challenging to accomplish because domain user accounts don't change their passwords on their own. You must perform the password changes manually or use an automated solution. Whichever way you choose, there are numerous dependencies that the SharePoint documentation and the WSS SDK don't describe very well.

You must update and deploy changed passwords, and there are additional concerns related to the farm account. For example, when you change the farm account password, you change the farm's credential key, and this affects the recoverability of the configuration database from backup.

Nevertheless, there is no alternative to changing the farm account password on a regular basis if you want to maintain system security in a SharePoint farm. Make sure you perform a backup after changing the farm account password.

Automating password changes is complicated despite the fact that the SharePoint object model includes the necessary logic to carry out credential updates. It might seem easy first glance, but even a script-based approach can quickly turn into a huge challenge. A full-featured solution based on the Microsoft .NET Framework and the SharePoint administrative object model is a good choice, but the best solution can only come directly from Microsoft in the form of additional system account innovations.

Almost 10 years ago, Microsoft modified the local system account to accommodate the needs of enterprise customers using Microsoft Exchange Server. This eventually resulted in the Network Service account with Windows Server 2003. But the Network Service account is not suitable for server farms, so we must still use domain user accounts and deal with the associated maintenance and security issues to the best of our abilities.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.