Sugerir tradução
 
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Fevereiro 2009 >  Manter credenciais de conta de segurança do Sha...
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 Maintaining Security Account Credentials
Pav Cherny


Frequently changing farm credentials and security account passwords are important measures for keeping a Microsoft Office SharePoint Server (MOSS) farm secure. Yet for administrators, these tasks are tedious and repetitive. The tools are difficult to use, the underlying processes are complex, good documentation is hard to find, and there is a certain risk of corrupting the server farm even when following all of the proper procedures.
Adding to the mix is problematic technical advice by Microsoft Product Support Services (PSS). On the one hand, there are useful Knowledge Base (KB) articles, such as " How to Change Service Accounts and Service Account Passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0 ." And on the other hand, there are disasters, such as " Error Message When You Try to Use the SharePoint Products and Technologies Wizard: 'Exception: System.ArgumentException: Error during Encryption or Decryption .'"
The above article states that you must create a new configuration database if the account credentials of a Web app can't be decrypted anymore. This can happen if you use a critical command switch at the wrong time or if the process of updating farm credentials completes unsuccessfully for any reason. This KB article did a fine job of instilling fear in admins that changing farm credentials can corrupt a server farm irreparably. Who can expect customers to maintain security in their SharePoint environments by frequently changing farm and security account passwords if they face that kind of risk?
Customers don't wipe out Active Directory to reset user accounts, and they should not be forced to wipe out their SharePoint configuration databases either just because a Web application password was lost. It isn't necessary to create a new configuration database. In most cases, it is sufficient to use the standard Stsadm.exe tool to overwrite corrupted credentials. And in all other cases, you can reset the passwords and retain your configuration database by using the tools included in the companion material, available in the February 2009 Code Download . Resetting passwords in Windows SharePoint Services (WSS) 3.0 and MOSS 2007 environments doesn't require access to old credential keys nor a new configuration database. But it does require better support tools from Microsoft and better documentation of the underlying processes that facilitate password changes.
This is the first column of a two-part series in which I review the standard procedures and tools for maintaining SharePoint security accounts, discuss their limitations, highlight the risks, and suggest an alternative approach to achieve better security, reduce administrative overhead, and therefore lower total cost of ownership (TCO) in SharePoint environments. This first part deals with the architectural details and the complicated process of accomplishing password changes.
It is vital to understand how SharePoint deals with security accounts and passwords whether you maintain security manually using scripts or by using a fully automated solution, such as the one I will introduce in next month's column. To keep my explanations realistic and practice oriented, I once again rely on a test environment. In this first part, a straightforward single-server installation is sufficient, as outlined in the companion worksheets. As always, my worksheets and companion tools are for test labs only and are not to be used in production environments. Use my tools at your own risk.

Password Changes in a SharePoint Environment
Changing the password of a SharePoint security account or the farm's configuration account is a remarkably complex undertaking. Among other things, you must apply changes in Active Directory and in the SharePoint server's local Security Account Manager (SAM) database, in the Service Control Manager (SCM) database, in the IIS metabase, in SQL Server, and, of course, in SharePoint content and configuration databases.
You also must replicate the changes to all other servers in the farm to apply the changes consistently. You might have to re-encrypt all the passwords of all SharePoint services and application pools for all servers in the farm if your changes affect the farm's credential key, which is the encryption key that SharePoint uses to protect the passwords of security accounts in the configuration database. When you change the farm's config account password, you implicitly change the farm's credential key. Figure 1 shows the process in a server farm with two front-end servers. Frankly, it is impressive that this process works as well as it does.
Figure 1 Changing the password of a SharePoint security account
All security account password changes begin in Active Directory, and from that moment forward, until you update the affected password in SharePoint, the farm is in an inconsistent state. The password is now outdated in IIS and elsewhere, but SharePoint is still operational.
This is good news for organizations with high-availability requirements. Password changes do not require system restarts. Windows services and IIS can continue to use the security token they obtained by logging on the affected security account with the old password when you last started the server. But don't restart IIS or the entire server during the transitional phase of password inconsistency.
IIS and other services would not be able to log on with the old password during the restart, and the affected application pool or service would not be able to come online anymore. In this situation, IIS writes a warning into the server's event log (see Figure 2). So don't wait too long with the password update in SharePoint following the password change in Active Directory.
Figure 2 IIS warns about outdated application pool credentials
In order to update the password of an application pool account, you should use SharePoint 3.0 Central Administration (_admin/FarmCredentialManagement.aspx) or the following Stsadm.exe command:
stsadm -o updateaccountpassword -userlogin <DOMAIN\USER> 
  -password <PASSWORD> -noadmin
In response, SharePoint encrypts the new password by using the farm's credential key and overwrites the old encrypted password in the configuration database. Next, SharePoint updates the account information in the IIS metabase and in all other necessary places. Once this is accomplished, SharePoint generates a timer job of type SPContentAppPoolCredentialDeploymentJobDefinition to deploy the new credentials on the remaining servers in the farm, which it places into the configuration database.
As seen in Figure 1, SharePoint relies on timer jobs to apply administrative settings globally on all servers in the farm. The SharePoint Timer services on the remaining servers in the farm pick up the job and accordingly update the local security settings on their servers with the help of the WSS Administration (SPAdmin) service to bring the farm back into a consistent state.
This is the process for application pool accounts, but there are many other types of SharePoint services that use security accounts, such as the SharePoint Timer service itself, the WSS Help Search service, and possibly Shared Services Providers (SSPs), Office SharePoint Server Search service, and single sign-on (SSO) service. There may be even more services, depending upon the solutions installed in your farm, and each service type has different password update requirements. The article at support.microsoft.com/kb/934838 contains a list of commands that you must use for the service accounts in WSS 3.0 and MOSS 2007. Check the product documentation of any additional solutions that you use for further tools, commands, and update procedures.
This highly diversified and uncoordinated landscape of tools and commands is one of the downsides of the current SharePoint security architecture. It doesn't scale well and can drive up TCO depending upon the number of custom solutions in your server farm that use security credentials. In the second part of this series, I will show you how to bring this under control so you can use a single solution to accomplish all the necessary updates regardless of the underlying service types.
The most important update scenario concerns the farm credentials. The password of the farm account is special because it affects the farm's credential key, which is used to encrypt all passwords in the farm, as mentioned earlier. So, following a change of the farm account's password in Active Directory, you must update SharePoint using the command:
stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER>
  -password <PASSWORD>
SharePoint then must re-encrypt all existing (encrypted) passwords in the configuration database, it must update the SharePoint Timer service account (which uses the farm account as its identity), and it must propagate these changes again to all servers in the farm by means of a timer job of type SPAdminAppPoolCredentialDeploymentJobDefinition.
Many things can go wrong during this phase. The timer job might get stuck in the queue, as illustrated in Figure 3, or the update process might fail unexpectedly, due perhaps to a sudden power outage, leaving behind old encrypted passwords that SharePoint now cannot decrypt anymore because the credential key has changed.
Figure 3 A credential deployment job stuck in the queue because the SharePoint Timer service is not running on all servers in the farm
In another scenario, you might update the passwords of application pool accounts before the new farm credentials have reached all servers in the farm, causing servers with the outdated credential key to fail because they cannot decrypt the updated password in the configuration database yet, as illustrated in Figure 4. This is an interesting scenario and the reason for the -noadmin switch in the updateaccountpassword command. If the farm account is also used as an application pool account (not recommended), then you should update the farm credentials first, wait until all servers in the farm have processed the timer job, and then update the application pools.
Figure 4 Hold application pool updates until the Administration Application Pool Credential Deployment job has been processed
Correspondingly, the updateaccountpassword command checks whether the specified security account is the farm account and informs you about the dependencies if this is the case without performing the update. By using the -noadmin switch, you disable this check and apply the changed password to the account in the application pool configuration, but it is difficult to automate these procedures in a script with appropriate lag time.

Troubleshooting Farm Credential Issues
Now let's take a closer look at the updatefarmcredentials command. It comes with a dangerous switch that can cause great pain, especially if it's used as described in the article " Error Message When You Try to Use the SharePoint Products and Technologies Wizard: 'Exception: System.ArgumentException: Error during Encryption or Decryption ”. I'm referring to the switch called -local. The SharePoint developers introduced this switch for performing local farm credential updates manually. The idea is that you can delete a timer job from the queue in Central Administration (_admin/ServiceJobDefinitions.aspx) if the job is corrupted or not processed for any other reason and then perform the necessary update step directly by using the command:
stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER> 
  -password <PASSWORD> -local
The -local switch instructs the updatefarmcredentials command to apply the password change only on the local computer. It is important to recognize, however, that this update affects the credential key and the SharePoint Timer service, but not the application pools, Search service, SSPs, and so forth. It is assumed that you already ran the updatefarmcredentials command without the -local switch on another server in the farm and thus re-encrypted all the passwords in the configuration database. It isn't necessary to perform this re-encryption step again. But what if you used the -local switch without taking this step?
Using the -local switch without first running the updatefarmcredentials command without this switch causes trouble because the -local switch changes the credential key. The application pool passwords are encrypted with the old key in the config database, but this key is now overwritten.
Take a look at Figure 5. You cannot run the updatefarmcredentials command without the -local switch anymore because this requires re-encryption of passwords that can no longer be decrypted. When the command fails, you can find entries in the Application event log stating: "Error re-encrypting credential Id 022e607e-b49e-40e4-bd3f-f56a3c69f94d with owner Id 431b6897-16eb-4b9a-be65-60f1f603008d during deploying of administration application pool credentials, please recreate credential manually. Operation is not valid due to the current state of the object."
Figure 5 Unable to re-encrypt application pool passwords because the passwords can no longer be decrypted
If you just changed the farm account in a single-server deployment from the Network Service account to a domain account, you are in real trouble because you can't change back to the old credential key in this case. The Network Service doesn't use a password, and the credential key is therefore random.
In a search for help, you might encounter that " Error Message When You Try to Use the SharePoint Products and Technologies Wizard: 'Exception: System.ArgumentException: Error during Encryption or Decryption ” article I mentioned earlier, and without further knowledge, your trouble worsens because you now learn that you must create a new configuration database to get rid of these passwords that can no longer be decrypted. It is an unbelievable constellation of unfortunate circumstances. You shouldn't be able to run the updatefarmcredentials command with the -local switch in the first place, or the command should create a backup copy of the old credential key so you can re-encrypt the passwords later on. Or it should simply detect that the passwords are not yet re-encrypted and re-encrypt them at this point.
Instead, the -local switch goes ahead and happily corrupts your SharePoint configuration database without any warnings, as shown in Figure 5. A support tool from Microsoft to reset those passwords that can no longer be decrypted would come in handy. And, of course, proper product documentation that warns you about the critical nature of certain command-line operations and that guides you out of this trouble would also be appreciated.
The good news is that the updateaccountpassword command can encrypt new passwords of application pool accounts without having to decrypt the old passwords. So, use this command to update all application pools that use domain accounts. This should take care of most, if not all, corrupted passwords. Unfortunately, you can't use this command to update application pools that use the Network Service account. This account doesn't require a password, so the updateaccountpassword command doesn't apply.
Interestingly, the Network Service account might be associated with password data in the configuration database. New application pools that use the Network Service have no passwords, yet if you ever change the application pool to use a domain account and then revert back, the Network Service inherits the domain account's password reference. SharePoint doesn't set the password to null (bad coding practice) and this rubbish data now causes the trouble.
It's an ironic twist that customers are supposed to throw away their configuration databases because rubbish and completely useless data can no longer be decrypted! If you are lucky, you can change the application pool configuration in Central Administration (_admin/FarmCredentialManage­ment.aspx) and specify a domain account. If you are unlucky, you encounter the encryption/decryption error displayed in Figure 6. You can't change the account in Central Administration, you can't use the updateaccountpassword command, you can't run the SharePoint Products and Technologies Configuration Wizard, and you can't update the farm credentials by using the updatefarmcredentials command. Now what do you do?
Figure 6 Trouble caused by Network Service password junk left behind in the configuration database
To solve this problem, you need a tool that goes straight into the configuration database and removes the junk, such as the Reset AppPool Password tool, illustrated in Figure 7 and included with source code in the companion material. This tool is very straightforward. It pulls the data of application pools that use accounts with associated encrypted passwords directly out of the configuration database and then uses the SharePoint object model to determine if the application pool password can be decrypted.
Figure 7 Resetting corrupted passwords to null
If accessing the password through the object model fails with an argument exception, the password is corrupted. Here, the tool gives you an opportunity to replace the password's array of encrypted byte values with a null reference and saves the changes back into the configuration database. Empty strings don't need to be decrypted and therefore don't cause an argument exception. Problem solved.
In order to complete the repair process, I recommend that you update the farm credentials and subsequently all application pool accounts by using Stsadm.exe and Central Administration. Your farm is back in a consistent state, and you didn't have to throw away your configuration database.

Conclusion
Despite the fact that changing farm credentials and security account passwords is a tedious and error-prone process, you need not fear that changing farm credentials will corrupt your server farm irreparably. The configuration database can be repaired even if you happen to lose your current credential key. You simply need to reset the affected passwords, and this is possible through the standard Stsadm.exe tool or a low-level database tool, such as Reset AppPool Password. So keep changing farm credentials and security accounts frequently, use strong passwords, and don't use the Network Service as a security account because it complicates the farm configuration and troubleshooting. Use dedicated domain accounts.
Now that you've addressed the risks of database corruption through password changes, you can focus your attention on the real issue in the SharePoint security architecture: the current architecture does not accommodate password changes very well. You need to apply too many commands in a more or less specific order depending on the service types you must update in your farm. Some commands have dangerous switches; some don't. Some commands can corrupt your configuration database; others are harmless. Some services need to be updated globally across the entire farm and others are local to a specific server.
In any case, administrative overhead is high due to the complexities involved, and security is generally low due to infrequent change schedules, weak passwords, and scripts that deal with passwords in clear text. In my next column, I'll show you how to tackle these issues and eliminate them—and for all service types, including those not yet developed, whatever their password update requirements. No more (manual) password changes!

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 Manter credenciais de conta de segurança
Pav Cherny


Com freqüência alterar credenciais do farm e conta de segurança as senhas são medidas importantes para manter um farm do Microsoft Office SharePoint Server (MOSS) segura. Ainda para administradores, essas tarefas são entediante e repetitivas. As ferramentas são difíceis de usar, os processos subjacentes são complexos, documentação de BOM é difícil localizar e há um determinado risco de corromper o server farm, mesmo quando seguir todas os procedimentos adequados.
Adicionar a combinação é problemática técnico pelo Microsoft Atendimento (PSS). A um lado, há útil artigos da Base de Dados de Conhecimento (KB), como" Como alterar contas de serviço e senhas de conta de serviço no SharePoint Server 2007 e no Windows SharePoint Services 3.0 ." E por outro lado, há desastres, como" Mensagem de erro quando você tenta usar o Assistente de tecnologias e produtos: ' exceções: System.ArgumentException: Erro durante criptografia ou descriptografia .'"
O artigo acima informa que você deve criar um novo banco de dados de configuração se as credenciais da conta de um aplicativo da Web não podem ser descriptografadas mais. Isso pode acontecer se você usar uma opção de comando crítica na hora errada ou se o processo de atualização farm credenciais conclui sem êxito por alguma razão. Este artigo da base de dados de CONHECIMENTO fez um trabalho bem de instilling medo em administradores que alterar credenciais do farm pode corromper um server farm irreparably. Quem pode esperar clientes para manter a segurança em seus ambientes de SharePoint, com freqüência alterando senhas de conta do farm e segurança se eles enfrentam esse tipo de risco?
Os clientes não apagar do Active Directory para redefinir contas de usuário, e eles não devem ser forçados a apagar seus bancos de dados de configuração do SharePoint ou só porque uma senha de aplicativo da Web foi perdida. Não é necessário criar um novo banco de dados de configuração. Na maioria dos casos, é suficiente usar a ferramenta de STSADM.exe padrão para substituir credenciais corrompidas. E em todos os outros casos, você pode redefinir as senhas e manter o banco de dados de configuração usando as ferramentas incluídas no material complementar, disponível no Download de código de fevereiro de 2009 . Redefinição de senhas no Windows SharePoint Services (WSS) 3.0 e ambientes do MOSS 2007 não exigir acesso aos antigos chaves de credenciais nem um novo banco de dados de configuração. Mas ele exige melhores ferramentas de suporte da Microsoft e uma melhor documentação dos processos subjacentes que facilitam a alterações de senha.
Isso é a primeira coluna de uma série duas partes em que eu examine os procedimentos padrão e as ferramentas de manutenção de contas de segurança do SharePoint, aborde suas limitações, realçar os riscos e sugere uma abordagem alternativa para obter melhor segurança, reduzir a sobrecarga administrativa e, portanto, diminuir, custo total de propriedade (TCO) em ambientes do SharePoint. Esta primeira parte lida com os detalhes de arquiteturais e o processo complicado de realização de alterações de senha.
É fundamental para entender como o SharePoint lida com contas de segurança e senhas Se você manter a segurança manualmente usando scripts ou usando uma solução totalmente automatizada, como aquela apresentará na coluna do próximo mês. Para manter meu explicações realistas e prática orientado a, eu novamente dependem um ambiente de teste. Na primeira parte, uma simples instalação de único servidor é suficiente, conforme descrito em planilhas complementar. Como sempre, meu planilhas e ferramentas complementares para laboratórios de teste somente e não devem ser usados em ambientes de produção. Uso minhas ferramentas de seu próprio.

Alterações de senha em um ambiente do SharePoint
Alterar a senha de uma conta de segurança do SharePoint ou conta de configuração do farm é uma tarefa bastante complexa. Entre outras coisas, você deve aplicar as alterações no Active Directory e no servidor do SharePoint banco de local Gerenciador de contas de segurança (SAM) dados, no banco de dados do Gerenciador de controle de serviço (SCM), na metabase do IIS, no SQL Server e, obviamente, no conteúdo do SharePoint e bancos de dados de configuração.
Você também deve replicar as alterações para todos os outros servidores no farm para aplicar as alterações consistente. Talvez seja necessário criptografar novamente todas as senhas de todos os serviços do SharePoint e pools de aplicativos para todos os servidores no farm se suas alterações afetarem a chave de credencial do farm, que é a chave de criptografia que SharePoint usa para proteger as senhas das contas de segurança no banco de dados de configuração. Quando você alterar senha de conta de configuração do farm, implicitamente altere chave de credencial do farm. a Figura 1 mostra o processo em um server farm com dois servidores front-end. Francamente, é impressionante que esse processo funciona bem como ele faz.
Figura 1 alterando a senha de uma conta de segurança do SharePoint
Todas as alterações de senha de conta de segurança começam no Active Directory e a partir do que momento frente, até você atualizar a senha afetada no SharePoint, o farm está em um estado inconsistente. A senha agora está desatualizada no IIS e em outro local, mas o SharePoint é ainda operacional.
Isso é boa notícia para organizações com requisitos de alta disponibilidade. Alterações de senha não exigem reinicializações de sistema. Os serviços do Windows e o IIS pode continuar a usar o token de segurança que ele obtido fazendo logon na conta de segurança afetado com a senha antiga ao iniciar o servidor pela última vez. Mas não reinicie o IIS ou todo o servidor durante a fase transição de inconsistência de senha.
IIS e outros serviços não poderá fazer logon com a senha antiga durante a reinicialização, e o pool de aplicativos afetados ou o serviço pode não poderá entrar online mais. Nessa situação, o IIS gravará um aviso no log de eventos do servidor (consulte a Figura 2 ). Portanto, não espere muito tempo com a atualização de senha no SharePoint após a alteração da senha no Active Directory.
A Figura 2 IIS avisa sobre credenciais de pool de aplicativos desatualizados
Para atualizar a senha de uma conta de pool de aplicativo, você deve usar Administração Central do SharePoint 3.0 (_admin/FarmCredentialManagement.aspx) ou o seguinte comando Stsadm.exe:
stsadm -o updateaccountpassword -userlogin <DOMAIN\USER> 
  -password <PASSWORD> -noadmin
Em resposta, o SharePoint criptografa a nova senha usando a chave de credencial do farm e sobrescreve a antiga senha criptografada no banco de dados de configuração. Em seguida, o SharePoint atualiza as informações de conta na metabase do IIS e em todos os outros lugares necessários. Depois que isso é feito, o SharePoint gera um trabalho de timer do tipo SPContentAppPoolCredentialDeploymentJobDefinition para implantar as novas credenciais nos servidores restantes do farm, o que ele coloca no banco de dados de configuração.
Como visto na Figura 1 , o SharePoint depende trabalhos de timer para aplicar configurações administrativas globalmente em todos os servidores do farm. Os serviços de Timer do SharePoint nos servidores restantes do farm pegar o trabalho e atualizar adequadamente as configurações de segurança local em seus servidores com a ajuda do serviço de administração do WSS (SPAdmin) para trazer o farm de volta para um estado consistente.
Isso é o processo para contas de pool de aplicativos, mas há muitos outros tipos de serviços de SharePoint que usam contas de segurança, como o próprio serviço de Timer do SharePoint, o serviço de procura de ajuda do WSS e, possivelmente, provedores de serviços compartilhados SSPs (serviço Office SharePoint Server Search e serviço do single sign-on (SSO). Não existe, pode ser ainda mais serviços, dependendo das soluções instaladas no seu farm, e cada tipo de serviço tem requisitos de atualização de senha diferentes. O artigo em support.microsoft.com/kb/934838 contém uma lista de comandos que você deve usar para as contas de serviço no WSS 3.0 e no MOSS 2007. Consulte a documentação do produto de quaisquer soluções adicionais que você usa para outras ferramentas, comandos e procedimentos de atualização.
Isso altamente diversified e paisagem isolada de ferramentas e comandos é uma das desvantagens da arquitetura de segurança do SharePoint atual. Ele não dimensionar bem e pode orientar up TCO dependendo do número de soluções personalizadas no seu farm que usam credenciais de segurança. A segunda parte desta série, VOU mostrar como colocar isso no controle para poder usar uma única solução para realizar todas as atualizações necessárias, independentemente dos tipos de serviço subjacente.
O cenário de atualização mais importante diz respeito as credenciais de farm. A senha da conta do farm é especial porque ele afeta a chave de credencial do farm, que é usada para criptografar todas as senhas no farm, como mencionado anteriormente. Portanto, após uma alteração de senha da conta do farm no Active Directory, você deve atualizar SharePoint usando o comando:
stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER>
  -password <PASSWORD>
Criptografar SharePoint, em seguida, deve novamente todas as senhas (criptografadas) existentes no banco de dados de configuração, ele deve atualizar a conta de serviço de Timer do SharePoint (que usa a conta do farm como sua identidade) e ele deve propagar essas alterações novamente em todos os servidores no farm por meio de um trabalho de timer do tipo SPAdminAppPoolCredentialDeploymentJobDefinition.
Muitas coisas podem dar erradas durante essa fase. O trabalho de timer pode obter presas na fila, conforme ilustrado na Figura 3 , ou o processo de atualização pode falhar inesperadamente, porque talvez uma queda de energia repentino, deixando para trás antigas senhas criptografadas que SharePoint agora não é possível descriptografar mais porque a chave de credencial foi alterada.
A Figura 3 um trabalho de implantação de credencial presas na fila porque o serviço de Timer do SharePoint não está sendo executado em todos os servidores do farm.
Em outro cenário, você pode atualizar as senhas das contas de pool de aplicativos antes que as novas credenciais farm atingiu todos os servidores do farm, causando servidores com a chave de credencial desatualizados falhe, pois eles não podem descriptografar a senha atualizada no banco de dados de configuração ainda, conforme ilustrado na Figura 4 . Esta é uma situação interessante e o motivo para a opção-opção noadmin no comando updateaccountpassword. Se a conta do farm também é usada como uma conta de pool de aplicativo (não recomendada), em seguida, atualize o farm credenciais em primeiro lugar, aguarde até que todos os servidores do farm terem processado o trabalho de timer e atualize os pools de aplicativos.
A Figura 4 manter atualizações de pool de aplicativos até que o trabalho de implantação de credenciais de pool de aplicativos de administração foi processado
Correspondentemente, o comando de updateaccountpassword verifica se a conta de segurança especificada é a conta do farm e informa sobre as dependências se esse for o caso sem executar a atualização. Usando a opção-opção noadmin, você desativar essa verificação e se aplicam a senha alterada à conta de na configuração do pool de aplicativo, mas é difícil automatizar esses procedimentos em um script com tempo de retardo apropriado.

Solucionando problemas de credenciais de farm
Agora vamos dar uma olhada mais perto no comando updatefarmcredentials. Ele vem com uma opção perigosa que pode causar grande dificuldade, especialmente se ele é usado conforme descrito no artigo" Mensagem de erro quando você tenta usar o Assistente de tecnologias e produtos: ' exceções: System.ArgumentException: Erro durante criptografia ou descriptografia ”. Estou referência à opção chamada - local. Os desenvolvedores do SharePoint introduziu essa opção para executar atualizações de credencial do farm local manualmente. A idéia é que você pode excluir um trabalho de timer da fila na Administração Central (_admin/ServiceJobDefinitions.aspx) se o trabalho estiver corrompido ou não processado por qualquer motivo e realizar, em seguida, a etapa de atualização necessário diretamente usando o comando:
stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER> 
  -password <PASSWORD> -local
Local-opção instrui o comando updatefarmcredentials para aplicar a alteração de senha apenas no computador local. É importante reconhecer, no entanto, que essa atualização afeta a chave de credencial e o serviço de Timer do SharePoint, mas não os pools de aplicativos, pesquisar o serviço, SSPs e assim por diante. Presume-se que você já executou o updatefarmcredentials comando sem-opção local em outro servidor do farm e, portanto, recriptografado todas as senhas no banco de dados de configuração. Não é necessário realizar esta etapa de nova criptografia novamente. Mas e se é usada a local opção - sem realizar esta etapa?
Usando a local opção - sem executar primeiro os updatefarmcredentials comando sem essa opção causa problemas porque o local opção altera a chave de credencial. As senhas de pool de aplicativo são criptografadas com a antiga chave no banco de dados de configuração, mas essa chave agora é substituída.
Dê uma olhada na Figura 5 . Não é possível executar o updatefarmcredentials comando sem-opção local mais porque isso requer a nova criptografia de senhas que não podem ser descriptografadas. Quando o comando falhar, você pode localizar entradas in the Application log de eventos informando: "Erro re-encrypting credencial ID 022e607e-b49e-40e4-bd3f-f56a3c69f94d com proprietário ID 431b6897-16eb-4b9a-be65-60f1f603008d durante a implantação de credenciais de pool de aplicativos de administração, recrie credencial manualmente. Operação não é válida devido ao estado atual do objeto."
A Figura 5 não é possível criptografar novamente as senhas de pool do aplicativo porque as senhas não podem ser descriptografadas
Se você acabou de alterar a conta do farm em uma implantação de único servidor da conta do serviço de rede para uma conta de domínio, você está em problemas reais pois você não poderá alterar novamente para a chave de credencial antiga nesse caso. O serviço de rede não usar uma senha, e a chave de credencial, portanto, aleatória.
Em uma pesquisa para obter ajuda, você pode encontrar que" Mensagem de erro quando você tenta usar o Assistente de tecnologias e produtos: ' exceções: System.ArgumentException: Erro durante criptografia ou descriptografia ” artigo mencionei anteriormente e sem conhecimento adicional, seu problema worsens porque você aprender agora que você deve criar um novo banco de dados de configuração para eliminar essas senhas que não podem ser descriptografadas. É um constellation unbelievable das circunstâncias infeliz. Você não deve ser capaz de executar os updatefarmcredentials comando com a opção-opção local em primeiro lugar, ou o comando deve criar uma cópia backup da chave de credencial do antigo para que você criptografar pode novamente as senhas mais tarde. Ou simplesmente deve detectar que as senhas não recriptografadas ainda e recriptografá-las neste momento.
Em vez disso, o local opção vai em frente e Felizmente corromper o banco de dados configuração do SharePoint sem avisos, como mostrado na Figura 5 . Uma ferramenta de suporte da Microsoft para redefinir as senhas que não podem ser descriptografadas seria útil. E, claro, documentação do produto adequado que avisa sobre a natureza crítica de determinadas operações de linha de comando e que orienta você fora desse problema também pode ser apreciar.
A boa notícia é que o comando updateaccountpassword pode criptografar novas senhas de contas de pool de aplicativos sem precisar descriptografar as senhas antigas. Por isso, use esse comando para atualizar todos os pools de aplicativos que usam contas de domínio. Isso deve ter cuidado da maioria, se não todos, senhas corrompida. Infelizmente, você não pode usar esse comando para atualizar os pools de aplicativos que usam a conta Serviço de rede. Essa conta não requer uma senha, portanto, o comando updateaccountpassword não aplicável.
Curiosamente, a conta do serviço de rede pode ser associada com dados de senha no banco de dados de configuração. Novos pools de aplicativos que usam o serviço de rede não têm senha, mas se você nunca alterar o pool de aplicativos para usar uma conta de domínio e, em seguida, reverter novamente, o serviço de rede herda referência de senha da conta de domínio. SharePoint não definir a senha como nulo (prática de codificação inválido) e esses dados rubbish agora faz com que o problema.
É um componente ironic que os clientes deveriam para jogar fora seus bancos de dados de configuração porque rubbish e dados totalmente inúteis não podem ser descriptografados! Se tiver sorte, você pode alterar a configuração de pool de aplicativo na Administração Central (_admin/FarmCredentialManage­ment.aspx) e especificar uma conta de domínio. Se você estiver unlucky, você encontrar o erro de criptografia/descriptografia exibido na Figura 6 . Você não pode alterar a conta na Administração Central, você não pode usar o comando updateaccountpassword, você não pode executar o SharePoint Products e o Assistente de configuração de tecnologias e você não pode atualizar as credenciais do farm usando o comando updatefarmcredentials. Agora o que fazer?
A Figura 6 problemas causados por senha do serviço de rede lixo deixadas para trás no banco de dados de configuração
Para resolver esse problema, você precisa de uma ferramenta que vai diretamente para o banco de dados de configuração e remove o lixo eletrônico, como a ferramenta Redefinir senha AppPool, ilustrado na Figura 7 e incluídos com código-fonte no material complementar. Essa ferramenta é muito simples. Ele recebe os dados de pools de aplicativos que usam contas com senhas criptografadas associadas diretamente fora do banco de dados configuração e usa o modelo de objeto SharePoint para determinar se a senha do pool de aplicativo pode ser descriptografada.
A Figura 7 Resetting corrompido senhas para nulo
Se acessando a senha através do modelo de objeto falhar com uma exceção de argumento, a senha está corrompida. Aqui, a ferramenta lhe a oportunidade de substituir da matriz a senha de valores de bytes criptografados com uma referência nula e salva que as alterações de volta para o banco de dados de configuração. Seqüências vazias não precisa ser descriptografada e, portanto, não causar uma exceção de argumento. Problema resolvido.
Para concluir o processo de reparo, recomendo que você atualizar as credenciais do farm e, subseqüentemente, todas as contas de pool aplicativo usando o Stsadm.exe e administração central. O farm é novamente em um estado consistente e você não precisa jogar fora seu banco de dados de configuração.

Conclusão
Apesar do fato de alteração de farm credenciais e senhas de contas de segurança é um processo tedioso e propenso a erros, você precisa não medo que alterar credenciais do farm corromperá o farm irreparably. O banco de dados de configuração pode ser reparado, mesmo se você perder sua chave de credencial atual. Você simplesmente precisa redefinir as senhas afetadas, e isso é possível por meio da ferramenta Stsadm.exe padrão ou uma ferramenta de banco de dados de nível inferior, como o Redefinir senha AppPool. Para manter alterar credenciais do farm e contas de segurança com freqüência, use senhas de alta segurança e não usar o serviço de rede como uma conta de segurança porque ela complica a configuração de farm e solução de problemas. Use contas de domínio dedicado.
Agora que você tenha solucionado os riscos de corrupção de banco de dados por meio de alterações de senha, você poderá se concentrar sua atenção no problema real na arquitetura de segurança do SharePoint: a arquitetura atual não acomoda alterações de senha bem. Você precisará aplicar muitos comandos em uma ordem específica mais ou menos dependendo dos tipos serviço que você deve atualizar no farm.. Alguns comandos possuem opções perigosas; alguns não. Alguns comandos podem corromper o banco de dados de configuração; outros são inofensivos. Alguns serviços precisam ser atualizados globalmente em toda a farm. e outros locais para um servidor específico.
Em qualquer caso, sobrecarga administrativa é alta devido às complexidades envolvidas, e a segurança é geralmente baixa devido a alteração e agendas, as senhas de baixa segurança e scripts que lidam com senhas em texto não criptografado. Em minha próxima coluna, mostrarei como lidar com esses problemas e elimine-as, e para todos os serviço tipos, incluindo os não ainda desenvolvido, que seus requisitos de atualização de senha. Não há mais alterações de senha (manuais)!

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