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)
Conteúdo
Produção de RMS do AD e hierarquias de pré-produção
Topologia de pré-produção de RMS do AD
Pré-configuração do servidor
Problemas de configuração de IRM do SharePoint
Problemas específicos de preproduction
Compilação e registro
Teste o protetor IRM
Implantando protetores de documento IRM personalizado
Conclusão
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
A Figura 7 tornar-se de que o IRM protetores corretamente são registrados como COM componentes antes de testar os protetores no 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
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.