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)

Contenu

Services et comptes de sécurité
Services et comptes de sécurité
Une commande pour tous les services
Passer la distance complète
Déploiement et à l'aide de la solution
Conclusion

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 ?

Ressources de sécurité

Mots de passe Web site Windows SharePoint Services

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.

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.