Sugerir tradução
 
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Maio 2009 >  Estender o WSS 3.0 para proteger documentos do ...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
Inside SharePoint Integrate Information Rights Management into SharePoint
Pav Cherny

Code download available at: ChernySharePoint2009_05.exe (871 KB)

Microsoft Office SharePoint Server (MOSS) 2007 ships with protectors based on the Information Rights Management (IRM) framework. These provide Microsoft Office users with the benefit of SharePoint integration with Active Directory Rights Management Services (AD RMS). Unfortunately, Windows SharePoint Services ( WSS ) 3.0 does not include IRM protectors out of the box. However, there is a solution. If you browse the sample applications and code snippets on the MSDN Code Gallery, among the gems you'll find is the Microsoft Office File Format Protectors source code , which Microsoft published in August 2008. The source code comes with a non-exclusive, worldwide, royalty-free "as-is" Microsoft Public License (Ms-PL). This is a great find because it means you can compile the source code and add these components to WSS 3.0 as well. In this way, you can benefit from AD RMS-based security and compliance features in any SharePoint environment.
In this column, I continue last month's discussion about SharePoint integration with AD RMS by showing you how to establish an AD RMS preproduction development environment, compile the IRM protectors, and integrate the compiled components into WSS 3.0. You don't actually need a preproduction environment to compile the IRM protectors, but it's an interesting exercise because it highlights some typical AD RMS configuration issues that you might encounter in a production environment. You don't need to be a C/C++ developer to understand the concepts around AD RMS production and preproduction hierarchies and how they affect the deployment of AD RMS, Microsoft Office, and WSS 3.0. And you don't need C/C++ development skills to compile and test IRM protectors. Developer topics, such as extending the source code or converting integrated protectors into autonomous protectors, are beyond the scope of this article. The only developer task you will encounter concerns the creation of a setup project with a few mouse clicks to simplify the deployment of the compiled protector components on your WSS 3.0 production servers. The May companion material (available on the code download page of TechNet Magazine) includes worksheets and tools that guide you through the deployment, compilation, and test procedures on computers running the x64 version of Windows Server 2008.

AD RMS Production and Preproduction Hierarchies
SharePoint, like any other application that wants to use AD RMS to encrypt or decrypt content, must have a digitally signed manifest that signs the application into the AD RMS hierarchy. This manifest defines those modules that can and cannot be loaded into the address space of the application in order to create a secure environment and protect the unencrypted content in memory. For a manifest to be valid, it must be digitally signed by a certificate authority (CA) that belongs to an AD RMS certificate hierarchy. This can be the production hierarchy with an application-signing CA controlled exclusively by Microsoft, or it can be the preproduction hierarchy that enables developers to self-sign application manifests. Note that a manifest can belong to either hierarchy, but not both. A manifest signed by a production CA is invalid in the preproduction hierarchy and vice versa because the hierarchies have different root authorities. Application manifests are covered in detail in the AD RMS SDK .
When you install the first AD RMS server in an Active Directory forest, you implicitly establish the AD RMS hierarchy. By default, the AD RMS installation routine uses a Microsoft DRM Server Self Enrollment Service CA to issue the Server Licensor Certificate (SLC), which is part of the hierarchy that leads back to the Microsoft DRM Production Root at the root of trust. Figure 1 shows this certification chain, derived from the SLC of a production AD RMS server. If you want to examine the AD RMS hierarchy in your own environment, check out the companion material, which includes the AD RMS Certificate Chain tool (CertificateChain.exe).
Figure 1 The AD RMS Application Signing Certifi cate belongs to the AD RMS preproduction hierarchy.
The Microsoft DRM Production Root establishes the production hierarchy, and Microsoft requires all software vendors to sign a Production License Agreement as a prerequisite to obtaining a production certificate and signing applications into the production hierarchy. The purpose of the production certificate is to create and sign manifests for released applications. For development purposes, you should use a preproduction certificate instead. Originally, Microsoft also required software vendors to sign a Development License Agreement to obtain a preproduction certificate, but a public key (ISVTier5AppSIgningPubKey.dat), private key (ISVTier5AppSigningPrivKey.dat), and the corresponding preproduction certificate (ISVTier5AppSignSDK_Client.xml) are now included in the AD RMS SDK so that you can sign manifests during development without having to contact Microsoft. As a side note, the keys and preproduction certificate are also included in the Microsoft Office File Format Protectors source code package.
Signing an application manifest using the preproduction certificate implies that you can't use the application in conjunction with a production AD RMS server. As Figure 1 reveals, the root issuer in the certificate chain of isvtier5appsignsdk_client.xml is Microsoft DRM ISV Root, which is clearly not the root of a production server. You can examine isvtier5appsignsdk_client.xml using my AD RMS Certificate Chain tool. It follows that you need an AD RMS server with a different SLC that has the Microsoft DRM ISV Root at the root of trust (see Figure 1). To deploy such an AD RMS server, you must establish a separate Active Directory forest for your development environment.

AD RMS Preproduction Topology
With a separate Active Directory forest, it is a good idea to give some thought to the AD RMS preproduction topology. Specifically, you must decide whether you want to install AD RMS on a standalone server or directly on the domain controller. In most cases, a domain controller deployment is sufficient for development purposes. Note that this is not a recommendation for production environments. In a production environment, you must not deploy AD RMS on a domain controller because the domain user account that you specify as the AD RMS network identity would then require domain administrator permissions to log on locally. Logging on locally is an administrator privilege on domain controllers. On a member server, the domain user account doesn't need elevated permissions at all. If you are unsure about the domain controller question in production environments, read Jason Tyler's blog article " The DOs and DON'Ts of RMS ." Regarding the idea of putting RMS on a domain controller, Jason says, "This is such a bad idea, that every time I see it, I want to go tell the person to go pick a switch and meet me behind the toolshed."
The next question is whether to install WSS 3.0, Office 2007, and Microsoft Visual Studio 2008 on the domain controller. Here you should definitely use a separate server, even in a development environment. As with the AD RMS issue, the security configuration of WSS 3.0 differs on domain controllers in comparison with member servers. By using a member server, you retain a configuration comparable to a WSS 3.0 production environment, which delivers more reliable results when testing compiled components. Of course, you can keep the domain controller and the member server on a single physical computer if you use Microsoft Hyper-V Server 2008, as illustrated in Figure 2. Hyper-V is 64-bit virtualization technology, so you can use the x64 edition of Windows Server 2008 on both virtual machines. Note that Hyper-V Server 2008 doesn't include graphical management tools, but you can install Hyper-V Server Remote Management Tools on a separate Windows Vista workstation, as outlined in the companion worksheet "Installing Hyper-V Server Remote Management on a Windows Vista Workstation."
Figure 2 A small-scale AD RMS development environment on a Hyper-V host.

Preproduction Server Configuration
Before installing the Active Directory Rights Management Services role, you must configure certain registry settings on the server so that the AD RMS installation enrolls the server in the preproduction hierarchy. If you skip this configuration step, you'll end up with the wrong hierarchy. Keep in mind that you cannot move an AD RMS server between hierarchies. If your server is enrolled in the production hierarchy, you must uninstall AD RMS, delete the AD RMS service connection point (SCP) in Active Directory, configure the registry, and then install the Active Directory Rights Management Services role again.
Figure 3 lists the registry setting that determines the AD RMS hierarchy on a computer running Windows Server 2008. Setting the Hierarchy parameter to 1 enables the preproduction hierarchy. A value of 0 or the absence of this parameter indicates that AD RMS should deploy in the production hierarchy. Additional registry settings exist for backward compatibility, but this is not a requirement in our development environment. For details, see the topic "Configure the Registry" in the AD RMS SDK. The following code can be saved as a registry (.reg) file to enable the preproduction hierarchy on an AD RMS server.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS\2.0]
"Hierarchy"=dword:00000001
Figure 3 The AD RMS client can’t access the AD RMS server.

SharePoint IRM Configuration Issues
The AD RMS server deployment and configuration is relatively uncomplicated. Trickier is the configuration of the member server running WSS 3.0 to sign SharePoint into the preproduction hierarchy. You can't just start SharePoint 3.0 Central Administration, switch to the Operations tab, click on Information Rights Management, and then select the option Use the default RMS server specified in Active Directory. Clicking OK would result only in the error message displayed in Figure 3. As the message reveals, the AD RMS client (msdrm.dll) is present; it is installed with Windows Server 2008 by default, but the AD RMS server is inaccessible.
Unfortunately, neither error message, nor trace log, nor application event log reveal the true nature of the issue. One option to get more detailed information is to access the URL specified in the Trace log directly in Internet Explorer, for example, https://adrms.litware.com:443/_wmcs/certification. Most likely, Internet Explorer reports a "problem with this website's security certificate" if the preproduction AD RMS server uses a self-signed secure sockets layer (SSL) certificate that the client doesn't trust. To trust the server's SSL certificate, you must install the SSL certificate in the Trusted Root Certification Authorities store on the local computer. Make sure you place the certificate in the physical store of the local computer because you must make the certificate available to all SharePoint security accounts, not just your own user account. The companion worksheet "Deploying WSS01 in the AD RMS Preproduction Environment" describes the steps.
Sometimes, it can be difficult to deal with self-signed SSL certificates. SharePoint determines the URL of the AD RMS Certification Web Service by means of the AD RMS SCP in Active Directory. If that SCP specifies a URL with a host name that differs from the host name in the Web server's SSL certificate, the Web server remains not trusted even after you install the SSL certificate in the Trusted Root Certification Authorities store. Figure 4 shows a common configuration scenario that leads to this issue. The configuration uses an alias in the AD RMS URL that differs from the actual host name. This facilitates server maintenance and disaster recovery because you can't change the AD RMS URL after the deployment of an AD RMS server, yet the CNAME record enables you to point the URL at a different server if necessary. As the four steps in Figure 4 indicate, first, the SharePoint server looks up the serviceBindingInformation attribute of the AD RMS SCP to determine the AD RMS URL. Next, it resolves the host name adrms.litware.com to dc01.litware.com based on the CNAME record. SharePoint then connects to dc01.litware.com, which returns the SSL certificate for dc01.litware.com, and this causes the mismatched address conflict.
Figure 4 The SSL certificate is not trusted due to a name mismatch.
To solve this conflict, issue an SSL certificate for adrms.litware.com on the AD RMS server by using the SelfSSL tool available in the Internet Information Services (IIS) 6.0 Resource Kit. The companion worksheet "Deploying DC01 in the AD RMS Preproduction Environment" includes download information and step-by-step instructions.
Fixing SSL certificate issues is the first step toward a functioning configuration, but a trusted SSL certificate isn't the only requirement. If you attempt to configure IRM without first granting the security account of the Central Administration application pool read and execute access, you receive the error message IRM will not work until the server grants permission. Domain account name used: WSS01$@litware.com. You get this error because the client must call the Certify method of the AD RMS Certification Web Service to obtain a Rights Account Certificate (RAC), which fails due to missing access permissions to the ServerCertification.asmx file. By default, only the AD RMS server's SYSTEM account has access. The recommended solution is to inherit permissions from the certification folder on ServerCertification.asmx and then add the computer accounts of your WSS 3.0 server(s) with read and execute permissions as well. This ensures that all potential application pool accounts have the required permissions. See the companion worksheet "Deploying DC01 in the AD RMS Preproduction Environment" for details.

Preproduction-Specific Issues
At this point, the IRM framework should be functional, except when you are in a preproduction environment. Remember that AD RMS client and applications must use a different certificate chain here. If you attempt to configure the IRM framework in the original configuration, you receive the error "The required Windows Rights Management client is present but could not be configured properly," and the trace log includes another useful hint, "The machine was not activated." This is an indicator that the AD RMS client is still in the production hierarchy. You can verify this in Registry Editor. Check the registry keys HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy. A value of 0 designates the production hierarchy. Changing these values to 1 activates the preproduction hierarchy. The following code lists a .reg file to apply the configuration changes conveniently.
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
However, don't be surprised that the registry changes aren't effective immediately. The error remains because the AD RMS client has already generated an incorrect machine certificate during the first unsuccessful attempt and continues to use this certificate. On your WSS server, open the C:\ProgramData\Microsoft\DRM\Server folder and delete all subfolders and files. You might also want to check the %LOCALAPPDATA%\Microsoft folder. If it includes a \DRM subfolder, delete the subfolder because it stores client licenses that aren't usable anymore in the preproduction hierarchy. The AD RMS client recreates these subfolders and certificate files within them as necessary.
Switching back to SharePoint 3.0 Central Administration, try again to configure IRM and don't let the next error message fool you: It's the same error message as before but the error reason is actually different. Check the trace log and you'll find that "There was a problem while creating and initializing a secure environment…" Now this is a manifest issue! SharePoint still uses the production manifest as the AD RMS Certificate Chain tool reveals if you open the Stsprtid.xml file located in the %PROGRAMFILES%\Common Files\Microsoft Shared\Web Server Extensions\12\Bin folder (see Figure 5).
Figure 5 The production manifest doesn’t work in the preproduction hierarchy.
You must delete (or rename) the production Stsprtid.xml file, generate a new manifest by using the Genmanifest.exe tool included in the AD RMS SDK as well as in the Microsoft Office File Format Protectors download package, and then restart IIS. The download package even comes with a SharePoint configuration file (sharepoint.mcf) and batch files (genmft.bat and genmft.64.bat) to simplify this task. Still, the batch file for 64-bit environments only signs Microsoft Office applications into the preproduction hierarchy and skips SharePoint. To sign in SharePoint on a 64-bit server, use the Sharepoint.bat file included in the companion material or use the Genmanifest.exe tool directly. The command syntax is
Genmanifest.exe -chain isvtier5appsignsdk_client.xml sharepoint.mcf
 Stsprtid.xml
See also the Genmanifest.exe page at msdn.microsoft.com/en-us/library/aa362621(VS.85).aspx.

Compilation and Registration
Having replaced the SharePoint manifest file, you can successfully complete the IRM configuration. We have finished the hard part. Now it's time to reap the rewards by compiling and testing the protector components. This is a straightforward undertaking. The source code comes with Visual Studio 2005 projects that you can upgrade to Visual Studio 2008 without problems. However, keep in mind that you are working on a 64-bit server. The Visual Studio projects are configured for a 32-bit environment. You must change this configuration to compile the components for the x64 platform, as illustrated in Figure 6. See also the companion worksheet "Compiling, Testing, and Deploying Microsoft Office File Format Protectors."
Figure 6 To use IRM protectors on a 64-bit WSS server, compile the source code for the x64 platform.
Visual Studio takes care of the COM component registration at build time, but you still must register the IRM protectors in WSS 3.0. Register the components with their class identifiers (CLSID) under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\IrmProtectors. Here is a registry file that accomplishes this step:
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"
You can also check the content of the IrmProtectors.reg file in the companion material. It contains additional keys for informational purposes. I included these keys because the IRM protectors of MOSS 2007 have similar entries. The only difference is that MOSS protectors actually use their settings while our IRM protectors use hard-coded values instead.

IRM Protector Testing
Now that WSS is aware of the IRM protectors, you can restart IIS, open your SharePoint site, configure an AD RMS policy for a document library, and then create, upload, and download documents to verify that the IRM protectors work. However, this can be time-consuming if you are struggling with basic COM registration issues. For example, if you forgot to activate the x64-bit platform in Visual Studio, the compilation process completes without errors, but the COM registration remains incomplete, WSS cannot load the protectors, and you will not be able to test AD RMS protection. You can save time by checking the COM registration first and performing tests in SharePoint only if the registration check shows complete success. Figure 7 shows a basic script to check the COM registration. It simply loads the COM components and displays a message box with the results.
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
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
With proper registration settings, the OpcIrmProtector component for Office 2007 document formats is immediately functional. However, the MsoIrmProtector component for legacy Office formats has an additional requirement. The folder that contains the MsoIrmProtector.dll must also contain a \1033 subfolder with template files. The template files come with the source code and are located in the \MsoIrmProtector\Templates folder. You must copy these files into the \1033 subfolder so that the MsoIrmProtector component can include them into AD RMS–protected documents for backward compatibility with Office applications that do not support AD RMS, such as Office 2000 and Office XP. Otherwise, you will not be able to open legacy Office documents. For example, you'll receive the error displayed in Figure 8 when you attempt to create a new Word document in a document library.
Figure 8 Word can’t read this document because the MsoIrmProtector is unable to create the document in proper format without the template files.

Deploying Custom IRM Document Protectors
Congratulations! You have successfully built, registered, and tested custom IRM protectors for WSS 3.0. Now, how do you get these components onto your WSS 3.0 production servers? After all, you must install the IRM protectors on all your servers if you want to use these components in your production environment. Performing the deployment manually would be tedious and error-prone. It's better to build a Setup project, include the DLLs and template documents within the required file structure, import the necessary registry settings to integrate the components into WSS 3.0, and then use the resulting Microsoft Windows Installer (.msi) file for deployment.
It is also a good idea to test the deployment on a reference system. Among other things, such testing reveals important prerequisites you must meet before deploying the components. Specifically, Visual Studio 2008 adds Microsoft .NET Framework 3.5 SP1 dependencies to Setup.exe and the protector components require a Microsoft Visual C++ redistributable package. This is a standard requirement for executables and DLLs compiled with Visual C++. Make sure the redistributable package matches the version you use in your development environment. For example, if you use Microsoft Visual Studio 2008 SP1, then deploy the Microsoft Visual C++ 2008 SP1 Redistributable Package (x64) . The companion worksheet "Testing the Microsoft Office File Format Protectors Deployment" demonstrates how to test the IRM protector deployment on a single server.

Conclusion
IRM-based protection of Microsoft Office documents used to require MOSS 2007, but by compiling the Microsoft Office File Format Protectors source code available on the MSDN Code Gallery you can integrate appropriate IRM protector components into WSS 3.0 as well. You can also modify the source code to implement custom features if you have C/C++ skills and have deployed SharePoint in an AD RMS preproduction environment. Keep in mind that your modifications affect all AD RMS–enabled document libraries. I recommend leaving the source code unaltered and checking the MSDN Code Gallery on a regular basis for updates and perhaps new versions with additional features, unless you are a developer looking for a great sample to integrate your own applications with the IRM framework. In this case, the source code is an excellent starting point.
Remember that Microsoft did not design the IRM framework to protect content items in SharePoint databases. You should not change the decryption routines, for example, or your SharePoint users might not be able to open the documents because the IRM framework grants only the application pool account and the current user AD RMS access permissions when protecting the content. Also keep in mind that certain protectors require other protectors to create a fully functional system. For example, the MsoIrmProtector protector for legacy Office document formats and the OpcIrmProtector protector for Office 2007 formats belong together. If you deployed the MsoIrmProtector protector without the OpcIrmProtector, a Word 2007 user might create a new document by using the template.doc content template in SharePoint, while saving the file as Doc1.docx. The MsoIrmProtector protector applies AD RMS protection to template.doc, so Doc1.docx would end up in the document library in rights-protected form because there is no OpcIrmProtector protector to decrypt the content upon upload. The application pool account and the current user would remain the only entities that can open this document. There are other ways to protect documents in SharePoint content databases through AD RMS, such as by using the ISPExternalBinaryStorage COM interface.

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.

Dentro do SharePoint Integrar o gerenciamento de direitos de informação ao SharePoint
Pav Cherny

Download do código disponível em: ChernySharePoint2009_05.exe (871 KB)

Microsoft Office SharePoint Server (MOSS) 2007 vem com protetores baseia a estrutura de gerenciamento de direitos de informação (IRM). Eles fornecem aos usuários do Microsoft Office o benefício da integração do SharePoint com o Active Directory Rights Management Services (RMS do AD). Infelizmente, o Windows SharePoint Services (WSS) 3.0 não inclui o protetor IRM sair da caixa de. No entanto, há uma solução. Se você procurar os aplicativos de exemplo e trechos de código na Galeria de código do MSDN, entre o tudo você verá é o Código-fonte protetores de formato de arquivo do Microsoft Office , que a Microsoft publicou no dia de 2008. O código-fonte vem com um não-exclusivo, no mundo inteiro, de royalties " como-é " licença pública do Microsoft (MS-PL). Isso é uma localização excelente porque significa você pode compilar o código-fonte e adicionar esses componentes para o WSS 3.0 também. Dessa forma, você pode se beneficiar dos AD RMS-com base em segurança e conformidade recursos em qualquer ambiente do SharePoint.
Nesta coluna, eu continuar discussão do mês passado sobre a integração do SharePoint com o RMS do AD, mostrando a você como estabelecer um ambiente de desenvolvimento de pré-produção RMS do AD, compilar o protetor IRM e integrar os componentes compilados WSS 3.0. Você não precisa realmente um ambiente de pré-produção para compilar o protetor IRM, mas é um exercício interessante porque ele realça alguns problemas de configuração de RMS do AD típicos que você pode encontrar em um ambiente de produção. Você não precisará ser um desenvolvedor de c/c++ para entender os conceitos em torno de produção RMS do AD e hierarquias de pré-produção e como eles afetam a implantação de RMS do AD, o Microsoft Office e o WSS 3.0. E você não precisa técnica de desenvolvimento do C/C ++ para compilar e testar protetor IRM. Tópicos de desenvolvedor, como estender o código-fonte ou converter integrado protetores protetores autônomos, são além do escopo deste artigo. A única tarefa desenvolvedor que você encontrará se refere a criação de um projeto de instalação com alguns cliques do mouse para simplificar a implantação dos componentes de protetor compilado em seus servidores de produção do WSS 3.0. O pode material complementar (disponível na página de download do código do TechNet Magazine) inclui ferramentas que orientam a implantação, compilação e testar procedimentos em computadores que executam a versão x 64 do Windows Server 2008 e planilhas.

Produção de RMS do AD e hierarquias de pré-produção
SharePoint, como qualquer outro aplicativo que deseja usar o RMS do AD para criptografar ou descriptografar o conteúdo, deve ter um manifesto assinado digitalmente que assina o aplicativo para a hierarquia de RMS do AD. Esse manifesto define esses módulos que podem e não podem ser carregado no espaço de endereço do aplicativo para criar um ambiente seguro e proteger o conteúdo não criptografado na memória. Para um manifesto a ser válido, ele deve ser digitalmente assinado por uma autoridade de certificação (CA) que pertence a uma hierarquia de certificado de RMS do AD. Isso pode ser a hierarquia de produção com uma CA de assinatura do aplicativo controlada exclusivamente pela Microsoft, ou pode ser a hierarquia de pré-permite que os desenvolvedores self-sign aplicativo manifestos. Observe que um manifesto pode pertencer a tanto hierarquia, mas não ambos. Um manifesto assinado por uma autoridade de certificação de produção é inválido na hierarquia de pré-produção e vice-versa, pois as hierarquias têm autoridades raiz diferentes. Manifestos de aplicativo são abordados em detalhes na SDK DE RMS DO AD .
Quando você instala o primeiro servidor RMS do AD em uma floresta do Active Directory, você implicitamente estabelecer a hierarquia de RMS do AD. Por padrão, a rotina de instalação do RMS do AD usa uma CA do serviço de registro do Microsoft DRM Server a mesmo para emitir SLC o Server licenciador certificados (,), que faz parte da hierarquia que leva novamente a raiz de produção do Microsoft DRM na raiz de confiança. a Figura 1 mostra essa cadeia de certificação, derivada o SLC, de uma produção servidor RMS do AD. Se você desejar examinar a hierarquia de RMS do AD no seu próprio ambiente, consulte o material complementar, que inclui a ferramenta de cadeia de certificados de RMS do AD (CertificateChain.exe).
Figura 1 O AD RMS aplicativo assinatura Certifi cate pertence a hierarquia de pré-produção RMS do AD.
A raiz de produção do DRM Microsoft estabelece a hierarquia de produção e a Microsoft requer todos os fornecedores de software assinar um contrato de licença de produção como pré-requisito para obter um certificado de produção e assine os aplicativos para a hierarquia de produção. O objetivo do certificado produção é criar e assinar manifestos para aplicativos lançados. Para fins de desenvolvimento, você deve usar um certificado de pré-em vez disso. Originalmente, o Microsoft também exigiu fornecedores de software assinar um contrato de licença desenvolvimento para obter um certificado de pré-produção, mas uma chave pública (ISVTier5AppSIgningPubKey.dat), a chave particular (ISVTier5AppSigningPrivKey.dat) e o certificado correspondente pré-produção (ISVTier5AppSignSDK_Client.xml) agora estão incluídos no SDK de RMS do AD para que você pode assinar manifestos durante o desenvolvimento sem ter que entrar em contato com a Microsoft. Como uma observação de lado, as chaves e certificados pré-também estão incluídos no pacote do código de origem protetores de formato de arquivo do Microsoft Office.
Assinatura de um manifesto de aplicativo usando o certificado pré-significa que você não pode usar o aplicativo em conjunto com um servidor de produção RMS do AD. Como Figura 1 revela, o emissor raiz da cadeia de certificados de isvtier5appsignsdk_client.xml é Microsoft DRM ISV Root, que é claramente não raiz de um servidor de produção. Você pode examinar isvtier5appsignsdk_client.xml usando minha ferramenta de cadeia de certificados de RMS do AD. Ela segue o que é necessário um servidor RMS do AD com um SLC, diferente que tenha o Microsoft DRM ISV Root na raiz de confiança (veja a Figura 1 ). Para implantar um servidor de RMS do AD, você deve estabelecer uma floresta do Active Directory separada para o seu ambiente de desenvolvimento.

Topologia de pré-produção de RMS do AD
Com uma floresta do Active Directory separada, ele é uma boa idéia para fornecer alguma idéia à topologia de pré-produção RMS do AD. Especificamente, você deve decidir se deseja instalar o RMS do AD em um servidor autônomo ou diretamente no controlador de domínio. Na maioria dos casos, uma implantação do controlador de domínio é suficiente para fins de desenvolvimento. Observe que esse não é uma recomendação para ambientes de produção. Em um ambiente de produção, você não deve implantar o RMS do AD em um controlador de domínio porque a conta de usuário de domínio que você especificar como a identidade de rede de RMS do AD, em seguida, seria requer permissões de administrador de domínio para fazer logon localmente. Fazer logon localmente é um privilégio de administrador em controladores de domínio. Em um servidor membro, a conta de usuário de domínio não precisa permissões elevadas em todos os. Se você não tiver certeza sobre a pergunta de controlador de domínio em ambientes de produção, leia artigo de blog do Jason Tyler" DOs e DON'Ts do RMS ." Sobre a idéia de colocar o RMS em um controlador de domínio, Jason diz, "isso é tal uma boa idéia, que sempre vê-la, desejo vá informar a pessoa para escolher uma opção e atender me atrás o toolshed."
A próxima pergunta é instalar o WSS 3.0, Office 2007 e Microsoft Visual Studio 2008 no controlador de domínio. Aqui você definitivamente deve usar um servidor separado, mesmo em um ambiente de desenvolvimento. Como com o problema de RMS do AD, a configuração de segurança do WSS 3.0 difere em controladores de domínio em comparação com servidores membros. Usando um servidor membro, você mantém uma configuração comparável a um ambiente de produção WSS 3.0, que proporciona resultados mais confiáveis quando testes componentes compilados. Obviamente, você pode manter o controlador de domínio e o servidor membro em um único computador físico se você usar o Microsoft Hyper-V Server 2008, conforme ilustrado na Figura 2 . Hyper-V é a tecnologia de virtualização de 64 bits, portanto, você pode usar a edição de 64 x do Windows Server 2008 em ambas as máquinas virtuais. Observe que a tecnologia Hyper-V Server 2008 não inclui ferramentas de gerenciamento gráfico, mas você pode instalar ferramentas de gerenciamento remoto do Hyper-V Server em uma estação de trabalho separada do Windows Vista, conforme descrito na planilha complementar "instalação Hyper-V Server gerenciamento remoto em uma estação de trabalho do Windows Vista."
A Figura 2 A pequena escala RMS do AD ambiente de desenvolvimento em um host Hyper-V.

Pré-configuração do servidor
Antes de instalar a função do Active Directory Rights Management Services, você deve configurar determinadas configurações do Registro no servidor para que a instalação do RMS do AD registra o servidor na hierarquia de pré-produção. Se você pular essa etapa de configuração, você acabará com a hierarquia errada. Tenha em mente que não é possível mover um servidor RMS do AD entre hierarquias. Se o servidor está inscrito na hierarquia de produção, você deve desinstalar o RMS do AD, excluir o ponto de conexão de serviço do RMS do AD (SCP) no Active Directory, configurar o registro e, em seguida, instalar a função do Active Directory Rights Management Services novamente.
a Figura 3 lista a configuração do Registro que determina a hierarquia de RMS do AD em um computador que executa o Windows Server 2008. Definir o parâmetro de hierarquia para 1 permite que a hierarquia de pré-produção. Um valor de 0 ou a ausência desse parâmetro indica que o RMS do AD deve implantar na hierarquia de produção. Configurações adicionais do Registro existem para compatibilidade com versões anteriores, mas isso não é um requisito em nosso ambiente de desenvolvimento. Para obter detalhes, consulte o tópico "Configurar o Registro" no SDK de RMS do AD. O código a seguir pode ser salvo como um arquivo de registro (. reg) para habilitar a hierarquia de pré-produção em um servidor RMS do AD.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS\2.0]
"Hierarchy"=dword:00000001
A Figura 3 O cliente RMS do AD can’t acessar o servidor RMS do AD.

Problemas de configuração de IRM do SharePoint
A implantação do servidor RMS do AD e a configuração é relativamente uncomplicated. Mais complicada, é a configuração do servidor membro que executa o WSS 3.0 para assinar o SharePoint para a hierarquia de pré-produção. Você apenas não é possível iniciar a Administração Central do SharePoint 3.0, alternar para a guia de operações, clique em Gerenciamento de direitos de informação e selecione a opção usar o servidor RMS padrão especificado no Active Directory. Se você clicar em OK resultaria somente na mensagem de erro exibida na Figura 3 . Como a mensagem se revela, o cliente RMS do AD (msdrm.dll) está presente; ele é instalado com o Windows Server 2008 por padrão, mas o servidor RMS do AD está inacessível.
Infelizmente, nem mensagem de erro, log de rastreamento, nem log de eventos do aplicativo revela a verdadeira natureza do problema. Uma opção para obter informações mais detalhadas é acessar a URL especificada no log rastreamento diretamente no Internet Explorer, por exemplo, https://adrms.litware.com:443/_wmcs/certification. Provavelmente, Internet Explorer relata um "problema com certificado de segurança deste site" se o servidor de RMS do AD pré-produção usa um certificado de camada (de segurança SSL) de auto-assinado soquetes que o cliente não confia. Para confiar o certificado do servidor SSL, instale o certificado SSL no armazenamento de autoridades de certificação raiz confiáveis do computador local. Verifique se que você colocar o certificado no armazenamento físico do computador local, porque você deve fazem com que o certificado disponíveis a todas as contas de segurança do SharePoint, não apenas sua própria conta de usuário. A planilha complementar "WSS01 de implantação no ambiente de pré-produção RMS do AD" descreve as etapas.
Às vezes, pode ser difícil lidar com certificados SSL auto-assinados. SharePoint determina a URL do serviço de Web de certificação de RMS do AD por meio do SCP de RMS do AD no Active Directory. Se esse SCP Especifica uma URL com um nome de host que difere do nome do host no certificado do SSL do servidor da Web, o servidor Web não permanecerá confiável mesmo após você instalar o certificado SSL no armazenamento do autoridades de certificação raiz confiáveis. a Figura 4 mostra um cenário de configuração comum que leva a esse problema. A configuração usa um alias na URL de RMS do AD que difere do nome do host real. Isso facilita a manutenção do servidor e permite a recuperação de desastres porque você não pode alterar a URL de RMS do AD após a implantação de um servidor RMS do AD, mas o registro CNAME que você aponte o URL em um servidor diferente, se necessário. Como indicarem as quatro etapas na Figura 4 , em primeiro lugar, o servidor do SharePoint procura o atributo serviceBindingInformation do SCP de RMS do AD para determinar a URL de RMS do AD. Em seguida, ele converte o adrms.litware.com de nome de host em dc01.litware.com baseia o registro CNAME. SharePoint, em seguida, se conecta ao dc01.litware.com, que retorna o certificado SSL para dc01.litware.com, e isso causa o conflito de endereço incompatível.
Figura 4 certificado O SSL é confiável devido a uma incompatibilidade de nome.
Para resolver este conflito, emita um certificado SSL para adrms.litware.com no servidor RMS do AD usando a ferramenta de SelfSSL disponível no Internet Information Services (IIS) 6.0 Resource Kit. A planilha complementar "DC01 de implantação no ambiente de pré-produção RMS do AD" inclui informações sobre o download e instruções passo a passo.
Corrigindo SSL problemas de certificado é a primeira etapa para uma configuração funcione, mas um certificado SSL confiável não é o único requisito. Se você tentar configurar IRM sem primeiro conceder a conta de segurança de administração central do pool de aplicativos ler e executar acesso, você receberá a mensagem que o IRM não funcionará até que o servidor concede permissão. Nome da conta de domínio usada: WSS01$@litware.com. Você obterá este erro porque o cliente deve chamam o método Certify do serviço do AD RMS certificação da Web para obter um RAC (direitos conta certificados), que falhar devido a falta de permissões de acesso para o arquivo ServerCertification.asmx. Por padrão, somente os conta de sistema do servidor RMS do AD tem acesso. A solução recomendada é herdar permissões da pasta certificação em ServerCertification.asmx e adicionar as contas de computador dos seus servidores do WSS 3.0 com leitura e execução permissões também. Isso garante que todas as possíveis contas de pool de aplicativo tenham as permissões necessárias. Consulte a planilha de complementar "DC01 de implantação no ambiente de pré-produção RMS do AD" para obter detalhes.

Problemas específicos de preproduction
Neste ponto, a estrutura IRM deve ser funcional, exceto quando você estiver em um ambiente de pré-produção. Lembre-se que cliente RMS do AD e aplicativos devem usar uma cadeia de certificados diferentes aqui. Se você tentar configurar a estrutura IRM na configuração original, você recebe o erro "o necessário Windows Rights Management cliente está presente, mas não pôde ser configurado corretamente" e o log de rastreamento inclui outra dica útil, "o computador não foi ativado". Isso é um indicador que o cliente RMS do AD esteja ainda na hierarquia de produção. Você pode verificar isso no Editor do Registro. Verifique as chaves do Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy e HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy. Um valor de 0 designa a hierarquia de produção. Alterar esses valores para 1 ativa a hierarquia de pré-produção. O código a seguir lista um arquivo .reg para aplicar as alterações de configuração convenientemente.
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
No entanto, não se surpreenda se as alterações no Registro não efetivas imediatamente. O erro permanece porque o cliente RMS do AD já foi gerado um certificado de máquina incorreta durante a primeira tentativa malsucedida e continuará a usar este certificado. Em seu servidor WSS, abra a pasta C:\ProgramData\Microsoft\DRM\Server e exclua todas as subpastas e arquivos. Também convém verifique a pasta %LOCALAPPDATA%\Microsoft. Se ele contém uma subpasta \DRM, exclua a subpasta porque ele armazena licenças de cliente que não pode ser usadas mais na hierarquia de pré-produção. O cliente RMS do AD recria essas subpastas e arquivos de certificado dentro deles conforme necessário.
Alternando de volta para Administração Central do SharePoint 3.0, tente novamente para configurar IRM e não deixe que a seguinte mensagem de erro enganá-lo: é a mesma mensagem de erro como antes, mas o motivo do erro é realmente diferente. O log de rastreamento e você descobrirá que "foi um problema ao criar e inicializar um environment… segura" de seleção Agora esse é um problema de manifesto! SharePoint ainda usa o manifesto de produção como a cadeia de certificados de RMS do AD ferramenta revela se você abrir o arquivo Stsprtid.xml localizado na pasta Files\Microsoft Shared\Web Server Extensions\12\Bin %PROGRAMFILES%\Common (consulte a Figura 5 ).
A Figura 5 O manifesto de produção doesn’t trabalhr a hierarquia de pré-produção.
Você deve excluir (ou renomear) a produção Stsprtid.xml de arquivos, gerar um novo manifesto usando a ferramenta Genmanifest.exe incluída no AD RMS SDK bem como no pacote de download de protetores de formato de arquivo do Microsoft Office e, em seguida, reiniciar o IIS. O pacote de download mesmo vem com um arquivo de configuração do SharePoint (sharepoint.mcf) e arquivos em lotes (genmft.bat e genmft.64.bat) para simplificar essa tarefa. Mesmo assim, o arquivo em lotes para ambientes de 64 bits somente assina aplicativos do Microsoft Office na hierarquia de pré-produção e ignora o SharePoint. Para entrar no SharePoint em um servidor de 64 bits, use o arquivo Sharepoint.bat incluído o material complementar ou use a ferramenta Genmanifest.exe diretamente. A sintaxe de comando é
Genmanifest.exe -chain isvtier5appsignsdk_client.xml sharepoint.mcf
 Stsprtid.xml
Consulte também a página de Genmanifest.exe em .aspx msdn.microsoft.com/en-us/library/aa362621 (VS.85).

Compilação e registro
Ter substituído o arquivo de manifesto do SharePoint, você pode concluir com êxito a configuração do IRM. Nós tiver terminado a parte difícil. Agora é hora de colher os benefícios, compilar e testar os componentes de protetor. Essa é uma tarefa simples. O código-fonte é fornecido com projetos do Visual Studio 2005 que você pode atualizar para o Visual Studio 2008 sem problemas. No entanto, tenha em mente que você estiver trabalhando em um servidor de 64 bits. Os projetos do Visual Studio são configurados para um ambiente de 32 bits. Você deve alterar esta configuração para compilar os componentes para a plataforma x 64, conforme ilustrado na Figura 6 . Consulte também a planilha complementar "Compiling, teste e implantação do Microsoft Office arquivo formato protetores."
A Figura 6 para usar o protetor IRM em um servidor WSS de 64 bits, compilar o código-fonte para a plataforma de 64 x.
O Visual Studio se encarrega do registro do componente COM em tempo de compilação, mas você ainda deve registrar o protetor IRM no WSS 3.0. Registrar os componentes com seus identificadores de classe (CLSID) em HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\IrmProtectors. Aqui é um arquivo de registro que executa esta etapa:
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"
Você também pode verificar o conteúdo do arquivo IrmProtectors.reg no material complementar. Ele contém chaves adicionais para fins informativos. Incluí essas chaves porque o protetor IRM do MOSS 2007 tem entradas semelhantes. A única diferença é que o MOSS protetores, na verdade, usam suas configurações enquanto os nossos protetor IRM usam valores codificados em vez disso.

Teste o protetor IRM
Agora que o WSS está ciente de que o protetor IRM, você pode reiniciar o IIS abrir o site do SharePoint, configurar uma diretiva de RMS do AD para uma biblioteca de documentos e, em seguida, criar, carregar e baixar documentos para verificar se o protetor IRM funciona. No entanto, isso pode ser demorado se você está enfrentando dificuldades com problemas de registro COM básicos. Por exemplo, se você esqueceu de ativar a x 64, plataforma de bits no Visual Studio, o processo de compilação é concluída sem erros, mas o registro COM permanece incompleto, WSS não é possível carregar o protetor, e não será possível testar a proteção de RMS do AD. Você pode economizar tempo verificando o registro COM pela primeira vez e executar testes no SharePoint somente se a verificação do registro concluído com êxito. Figura 7 mostra um script básico para verificar o registro COM. Ele simplesmente carrega os componentes COM e exibe uma caixa de mensagem com os resultados.
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
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
Com configurações de registro apropriada, o componente OpcIrmProtector para formatos de documento do Office 2007 é imediatamente funcional. No entanto, o componente MsoIrmProtector para formatos herdados do Office possui um requisito adicional. A pasta que contém o MsoIrmProtector.dll também deve conter uma subpasta \1033 com arquivos de modelo. Os arquivos de modelo vêm com o código-fonte e estão localizados na pasta \MsoIrmProtector\Templates. Você deve copiar esses arquivos para a subpasta \1033 para que o componente MsoIrmProtector possa incluí-las em documentos do AD RMS–protected para compatibilidade com versões anteriores com aplicativos do Office que não oferecem suporte a RMS do AD, como o Office 2000 e o Office XP. Caso contrário, não será capaz de abrir documentos do Office herdados. Por exemplo, você receberá o erro exibido na Figura 8 quando você tentar criar um novo documento do Word em uma biblioteca de documentos.
A Figura 8 que Word can’t ler este documento porque o MsoIrmProtector está não é possível criar o documento no formato adequado sem os arquivos de modelo.

Implantando protetores de documento IRM personalizado
Parabéns! Você com êxito têm criado, registrado e testado personalizados protetores de IRM do WSS 3.0. Agora, como você obtém esses componentes para seus servidores de produção do WSS 3.0? Afinal de contas, você deve instalar o protetor IRM em todos os servidores se você desejar usar esses componentes em seu ambiente de produção. Executar a implantação manualmente seria tedioso e propenso a erros. É melhor criar um projeto de instalação, incluir as DLLs e documentos do modelo dentro a estrutura de arquivos necessários, importar as configurações necessárias no Registro para integrar os componentes WSS 3.0, e, em seguida, usar o arquivo de Microsoft Windows Installer (.msi) resultante para a implantação.
Também é uma boa idéia testar a implantação em um sistema de referência. Entre outras coisas, esse teste revela pré-requisitos importantes, que você deve atender antes de implantar os componentes. Especificamente, o Visual Studio 2008 adiciona dependências do Microsoft .NET Framework 3.5 SP1 para Setup.exe e os componentes de protetor requerem um pacote redistribuível do Microsoft Visual C++. Isso é um requisito padrão para arquivos executáveis e DLLs compilados com o Visual C++. Verifique se que o pacote redistribuível corresponde da versão que usar em seu ambiente de desenvolvimento. Por exemplo, se você usar o Microsoft Visual Studio 2008 SP1, em seguida, implante o Microsoft SP1 de 2008 Visual C++ Redistributable Package (x 64) . A planilha complementar "Testando a Microsoft Office arquivo formato protetores de implantação" demonstra como testar a implantação de protetor IRM em um único servidor.

Conclusão
Proteção de IRM-com base em dos documentos do Microsoft Office usada para exigir o MOSS 2007, mas ao compilar o código de origem de protetores de formato de arquivo do Microsoft Office disponível na Galeria de código MSDN você pode integrar componentes de protetor IRM apropriados em WSS 3.0 também. Você também pode modificar o código de origem para implementar recursos personalizados se você tiver c/c++ habilidades e ter implantado SharePoint em um ambiente de pré-produção de RMS do AD. Tenha em mente que suas modificações afetam todas as bibliotecas de documentos RMS–enabled do AD. Eu recomendo deixando o código-fonte inalterada e verificando a Galeria de código do MSDN em intervalos regulares para atualizações e talvez novas versões com recursos adicionais, a menos que você seja um desenvolvedor procurando uma amostra de excelente para integrar seus próprios aplicativos com a estrutura IRM. Nesse caso, o código de origem é um excelente ponto de partida.
Lembre-se de que o Microsoft não criar a estrutura do IRM para proteger os itens de conteúdo em bancos de dados do SharePoint. Você não deve alterar as rotinas de descriptografia, por exemplo, ou os usuários do SharePoint não poderá abrir os documentos porque a estrutura IRM concede somente a conta do pool de aplicativos e o usuário atual permissões de acesso de RMS do AD ao proteger o conteúdo. Também tenha em mente que determinados protetores exigem outros protetores criar um sistema totalmente funcional. Por exemplo, o protetor MsoIrmProtector herdados formatos de documento do Office e o protetor OpcIrmProtector formatos do Office 2007 pertencer juntos. Se você implantou o protetor MsoIrmProtector sem o OpcIrmProtector, um usuário do Word 2007 pode criar um novo documento usando o modelo de conteúdo modelo.doc no SharePoint, ao salvar o arquivo como Doc1.docx. O protetor MsoIrmProtector se aplica a proteção de RMS do AD ao modelo.doc, para Doc1.docx acabaria na biblioteca de documentos no formulário protegidas por direitos porque não há nenhum protetor OpcIrmProtector para descriptografar o conteúdo após o carregamento. A conta do pool de aplicativos e o usuário atual permaneceria as somente entidades que podem abrir este documento. Há outras maneiras para proteger documentos em SharePoint bancos de dados conteúdos por meio de RMS do AD, tais como usando a interface COM ISPExternalBinaryStorage.

pav Cherny é um especialista IT e autor especializado em tecnologias Microsoft para colaboração e a comunicação unificada. Suas publicações incluem informes oficiais, manuais de produto e livros com um foco em operações de TI e administração do sistema. Pav é presidente da Biblioso Corporation, uma empresa especializada em serviços de documentação e localização gerenciados.

Page view tracker