Suggérer une traduction
 
Suggestions d'autres utilisateurs :

progress indicator
Aucune autre suggestion.
TechNet Magazine > Accueil > Tous les numéros > 2009 > TechNet Magazine Mars 2009 >  Automatiser les mises à jour des informations d...
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 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 sppwd.com that will, in the near future, provide the MOSS components and other updates as well as further documentation of features and programming interfaces.
The current prototype is for test purposes only and is not to be used in production environments. Not fully tested, it nevertheless demonstrates that SharePoint security account maintenance does not have to increase administrative overhead. The companion material for this column, available at 2009 TechNet Code Downloads , includes worksheets, compiled assemblies, and source code.

Services and Security Accounts
Have you ever wondered why you need to use so many different commands to update SharePoint security accounts after a password change in Active Directory? Then check out the article " How to Change Service Accounts and Service Account Passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0 ."
It describes five different commands (updateaccountpassword, spsearch/farmserviceaccount, spsearch/farmcontentaccessaccount, updatefarm­credentials, and editssp/ssplogin), and it still doesn't cover all aspects.
Moreover, the article's sample script, while useful as a template, showcases a weak security configuration because it assumes you use the same account and password for all services in the farm. Try adapting this script to a farm environment where each service and application pool uses a different user account and password, and you can experience a great scripting challenge. Maintaining system security through scripts isn't easy in a SharePoint farm.
The reason for the complexities is buried deep within the SharePoint security design. As you learn by using the stsadm -o enumservices command, SharePoint relies on a number of services, and each service has different security dependencies.
If you look up the type name that the enumservices command returns for each service in the WSS 3.0 SDK, you'll find that some of these services use no security accounts, while others may use a single security account or require multiple accounts. For example, messaging-related services and the diagnostics service are not associated with security account information, the SharePoint Timer service uses a single security account, the Search service has a service account as well as a crawler account, and the Web app service can have as many security accounts as there are application pools.
And there is more. The SharePoint Administration Service, for example, must use the local system account, so it doesn't require a domain security account even in a SharePoint farm. Some solutions can also introduce their own services, such as Microsoft Office Project Server (MOPS) 2007. The sky is the limit, considering that you can also have any number of custom solutions with varying security requirements.
Of course, there's no way to enforce common update procedures across such a diverse portfolio of services, so it's no surprise that SharePoint features a rich set of update commands. Essentially, every solution must provide its own individual tools and update procedures, increasing the administrative overhead in proportion to the number of services in the SharePoint environment. Figure 1 illustrates the relationship between SharePoint services and security accounts as well as the applicable update commands.
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
Conclusion
Security accounts are prime targets for attacks, because they can provide full access to all site collections and site data in a farm regardless of permissions and access controls defined at the SharePoint level. One basic strategy to prevent these attacks from succeeding is to use strong security account passwords and change them frequently.
This is challenging to accomplish because domain user accounts don't change their passwords on their own. You must perform the password changes manually or use an automated solution. Whichever way you choose, there are numerous dependencies that the SharePoint documentation and the WSS SDK don't describe very well.
You must update and deploy changed passwords, and there are additional concerns related to the farm account. For example, when you change the farm account password, you change the farm's credential key, and this affects the recoverability of the configuration database from backup.
Nevertheless, there is no alternative to changing the farm account password on a regular basis if you want to maintain system security in a SharePoint farm. Make sure you perform a backup after changing the farm account password.
Automating password changes is complicated despite the fact that the SharePoint object model includes the necessary logic to carry out credential updates. It might seem easy first glance, but even a script-based approach can quickly turn into a huge challenge. A full-featured solution based on the Microsoft .NET Framework and the SharePoint administrative object model is a good choice, but the best solution can only come directly from Microsoft in the form of additional system account innovations.
Almost 10 years ago, Microsoft modified the local system account to accommodate the needs of enterprise customers using Microsoft Exchange Server. This eventually resulted in the Network Service account with Windows Server 2003. But the Network Service account is not suitable for server farms, so we must still use domain user accounts and deal with the associated maintenance and security issues to the best of our abilities.

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

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

Téléchargement de code disponible à : ChernySharePoint2009_03.exe (821 KO)

Microsoft Windows SharePoint Services (WSS) 3.0 et Microsoft Office SharePoint Server (MOSS) 2007 commande sécurité Gestion de la limite avec les services et processus de travail qui reposent sur les comptes d'utilisateur de domaine pour la prise en charge le contrôle d'accès discrétionnaire (DAC), modèle de sécurité de Windows Server. Dans le rôle des comptes de sécurité, comptes d'utilisateur de domaine ont toujours mal à besoins d'entreprise. Cela s'applique à n'importe quel environnement client/serveur et encore plus donc pour batteries de serveurs SharePoint, chaque service d'une batterie de serveurs gère ses propres informations de compte et impose ses propres procédures mise à jour spécifique, indépendamment des autres services qui pouvez utiliser les mêmes informations d'identification. Le compte en question peut être le même compte dans Active Directory, mais vous devez toujours mettre à jour chaque service individuellement après un changement de mot de passe.
N'oubliez bien entendu, tout d'abord pas tous les services qui utilisent un compte. Il peut être difficile à suivre les recommandations de sécurité qui propose l'utilisation de comptes de domaine distinct pour services SQL Server, services d'administration centrale et du minuteur SharePoint, recherche service et le robot d'indexation, fournisseurs de services partagés (SSP), pools d'applications Web, service d'authentification unique, utilisateur Importation de profil et comptes Excel Services.
Et, bien sûr, il existe différents mots de passe forts pour chaque compte et les modifications de fréquentes mot de passe pour effectuer le suivi des. Ne serait-il pas idéal maîtriser ce défi sans impliquer de surcharge administrative ?
Dans ce le deuxième article d'une série de deux parties, je étudier aspects de sécurité de SharePoint, spécifiquement sécurité compte maintenance et présente une solution à automatiser les modifications de mot de passe à obtenir une meilleure sécurité et réduire la charge administrative.
L'idée sous-jacente est relativement simple : une solution personnalisée pouvez obtenir tous les noms de compte de sécurité et les mots de passe en utilisant le modèle d'objet d'administration SharePoint. La solution pouvez utiliser ces informations pour ouvrir une session sur Active Directory, modifier le mot de passe correspondant via ADSI (Active Directory Service Interfaces) et mettre à jour affectés tous les services dans la batterie de serveurs locale.
De cette façon, les administrateurs SharePoint inutile traitent des mots de passe des comptes sécurité plus. Toutefois, l'implémentation de l'idée ne simple. Au final, J'AI trouvé moi-même création de plusieurs composants, notamment les extensions de commandes Stsadm.exe, les pages d'application pour le site Administration centrale de SharePoint 3.0, un service Windows intégré de SharePoint et une interface de programmation simple pour normaliser les modifications de mot de passe dans tous les types de SharePoint services.
Je ne possède suffisamment de temps pour couvrir tous les services MOSS encore, mais le prototype en cours prend en charge de WSS 3.0. J'ai créé un site Web à sppwd.com qui, dans un avenir proche, fourniront les composants MOSS et autres mises à jour ainsi plus documentation des fonctionnalités et interfaces de programmation.
Le prototype en cours concerne le test uniquement ; ne doit pas être utilisé dans les environnements de production. Pas entièrement testé, il néanmoins illustre que Gestion des comptes de sécurité de SharePoint ne dispose pas d'augmenter les tâches administratives. Le matériel associé de cette colonne disponible à Téléchargements TechNet code 2009 , inclut feuilles de calcul, assemblys compilés et le code source.

Services et comptes de sécurité
Vous êtes-vous jamais demandé pourquoi vous devez utiliser des commandes différentes tellement pour mettre à jour les comptes de sécurité de SharePoint après qu'un mot de passe modifié dans Active Directory ? Puis consultez l'article » Comment modifier comptes de service et les mots de service passe de comptes dans SharePoint Server 2007 et dans Windows SharePoint Services 3.0 ."
Il décrit cinq commandes différentes (updateaccountpassword, spsearch/farmserviceaccount spsearch/farmcontentaccessaccount, updatefarm­credentials et editssp/ssplogin) et elle n'est pas toujours couvre tous les aspects.
En outre, l'article exemple de script, tandis qu'utile comme un modèle présente une configuration de sécurité faible car il suppose que vous utilisez les mêmes compte et le même mot de passe pour tous les services de la batterie de serveurs. Essayez d'adapter ce script pour un environnement de batterie de serveurs où chaque service et l'application réserve utilise un compte d'utilisateur différent et un mot de passe et vous pouvez rencontrer un défi de script très. Gestion sécurité du système via scripts n'est pas simple dans une batterie SharePoint.
La raison de la complexité est cachée profondeur dans la conception de sécurité de SharePoint. Comme vous savoir en utilisant la commande stsadm-o enumservices, SharePoint s'appuie sur un certain nombre de services, et chaque service a dépendance de sécurité différent.
Si vous recherchez le nom du type qui la commande enumservices renvoie pour chaque service dans le Kit de développement WSS 3.0, vous remarquerez que certains de ces services utilisent sans comptes de sécurité, tandis que d'autres utilisateurs peuvent utiliser un compte de sécurité unique ou nécessitent plusieurs comptes. Par exemple, services de messagerie liées et le service diagnostics sont non associés aux informations de compte de sécurité, le service de minuterie SharePoint utilise un compte de sécurité unique, le service de recherche dispose d'un compte de service ainsi que d'un compte de robot et le service Application Web peut avoir que plusieurs comptes de sécurité comme il pools d'applications.
Et il est plus. Le service d'administration SharePoint, par exemple, devez utiliser le compte système local, afin qu'il ne nécessite pas un compte de sécurité domaine même dans une batterie SharePoint. Certaines solutions peuvent introduire également leurs propres services, tels que Microsoft Office Project Server (MOPS) 2007. Le ciel constitue la limite, envisagez que vous pouvez également avoir n'importe quel nombre de solutions personnalisées avec des variables d'exigences en matière de sécurité.
Bien entendu, il n'est aucun moyen d'appliquer courantes procédures de mise à jour sur ce divers un porte-documents des services, donc il est sans surprise que SharePoint comporte un ensemble complet de commandes de mise à jour. Pour l'essentiel, chaque solution doit fournir des ses propres outils individuels et mettre à jour des procédures, augmentant la surcharge administrative dans proportionnellement au nombre de services dans l'environnement de SharePoint. la figure 1 illustre la relation entre les services SharePoint et comptes de sécurité, ainsi que les commandes de mise à jour applicables.
Figure 1 une relation entre les comptes de services et de sécurité de SharePoint

Services et comptes de sécurité
La disposition des services et comptes de sécurité peut sembler confuse, mais il existe un ordre hiérarchique appliqué via le modèle d'objet SharePoint, comme illustré dans la figure 2 . À la base de tous les services SharePoint est la classe SPService. Cette classe n'inclut pas un compte de sécurité car, comme nous l'avons vu précédemment, pas tous les services nécessitent des informations d'identification. Services qui nécessitent des informations d'identification peuvent hérite une identité de la classe SPWindowsService ou implémenter leurs propres.
La figure 2 hiérarchies d'héritage de SharePoint services
La classe SPSearchService, par exemple, une identité de processus hérite de la classe SPWindowsService et gère également son propre compte robot d'indexation. La classe SPWebService, d'autre part, n'a pas besoin une identité de processus SPWindowsService­based, afin qu'il hérite directement de la classe SPService et gère ses propres comptes de sécurité dans l'écran d'identités de pool d'application.
Il existe plusieurs faits importants de prendre loin dans la hiérarchie d'héritage. Tout d'abord et avant tout, n'il y sont pas vraiment que différentes façons à gérer les comptes de sécurité dans une batterie SharePoint. Les services SharePoint utilisent principalement identité de processus ou application pool d'identité. Ces types d'identité sont très similaires par rapport à la mise à jour des informations de sécurité, car la classe SP­ApplicationPool est dérivée de la classe SPProcessIdentity.
Ensuite, les identités des services SharePoint sont disponibles pour des scripts personnalisés et les applications administratives. Il est possible accéder à chaque service SharePoint individuel via la classe de base SP­Service pour accéder aux noms d'ouverture de session et les mots de passe.
Enfin, le modèle d'objet SharePoint sait déjà comment gérer identité de processus et identité pool d'application. Entre autres choses, le modèle objet inclut la logique de définir et mettre à jour mots de passe, de sorte que vous n'avez besoin de réinventer la roue lorsque vous utilisez des outils personnalisés. Vous seulement devez appellent les méthodes requises, même si ce n'est pas sans obstacles car le Kit de développement WSS n'est pas expliquent les dépendances très bien.
Mise à jour les comptes de sécurité nécessite plus de définition des propriétés nom d'utilisateur et mot de passe (ou SecurePassword) d'identité de processus (SPProcess­Identity) ou application pool identités (SPApplicationPool) et d'appeler la méthode de mise à jour. Cela n'est pas placer la batterie de serveurs en dans état opérationnel. La méthode Update met simplement à jour le mot de passe dans la base de données de configuration SharePoint, mais il n'est pas mise à jour les services sous-jacente ou les pools d'application.
Il est important de N'oubliez pas que les ressources affectées existent en dehors de l'environnement de SharePoint. Services Windows gérer leurs informations de sécurité dans la base de données du service contrôle Manager (SCM), situé dans le Registre sur chaque serveur sous HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services.
Applications Web, y d'autre part, de ressources des services Internet (IIS). Pour les mettre à jour, vous devez appeler méthode de déploiement de l'identité avec la méthode Update. La méthode de déploiement déclenche la logique de SharePoint pour mettre à jour tous les serveurs de la batterie de serveurs au moyen d'appels API locaux et les tâches du minuteur SharePoint. Il modifie également clé d'identification de la batterie si votre modification se produit pour affecter le mot de passe du pool d'applications de l'application Web Administration centrale (SPWebService.AdministrationService).
Cette modification de mot de passe affecte également le service du minuteur SharePoint, qui est étroitement couplée à l'infrastructure d'administration, vous ne devez mettre à jour le service du minuteur SharePoint directement. Pour plus de détails concernant les procédures standard pour effectuer des modifications de mot de passe dans un environnement de batterie de serveurs avec plusieurs serveurs, vous devez lisez mon article à partir de mois dernier " Gestion des informations d'identification du compte sécurité ."

Une commande pour tous les services
Malgré la complexité la bonne nouvelle est que le modèle d'objet SharePoint s'occupe de tous les détails de mise à jour de moindres dans une batterie de serveurs. Il suffit de tirer parti des fonctionnalités existantes dans une extension Stsadm personnalisée pour implémenter une commande de mise à jour unique pour tous les services :
stsadm -o changepwd -user DOMAIN\Account -oldpwd old_p@ssw0rd
 -newpwd new_ p@ssw0rd
Il est vraiment inutile pour les nombreuses commandes autre mise à jour. Après tout, il est clair que vous devez modifier le mot de passe dans tous les emplacements, y compris Active Directory, base de données de configuration, base de données des services Windows, les services Internet (IIS) et ce qu'autres référentiels d'informations d'identification un service particulier peut utiliser.
Il pas d'option pour laisser un mot de passe obsolète derrière. Avoir une extension commande prendre en charge toutes les dépendances implique plus cohérents modifications de mot de passe affectés toutes les ressources et moins de problèmes liés mot de passe de la batterie de serveurs.
En outre, si vous l'implémentation d'une extension STSADM est des attributs de facile et amusante. Simplement suivez les étapes décrites dans le Kit de développement WSS sous le titre » Comment : étendre l'utilitaire STSADM ." Je vous recommande également que vous extrayez Du Gary Lapointe blog de très exemples et une liste impressionnant des extensions utiles que vous pouvez trouver utile dans votre travail quotidien en tant qu'administrateur SharePoint.
Avec les Stsadm implémentation détails en d'en, nous peuvent concentrer nos efforts sur l'implémentation de la solution réelle, qui est difficile assez considérer que peuvent services SharePoint utiliser autant d'informations d'identification. Il peut inclure identité de processus, application pool identités et des autres comptes.
Il ne simplement aucun moyen de connaître les dépendances de sécurité de chaque service SharePoint amont. Vous pouvez obtenir le rangement avec les services WSS et MOSS standard, mais une solution vraiment utile doit prend également en charge services personnalisés avec différentes exigences.
Traiter différents, il convient mieux via une API. L'API decouples l'extension de commande des services sous-jacent et de cette manière permet aux développeurs d'intégrer leurs propres composants qui contient la logique pour exécuter des modifications de mot de passe pour leurs services.
J'appelle ces composants enfichables proxys de service. À compter sur ces composants proxy, l'extension de commande peut accepter n'importe quel service, les développeurs ne doivent fournir des outils de mise à jour plus mot de passe plus et les administrateurs ne devrez traitent plus complexités de sécurité des services sous-jacent. Par conséquent le fardeau administratif pour gérer les comptes de sécurité dans un environnement SharePoint réduit.
Nos API de proxy de service doit effectuer deux opérations de base : il doit activer l'extension de commande déterminer les comptes de sécurité de tous les services pris en charge et il doit activer l'extension de commande mettre à jour les mots de passe associés. En conséquence, l'API nécessite deux méthodes : Resolve­Identities et ChangePassword.
Tout d'abord, l'extension commande énumère tous les services de la batterie de serveurs à l'aide de la collection SPFarm.Local.Services. Pour chaque type de service, l'extension commande charge également dynamiquement un proxy de service, enregistré pour le service dans un fichier de configuration XML respecte la convention d'appellation passwordproxies.*.xml (tels que passwordproxies.WSSProxies.xml).
Ensuite, l'extension commande appelle la méthode ResolveIdentities du proxy de service enregistrés, passant ainsi que d'une référence à l'objet du service. Le composant proxy extrait les comptes de sécurité souhaité le service sous-jacent et renvoie ces informations à l'extension de commande.
Le résultat est une association entre les comptes de sécurité et services qui est l'inverse de l'association définie dans le modèle d'objet SharePoint. Au lieu des services en cours les parents des comptes de sécurité, comptes de sécurité sont désormais les parents des services, comme illustré dans la figure 3 . Cette architecture indique la relation réelle entre les services et les comptes de sécurité mieux.
La figure 3 inverse de la relation entre les comptes de sécurité et les services SharePoint
Plus important, l'extension de commande peut maintenant mettre à jour les comptes de sécurité dans Active Directory et puis itérer sur tous les objets service dépendant d'appeler la méthode ChangePassword, des proxys correspondants pour mettre à jour le mot de passe.
Là encore, les composants de proxy contient la logique de service particulière nécessaire pour effectuer les modifications de mot de passe. L'extension de commande lui-même ne traitent pas des détails d'implémentation service particulière.
Si vous êtes intéressé par les détails, extraire le fichier SPPwdServiceProxy.cs dans le support associé. Il définit le proxy API par le biais d'une classe de SPPwdServiceProxy abstraite avec ses deux méthodes, ResolveIdentities et ChangePassword. Pour obtenir des exemples implémentation, consultez les définitions de classe dans la bibliothèque de classe WSSProxies.
La bibliothèque WSSProxies illustre comment utiliser le proxy du service API pour effectuer des modifications de mot de passe pour les services de WSS 3.0 standard. Il n'est pas compliquée de modifier le mot de passe de compte sécurité par programmation. Tout ce dont vous avez besoin sont trois lignes de code pour l'identité de processus et les trois lignes pour les identités pool d'application. Le modèle d'objet SharePoint fait le reste.
Seul le compte de la classe SPSearchService analyse pose un défi car Microsoft marqué l'écriture de mot de passe analyse uniquement, pour que vous ne pouvez pas lire avec les méthodes ordinaires. Cela rend difficile aux développeurs de solutions de créer des solutions de sécurité.

Passer la distance complète
Avec une extension seule commande couvrant tous les services, faites-le nous concentrer notre attention sur quelques opportunités d'amélioration supplémentaire. La première est pour éliminer la nécessité de spécifier les mots de passe en texte clair à une invite de commandes, qui n'est pas une pratique sécurisée. Même la boîte de mot de passe plus simple interface utilisateur graphique de serait masque ces informations.
Une autre possibilité consiste à augmenter la complexité des mots de passe sans augmenter le fardeau administratif. Peut-être mots de passe avec sept caractères alphanumériques aléatoires ont une fois considéré comme sécurisé, mais que hypothèse a été établie longtemps et probablement ne contient pas vrai pour les comptes de sécurité maintenant.
Est-il utilisant 50 ou plusieurs caractères pour ressources importantes, telles que les comptes de sécurité de SharePoint : 3ZK2AQUuqZ7/M7­NBIEvc {XKregSMaVmQgiZaZXik­hL8E {dQuwyQ pour la batterie de serveurs compte ; TA3pIa7yUyJikc6FxTFl = K9EQcb8lBn­hp8ej03lt3 + mA = 7aqgKA pour l'application Web par défaut ; PXMzzAxrHvO/L9MZyd0SkVuMv9/co0ocluYCq/4TID/n + DLj­XYA pour le compte service de recherche ; et qjoNlEvOX $ 7vbEjrnDd5lXLPYvZEFf­gRpij $8amSbEVpj2O474Q pour le compte du robot ?
Il strikes me comme funny d'imaginer un administrateur d'entrer manuellement ces types de mots de passe. Une autre amélioration opportunité liée aux vérifications de sécurité. Par défaut, SharePoint ne vous avertit sur les configurations de sécurité faible, tels que les pools d'applications avoir accès à la métabase IIS ou en utilisant le compte de batterie de serveurs comme leur identité de sécurité. Une solution personnalisée peut effectuer ces vérifications de façon régulière.
Et enfin, pourquoi administrateurs SharePoint devez gérer ces mots de passe pour les comptes de sécurité ? Pirates sont peut-être celles uniquement intéressés par connaître ces mots de passe. Les administrateurs généralement inutile les utiliser.
Bien entendu, SharePoint offre de nombreuses options pour résoudre ces opportunités. Vous pouvez utiliser les scripts, mais les scripts généralement gérer les mots de passe en texte clair. Vous pouvez utiliser tâches Timer personnalisées, dont le service de minuterie SharePoint processus dans intervalles planifiés, mais le service de minuterie déjà s'occupe de nombreuses tâches, y compris les déploiements d'informations d'identification.
Il serait difficile de coordonner des tâches de déploiement d'informations d'identification avec travaux modification de mot de passe. Il semblait préférable d'implémenter un service SharePoint distinct qui utilise le compte de batterie de serveurs comme son identité de processus pour pouvoir utiliser complète le modèle d'objet d'administration SharePoint.
Entre autres choses, vous pouvez arrêter ce service à tout moment sans affecter les autres processus et vous pouvez désactiver ce service si vous souhaitez modifier les mots de passe manuellement. La solution inclut plusieurs outils pour cela, comme Stsadm extensions de commandes une application Windows et pages d'application Administration centrale personnalisés, tel qu'affiché dans la figure 4 .
La figure 4 architecture de solution SPPwd
En fait, toutes les applications SPPwd reposent sur le même ensemble d'extensions de STSADM, et il n'est qu'un seul chemin de code indépendamment de quel outil que vous utilisez. Via une couche de logique métier courants, les extensions de commandes conjointement avec les proxys de service effectuer le réel traitement, tandis que les applications SPPwd utilisent des objets talon pour charger dynamiquement les extensions de commandes au moment de l'exécution.
Ce couplage libre permet de remplacer certaines extensions de commandes sans avoir à modifier les applications SPPwd. Par exemple, si vous préférez utiliser un générateur de mot de passe différent, vous pouvez créer une extension de commande, déployer dans le global assembly cache et modifier l'entrée de commande genpwd dans le fichier de configuration stsadmcommands.passwordmanagement.xml. La solution place dans le dossier %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\12\Config conformément aux conventions d'extensibilité de Stsadm.
Le Générateur de par défaut crée ces mots de passe longs, doivent être suffisants dans la plupart des cas. la figure 5 répertorie les extensions de commandes SPPwd avec une brève description de leur rôle. Vous pouvez également utiliser la stsadm - Aide commande <extension> pour afficher plus d'informations sur les paramètres disponibles et exemples de ligne de commande.
Extensions de commandes stsadm figure 5 de la solution SPPwd
Extension Fichier de code Description
AccessCheck SPPwdAccessCheck.cs Vérifie si l'utilisateur actuel ou un compte spécifique a accès de lecture aux informations sensibles à la sécurité dans la métabase IIS et le Registre local. Le service SPPwd analyse les résultats de ces vérifications, ainsi que la configuration de compte de sécurité générale et écrit des avertissements dans le journal des événements d'applications s'il détecte les faiblesses de sécurité.
changepwd SPPwdChangePwd.cs Modifie le mot de passe pour le compte d'utilisateur spécifié dans Active Directory et tous les services SharePoint qui utilisent le compte comme une identité de sécurité.
genpwd SPPwdGenerator.cs Génère des mots de passe aléatoires basés sur un Algorithmes RNG (aléatoire numéro de génération) et le hachage cryptographique qui peuvent être considéré comme raisonnablement sécurisé.
sppwdsetup SPPwdServiceSetup.cs Installe ou désinstalle le service de Windows sur le serveur SharePoint local.
enumpoolaccounts SPPwdAppPoolAccounts.cs Répertorie les identités des applications Web SharePoint en tant que parents des pools d'applications associées. Le service SPPwd utilise ces informations pour vérifier les points faibles de sécurité, telles que les pools d'applications qui partager la même identité ou qui utilisent le compte de batterie de serveurs.
enumserviceids SPPwdListServiceIds.cs Répertorie les identités des services disponibles de la batterie de serveurs SharePoint en tant que parents de leurs services associés. Le service SPPwd utilise ces informations pour extraire le nom de connexion et le mot de passe actuel de chaque service afin d'utiliser ces informations pour les ouvertures de session Active Directory et effectuer les modifications de mot de passe.
enumproxies SPPwdServiceProxies.cs Répertorie les objets SPPwdServiceProxy enregistré et chargé sur le serveur. Cet outil est utile pour les développeurs qui souhaitent vérifier la configuration de leurs proxys de service.
enumsppwdservers SPPwdServerList.cs Répertorie le nom de domaine pleinement qualifié des serveurs SharePoint de la batterie locale, configurés pour exécuter le service SPPwd. Cette information est utile lorsque vous configurez des comptes de sécurité les modifications de mot de passe automatique.
sppwdacctcfg SPPwdAccountSettings.cs Configure les paramètres liés à la SPPwd pour le compte de sécurité spécifiée dans Active Directory. Le service SPPwd ne traite pas comptes de sécurité sauf si extensionAttribute10 le compte est définie sur le nom de domaine complet de l'ordinateur exécutant le service SPPwd. En outre, attribut description le compte de sécurité doit contenir la clause « ce compte est utilisé uniquement dans la batterie de serveurs SharePoint: < Nom de la batterie de Serveurs >. »
sppwdsvccfg SPPwdConfig.cs Affiche ou modifie la configuration système du service SPPwd. Paramètres incluent l'intervalle de vérification de configuration, le âge maximale du mot de passe de comptes de sécurité, le niveau de détail pour les événements écrits dans le journal des événements d'application et un paramètre pour désactiver le mode Whatif explicitement. Par défaut, le service SPPwd s'exécute en mode Whatif pour empêcher les modifications accidentelles du mot de passe. Dans Whatif mode le service uniquement prétendant modifier les mots de passe et indique le résultat de l'opération, mais il fait ne pas valider toutes les modifications.
Réseau privé SPPwdCheckHeartbeat Gère les travaux de pulsation du minuteur SharePoint dans une batterie de serveurs SharePoint. La solution SPPwd utilise ces pulsations pour détecter des serveurs en mode hors connexion et empêche les modifications de mot de passe dans ce cas.

Déploiement et à l'aide de la solution
Les feuilles de calcul dans le matériel associé expliquent lignes en détail comment déployer et utiliser la solution SPPwd dans un environnement à serveur unique ainsi que d'une batterie. Vous devez déployer la solution sur un serveur SharePoint en utilisant les commandes Stsadm addsolution et deploysolution standard.
SharePoint puis distribue la solution à tous les serveurs de la batterie via des travaux du minuteur. Dès que ces tâches sont terminées, vous pouvez activer la fonctionnalité de solution pour étendre le site Administration centrale et installer le service Windows en utilisant l'extension commande sppwdsetup.
Le matériel associé inclut un fichier DeployTo.bat pour automatiser ces tâches. Entre autres choses, le fichier de commandes explique comment attendre des travaux du minuteur avant de poursuivre d'autres étapes de déploiement.
Par défaut, le service SPPwd est uniquement disponible sur le serveur où vous exécutez le fichier DeployTo.bat. Vous pouvez configurer le service s'exécute sur plusieurs serveurs SharePoint, mais il n'est qu'une seule instance d'un compte de sécurité dans Active Directory, et il impose les deux conditions suivantes : une seule instance de service SPPwd peut être autoritée pour un compte de sécurité spécifique, et le compte de sécurité ne doit pas être utilisé dans plusieurs batteries.
Plusieurs instances de service processus la même compte peut entraîner des problèmes d'accès simultanés et n'est pas nécessaire puisque SharePoint propage les mises à jour d'informations d'identification de la batterie locale automatiquement. Partagé sécurité comptes ne sont pas pris en charge car le service SPPwd ne peut pas mettre à jour informations de compte de sécurité entre plusieurs batteries.
Le service SPPwd met uniquement à jour les comptes de sécurité qui spécifient nom de domaine dans l'attribut adminDescription pleinement qualifié du serveur et qui confirmer dans leur attribut description qu'ils sont utilisés uniquement dans la batterie locale SharePoint, comme indiqué dans la figure 6 . Consultez le matériel associé pour plus d'informations concernant la configuration de comptes de sécurité et le service SPPwd pour automatiser les modifications de mot de passe.
La figure 6 SPPwd déploiement et configuration de compte de sécurité
Conclusion
Comptes de sécurité sont prime cibles pour les attaques, car ils peuvent fournir un accès complet aux toutes les collections de sites et données de site dans une batterie de serveurs indépendamment des autorisations et des contrôles d'accès définis au niveau de SharePoint. Une stratégie de base pour éviter ces attaques réussi consiste à utiliser de mot de passe de sécurité renforcée compte et les modifier fréquemment.
Ceci est un défi pour accomplir car comptes d'utilisateur de domaine n'est pas changer leurs mots de passe de leurs propres. Vous devez effectuer les modifications de mot de passe manuellement ou utiliser une solution automatisée. N'importe quel moyen que vous choisissez, il y a des nombreuses dépendances décrivant la documentation SharePoint et le Kit de développement WSS n'est pas très bien.
Vous devez mettre à jour et déployer des mots de passe modifiés et il existe des problèmes supplémentaires associées au compte de batterie de serveurs. Par exemple, lorsque vous modifiez le mot de passe du compte de batterie de serveurs, vous modifiez d'informations d'identification clé la batterie, et ceci affecte la récupération de la base de données de configuration à partir d'une sauvegarde.
Néanmoins, il n'existe aucune alternative changer le mot de passe du compte batterie de serveurs de façon régulière, si vous souhaitez maintenir la sécurité du système dans une batterie de serveurs SharePoint. Assurez-vous que vous effectuez une sauvegarde après avoir modifié le mot de passe du compte de batterie de serveurs.
Automatisation des modifications de mot de passe est complexe malgré le fait que le modèle d'objet de SharePoint inclut la logique nécessaire pour exécuter des mises à jour des informations d'identification. Il peut sembler simple premier coup de œil, mais même une approche basée sur un script peut rapidement transformer en un défi important. Une solution complète basée sur Microsoft .NET Framework et le modèle d'objet d'administration SharePoint est un bon choix, mais la meilleure solution peut uniquement provenir directement Microsoft sous la forme d'innovations compte système supplémentaire.
Presque 10 années, Microsoft modifié le compte système local pour prendre en charge les besoins de clients d'entreprise à l'aide de Microsoft Exchange Server. A ce finalement provoqué le compte Service réseau dans Windows Server 2003. Mais le compte Service réseau n'est pas adapté aux batteries de serveurs, nous doit toujours utiliser des comptes d'utilisateur de domaine et traitent de la maintenance associé et de problèmes de sécurité pour le meilleur de nos fonctionnalités.

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