SharePoint à l'intérieur Intégrer Gestion des droits relatifs à l'information dans SharePoint
Pav Cherny
Téléchargement de code disponible à : ChernySharePoint2009_05.exe(871 KO)
Contenu
AD RMS production et les hiérarchies de pré-production
Topologie de pré-production AD RMS
Configuration du serveur pré-production
Problèmes de configuration de Gestion des droits relatifs à l'information (IRM) de SharePoint
Problèmes spécifiques de preproduction
Compilation et l'enregistrement
Logiciel de protection IRM test
Déploiement de protecteurs de type document personnalisé Gestion des droits relatifs à l'information (IRM)
Conclusion
Microsoft Office SharePoint Server (MOSS) 2007 est livré avec protecteurs de type en fonction de l'infrastructure de gestion des droits relatifs à l'information (IRM). Ces fournir aux utilisateurs de Microsoft Office présente l'avantage de SharePoint intégration avec Active Directory Rights Management Services (RMS Active Directory). Malheureusement, Windows SharePoint Services (WSS) 3.0 n'inclut pas les protecteurs de gestion des droits relatifs à l'information (IRM) de la zone. Cependant, est une solution. Si vous parcourez les exemples d'applications et les extraits de code de la bibliothèque de code MSDN, entre les gems vous trouverez est le Code source protecteurs de format de fichier Microsoft Office, dont Microsoft a publié dans 2008 août. Le code source est fourni avec un non exclusif, dans le monde entier, libres de droits « en tant que-est « licence public de Microsoft (MS-PL). C'est une recherche très parce qu'il signifie que vous pouvez compiler le code source et ajouter ces composants à WSS 3.0 ainsi. De cette façon, vous pouvez bénéficier dans Active Directory en fonction de RMS sécurité et de conformité fonctionnalités dans n'importe quel environnement SharePoint.
Dans cette chronique, J'AI Poursuivons discussion du mois dernier sur SharePoint intégration avec Active Directory RMS en vous montrant comment établir un environnement de développement de pré-production AD RMS, compiler les protecteurs de gestion des droits relatifs à l'information (IRM) et intégrer les composants compilés dans WSS 3.0. Vous n'est pas réellement besoin un environnement de pré-production pour compiler les protecteurs de gestion des droits relatifs à l'information (IRM), mais il est un exercice intéressant car elle met en évidence certains problèmes de configuration AD RMS standard qui vous pouvez rencontrer dans un environnement de production. Vous ne devez devenir un développeur c/c++ pour comprendre les concepts autour de production AD RMS et hiérarchies de pré-production et leur impact sur le déploiement de AD RMS, Microsoft Office et WSS 3.0. Et vous n'avez pas besoin compétences de développement c/c++ pour compiler et tester des logiciels de protection IRM. Rubriques de développement, telles que étendre le code source ou de conversion intégré protecteurs de type protecteurs de type autonomes, sont abordée dans cet article. La seule tâche développeur, que vous rencontrerez concerne la création d'un projet d'installation avec quelques clics de souris pour simplifier le déploiement des composants protecteur compilé sur vos serveurs de production WSS 3.0. Mai matériel associé (disponible dans la page de téléchargement de code de TechNet Magazine) contient des feuilles de calcul et des outils qui vous guident dans le déploiement, la compilation et tester des procédures sur les ordinateurs exécutant la version x 64 de Windows Server 2008.
AD RMS production et les hiérarchies de pré-production
SharePoint, comme toute autre application souhaite utiliser AD RMS pour chiffrer ou déchiffrer le contenu, doit avoir un manifeste signé numériquement qui se connecte à l'application dans la hiérarchie AD RMS. Ce manifeste définit ces modules qui peut et ne peut pas être chargées dans l'espace d'adressage de l'application pour créer un environnement sécurisé et protéger le contenu non chiffré dans la mémoire. Pour un manifeste soit valide, il doit être signé numériquement par une autorité de (certification CA) qui appartient à une hiérarchie de certificat AD RMS. Cela peut être la hiérarchie de production avec une autorité de CERTIFICATION de signature de l'application contrôlée exclusivement par Microsoft, ou il peut être la hiérarchie de pré-production qui permet aux développeurs d'auto-signer application manifestes. Notez qu'un manifeste peut appartenir à une hiérarchie, mais pas les deux. Un manifeste signé par une autorité de CERTIFICATION de production est pas valide dans la hiérarchie de pré-production et inversement car les hiérarchies ont des autorités racine différents. Manifestes d'application sont expliqués en détail dans le KIT DE DÉVELOPPEMENT LOGICIEL RMS ACTIVE DIRECTORY.
Lorsque vous installez le premier serveur RMS d'Active Directory dans une forêt Active Directory, vous définissez implicitement la hiérarchie AD RMS. Par défaut, la routine d'installation AD RMS utilise une autorité de CERTIFICATION automatique d'inscription de service Microsoft DRM, Digital Rights MANAGEMENT Server pour émettre le serveur licence certificat (SLC), qui fait partie de la hiérarchie qui entraîne la racine Microsoft DRM fabrication à la racine de confiance. la figure 1 illustre cette chaîne de certification, dérivé de le SLC d'une production serveur AD RMS. Si vous souhaitez examiner la hiérarchie Active Directory RMS dans votre propre environnement, consultez le matériel associé, qui inclut l'outil de chaîne de certificats Active Directory RMS (CertificateChain.exe).
Figure 1 la AD RMS application signature Certifi cate appartient à la hiérarchie de pré-production AD RMS.
La racine de production Microsoft DRM établit la hiérarchie de production et Microsoft nécessite que tous les fournisseurs de logiciels signer un contrat de licence production comme condition préalable pour obtenir un certificat de production et de signer des applications dans la hiérarchie de production. Le le certificat de production sert à créer et signer les manifestes pour les applications publiées. À des fins de développement, vous devez utiliser un certificat de pré-production à la place. À l'origine, Microsoft également les fournisseurs de logiciels signer un contrat de licence développement pour obtenir un certificat de pré-production requis, mais une clé publique (ISVTier5AppSIgningPubKey.dat), la clé privée (ISVTier5AppSigningPrivKey.dat) et le certificat de pré-production correspondant (ISVTier5AppSignSDK_Client.xml) sont maintenant inclus dans le Kit de développement logiciel RMS Active Directory afin que vous pouvez signer manifestes lors du développement sans avoir à contacter Microsoft. Qu'un côté une note, les clés et les certificats pré-production également figurent dans le package de code source protecteurs de format de fichier Microsoft Office.
Signature d'un manifeste d'application en utilisant le certificat de pré-production implique que vous ne pouvez pas utiliser l'application en association avec un serveur de production AD RMS. figure 1 révèle, l'émetteur racine de la chaîne de certificat d'isvtier5appsignsdk_client.XML est DRM fil racine Microsoft, qui est clairement pas la racine un serveur de production. Vous pouvez examiner isvtier5appsignsdk_client.xml à l'aide de mon outil chaîne de certificats Active Directory RMS. Il suit que vous avez besoin un serveur RMS d'Active Directory avec un autre SLC qui est la racine Microsoft DRM éditeurs de logiciels lors de la racine de confiance (voir figure 1 ). Pour déployer tel un serveur RMS Active Directory, vous devez établir une forêt Active Directory séparée pour votre environnement de développement.
Topologie de pré-production AD RMS
Avec une forêt Active Directory séparée, il est conseillé de donner une pensée à la topologie de pré-production AD RMS. Plus précisément, vous devez décider si pour l'installer AD RMS sur un serveur autonome ou directement sur le contrôleur de domaine. Dans la plupart des cas, un déploiement de contrôleur de domaine est suffisante fins de développement. Notez que ce n'est pas une recommandation pour les environnements de production. Dans un environnement de production, vous devez déployer pas AD RMS sur un contrôleur de domaine parce que le compte d'utilisateur de domaine que vous spécifiez comme identité du réseau AD RMS serait puis nécessitent des autorisations d'administrateur de domaine pour ouvrir une session localement. Ouvrir une session localement est un privilège d'administrateur sur les contrôleurs de domaine. Sur un serveur membre, le compte d'utilisateur de domaine n'a pas besoin autorisations élevées tout. Si vous doutez de la question de contrôleur de domaine dans des environnements de production, lisez article suivant dans blog du Tyler Jason » Le DOs et DON'Ts de RMS." Concernant l'idée de placer RMS sur un contrôleur de domaine, Jason dit, « il est tel une idée incorrecte, que chaque fois que je vois, je veux indiquer la personne à choisir un commutateur et répondent à me derrière le toolshed. »
La question suivante est si vous souhaitez installer WSS 3.0, Office 2007 et Visual Studio 2008 sur le contrôleur de domaine. Ici, vous devez absolument utiliser un serveur distinct, même dans un environnement de développement. Comme avec le problème AD RMS, la configuration de sécurité de WSS 3.0 diffère sur les contrôleurs de domaine en comparaison avec les serveurs membres. À l'aide d'un serveur membre, vous conserver une configuration comparable à un environnement de production WSS 3.0, qui offre des résultats plus fiables lorsque test compilé composants. Bien entendu, vous pouvez conserver le contrôleur de domaine et le serveur membre sur un ordinateur physique unique si vous utilisez Microsoft technologie Hyper-V Server 2008, comme illustré dans la figure 2 . La technologie Hyper-V est la technologie de virtualisation de 64 bits, donc vous pouvez utiliser la version 64 x de Windows Server 2008 sur les deux ordinateurs virtuels. Notez que la technologie Hyper-V Server 2008 n'inclut pas Outils de gestion graphique, mais vous pouvez installer Outils de gestion à distance la technologie Hyper-V Server sur un poste de travail Windows Vista distinct, comme indiqué dans la feuille de calcul Compagnon « Installation de la technologie Hyper-V Server à distance gestion sur une station de travail Windows Vista. »
La figure 2 A à petite échelle AD RMS environnement de développement sur un host. Hyper-V
Configuration du serveur pré-production
Avant d'installer le rôle Active Directory Rights Management Services, vous devez configurer certains paramètres de Registre sur le serveur de sorte que l'installation de AD RMS enrolls le serveur dans la hiérarchie de pré-production. Si vous ignorez cette étape de configuration, vous obtiendrez avec la hiérarchie incorrecte. Gardez à l'esprit que vous ne pouvez pas déplacer un serveur RMS d'Active Directory entre des hiérarchies. Si votre serveur est inscrit dans la hiérarchie de production, vous devez désinstallez AD RMS, supprimer le point de connexion de service AD RMS (SCP) dans Active Directory, configurer le Registre et puis installer le rôle de Active Directory Rights Management Services à nouveau.
la figure 3 répertorie le paramètre de Registre qui détermine la hiérarchie Active Directory RMS sur un ordinateur exécutant Windows Server 2008. Définir le paramètre de hiérarchie sur 1 permet à la hiérarchie de pré-production. Une valeur de 0 ou l'absence de ce paramètre indique que AD RMS doit déployer dans la hiérarchie de production. Paramètres de Registre supplémentaires existent pour la rétrocompatibilité, mais ce n'est pas une exigence dans notre environnement de développement. Pour plus d'informations, voir la rubrique « Configurer le Registre » dans le Kit de développement logiciel RMS Active Directory. Le code suivant peut être enregistré en tant que fichier du Registre (.reg) pour activer la hiérarchie de pré-production sur un serveur RMS d'Active Directory.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS\2.0]
"Hierarchy"=dword:00000001
La figure 3 le client RMS d'Active Directory can’t accéder au serveur AD RMS.
Problèmes de configuration de Gestion des droits relatifs à l'information (IRM) de SharePoint
Le déploiement de serveur RMS d'Active Directory et la configuration est relativement uncomplicated. Trickier est la configuration du serveur membre exécutant WSS 3.0 pour vous connecter SharePoint dans la hiérarchie de pré-production. Vous ne pouvez pas simplement démarrage de l'Administration centrale de SharePoint 3.0, basculer vers l'onglet opérations cliquez sur Gestion des droits relatifs à l'information et puis sélectionnez l'option Utiliser le serveur RMS par défaut spécifié dans Active Directory. Cliquez sur OK créerait uniquement le message d'erreur affiché dans Figure 3 . Comme le message révèle, le client RMS Active Directory (msdrm.dll) est présent ; il est installé avec Windows Server 2008 par défaut, mais le serveur RMS d'Active Directory est inaccessible.
Malheureusement, ni message d'erreur, ni journal de suivi ni journal des événements Applications révéler la nature de cette propriété a la valeur true de ce problème. Une option pour obtenir plus d'informations consiste à accéder à l'URL spécifiée dans le journal de suivi directement dans Internet Explorer, par exemple, https://adrms.litware.com:443/\_wmcs/certification. Vraisemblablement, Internet Explorer signale un « problème avec le certificat de sécurité de ce site Web » si le serveur Active Directory RMS pré-production utilise un certificat auto-signé sockets sécurisés (layer) le client n'est pas confiance. Pour approuver le certificat de serveur SSL, vous devez installer le certificat SSL dans la banque d'autorités de certification racines de confiance sur l'ordinateur local. Assurez-vous que vous placer le certificat dans le magasin physique de l'ordinateur local car vous devez effectuer le certificat disponibles pour les comptes de sécurité SharePoint tout, non seulement votre propre compte d'utilisateur. La feuille de calcul Compagnon « WSS01 déploiement dans l'environnement de pré-production RMS Active Directory » décrit les étapes.
Parfois, il peut être difficile à gérer des certificats auto-signés SSL. SharePoint détermine l'URL du service Active Directory RMS certification Web au moyen de la SCP RMS Active Directory dans Active Directory. Si ce SCP spécifie une URL avec un nom ordinateur hôte qui diffère le nom ordinateur hôte du certificat SSL du serveur, le serveur Web reste non approuvé même après l'installation du certificat SSL dans la banque d'autorités de certification racine de confiance. la figure 4 illustre un scénario courant configuration qui mène à ce problème. La configuration utilise un alias dans l'URL AD RMS qui diffère le nom réel ordinateur hôte. Cela facilite serveur maintenance et incident récupération car vous ne pouvez pas modifier l'URL de RMS Active Directory après le déploiement d'un serveur RMS d'Active Directory, mais l'enregistrement CNAME permet à pointer l'URL sur un autre serveur si nécessaire. Comme les quatre étapes dans la figure 4 indiquent, tout d'abord, le serveur SharePoint recherche l'attribut serviceBindingInformation de la SCP RMS Active Directory pour déterminer l'URL RMS Active Directory. Ensuite, il résout la adrms.litware.com nom ordinateur hôte dc01.litware.com en fonction de l'enregistrement CNAME. SharePoint se connecte ensuite à dc01.litware.com, qui renvoie le certificat SSL pour dc01.litware.com, et ainsi, le conflit d'adresse ne correspondent pas.
La figure 4 certificat SSL le n'est pas approuvé en raison d'une non-concordance de nom.
Pour résoudre ce conflit, émettre un certificat SSL pour adrms.litware.com sur le serveur RMS d'Active Directory à l'aide de l'outil SelfSSL disponible dans le Kit de ressources de services Internet (IIS) 6.0. La feuille de calcul Compagnon « dc01 déploiement dans l'environnement de pré-production RMS Active Directory » inclut également des informations sur le téléchargement et instructions.
Résolution SSL problèmes de certificat est la première étape vers une configuration fonctionne, mais un certificat SSL fiable n'est pas la seule condition requise. Si vous essayez de configurer Gestion des droits relatifs à l'information (IRM) sans premier accorder le compte de sécurité de l'administration centrale pool d'applications lecture et exécution access, vous recevez le message d'erreur que Gestion des droits relatifs à l'information (IRM) ne fonctionnera pas tant que le serveur accorde l'autorisation. Nom du compte de domaine utilisé : WSS01$@litware.com. Vous obtenez cette erreur, car le client doit appeler la méthode Certify du service Web AD RMS certification pour obtenir un droits compte certificat (RAC), qui échoue due to autorisations d'accès manquant dans le fichier ServerCertification.asmx. Par défaut, seul du serveur AD RMS système compte a accès. La solution recommandée consiste à hériter des autorisations le dossier certification ServerCertification.asmx et puis ajoutez les comptes d'ordinateur de vos serveurs WSS 3.0 à lire et exécuter autorisations as well. Cela garantit que tous les comptes de pool d'application potentiel possèdent les autorisations requises. Reportez-vous à la feuille Compagnon « dc01 déploiement dans l'environnement de pré-production RMS Active Directory » pour détails.
Problèmes spécifiques de preproduction
À ce stade, l'infrastructure de gestion des droits relatifs à l'information (IRM) doit être fonctionnel, sauf lorsque sont dans un environnement de pré-production. N'oubliez pas que client AD RMS et les applications doivent utiliser une chaîne de certificat différent ici. Si vous essayez configurer l'infrastructure de gestion des droits relatifs à l'information (IRM) dans la configuration d'origine, vous recevez l'erreur « le requis Windows Rights Management client est présent mais n'a pas pu être configuré correctement », et le journal de suivi contient un autre indice utile « l'ordinateur n'a pas activé. » Ceci est un indicateur qui le client RMS Active Directory se trouve toujours dans la hiérarchie de production. Vous pouvez vérifier dans l'Éditeur du Registre. Vérifiez les clés de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy et HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy. Une valeur égale à 0 désigne la hiérarchie de production. Modification de ces valeurs sur 1 active la hiérarchie de pré-production. Le code suivant indique un fichier .reg pour appliquer facilement les modifications de configuration.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM]
"Hierarchy"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\uDRM]
"Hierarchy"=dword:00000001
Cependant, ne soyez pas surpris que ne sont les modifications du Registre pas effet immédiatement. L'erreur reste car le client RMS Active Directory a déjà généré un certificat d'ordinateur incorrect lors de la première tentative échoue et continue à utiliser ce certificat. Sur votre serveur WSS, ouvrez le dossier C:\ProgramData\Microsoft\DRM\Server et supprimez tous ses sous-dossiers et fichiers. Vous souhaiterez peut-être également vérifier le dossier %LOCALAPPDATA%\Microsoft. Si elle inclut un sous-dossier \DRM, supprimer le sous-dossier, car il stocke les licences client qui ne sont pas utilisables plus dans la hiérarchie de pré-production. Le client RMS Active Directory recrée ces sous-dossiers et les certificats des fichiers dans les que nécessaire.
Passez revenir à l'administration centrale de SharePoint 3.0, essayez à nouveau configurer Gestion des droits relatifs à l'information (IRM) et ne pas laisser la prochaine message d'erreur duperie : il est le même message d'erreur comme avant, mais la raison de l'erreur est en fait différente. Vérification que le journal de suivi et vous trouverez que » A un problème est lors créer et d'initialisation un environment… sécurisé » C'est maintenant un problème manifest ! SharePoint utilise toujours le manifeste de production en tant que le révèle outil chaîne de certificats Active Directory RMS si vous ouvrez le fichier Stsprtid.xml situé dans le dossier %PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\12\BIN (voir figure 5 ).
La figure 5 le manifeste de production doesn’t travailler dans la hiérarchie de pré-production.
Vous devez supprimer (ou renommer) la production Stsprtid.xml de fichiers, générer un nouveau manifeste en utilisant l'outil Genmanifest.exe inclus dans le AD RMS SDK ainsi que dans le package de téléchargement protecteurs de format de fichier Microsoft Office et redémarrez IIS. Le package de téléchargement est fourni même avec un fichier de configuration SharePoint (sharepoint.mcf) et de lot de fichiers (genmft.bat et genmft.64.bat) pour simplifier cette tâche. Cependant, le fichier de commandes pour les environnements de 64 bits uniquement connecte les applications Microsoft Office dans la hiérarchie de pré-production et ignore SharePoint. Pour vous connecter sur un serveur 64 bits dans SharePoint, utiliser le fichier Sharepoint.bat du support associé ou utilisez l'outil Genmanifest.exe directement. La syntaxe de cette commande est
Genmanifest.exe -chain isvtier5appsignsdk_client.xml sharepoint.mcf
Stsprtid.xml
Consultez également la page Genmanifest.exe à .aspx msdn.microsoft.com/en-us/library/aa362621 (VS.85).
Compilation et l'enregistrement
Avoir remplacé le fichier manifest de SharePoint, vous pouvez effectuer avec succès la configuration de Gestion des droits relatifs à l'information (IRM). Nous avez terminé le plus difficile. Il est maintenant temps de récolter les récompenses par compiler et tester les composants du logiciel de protection. C'est une opération simple. Le code source est fourni avec projets Visual Studio 2005 que vous pouvez mettre à niveau vers Visual Studio 2008 sans problème. Conserve toutefois N'oubliez pas que vous travaillez sur un serveur 64 bits. Les projets Visual Studio sont configurés pour un environnement 32 bits. Vous devez modifier cette configuration pour compiler les composants de la plate-forme x 64, comme illustré dans la figure 6 . Voir également la feuille de calcul Compagnon « Compiling, test et protecteurs de format de fichier déploiement Microsoft Office. »
La figure 6 pour utiliser des logiciels de protection IRM sur un serveur WSS 64 bits, de compiler le code source pour la plate-forme x 64.
Visual Studio s'occupe de l'enregistrement du composant COM en temps de compilation, mais vous devez toujours enregistrer les protecteurs de gestion des droits relatifs à l'information (IRM) dans WSS 3.0. Enregistrer les composants avec leur identificateur de classe (CLSID) sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\IrmProtectors. Ici, est un fichier Registre qui effectue cette étape :
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server
Extensions\12.0\IrmProtectors]
"{2E4402B2-F2DA-4BC8-BB2C-41BECF0BDDDB}"="MsoIrmProtector"
"{81273702-956F-4CBD-9B16-43790558EE29}"="OpcIrmProtector"
Vous pouvez également vérifier le contenu du fichier IrmProtectors.reg dans le support associé. Il contient des clés supplémentaires à titre informatif. J'inclus ces clés car les protecteurs de gestion des droits relatifs à l'information (IRM) de MOSS 2007 ont des entrées similaires. La seule différence est que les protecteurs de type MOSS utilisent réellement leurs paramètres alors que notre logiciels de protection IRM utilisent des valeurs codée en dur au lieu de cela.
Logiciel de protection IRM test
Maintenant que WSS est conscient de logiciels de protection l'IRM, vous pouvez redémarrer IIS, ouvrez votre site SharePoint, configurer une stratégie AD RMS pour une bibliothèque de documents, créer, télécharger, puis télécharger des documents pour vérifier que les protecteurs de gestion des droits relatifs à l'information (IRM) fonctionnent. Toutefois, cela peut être long si vous êtes struggling des problèmes de l'enregistrement COM base. Par exemple, si vous avez oublié d'activer la x 64 - bits plate-forme dans Visual Studio, le processus de compilation terminée sans erreur, mais l'enregistrement COM reste incomplète, WSS ne peut pas charge les protecteurs de type et vous ne pourrez pas tester protection AD RMS. Vous pouvez gagner du temps en vérifiant l'inscription COM tout d'abord et exécution des tests de SharePoint uniquement si la vérification de l'enregistrement indique la réussite complète. la figure 7 montre un script simple pour vérifier l'inscription COM. Il suffit charge les composants COM et affiche une boîte de message avec les résultats.
On Error Resume Next
set MsoIrmProtector=NOTHING
set OpcIrmProtector=NOTHING
set MsoIrmProtector=CreateObject("MsoIrmProtector.MsoIrmProtector")
set OpcIrmProtector=CreateObject("OpcIrmProtector.OpcIrmProtector")
IF MsoIrmProtector IS NOTHING AND OpcIrmProtector IS NOTHING THEN
Wscript.Echo "Unable to load MsoIrmProtector and OpcIrmProtector."
ELSEIF MsoIrmProtector IS NOTHING THEN
Wscript.Echo "OpcIrmProtector loaded successfully, but
unable to load MsoIrmProtector."
ELSEIF OpcIrmProtector IS NOTHING THEN
Wscript.Echo "MsoIrmProtector loaded successfully, but
unable to load OpcIrmProtector."
ELSE
Wscript.Echo "MsoIrmProtector and OpcIrmProtector loaded
successfully."
END IF
Logiciels de la figure 7 Création que protection IRM sont correctement enregistrés en tant que composants COM avant de tester les protecteurs de type dans SharePoint.
On Error Resume Next
set MsoIrmProtector=NOTHING
set OpcIrmProtector=NOTHING
set MsoIrmProtector=CreateObject("MsoIrmProtector.MsoIrmProtector")
set OpcIrmProtector=CreateObject("OpcIrmProtector.OpcIrmProtector")
IF MsoIrmProtector IS NOTHING AND OpcIrmProtector IS NOTHING THEN
Wscript.Echo "Unable to load MsoIrmProtector and OpcIrmProtector."
ELSEIF MsoIrmProtector IS NOTHING THEN
Wscript.Echo "OpcIrmProtector loaded successfully, but
unable to load MsoIrmProtector."
ELSEIF OpcIrmProtector IS NOTHING THEN
Wscript.Echo "MsoIrmProtector loaded successfully, but
unable to load OpcIrmProtector."
ELSE
Wscript.Echo "MsoIrmProtector and OpcIrmProtector loaded
successfully."
END IF
Avec l'enregistrement correct paramètres, le composant OpcIrmProtector de formats de document Office 2007 est immédiatement fonctionnel. Toutefois, le composant MsoIrmProtector de formats Office héritées a un besoin supplémentaire. Le dossier qui contient le MsoIrmProtector.dll doit également contenir un sous-dossier \1033 avec des fichiers de modèle. Les fichiers de modèle sont fournis avec le code source et sont situés dans le dossier \MsoIrmProtector\Templates. Vous devez copier ces fichiers dans le sous-dossier \1033 afin que le composant MsoIrmProtector pouvez les inclure dans les documents RMS–protected Active Directory pour assurer la compatibilité avec applications Office qui ne prennent pas en charge AD RMS, tels que Office 2000 et Office XP. Dans le cas contraire, vous ne pourrez pas ouvrir des documents Office hérités. Par exemple, vous recevrez l'erreur affichée dans la figure 8 lorsque vous essayez de créer un nouveau document Word dans une bibliothèque de documents.
La figure 8 que Word can’t lire ce document car la MsoIrmProtector est impossible de créer le document au format approprié sans les fichiers de modèle.
Déploiement de protecteurs de type document personnalisé Gestion des droits relatifs à l'information (IRM)
Félicitations ! Vous avez correctement créé, enregistré et testé personnalisés protecteurs de gestion des droits relatifs à l'information (IRM) pour WSS 3.0 vous. Maintenant, comment puis-je vous procurer ces composants sur vos serveurs de production WSS 3.0 ? Après tout, vous devez installer les protecteurs de gestion des droits relatifs à l'information (IRM) sur vos serveurs si vous souhaitez utiliser ces composants dans votre environnement de production. Effectuer le déploiement manuellement serait fastidieux et sujette aux erreurs. Il est préférable créer un projet d'installation, inclure les DLL et les documents de modèle dans la structure du fichier requis, importer les paramètres de Registre nécessaires pour intégrer les composants WSS 3.0 et ensuite utiliser le fichier Microsoft Windows Installer (.msi) obtenu pour le déploiement.
Il est également conseillé de tester le déploiement sur un système de référence. Entre autres choses, ces tests révèle importants conditions préalables que vous devez disposer avant de déployer les composants. En particulier, Visual Studio 2008 ajoute des dépendances de Microsoft .NET Framework 3.5 SP1 à Setup.exe et les composants de protecteur nécessitent un package redistribuable Microsoft Visual C++. Ceci est un impératif standard pour les fichiers exécutables et DLL compilé avec Visual C++. Vérifiez que le package redistribuable correspond à la version que vous utilisez dans votre environnement de développement. Par exemple, si vous utilisez Visual Studio 2008 SP1, puis déployer le Microsoft Visual C++ 2008 SP1 Redistributable Package (x 64). La feuille de calcul Compagnon "test du déploiement Microsoft Office fichier format protecteurs de type » montre comment tester le déploiement logiciel de protection IRM sur un seul serveur.
Conclusion
Protection IRM à en fonction des documents Microsoft Office utilisé pour demander de MOSS 2007, mais à compiler le les protecteurs de format de fichier Microsoft Office code source disponible dans la bibliothèque de code MSDN vous pouvez intégrer appropriée IRM protecteur de composants dans WSS 3.0 ainsi. Vous pouvez également modifier le code source permettant d'implémenter des fonctionnalités personnalisées si vous avez compétences c/c++ et que vous avez déployé SharePoint dans un environnement de pré-production AD RMS. Gardez à l'esprit que les modifications apportées affectent toutes les bibliothèques de documents RMS–enabled Active Directory. Je recommande de laisser le code source non modifié et la vérification de la galerie de code MSDN de façon régulière pour mises à jour et peut-être nouvelles versions avec les fonctionnalités supplémentaires, sauf si vous êtes un développeur recherchez un exemple idéal pour intégrer vos propres applications avec l'infrastructure de gestion des droits relatifs à l'information (IRM). Dans ce cas, le code source est un excellent point de départ.
N'oubliez pas que Microsoft n'a pas concevoir l'infrastructure de gestion des droits relatifs à l'information (IRM) pour protéger les éléments de contenu dans les bases de données SharePoint. Vous ne devez pas modifier les routines de décryptage, par exemple, ou vos utilisateurs SharePoint ne soient mesure d'ouvrir les documents parce que l'infrastructure de gestion des droits relatifs à l'information (IRM) n'octroie que le compte du pool d'applications et l'utilisateur actuel autorisations d'accès AD RMS lorsque la protection du contenu. Gardez également à l'esprit que certains logiciels de protection nécessitent des autres logiciels de protection créer un système entièrement fonctionnel. Par exemple, le protecteur MsoIrmProtector pour les anciens formats de document Office et le protecteur OpcIrmProtector pour les formats d'Office 2007 appartiennent ensemble. Si vous avez déployé le protecteur MsoIrmProtector sans le OpcIrmProtector, un utilisateur de Word 2007 peut créer un nouveau document à l'aide le modèle de contenu template.doc dans SharePoint, base de données lors de l'enregistrement du fichier en tant que Doc1.docx. Le protecteur MsoIrmProtector aux AD RMS protection template.doc donc Doc1.docx serait finissent dans la bibliothèque de documents dans formulaire rights-protected car il n'existe aucun protecteur OpcIrmProtector pour déchiffrer le contenu à télécharger. Le compte du pool d'applications et l'utilisateur actuel est restent les entités uniquement peuvent ouvrir ce document. Il existe d'autres méthodes pour protéger des documents dans SharePoint des bases de données contenus dans AD RMS, comme en utilisant l'interface COM ISPExternalBinaryStorage.
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.