The Mit's Blog

SharePoint : Sécurité, comptes NT et services inhérents, ce qu'il est bon de savoir

Aprés lecture du post de Fabrice (qui décidemment commence à prendre à son interim SharePoint   ) sur

 
  SharePoint : Changement de compte NT d'une installation SharePoint Portal Server (SPS)

Je me suis taté à étendre un peu la problématique. En effet, l'article est un trés bon tutorial pour effectuer le changement de compte mais il souligne peu les raisons de tant de dépendance entre SQL/POOL/SPS et tuti quanti

Donc je viens en renfort de Fabrice et je vais vous detailler/linker quelques points importants de la sécurité systéme de la technologie SharePoint.
>>> Eh oui, un probléme sur le compte du pool IIS et vous vous retrouvez directement sur une jolie page 403 par exemple

Avant de commencer, je remets en avant les liens trés importants sur le cas de changement de compte d'exécution SharePoint :

• KB 837813 : How to change the user account and the password in SharePoint Portal Server 2003
• SharePoint: changing the password of the SharePoint Administrator

Pour resumer rapidement la couche d'exécution de SharePoint face aux permissions NT, on peut la détailler :

1. Les comptes de services
2. les comptes d'accés BDD SQL Server
3. Le compte d'indexation du crawler
4. le compte du pool IIS

Evidemment, l'ensemble de ces 4 points sont effectués dés l'installation de la ferme serveur, une modification du compte de l'installation est loin d'être anodine

Plutôt que de reprendre tout le détail, voici un post incontournable, qui lui justement fait cet inventaire avec toute les informations nécessaire :

SharePoint and Stuff ... : SharePoint Services and App Pool Account Permissions

 Pour ceux qui sont préssés, je reprendrais leur conclusion :

It may be easier to have a single user account as the service account for all SPS services, a single account for content crawling a single account for the configuration db access and then an account each for each application pool. E.g.:

Add "Domain\ServiceAccount" to "Power User" group on all Portal Servers. This account will be used to run all SPS services, will be the database configuration account and will be the application pool identity for the SharePoint Central Administration web site.
Grant this account the Database Creators and Security Administrators roles in SQL Server.

1. During SPS install specify the Domain\ServiceAccount as the database configuration account
2. Just after SPS installation, during SPS configuration specify the Domain\ContentCrawlUserAcc as the content crawler account and Domain\PortalAppPoolUser as the application pool identity for the default portal application pool
3. Create custom "SharePoint Administrators" group
4. Add "Domain\ContentCrawlUserAcc" to the custom "SharePoint Administrators" Group
5. Add "Domain\ServiceAcc" to the custom "SharePoint Administrators" Group
6. Using the Windows SharePoint Services administration Web pages, you should change the Windows SharePoint Services administrator account to the custom "SharePoint Administrators" group
7. Ensure that user cannot change password and password never expires are selected for these user accounts in AD.
8. A good practice is to ensure that "user user cannot change password" and "password never expires" are selected for these user accounts in AD

 Mais si on revient à un mode d'utilisation plus classique de SharePoint, j'ai souvent été confronté non pas à des changements de comptes d'exécution mais à des modifications des pools applicatifs pour des raison diverses et variés.
>>> raison toujours justifiés de capital et urgente (et pourtant si simple aa tenir compte dés l'install non ?)

Et la,c'est le drame : de jolies pages 403 en lieu et place de vos applications SharePoint.

Et non, passez le tout en "Local Service" n'est pas une solution même temporaire comme l'admin domaine d'ailleur ...

A vrai dire, le compte d'execution du pool doit respecter plusieurs groupe NT ainsi que certaines dépendances comme bien décris ici :

Changing the SharePoint Portal Server Application Pool After Installation

Mais le probléme du pool n'est pas entierement résolu ..
>>> si vous chargez un peu trop le même pool avec plein de serveur virtuel WSS, vous pouvez risquer plusieurs déboire comme

• prb de login dans l'explorer view
• prb de perf
• ralentissement intempestif

A priori, si on se référe au guide d'admin, un server WSS front end supporte trés bien jusqu'à 10 virtual server :

http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsb02.mspx?mfr=true
SharePoint Team Services v1.0 supported approximately 1000 virtual servers per server. Windows SharePoint Services supports many fewer virtual servers per front-end Web server (approximately 10). This difference is a result of the use of ASP.NET, which creates a separate set of compiled DLLs for each virtual server

Mais si on veut des configurations plus lourdes, avec moultes server, ou mêmes optimiser un virtual server face à un autre en jouant sur des pools spécifiques ...

La, il faut avouer qu'on ne trouve pas moultes informations, enfin, avant je voulait dire

MindSharp a justement fait un post de référence sur le sujet suite à quelques experiences et souffrances avec leur divers projets SharePoint :

 How Many Virtual Servers Should Be Associated with a Single Application Pool?

“First, you need to do some performance monitoring of the process that runs your SharePoint threads.  This will be the W3WP processes.  You need to *know* how much memory these processes are consuming on average.  There will always be spikes and valleys, but the overall average is what you're after.

Secondly, you need to decide if you're going to run the /3GB switch and perhaps the /USERVA switch to allocate more of the 4GB address space to UM, which is where SharePoint runs.

Thirdly, if you've never run SharePoint and are trying to predict the future without any past history, then your best practice here is to guess based on the numbers that Microsoft has provided.  What do I think?  Well, here's my take on all this, in a nutshell:

1. Do not run more than 10 virtual servers per application pool until you have some performance monitoring experience behind you and you can point to your own numbers which tell you that your app pools can handle more virtual servers

2. Do not plan to run more than 20 virtual servers on a single physical server without adding a second (or more) web server in your farm.  The reason I say this is because if you're running 20 virtual servers, you've got a growing, busy farm and chances are good that your best practice will be to scale out before you scale up. 

3. Always purchase servers with 4GB of RAM to give yourself maximum flexibility in memory allocation for your application pools.  BTW, I also recommend dual proc whenever you can get it.  Most are doing this these days, so this is nothing profound.

4. I recommend running a web garden of 2-3 for each application pool.  When stsadm runs, it locks one of the threads for it's own use.  Having other threads available to service calls during backup/restore operations is necessary in most environments.  In addition, if a thread becomes very busy, the other threads can pick up the slack.”

Source : Mart Muller's Sharepoint Weblog : Number of application pools and virtual servers
>>> Merci encore Bill English !

Bon je crois que l'ensemble a bien été couvert non ?

Mais ne nous arretons pas en si bon chemin !!!

Je voudrais encore mettre en relief, un soucis MAIS vraiment enervant en cas de changement de compte d'execution, il s'agit du service TIMER qui gére une partie du systéme des alertes, les fameux petits mails SharePoint sur les nouveaux documents ou modification de données
>>> Il existe plusieur causes possible à son non fonctionnement, la FAQ WSS les énumere tous avec les workaround associé

FAQ: III.55.1 - Alerts aren't working even if the...

Bien dans mon cas (la derniere fois, c'etait il y a 4 jours), il s'agissait tout simplement de l'antivirus qui considéré que l'envoie de mail par le server venait d'un worms ....

SPSNotification Prevent mass mailing worms from sending mail 

Comme quoi il faut bien rester méfiant dans une installation server. De la sécurité aux comptes d'exécution en passant par les services annexes
>>> Ne négligez rien BIEN au contraire

Renaud Comte aka TheMit