Suggérer une traduction
 
Suggestions d'autres utilisateurs :

progress indicator
Aucune autre suggestion.
TechNet Magazine > Accueil > Tous les numéros > 2009 > TechNet Magazine Février 2009 >  Gestion des informations d'identification compt...
Affichage du contenu :  côte à côteAffichage du contenu : côte à côte
Ce contenu traduit automatiquement peut être modifié par les membres de la communauté. Nous vous invitons à améliorer la traduction en cliquant sur le lien « Modifier » associé aux phrases ci-dessous.
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.

SharePoint à l'intérieur Gestion des informations d'identification du compte sécurité
Pav Cherny


Modifier fréquemment informations d'identification de batterie de serveurs et compte de sécurité mots de passe sont des mesures importantes pour préserver une batterie de serveurs Office SharePoint Server (MOSS) sécurisé. Pour les administrateurs, ces tâches sont encore répétitives et fastidieuses. Les outils sont difficiles à utiliser, les processus sous-jacents sont complexes, bonne documentation est difficile à trouver et il y a un certain risque de corruption de la batterie de serveurs même lorsque suivant toutes les procédures appropriés.
L'ajout à la gamme est problématique conseils techniques par Microsoft Product Support technique (PSS). En une part, utiles Base de connaissances (KB) articles sont, comme « disponibles Comment modifier comptes de service et les mots de service passe de comptes dans SharePoint Server 2007 et dans Windows SharePoint Services 3.0 ." Et d'autre part, il existe incident, telles que » Message d'erreur lorsque vous essayez d'utiliser l'Assistant de technologies et produits SharePoint: « exception : System.ArgumentException : erreur au cours de chiffrement ou le déchiffrement .'"
L'article ci-dessus indique que vous devez créer une nouvelle base de données de configuration si les informations d'identification de compte d'une application Web ne peut pas être déchiffrées plus. Cela peut se produire si vous utiliser un commutateur de commande critique au moment incorrecte ou si le processus de mise à jour de batterie de serveurs informations d'identification complète sans succès pour une raison quelconque. Cet article de la base de CONNAISSANCES fait un travail bien d'instilling peur d'administrateurs que la modification des informations d'identification de batterie de serveurs peut endommager une batterie de serveurs irreparably. Qui peuvent attendre les clients à maintenir la sécurité dans leurs environnements SharePoint en modifiant fréquemment passe de compte de batterie de serveurs et de sécurité si elles face à ce type de risque ?
Clients n'est pas effacer les Active Directory pour réinitialiser des comptes d'utilisateur et qu'ils ne doivent pas être forcés à effacer les leurs bases de données de configuration SharePoint soit simplement car un mot de passe d'application Web a été perdue. Il n'est pas nécessaire créer une nouvelle base de données de configuration. Dans la plupart des cas, il est suffisante pour utiliser l'outil Stsadm.exe standard pour remplacer les informations d'identification endommagées. Dans tous les autres cas, vous pouvez réinitialiser les mots de passe et conserver votre base de données de configuration à l'aide des outils du support associés, disponibles dans le Téléchargement de code 2009 février . Réinitialisation des mots de passe dans Windows SharePoint Services (WSS) 3.0 et MOSS 2007 environnements ne nécessite pas accès aux anciennes informations d'identification clés ni une nouvelle base de données de configuration. Mais il nécessite une meilleure outils de support de Microsoft et une meilleure documentation des processus sous-jacent qui facilitent les modifications de mot de passe.
Ceci est la première colonne d'une série en deux parties dans lequel j'examinez les procédures standard et les outils de gestion des comptes de sécurité de SharePoint, discuter leurs limitations, mettez en surbrillance les risques et proposer une autre approche pour obtenir une meilleure sécurité, réduire les tâches administratives et réduire par conséquent coût total de possession (TCO, Total Cost of OWNERSHIP) dans les environnements de SharePoint. Cette première partie traite les détails d'architecturales et le processus complexe d'effectuer des modifications de mot de passe.
Il est essentiel de comprendre comment SharePoint traite des comptes de sécurité et des mots de passe que vous maintenir la sécurité manuellement à l'aide de scripts ou en utilisant une solution entièrement automatisée, telle que celle que je présente dans la chronique du mois prochain. Pour conserver mon explications réalistes et les exercices pratiques orientées, J'AI une fois encore reposent sur un environnement de test. Dans cette première partie, une installation serveur unique simple est suffisante, comme indiqué dans les feuilles de calcul associé. Comme toujours, mes feuilles de calcul et les outils associés sont des laboratoires de test uniquement et sont ne pas à utiliser dans les environnements de production. Utilisez mes outils à vos propres risques périls.

Modifications de mot de passe dans un environnement de SharePoint
La modification du mot de passe d'un compte de sécurité de SharePoint ou compte de configuration de la batterie est une opération très complexe. Entre autres choses, vous devez appliquer modifications dans Active Directory et du serveur SharePoint base de local Gestionnaire de comptes de sécurité (SAM) données, dans la base de données Gestionnaire de contrôle des services (SCM), dans la métabase IIS dans SQL Server et, bien sûr, dans le contenu SharePoint et bases de données de configuration.
Vous devez répliquer les modifications à tous les autres serveurs de la batterie pour appliquer les modifications cohérente. Vous devrez peut-être Rechiffrer toutes les mots de passe tous les services SharePoint et les pools d'applications pour tous les serveurs de la batterie des si vos modifications affectent la clé Informations d'identification de la batterie, qui est la clé de chiffrement que SharePoint utilise pour protéger les mots de passe de comptes de sécurité dans la base de données de configuration. Lorsque vous modifiez passe configuration de la batterie, vous modifiez implicitement clé d'identification de la batterie. la figure 1 illustre le processus dans une batterie de serveurs avec deux serveurs frontaux. Franchement, il est impressionnant que ce processus fonctionne, ainsi qu'il ne.
Figure 1 modification le mot de passe d'un compte de sécurité SharePoint
Toutes les modifications de mot de passe de compte sécurité commencent dans Active Directory et à partir de cet instant avant, jusqu'à ce que vous mettre à jour le mot de passe affecté dans SharePoint, la batterie de serveurs est dans un état incohérent. Le mot de passe est maintenant obsolète dans IIS et ailleurs, mais SharePoint est encore opérationnel.
Voici la bonne nouvelle pour les organisations avec les exigences de haute disponibilité. Les modifications de mot de passe ne nécessitent pas de redémarrage système. Les services Windows et les services Internet (IIS) peut continuer à utiliser le jeton de sécurité qu'ils obtenus à la journalisation sur le compte de sécurité affecté avec l'ancien mot de passe lorsque vous dernier démarrage du serveur. Mais ne pas redémarrer IIS ou l'ensemble du serveur lors de la phase transitoires d'incohérence de mot de passe.
Services Internet (IIS) et d'autres services est peut-être pas se connecter avec l'ancien mot de passe lors du redémarrage, et le pool d'applications affectées ou le service ne peut pas à venir en ligne plus. Dans ce cas, IIS écrit un message d'avertissement dans journal des événements du serveur (voir figure 2 ). Donc ne pas attendre trop long avec la mise à jour mot de passe dans SharePoint après la modification de mot de passe de Active Directory.
La figure 2 avertit de services Internet (IIS) sur les informations d'identification du pool d'applications obsolètes
Afin de mettre à jour le mot de passe d'un compte de pool d'application, vous devez utiliser Administration centrale SharePoint 3.0 (_admin/FarmCredentialManagement.aspx) ou de la commande Stsadm.exe suivante :
stsadm -o updateaccountpassword -userlogin <DOMAIN\USER> 
  -password <PASSWORD> -noadmin
En réponse, SharePoint chiffre le nouveau mot de passe à l'aide d'informations d'identification clé de la batterie et remplace le ancien mot de passe chiffré dans la base de données de configuration. Ensuite, SharePoint met à jour les informations de compte dans la métabase IIS et tous les autres endroits nécessaires. Une fois que cela est effectué, SharePoint génère un travail du minuteur de type SPContentAppPoolCredentialDeploymentJobDefinition pour déployer des nouvelles informations d'identification sur les serveurs restants de la batterie, elle place dans la base de données de configuration.
Comme le montre la figure 1 , SharePoint repose sur les travaux de minuteur à appliquer globalement des paramètres d'administration sur tous les serveurs de la batterie de serveurs. Les services du minuteur SharePoint sur les autres serveurs de la batterie de serveurs prélever le travail et mettre à jour en conséquence les paramètres de sécurité locale sur leurs serveurs à l'aide du service d'administration WSS (SPAdmin) pour permettre la batterie de serveurs dans un état cohérent.
Ceci est le processus de comptes de pool d'applications, mais il existe plusieurs autres types de services SharePoint qui utilisent des comptes de sécurité, tels que le service de minuterie SharePoint lui-même, le service de recherche de l'aide de WSS et éventuellement fournisseurs de services partagés (SSP), service Office SharePoint Server Search et simple sign-on (SSO) service. Il risque d'être d'autres services, selon les solutions installées dans votre batterie de serveurs, ou de chaque type de service a des exigences de mise à jour de mot de passe différent. L'article à support.microsoft.com/kb/934838 contient une liste de commandes que vous devez utiliser pour les comptes de service de WSS 3.0 et MOSS 2007. Consultez la documentation produit des solutions plues utilisé pour les autres outils, commandes et les procédures de mise à jour.
Ce très diversified et uncoordinated Paysage d'outils et commandes est une des inconvénients de l'architecture de sécurité SharePoint en cours. Il n'est pas redimensionner et et entraînent des CTP selon le nombre de solutions personnalisées de votre batterie qui utilise les informations d'identification de sécurité. Dans la deuxième partie de cette série, j'expliquerai comment placer sous contrôle pour pouvoir utiliser une solution unique pour effectuer toutes les les mises à jour nécessaires, quel que soit des types de service sous-jacent.
Le scénario de mise à jour plus important concerne les informations d'identification de batterie de serveurs. Le mot de passe du compte de batterie de serveurs est spéciale, car il affecte la clé de la batterie d'informations d'identification, qui sert à chiffrer tous les mots de passe de la batterie, comme nous l'avons vu précédemment. Par conséquent, après un changement de mot de passe du compte de batterie de serveurs dans Active Directory, vous devez mettre à jour SharePoint à l'aide de la commande :
stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER>
  -password <PASSWORD>
SharePoint puis doit Rechiffrer toutes les passe (chiffrés) existant dans la base de données de configuration, il doit mettre à jour le compte de service du minuteur SharePoint (qui utilise le compte de batterie de serveurs comme son identité) et il doit propager ces modifications à nouveau à tous les serveurs de la batterie de serveurs by means of un travail du minuteur de type SPAdminAppPoolCredentialDeploymentJobDefinition.
De nombreux facteurs permettent d'accéder incorrects pendant cette phase. Le travail du minuteur peut obtenir bloqué dans la file d'attente, comme illustré dans la figure 3 , ou le processus de mise à jour peut échouer de manière inattendue, en raison par exemple une panne de courant soudain, en laissant derrière ancien passe chiffrés que SharePoint maintenant ne peut pas décrypter plus car la clé informations d'identification a changé.
La figure 3 un travail de déploiement d'informations d'identification bloqués dans la file d'attente fait que le service de minuterie SharePoint ne fonctionne pas sur tous les serveurs de la batterie
Dans un autre scénario, vous mettre à pourriez jour les mots de passe comptes de pool d'applications des avant que le nouveau compte de batterie de serveurs ont atteint tous les serveurs de la batterie, à l'origine des serveurs avec la clé Informations d'identification obsolète Échec car ils ne peut pas déchiffrer le mot de passe mis à jour dans la base de données de configuration encore, comme illustrée dans la figure 4 . C'est un scénario intéressant et la raison pour le commutateur noadmin dans la commande updateaccountpassword. Si le compte de batterie de serveurs est également utilisé comme un compte de pool d'application (non recommandé), vous devez mettre à jour la batterie de serveurs informations d'identification tout d'abord, attendez que tous les serveurs de la batterie de serveurs ont traité le travail du minuteur et mettre à jour les pools d'applications.
La figure 4 maintenir à pool jour des applications jusqu'à ce que le travail Administration Application Pool Credential Deployment a été traité
En conséquence, la commande updateaccountpassword vérifie si le compte de sécurité spécifiée est le compte de batterie de serveurs et vous informe sur les dépendances si c'est le cas sans effectuer la mise à jour. En utilisant le - commutateur noadmin, vous désactiver cette vérification et appliquez le mot de passe modifié au compte de la configuration de pool d'application, mais il est difficile d'automatiser ces procédures dans un script avec un retard appropriée.

Résolution des problèmes d'informations d'identification de la batterie
Maintenant nous allons examiner un plus près la commande updatefarmcredentials. Il est fourni avec un commutateur dangereux qui peut provoquer grande difficulté, surtout s'il est utilisé comme décrit dans l'article » Message d'erreur lorsque vous essayez d'utiliser l'Assistant de technologies et produits SharePoint: « exception : System.ArgumentException : erreur au cours de chiffrement ou le déchiffrement ”. Je suis référence au commutateur appelé - local. Les développeurs SharePoint introduit ce commutateur pour effectuer des mises à jour d'informations d'identification de batterie locale manuellement. L'idée est que vous pouvez supprimer un travail du minuteur de la file d'attente dans l'administration centrale (_admin/ServiceJobDefinitions.aspx) si le travail est endommagé ou non traitée pour une raison quelconque et puis effectuez l'étape de la mise à jour nécessaire directement à l'aide la commande :
stsadm -o updatefarmcredentials -userlogin <DOMAIN\USER> 
  -password <PASSWORD> -local
Le paramètre-local commutateur indique à la commande updatefarmcredentials pour appliquer la modification du mot de passe uniquement sur l'ordinateur local. Il est important reconnaître, cependant, cette mise à jour affecte la clé informations d'identification et le service de minuterie SharePoint, mais pas les pools d'applications, recherche de service, fournisseurs de services partagés (SSP) et ainsi de suite. Il est supposé que vous avez déjà exécuté la updatefarmcredentials commande sans le commutateur local sur un autre serveur de la batterie de serveurs et par conséquent re-encrypted tous les mots de passe dans la base de données de configuration. Il n'est pas nécessaire effectuer cette étape de rechiffrement à nouveau. Mais que se passe-t-il si utilisé le commutateur local sans effectuer cette étape ?
À l'aide le commutateur local sans la première exécution les updatefarmcredentials commande sans ce commutateur entraîne des problèmes car le paramètre-local commutateur modifie la clé informations d'identification. Les mots de pool d'application sont chiffrés avec la clé ancienne dans la base de données de configuration, mais cette clé est désormais remplacée.
Observez figure 5 . Vous ne pouvez pas exécuter le updatefarmcredentials commande sans le commutateur local plus parce que ceci exige le rechiffrement des mots de passe qui peuvent ne plus être déchiffrées. Lorsque la commande échoue, vous pouvez trouver entrées dans le journal des événements Application indiquant: « erreur re-encrypting credential ID 022e607e-b49e-40e4-bd3f-f56a3c69f94d avec propriétaire ID 431b6897-16eb-4b9a-be65-60f1f603008d pendant le déploiement des informations d'identification administration application pool, recréez d'informations d'identification manuellement. Opération n'est pas valide en raison de l'état actuel de l'objet. »
La figure 5 Impossible Pour rechiffrer les mots de passe application pool, car les mots de passe peuvent ne plus être déchiffrées
Si vous avez modifié simplement le compte de batterie de serveurs dans un déploiement single-server à partir du compte service réseau à un compte de domaine, vous êtes en véritable problème car vous ne pouvez pas changer revenir à la clé Informations d'identification ancienne dans ce cas. Le service de réseau n'est pas utiliser un mot de passe et la clé informations d'identification est par conséquent aléatoire.
Dans une recherche d'aide, vous pouvez rencontrer que » Message d'erreur lorsque vous essayez d'utiliser l'Assistant de technologies et produits SharePoint: « exception : System.ArgumentException : erreur au cours de chiffrement ou le déchiffrement ” article mentionné précédemment et sans connaissances supplémentaires, votre problème worsens car vous apprendre maintenant que vous devez créer une nouvelle base de données de configuration pour vous débarrasser de ces mots de passe peuvent ne plus être déchiffrées. Il est une constellation unbelievable des circonstances malheureuse. Vous ne devriez pas pouvoir s'exécuter en premier lieu les updatefarmcredentials commande avec le commutateur local, ou la commande doit créer une copie sauvegarde de la clé Informations d'identification ancien afin de vous pouvez rechiffrer les mots de passe plus tard. Ou il devrait détecter connexion simplement que les mots de passe non encore re-encrypted et rechiffrer les à ce stade.
Au lieu de cela, le paramètre-local commutateur va à l'avance et Heureusement endommage votre base de données de configuration SharePoint sans les avertissements, comme illustré figure 5 . Un outil de prise en charge de Microsoft pour réinitialiser les mots de passe peuvent ne plus être déchiffrées est sont utile. Et, bien sûr, correcte documentation qui vous avertit sur la nature critique de certaines opérations de ligne de commande et qui vous guide de ce problème est également être appréciée.
La bonne nouvelle est que la commande updateaccountpassword pouvez crypter nouveau mots de passe des comptes de pool d'applications sans devoir déchiffrer les anciens mots de passe. Par conséquent, utilisez cette commande pour mettre à jour tous les pools d'applications qui utilisent des comptes de domaine. Il doit s'en occupent plus, si pas tous les mots de passe endommagé. Malheureusement, vous ne pouvez pas utiliser cette commande pour mettre à jour les pools d'applications qui utilisent le compte service réseau. Ce compte ne nécessite pas un mot de passe, la commande updateaccountpassword ne s'appliquent.
Curieusement, le compte service réseau peut être associé aux données de mot de passe dans la base de données de configuration. Aucun mot de passe de disposer de nouveaux pools d'applications qui utilisent le service de réseau, tout si vous changez le pool d'applications à utiliser un compte de domaine et revenir retour, le service de réseau hérite de référence de mot de passe du compte de domaine. SharePoint n'affecte pas le mot de passe à null (codage déconseillé) et ces données rubbish maintenant provoque les problèmes.
C'est une condition ironic qui clients sont censés pour jeter les bases de données de configuration car rubbish et données totalement inutiles peuvent plus être déchiffrées ! Si vous êtes chance, vous pouvez modifier la configuration pool d'applications dans l'administration centrale (_admin/FarmCredentialManage­ment.aspx) et spécifier un compte de domaine. Si vous êtes unlucky, vous rencontrer l'erreur de chiffrement/déchiffrement affichée dans la figure 6 . Vous ne pouvez pas modifier le compte dans l'administration centrale, vous ne pouvez pas utiliser la commande updateaccountpassword, vous ne pouvez pas exécuter l'Assistant de configuration technologies et produits SharePoint et vous ne pouvez pas mettre à jour les informations d'identification de batterie de serveurs à l'aide la commande updatefarmcredentials. Maintenant que devez-vous faire ?
La figure 6 trouble provoqué par un mot de passe service réseau indésirable conservés dans la base de données de configuration.
Pour résoudre ce problème, vous devez un outil qui se place directement dans la base de données de configuration et supprime le courrier indésirable, telles que l'outil réinitialiser le mot de passe AppPool, illustré figure 7 et inclus avec code source dans le support associé. Cet outil est très simple. Il extrait les données de pools d'applications qui utilisent des comptes avec associé passe chiffrés directement de la base de données de configuration, puis utilise le modèle d'objet SharePoint pour déterminer si le mot de passe application pool peut être déchiffrée.
La figure 7 Resetting endommagé mots de passe null
Si accéder le mot de passe via le modèle objet échoue avec une exception d'argument, le mot de passe est endommagé. Ici, il vous donne une possibilité pour remplacer tableau le mot de passe de valeurs d'octets cryptés par une référence null et enregistre que les modifications en différé dans la base de données de configuration. Chaînes vides n'avez pas à être déchiffré et n'engendrent donc pas une exception d'argument. Problème résolu.
Est pour réaliser le processus de réparation, J'AI recommandé de mettre à jour les informations d'identification de batterie de serveurs et ensuite toutes les applications pool comptes en utilisant Stsadm.exe et l'administration centrale. Votre batterie de serveurs est nouveau dans un état cohérent, et vous devrez jeter votre base de données de configuration vous n'avez pas.

Conclusion
Malgré le fait que modification des informations d'identification de batterie de serveurs et mot de passe de compte sécurité est un processus fastidieux et sujette aux erreurs, vous devez irreparably peur que modifier des informations d'identification de batterie de serveurs endommagera votre batterie de serveurs. La base de données de configuration peut être réparé même si vous perdez votre clé d'identification en cours. Vous devez simplement réinitialiser les mots de passe affectés, et cela est possible via l'outil Stsadm.exe standard ou un outil plus bas niveau base de données, tel que réinitialiser le mot de passe AppPool. Pour conserver Modifier informations d'identification de batterie de serveurs et comptes de sécurité fréquemment, utilisez mots de passe forts et n'est pas d'utiliser le service de réseau comme un compte de sécurité car il complicates la configuration de batterie de serveurs et résolution des problèmes. Utiliser comptes de domaine dédié.
Maintenant que vous avez adressé les risques de corruption de base de données par les modifications de mot de passe, vous pouvez vous concentrer votre attention sur le problème réel dans l'architecture de la sécurité de SharePoint : l'architecture actuelle ne pas prendre en charge les modifications de mot de passe très bien. Vous devez appliquer trop de commandes dans un ordre plus ou moins spécifique selon les types de service que vous devez mettre à jour de votre batterie de serveurs. Certaines commandes commutateurs dangereuses ; certains ne. Certaines commandes peuvent endommager votre base de données de configuration ; d'autres sont sans danger. Certains services doivent être mis à jour globalement sur toute la batterie de serveurs et d'autres sont locaux à un serveur spécifique.
Dans des cas, charge administrative est élevé en raison de la complexité impliquée, et la sécurité est généralement faible due à modification ponctuels plannings, les mots de passe faibles et scripts qui traitent des mots de passe en texte clair. Dans mon prochain article, je vais montrer vous comment résoudre ces problèmes et d'éliminer les, et pour tout service types, y compris les n'est ne pas encore développé, ce que leurs besoins de mise à jour de mot de passe. Les modifications de (manuelle) mot de passe plus !

Pav Cherny est un expert informatique et l'auteur spécialisé dans les technologies Microsoft de collaboration et de communication unifiée. Son compositions incluent les blancs, produit manuels et livres avec une spécialisation sur les opérations INFORMATIQUES et d'administration système. Pav est président de Biblioso Corporation, une entreprise spécialisée dans les services de documentation et de localisation gérés.

Page view tracker