Sugerir tradução
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Março 2009 >  Automatizar atualizações de credenciais de cont...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
Inside SharePoint Updating Security Account Credentials
Pav Cherny

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

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?
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 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.
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.
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.
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.
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.
Figure 6 SPPwd deployment and security account configuration
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.

Dentro do SharePoint Atualizar as credenciais de conta de segurança
Pav Cherny

Download do código disponível em: ChernySharePoint2009_03.exe (821 KB)

Microsoft Windows SharePoint Services (WSS) 3.0 e gerenciamento de segurança do Microsoft Office SharePoint Server (MOSS) 2007 envio até o limite com os serviços e processos de trabalho que dependem de contas de usuário de domínio para oferecer suporte o controle de acesso discricional (DAC) com base no modelo segurança de Windows Server. Na função de contas de segurança, as contas de usuário de domínio sempre tem lutavam atender às necessidades da empresa. Isso se aplica a qualquer ambiente de cliente/servidor e ainda mais portanto farms de servidor dimensão SharePoint, como cada serviço em um farm mantém suas próprias informações de conta e impõe seus próprios procedimentos de atualização específica, independentemente de outros serviços que podem usar as mesmas credenciais. A conta em questão pode ser a mesma conta no Active Directory, mas você ainda precisará atualizar cada serviço individualmente após uma alteração de senha.
Obviamente, primeiro esqueça todos os serviços que usam uma conta. Ele pode ser um desafio para seguir as recomendações de segurança que sugerem usando contas de domínio separados para serviços do SQL Server, serviços de administração central e o timer do SharePoint, pesquisa de serviço e rastreador, provedores de serviços compartilhados (SSPs), pools de aplicativo da Web, serviço Single Sign-on, perfil de importação de usuário e contas de serviços do Excel.
E, obviamente, não há senhas diferentes para cada conta e alterações de senha freqüentes para controlar. Não seria bom mestre esse desafio sem incorrer em sobrecarga administrativa?
Nesta segunda parte de uma série de duas partes, abordam aspectos da segurança do SharePoint, especificamente segurança conta manutenção e apresentar uma solução para automatizar as alterações de senha para obter maior segurança e reduzir a sobrecarga administrativa.
A idéia subjacente é relativamente simples: uma solução personalizada pode obter todos os nomes de conta de segurança e senhas usando o modelo de objeto administrativo do SharePoint. A solução pode usar essas informações para fazer logon no Active Directory, alterar as senhas correspondentes por meio de Active Directory Service Interfaces (ADSI) e atualizar serviços todos afetados no farm local.
Dessa forma, os administradores do SharePoint não precisam lidar com senhas de contas de segurança mais. No entanto, não foi tão simples implementando a idéia. No final, eu me vi criar vários componentes, incluindo as extensões de comando Stsadm.exe, páginas de aplicativos para o site de Administração Central do SharePoint 3.0, um serviço do Windows integrada ao SharePoint e uma interface de programação básica para normalizar alterações de senha através de todos os tipos de serviços do SharePoint.
Não tenho tempo suficiente para cobrir todos os serviços do MOSS ainda, mas o protótipo atual oferece suporte a WSS 3.0. Criei um site da Web em que, no futuro próximo, oferecerá os componentes do MOSS e outras atualizações, bem como mais documentação de recursos e interfaces de programação.
O protótipo atual é para fins de teste somente e não deve ser usado em ambientes de produção. Não é totalmente testada, ele Entretanto demonstra que manutenção de conta de segurança do SharePoint não é necessário aumentar a sobrecarga administrativa. O material complementar para nesta coluna, disponível em Downloads de código do TechNet 2009 , inclui planilhas, assemblies compilados e código-fonte.

Serviços e contas de segurança
Ter você nunca saber por que você precise usar muitos comandos diferentes para atualizar contas de segurança do SharePoint após alterar uma senha no Active Directory? Em seguida, leia o artigo" Como alterar contas de serviço e senhas de conta de serviço no SharePoint Server 2007 e no Windows SharePoint Services 3.0 ."
Ele descreve cinco comandos diferentes (updateaccountpassword, SPSEARCH/farmserviceaccount, SPSEARCH/farmcontentaccessaccount, updatefarm­credentials e editssp/ssplogin), e ele ainda não abrangerá todos os aspectos.
Além disso, o script de exemplo deste artigo, enquanto útil como um modelo, apresenta uma configuração de segurança precária porque ele assume que você use a mesma conta e senha para todos os serviços no farm.. Tente adaptando o script para um ambiente de farm em que cada serviço e aplicativo pool usa uma conta de usuário diferente e senha, e você pode enfrentar um grande desafio de script. Mantendo segurança do sistema por meio de scripts não é fácil em um farm do SharePoint.
A razão para as complexidades é encoberta profundidade dentro o design de segurança do SharePoint. Como você aprendeu, usando o comando de enumservices stsadm -o, SharePoint depende de inúmeros serviços, e cada serviço possui dependências de segurança diferentes.
Se você pesquisar o nome do tipo que o comando enumservices retorna para cada serviço no SDK do WSS 3.0, você encontrará que alguns desses serviços não usam nenhuma conta de segurança, enquanto outros podem usar uma conta de segurança único ou exigir várias contas. Por exemplo, serviços relacionados a mensagens e o serviço de diagnóstico não estão associados a informações de conta de segurança, o serviço de Timer do SharePoint usa uma conta de segurança único, o serviço de pesquisa tem uma conta de serviço, bem como uma conta de rastreador e o serviço de aplicativo da Web pode ter várias contas de segurança como há são pools de aplicativos.
E não existe mais. O serviço de administração do SharePoint, por exemplo, deve usar a conta do sistema local, para que ele não requer uma conta de segurança de domínio, mesmo em um farm do SharePoint. Algumas soluções também podem apresentar seus próprios serviços, como o Microsoft Office Project Server (MOPS) 2007. O céu é o limite, considerando que você também pode ter qualquer número de soluções personalizadas com variáveis requisitos de segurança.
Claro, não há nenhuma maneira de aplicar procedimentos de atualização comuns em um portfólio variado de serviços, portanto, não é nenhuma surpresa que SharePoint apresenta um conjunto rico de comandos de atualização. Basicamente, cada solução deve fornecer suas próprias ferramentas individuais e atualizar procedimentos, aumentando a sobrecarga administrativa em proporção ao número de serviços no ambiente do SharePoint. a Figura 1 ilustra a relação entre os serviços do SharePoint e contas de segurança bem como os comandos de atualização aplicável.
Figura 1 relação entre contas de segurança e serviços do SharePoint

Serviços e contas de segurança
A organização de serviços e contas de segurança pode parecer confusa, mas há uma ordem hierárquica aplicada por meio do modelo de objeto SharePoint, como ilustrado na Figura 2 . Na base de todos os serviços do SharePoint é a classe SPService. Esta classe não inclui uma conta de segurança porque, como mencionado anteriormente, nem todos os serviços requerem credenciais. Serviços que necessitam de credenciais podem herdar uma identidade da classe SPWindowsService ou implementar seus próprios.
A Figura 2 hierarquias de herança de serviços do SharePoint
Por exemplo, a classe SPSearchService, herda de uma identidade de processo da classe SPWindowsService e também mantém sua própria conta de rastreador. A classe SPWebService, por outro lado, não precisa uma identidade de processo SPWindowsService­based, portanto, ele herda diretamente da classe SPService e mantém suas próprias contas de segurança na forma de identidades do pool de aplicativos.
Há vários fatos importantes fora da hierarquia de herança. Primeiro e foremost, existem realmente que muitas maneiras diferentes para lidar com contas de segurança em um farm do SharePoint. Serviços do SharePoint principalmente usam identidades de processo ou identidades de pool de aplicativos. Esses tipos de identidade são muito semelhantes em relação ao atualizar informações de segurança, porque a classe SP­ApplicationPool é derivada da classe SPProcessIdentity.
Em segundo lugar, as identidades dos serviços do SharePoint estão disponíveis para aplicativos administrativos e scripts personalizados. É possível ir para cada serviço individual do SharePoint por meio da classe base SP­Service para acessar os nomes de logon e senhas.
Em terceiro lugar, o modelo de objeto SharePoint já sabe como lidar com identidades do processo e identidades de pool de aplicativo. Entre outras coisas, o modelo de objeto inclui a lógica para definir e atualizar as senhas, portanto, você não precisará reinventar a roda ao usar ferramentas personalizadas. Você só precisará chamar os métodos necessários, embora isso não é sem obstáculos porque o SDK do WSS não explicar as dependências muito bem.
Atualizar contas de segurança requer a mais de definir as propriedades nome de usuário e senha (ou SecurePassword) de identidades de processo (SPProcess­Identity) ou identidades de pool de aplicativos (SPApplicationPool) e chamando o método Update. Isso não coloca o farm novamente em estado operacional. O método Update apenas atualiza a senha no banco de dados de configuração do SharePoint, mas ele não atualiza os serviços base ou pools de aplicativo.
É importante ter em mente que os recursos afetados existem fora do ambiente de SharePoint. Serviços do Windows mantêm suas informações de segurança no banco de dados do Service Control Manager (SCM), localizadas no registro em cada servidor em HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services.
Aplicativos da Web, por outro lado, estão recursos do IIS. Para atualizá-los, você deve chamar método de implantação da identidade juntamente com o método Update. O método de implantação dispara a lógica de SharePoint para atualizar todos os servidores no farm por meio de chamadas de API locais e trabalhos de timer do SharePoint. Ele também altera chave de credencial do farm se a alteração afeta a senha do pool de aplicativos para o aplicativo Web da Administração Central (SPWebService.AdministrationService).
Essa alteração de senha também afeta o serviço de Timer do SharePoint, que está intimamente ligado com a infra-estrutura administrativa, portanto, você não precisa atualizar o serviço de Timer do SharePoint diretamente. Para obter detalhes sobre os procedimentos padrão para realizar alterações de senha em um ambiente de farm com vários servidores, leia minha coluna do mês passado " Manter credenciais de conta de segurança ."

Um comando para todos os serviços
Apesar das complexidades, a boa notícia é que o modelo de objeto SharePoint cuida de todos os detalhes de atualização detalhes em um server farm. Precisamos apenas tirar proveito dos recursos existentes em uma extensão de STSADM personalizada para implementar um comando de atualização única para todos os serviços:
stsadm -o changepwd -user DOMAIN\Account -oldpwd old_p@ssw0rd
 -newpwd new_ p@ssw0rd
Não é realmente necessário para vários comandos de atualização diferente. Afinal, é claro que você deve alterar a senha em todos os locais, incluindo do Active Directory, banco de dados de configuração, o banco de dados de serviços de Windows, IIS e que outros repositórios de credencial um determinado serviço pode usar.
Ele não uma opção para deixar uma senha desatualizada atrás. Com uma extensão de comando cuidar de todas as dependências implica alterações de senha mais consistentes em todos os recursos afetados e menos problemas de senha-relacionados no farm.
Além disso, a implementação de uma extensão de STSADM é fácil e divertido. Apenas execute os passos descritos no SDK do WSS sob o título" Como: Estender o utilitário STSADM ." Também recomendo que você fazer check-out Blog do Carlos Lapointe Para exemplos excelentes e uma lista impressionante de extensões útil que pode ser útil em seu trabalho diário como um administrador do SharePoint.
Com os STSADM implementação detalhes fora do caminho, podem se concentrar nossos esforços como implementar a solução real, que é difícil suficiente considerando que podem de serviços do SharePoint usar qualquer número de credenciais. Isso pode incluir identidades de processo, identidades de pool de aplicativos e outras contas.
Não é apenas possível saber as dependências de segurança de cada serviço do SharePoint com antecedência. Você pode obter imediatamente com os serviços padrão do WSS e MOSS, mas uma solução realmente útil deve também oferecer suporte a serviços personalizados com requisitos diferentes.
Lidar com várias melhor é realizada por meio de uma API. A API desmembra a extensão de comando dos serviços base e dessa maneira permite aos desenvolvedores conecte seus próprios componentes que contém a lógica para executar alterações de senha para seus serviços.
Chamo esses componentes conectáveis proxies de serviço. Por contar com esses componentes de proxy, a extensão de comando pode acomodar qualquer serviço, os desenvolvedores não precisam fornecer ferramentas de atualização de senha adicional mais e os administradores não devem lidar com complexidades de segurança de serviços subjacentes mais. Assim, diminui a carga administrativa para manter contas de segurança em um ambiente do SharePoint.
Nosso proxy do serviço API deve fazer duas coisas básicas: ele deve habilitar a extensão de comando para determinar as contas de segurança de cada serviço com suporte e ele deve habilitar a extensão de comando atualizar as senhas associadas. Da mesma forma, a API requer dois métodos: Resolve­Identities e ChangePassword.
Em primeiro lugar, a extensão de comando enumera todos os serviços no farm. usando a coleção SPFarm.Local.Services. Para cada tipo de serviço, a extensão de comando também dinamicamente carrega um proxy de serviço, registrado para o serviço em um arquivo de configuração com base em XML que segue a convenção de nomenclatura passwordproxies.*.xml (como passwordproxies.WSSProxies.xml).
Em seguida, a extensão do comando chama o método ResolveIdentities o proxy de serviço registrado, passando uma referência ao objeto serviço. O componente proxy extrai as contas de segurança desejado do serviço de base e retorna essa informação para a extensão de comando.
O resultado é uma associação entre contas de segurança e serviços que é o contrário da associação estabelecida no modelo de objeto SharePoint. Em vez de serviços sendo os principais das contas de segurança, contas de segurança são agora os pais dos serviços, conforme ilustrado na Figura 3 . Essa arquitetura reflete a relação real entre serviços e contas de segurança melhor.
A Figura 3 reverter a relação entre contas de segurança e serviços do SharePoint
Mais importante, a extensão de comando pode atualizar agora as contas de segurança no Active Directory e, em seguida, iterar em todos os objetos serviço dependente para chamar o método ChangePassword dos proxies correspondentes para atualizar a senha.
Novamente, os componentes de proxy contém a lógica de específico do serviço necessário para realizar as alterações de senha. A extensão de comando propriamente dito não lidam com detalhes de implementação específico do serviço.
Se você estiver interessado nos detalhes, consulte no material complementar arquivo SPPwdServiceProxy.cs. Ele define o proxy API por meio de um resumo SPPwdServiceProxy classe com seus dois métodos, ResolveIdentities e ChangePassword. Para obter exemplos de implementação, consulte as definições de classes na biblioteca de classes WSSProxies.
A biblioteca WSSProxies ilustra como usar o proxy de serviço API para executar alterações de senha para os serviços padrão do WSS 3.0. Não é complicado para alterar senhas de contas de segurança por meio de programação. Tudo o que você precisa são três linhas de código para identidades de processo e das mesmas três linhas para identidades do pool de aplicativos. O modelo de objeto SharePoint faz o resto.
Somente a conta rastreamento da classe SPSearchService representa um desafio porque Microsoft marcado como a gravação de senha de rastreamento somente, para que você não pode lê-lo com métodos comuns. Isso torna difícil para a solução aos desenvolvedores criar soluções de segurança.

Passar a distância total
Com uma extensão de único comando abrangendo todos os serviços, permita-nos se concentrar nossa atenção na algumas oportunidades de aprimoramento adicional. O primeiro é eliminar a necessidade de especificar senhas em texto não criptografado em um prompt de comando, que não é uma prática de segurança. Até mesmo a mais simples caixa de senha na interface gráfica do usuário seria máscara essas informações.
Outra oportunidade é aumentar a complexidade das senhas sem aumentar a carga administrativa. Talvez a senhas com sete caracteres alfanuméricos aleatórios eram depois considerado seguro, mas que suposição foi estabelecida um muito tempo atrás e provavelmente não mantém true para contas de segurança agora.
Que tal usando 50 ou mais caracteres para recursos importantes, tais como contas de segurança do SharePoint: 3ZK2AQUuqZ7/M7­NBIEvc {XKregSMaVmQgiZaZXik­hL8E {dQuwyQ para o farm conta; TA3pIa7yUyJikc6FxTFl = K9EQcb8lBn­hp8ej03lt3 + mA = 7aqgKA para o aplicativo da Web padrão; DLj­XYA PXMzzAxrHvO/L9MZyd0SkVuMv9/co0ocluYCq/4TID/n + para a conta do serviço pesquisa; e qjoNlEvOX $ 7vbEjrnDd5lXLPYvZEFf­gRpij $8amSbEVpj2O474Q para a conta do rastreador?
Ele apresenta-me como funny imaginar um administrador digitar esses tipos de senhas manualmente. Outra oportunidade de melhoria se relaciona com verificações de segurança. Por padrão, SharePoint não avisar você sobre configurações de segurança fraca, como pools de aplicativos tenham acesso à metabase do IIS ou usando a conta do farm como sua identidade de segurança. Uma solução personalizada pode executar essas verificações regularmente.
E finalmente, por que fazer os administradores de SharePoint precisará lidar com essas senhas para contas de segurança? Os invasores são talvez os únicos interessados em saber essas senhas. Os administradores geralmente não precisam usá-los.
Obviamente, o SharePoint oferece muita de opções para lidar com essas oportunidades. Você pode usar scripts, mas scripts geralmente manipular senhas em texto não criptografado. Você pode usar trabalhos de timer personalizados, que processa o serviço de Timer do SharePoint em intervalos programados, mas o serviço de timer já se encarrega de várias tarefas, incluindo as implantações de credenciais.
É difícil coordenar trabalhos de implantação de credencial com trabalhos de alteração de senha. Parece que funcionou melhor implementar um serviço de SharePoint separado que utiliza a conta do farm como sua identidade de processo para obter acesso total ao modelo de objeto administrativo do SharePoint.
Entre outras coisas, você pode interromper esse serviço a qualquer momento sem afetar outros processos, e você pode desativar este serviço se você preferir alterar senhas manualmente. A solução inclui várias ferramentas para essa finalidade, como as extensões de comando STSADM, um aplicativo do Windows e páginas de aplicativo Administração Central personalizadas, conforme exibido na Figura 4 .
A Figura 4 arquitetura da solução SPPwd
Basicamente, todos os aplicativos de SPPwd contam com o mesmo conjunto de extensões de STSADM, portanto não há apenas um caminho de código, independentemente da qual ferramenta você usar. Através de uma camada de lógica comercial comum, as extensões de comando em conjunto com os proxies de serviço executam o real processar, enquanto os aplicativos SPPwd usam objetos de stub para carregar as extensões de comando dinamicamente em tempo de execução.
Este rigidez permite que você substitua certas extensões de comando sem ter que modificar os aplicativos SPPwd. Por exemplo, se você preferir usar um gerador de senha diferentes, você pode criar uma extensão de comando, implantá-lo no cache global de assemblies e modificar a entrada de comando genpwd no arquivo de configuração stsadmcommands.passwordmanagement.xml. A solução coloca na pasta %Programas%\Common Files\Microsoft Shared\Web Server Extensions\12\Config acordo com as convenções de extensibilidade de STSADM.
O gerador de padrão cria essas senhas longas, que devem ser suficientes na maioria dos casos. a Figura 5 lista as extensões de comando SPPwd com uma breve descrição de sua finalidade. <extension>Você também pode usar o stsadm - ajuda <extensão> comando para exibir mais informações sobre parâmetros disponíveis e exemplos de linha de comando.
A Figura 5 STSADM extensões de comando para a solução SPPwd
Extensão Arquivo de código Descrição
AccessCheck SPPwdAccessCheck.cs Verifica se o usuário atual ou uma conta especificada tem acesso de leitura a informações confidenciais na metabase do IIS e o Registro local. O serviço SPPwd analisa os resultados dessas verificações bem como a configuração de conta de segurança geral e grava avisos no log de eventos do aplicativo se detectar pontos fracos na segurança.
changepwd SPPwdChangePwd.cs Altera a senha para a conta de usuário especificado no Active Directory e todos os serviços do SharePoint que usam a conta como uma identidade de segurança.
GenPwd SPPwdGenerator.cs Gera senhas aleatórias com base em um gerador de número aleatório (RNG) e hash algoritmos de criptografia que podem ser considerada razoavelmente segura.
sppwdsetup SPPwdServiceSetup.cs Instala ou desinstala o serviço do Windows no servidor SharePoint local.
enumpoolaccounts SPPwdAppPoolAccounts.cs Lista as identidades dos aplicativos da Web do SharePoint como pais de seus pools de aplicativos associado. O serviço SPPwd usa essas informações para verificar vulnerabilidades de segurança, como pools de aplicativos que compartilham a mesma identidade ou que usam a conta do farm.
enumserviceids SPPwdListServiceIds.cs Lista as identidades dos serviços disponíveis no server farm do SharePoint como pais dos seus serviços associados. O serviço SPPwd usa essas informações para recuperar o nome de logon e a senha atual de cada serviço para usar essas informações para logons de Active Directory e realizar alterações de senha.
enumproxies SPPwdServiceProxies.cs Lista os objetos SPPwdServiceProxy registrado e carregado no servidor. Essa ferramenta é útil para desenvolvedores que desejam verificar a configuração de seus proxies de serviço.
enumsppwdservers SPPwdServerList.cs Lista o nome de domínio totalmente qualificado dos servidores do SharePoint no farm local, configurados para executar o serviço SPPwd. Essas informações são úteis ao configurar contas de segurança para alterações de senha automatizada.
sppwdacctcfg SPPwdAccountSettings.cs Configura SPPwd-relacionados para a conta de segurança especificados no Active Directory. O serviço SPPwd não processa contas de segurança a menos que extensionAttribute10 da conta esteja definido como o nome de domínio totalmente qualificado do computador que esteja executando o serviço SPPwd. Além disso, o atributo de descrição da conta de segurança deve conter a expressão " esta conta só é usada no farm do SharePoint: < Nome do Farm >. "
sppwdsvccfg SPPwdConfig.cs Exibe ou altera a configuração de sistema do serviço SPPwd. As configurações incluem o intervalo de verificação de configuração, a duração máxima para contas de segurança, o nível de detalhe para eventos gravados no log de eventos do aplicativo e um parâmetro para desativar o modo de whatif explicitamente. Por padrão, o serviço de SPPwd é executado no modo de whatif para evitar alterações acidentais de senha. Em whatif modo o serviço apenas finja alterar as senhas e relata o resultado da operação, mas ele realmente não confirmar as alterações.
Pulsação SPPwdCheckHeartbeat Gerencia os trabalhos de pulsação do timer do SharePoint em um farm do SharePoint. A solução SPPwd usa esses pulsações para detectar servidores off-line e impede que alterações de senha nesse caso.

Implantação e usando a solução
As planilhas em material complementar descrevem em detalhes como implantar e usar a solução SPPwd em um ambiente de servidor único bem como em um farm de servidor. Você só precisará implantar a solução em um servidor do SharePoint usando os comandos de STSADM addsolution e deploysolution padrão.
SharePoint, em seguida, distribui a solução para todos os servidores do farm por meio de trabalhos de timer. Assim que esses trabalhos são concluídos, você pode ativar o recurso de solução para estender o site da Administração Central e instalar o serviço do Windows usando a extensão de comando sppwdsetup.
O material complementar inclui um arquivo DeployTo.bat para automatizar essas tarefas. Entre outras coisas, o arquivo em lotes demonstra como aguardar trabalhos de timer para concluir antes de prosseguir com outras etapas de implantação.
Por padrão, o serviço de SPPwd só está disponível no servidor em que você executar o arquivo de DeployTo.bat. Você pode configurar o serviço para ser executado em vários servidores do SharePoint, mas há apenas uma instância de uma conta de segurança no Active Directory, e ele impõe os seguintes requisitos de dois: apenas uma instância de serviço SPPwd pode ser autoritativo para uma conta de segurança em particular, e a conta de segurança não deve ser usada em vários farms.
Ter várias instâncias do serviço processar a mesma conta pode causar problemas de acesso simultâneo e não é necessária pois SharePoint propaga atualizações de credencial no farm local automaticamente. Compartilhar contas não são suportadas porque o serviço SPPwd não é possível atualizar informações de conta de segurança entre vários farms de segurança.
O serviço SPPwd só atualiza contas de segurança que especificam nome de domínio no atributo adminDescription totalmente qualificado do servidor de e que confirme em seu atributo de descrição que eles só estão usados no local farm do SharePoint, conforme indicado na Figura 6 . Consulte o material complementar para obter mais informações sobre a configuração de contas de segurança e o serviço de SPPwd para automatizar as alterações de senha.
A Figura 6 SPPwd implantação e configuração de conta de segurança
Contas de segurança são principais alvos de ataques, porque eles podem fornecer acesso completo a todos os conjuntos de sites e dados de site em um farm, independentemente das permissões e os controles de acesso definidos no nível do SharePoint. Uma estratégia básica para impedir esses ataques subseqüente é usar senhas de conta de alta segurança e alterá-los com freqüência.
Isso é desafiadora para realizar porque as contas de usuário de domínio não alterem suas senhas em seus próprios. Você deve executar as alterações de senha manualmente ou usar uma solução automatizada. O modo escolhido, há várias dependências que a documentação do SharePoint e o SDK do WSS não descrevem muito bem.
Você deve atualizar e implantar senhas alteradas e há questões adicionais relacionadas à conta farm. Por exemplo, quando você altera a senha da conta do farm, você alterar a chave de credencial do farm, e isso afeta a capacidade de recuperação do banco de dados de configuração de backup.
No entanto, há não alternativa para alterar a senha de conta do farm regularmente se você quiser manter a segurança do sistema em um farm do SharePoint. Verifique se que você executar um backup após alterar a senha da conta do farm.
Automatizar as alterações de senha é complicado Apesar o fato de que o modelo de objeto SharePoint inclui a lógica necessária para executar atualizações de credenciais. Pode parecer fácil rapidamente primeiro, mas até mesmo uma abordagem baseada em script pode ativá rapidamente em um grande desafio. Uma solução completa baseada no Microsoft .NET Framework e o modelo de objeto administrativo do SharePoint é uma boa opção, mas a melhor solução só pode vir diretamente de Microsoft na forma de inovações de conta de sistema adicionais.
Quase 10 anos atrás, a Microsoft modificou a conta do sistema local para acomodar as necessidades dos clientes da empresa usando o Microsoft Exchange Server. Eventualmente isso resultou na conta do serviço de rede com o Windows Server 2003. Mas a conta do serviço de rede não é adequada para farms de servidor, para que nós deve usar contas de usuário de domínio e lidar com a manutenção associada e problemas de segurança para o melhor de nossa capacidade.

pav Cherny é um especialista IT e autor especializado em tecnologias Microsoft para colaboração e a comunicação unificada. Suas publicações incluem informes oficiais, manuais de produto e livros com um foco em operações de TI e administração do sistema. Pav é presidente da Biblioso Corporation, uma empresa especializada em serviços de documentação e localização gerenciados.

Page view tracker