Dentro de SharePoint Integrar el servicio Information Rights Management en SharePoint
Pav Cherny
Descarga de código disponible en: ChernySharePoint2009_05.exe(871 KB)
Contenido
Producción de RMS de Active Directory y jerarquías de preproducción
Topología de Active Directory RMS preproducción
Configuración del servidor preproducción
Problemas de configuración de IRM de SharePoint
Los problemas específicos de preproducción
Compilación y de registro
El protector IRM pruebas
Implementar protectores de documentos IRM personalizados
Conclusión
Microsoft Office SharePoint Server (MOSS) 2007 incluye protectores basados en el marco de Information Rights Management (IRM). Estos proporcionan los usuarios de Microsoft Office las ventajas de integración de SharePoint con Active Directory Rights Management Services (RMS de Active Directory). Desgraciadamente, Windows SharePoint Services (WSS) 3.0 no incluye protectores IRM de fábrica. Sin embargo, hay una solución. Si examina las aplicaciones de ejemplo y los fragmentos de código en la galería de código de MSDN, entre los gemas encontrará es la Código fuente de protectores de formato de archivo de Microsoft Office, que publicado por Microsoft en agosto de 2008. El código fuente incluye un no exclusivo, todo el mundo, libre de regalías " como-es " licencia pública de Microsoft (M-PL). Esto es una gran búsqueda porque significa puede compilar el código fuente y agregar estos componentes a WSS 3.0 también. De este modo, puede beneficiarse de Active Directory en función de RMS características de seguridad y cumplimiento en cualquier entorno de SharePoint.
En esta columna, continuar discusión del mes pasado acerca de integración de SharePoint con AD RMS mostrándole cómo establecer un entorno de desarrollo de preproducción AD RMS, compilar los protectores IRM e integrar los componentes compilados en WSS 3.0. No necesita realmente un entorno de preproducción para compilar los protectores IRM, pero es un ejercicio interesante porque resaltan algunos problemas de configuración AD RMS típicos que pueden surgir en un entorno de producción. No es necesario que un desarrollador de C/C ++ para comprender los conceptos alrededor de producción de RMS de Active Directory y las jerarquías de preproducción y cómo afectan a la implementación de Active Directory RMS, Microsoft Office y WSS 3.0. Y no necesita experiencia de desarrollo de C/C ++ en compilar y probar los protectores IRM. Temas de desarrollador, como extender el código fuente o convertir integradas protectores protectores autónomos, son más allá del alcance de este artículo. La única tarea de desarrollador que se encontrará afecta a la creación de un proyecto de instalación con unos pocos clics del mouse (ratón) para simplificar la implementación de los componentes protector compilado en los servidores de producción WSS 3.0. Mayo material complementario (disponible en la página de descarga de código de TechNet Magazine) incluye las hojas de cálculo y herramientas que le guía por la implementación, compilación y probar procedimientos en equipos que ejecutan la versión x 64 de Windows Server 2008.
Producción de RMS de Active Directory y jerarquías de preproducción
SharePoint, al igual que cualquier otra aplicación que desea utilizar Active Directory RMS para cifrar o descifrar el contenido, debe tener un manifiesto firmado digitalmente que firma la aplicación en la jerarquía de Active Directory RMS. Este manifiesto define los módulos que pueden y no se carga en el espacio de direcciones de la aplicación para crear un entorno seguro y proteger el contenido sin cifrar en la memoria. Para que un manifiesto de ser válido, se debe ser firmado digitalmente por una entidad emisora de certificados (CA) que pertenece a una jerarquía de certificados AD RMS. Esto puede ser la jerarquía de producción con una entidad de CERTIFICACIÓN de firma de la aplicación controlado exclusivamente por Microsoft, o puede ser la jerarquía de preproducción que permite a los desarrolladores self-sign aplicación manifiestos. Tenga en cuenta que un manifiesto puede pertenecer a ser jerarquía, pero no ambos. Un manifiesto firmado por una entidad emisora de CERTIFICADOS de producción es no válido en la jerarquía de preproducción y viceversa, porque las jerarquías tienen entidades emisoras raíz diferente. Manifiestos de aplicación se tratan detalladamente en el AD RMS SDK.
Cuando se instala el primer servidor de RMS de Active Directory en un bosque de Active Directory, se establece implícitamente la jerarquía de Active Directory RMS. De forma predeterminada, la rutina de instalación de RMS de Active Directory utiliza una CA de servicio de inscripción a sí mismo de Microsoft DRM Server para emitir el certificado de licencia de servidor (SLC), que forma parte de la jerarquía que lleva a la raíz de producción de DRM de Microsoft en la raíz de confianza. la figura 1 muestra esta cadena de certificación, derivada de la SLC de un servidor RMS de Active Directory de producción. Si desea examinar la jerarquía de Active Directory RMS en su propio entorno, consulte el material complementario, que incluye la herramienta de cadena de certificados RMS de Active Directory (CertificateChain.exe).
Figura 1 el AD RMS aplicación firma Certifi cate pertenece a la jerarquía de preproducción AD RMS.
La raíz de producción de DRM Microsoft establece la jerarquía de producción, y Microsoft requiere que todos los proveedores de software firmar un contrato de licencia de producción como un requisito previo para obtener un certificado de producción y la firma aplicaciones en la jerarquía de producción. El propósito del certificado de producción es crear y firmar manifiestos para las aplicaciones publicadas. Para propósitos de desarrollo, debe utilizar un certificado de preproducción en su lugar. Originalmente, proveedores de software firmar un contrato de licencia desarrollo para obtener un certificado de preproducción necesarios Microsoft también, pero una clave pública (ISVTier5AppSIgningPubKey.dat), clave privada (ISVTier5AppSigningPrivKey.dat) y el del certificado de preproducción correspondiente (ISVTier5AppSignSDK_Client.xml) ahora se incluyen en el SDK de RMS de Active Directory para que se puedan firmar manifiestos durante la fase de desarrollo sin tener que ponerse en contacto con Microsoft. Como una nota al margen, las claves y certificados de preproducción están también incluidos en los protectores de formato de archivo de Microsoft Office origen código paquete.
Firma un manifiesto de aplicación con el certificado de preproducción implica que la aplicación no puede usar en combinación con un servidor de producción AD RMS. Como se muestra la figura 1 , el emisor raíz de la cadena de certificados de isvtier5appsignsdk_client.xml es Microsoft DRM ISV raíz, que claramente no es la raíz de un servidor de producción. Puede examinar isvtier5appsignsdk_client.xml con mi herramienta de la cadena de certificados AD RMS. Se deduce que necesita un servidor RMS de Active Directory con un SLC diferente que tenga la raíz de proveedor de software de DRM de Microsoft en la raíz de confianza (consulte la figura 1 ). Para implementar dicho un servidor de RMS de Active Directory, debe establecer un bosque de Active Directory independiente para su entorno de desarrollo.
Topología de Active Directory RMS preproducción
Con un bosque de Active Directory independiente, es una buena idea para conceder a algunas ideas a la topología de preproducción AD RMS. En concreto, debe decidir si desea instalar RMS de Active Directory en un servidor independiente o directamente en el controlador de dominio. En la mayoría de los casos, una implementación del controlador de dominio basta para propósitos de desarrollo. Tenga en cuenta que no es una recomendación para los entornos de producción. En un entorno de producción, no debe implementar Active Directory RMS en un controlador de dominio ya que la cuenta de usuario de dominio especifique como la identidad de la red AD RMS, a continuación, se requieren permisos de administrador de dominio iniciar sesión localmente. Iniciar sesión localmente es un privilegio de administrador en los controladores de dominio. En un servidor miembro, la cuenta de usuario de dominio no necesita en todos los permisos elevados. Si no sabe con certeza acerca de la pregunta de controlador de dominio en los entornos de producción, lea el artículo de blog de Jason Tyler" Los DOs y DON'Ts de RMS." Con respecto a la idea de poner RMS en un controlador de dominio, Jason dice "se trata de una idea errónea, que cada vez verlo, desee ir indicar a la persona que vaya elegir un modificador y cumplirme detrás de la toolshed."
La siguiente pregunta es si desean instalar WSS 3.0, Office 2007 y Visual Studio 2008 en el controlador de dominio. Aquí definitivamente debe utilizar un servidor independiente, incluso en un entorno de desarrollo. Como que con el problema de RMS de Active Directory, la configuración de seguridad de WSS 3.0 varía de controladores de dominio en comparación con los servidores miembro. Mediante un servidor miembro, se conserva una configuración comparable a un entorno de producción de WSS 3.0, que ofrece resultados más confiables cuando las pruebas compilan los componentes. Por supuesto, puede mantener el controlador de dominio y el servidor miembro en un único equipo físico si utilizas Microsoft Hyper-V Server 2008, como se ilustra en la figura 2 . Hyper-V es la tecnología de virtualización de 64 bits, por lo que puede utilizar la edición de 64 x de Windows Server 2008 en ambos equipos virtuales. Tenga en cuenta que Hyper-V Server 2008 no incluye herramientas gráficas de administración, pero se pueden instalar herramientas de administración remota de Hyper-V Server en una estación de trabajo independiente de Windows Vista, tal y como se describe en la hoja de cálculo complementario "instalación Hyper-V Server remota administración en una estación de trabajo de Windows Vista."
La Figura 2 A pequeña escala AD RMS entorno de desarrollo en un host. Hyper-V
Configuración del servidor preproducción
Antes de instalar la función de servicios de administración de derechos de Active Directory, debe configurar ciertas opciones del registro en el servidor para que la instalación de Active Directory RMS inscriba el servidor en la jerarquía de preproducción. Si se omite este paso de configuración, le acabar con la jerarquía incorrecta. Tenga en cuenta que no se puede mover un servidor RMS de Active Directory entre jerarquías. Si el servidor está registrado en la jerarquía de producción, debe desinstalar RMS de Active Directory, eliminar el punto de conexión de servicio (SCP) de AD RMS en Active Directory, configurar el registro y, a continuación, instalar de nuevo la función de servicios de administración de derechos de Active Directory.
Figura 3 se muestran la configuración del registro que determina la jerarquía de Active Directory RMS en un equipo que ejecuta Windows Server 2008. Si se establece el parámetro de la jerarquía en 1, activa la jerarquía de preproducción. Un valor de 0 o la ausencia de este parámetro indica que debe implementar Active Directory RMS en la jerarquía de producción. Existen otras opciones del registro para la compatibilidad con versiones anteriores, pero esto no es un requisito en nuestro entorno de desarrollo. Para obtener más información, vea el tema "Configurar el registro" en el SDK de RMS de Active Directory. En el siguiente código se puede guardar como un archivo del (registros. reg) para habilitar la jerarquía de preproducción en un servidor RMS de Active Directory.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS\2.0]
"Hierarchy"=dword:00000001
La figura 3 el cliente RMS de Active Directory can’t acceso al servidor RMS de Active Directory.
Problemas de configuración de IRM de SharePoint
La implementación de servidor de RMS de Active Directory y la configuración es relativamente uncomplicated. Más complicada es la configuración del servidor miembro que ejecute WSS 3.0 para firmar SharePoint en la jerarquía de preproducción. No se puede simplemente iniciar la administración central de SharePoint 3.0, cambiar a la ficha operaciones haga clic en Information Rights Management y, a continuación, seleccione la opción usar el servidor de RMS predeterminado especificado en Active Directory. Al hacer clic en ACEPTAR daría como resultado sólo la mensaje de error aparece en Figure 3 . Como se muestra el mensaje, el cliente RMS de Active Directory (msdrm.dll) está presente; se instala con Windows Server 2008 de forma predeterminada, pero el servidor RMS de Active Directory es inaccesible.
Por desgracia, ni mensaje de error, ni el registro de seguimiento ni registro de eventos de aplicación revelar la naturaleza del problema es true. Una opción para obtener información más detallada consiste en tener acceso a la dirección URL especificada en el registro de seguimiento directamente en Internet Explorer, por ejemplo, https://adrms.litware.com:443/\_wmcs/certification. Lo más probable es que Internet Explorer le informa un "problema con certificado de seguridad de este sitio Web" si el servidor de RMS de Active Directory preproducción utiliza un certificado de capa (SSL) con firma personal secure sockets que no confía el cliente. Para que se confía en el certificado del servidor SSL, debe instalar el certificado SSL en el almacén de entidades emisoras de certificados raíz de confianza del equipo local. Asegúrese de que coloca el certificado en el almacén físico del equipo local porque debe realizar el certificado disponible para cuentas de seguridad de SharePoint todo, no sólo su propia cuenta de usuario. La hoja de cálculo complementario "WSS01 de implementación en el entorno de preproducción RMS Active Directory" describe los pasos.
En ocasiones, puede resultar difícil tratar con certificados autofirmados de SSL. SharePoint determina la dirección URL del servicio Web de Active Directory RMS certificados de por medio de la SCP de RMS de Active Directory en Active Directory. Si ese SCP especifica una dirección URL con un nombre de host que difiera del nombre de host en certificado SSL del servidor Web de, el servidor Web permanece no confianza incluso después de instalar el certificado SSL en el almacén Entidades emisoras raíz de confianza. la figura 4 muestra un escenario de configuración común que lleva a este problema. La configuración utiliza un alias en la URL RMS de Active Directory que difiera del nombre de host real. Esto facilita el servidor de mantenimiento y recuperación ante desastres porque no puede cambiar la dirección URL de AD RMS después de la implementación de un servidor RMS de Active Directory, pero el registro CNAME permite punto la dirección URL en un servidor diferente si es necesario. Como indican los cuatro pasos en la figura 4 , en primer lugar, el servidor de SharePoint busca el atributo serviceBindingInformation de la SCP de RMS de Active Directory para determinar la dirección URL de AD RMS. A continuación, resuelve el adrms.litware.com de nombre de host en dc01.litware.com basándose en el registro CNAME. SharePoint, a continuación, se conecta al dc01.litware.com, que devuelve el certificado SSL para dc01.litware.com, y esto hace que el conflicto de dirección no coincidente.
La figura 4 SSL el certificado es de no confianza debido a un error coincidencia nombre.
Para resolver este conflicto, emitir un certificado SSL para adrms.litware.com en el servidor RMS de Active Directory mediante la herramienta SelfSSL disponible en el Kit de recursos de Internet Information Services (IIS) 6.0. La hoja de cálculo complementario "DC01 de implementación en el entorno de preproducción RMS Active Directory" incluye información de descarga y obtener instrucciones paso a paso.
Corregir SSL problemas de certificado es el primer paso hacia una configuración de funcionamiento, pero un certificado SSL de confianza no es el único requisito. Si se intenta configurar IRM sin concederle primero la cuenta de seguridad de la administración central de grupo de aplicaciones de lectura y acceso de ejecución, recibirá el mensaje de error que IRM no funcionará hasta que el servidor concede permiso. Nombre de cuenta de dominio utilizado: WSS01$@litware.com. Obtendrá este error porque el cliente debe llamar al método Certify del servicio Web de certificación de RMS Active Directory para obtener un certificado de cuenta de derechos (RAC), que se produce un error due to permisos de acceso que faltan en el archivo ServerCertification.asmx. De forma predeterminada, sólo la AD RMS cuenta del servidor del sistema tiene acceso. La solución recomendada es heredar permisos de la carpeta certificados ServerCertification.asmx y, a continuación, agregar las cuentas de equipo de los servidores de WSS 3.0 con lectura y ejecución as well permisos. Esto garantiza que todas las cuentas de grupo de aplicación posibles tengan los permisos necesarios. Consulte dicha hoja complementario "DC01 de implementación en el entorno de preproducción RMS Active Directory" para los detalles.
Los problemas específicos de preproducción
En este momento, el marco IRM debe ser funcional, excepto cuando se encuentra en un entorno de preproducción. Recuerde que cliente RMS de Active Directory y las aplicaciones, deben utilizar una cadena de certificados diferentes aquí. Si intenta configurar el marco de IRM en la configuración original, recibirá el error "el requiere Windows Rights Management cliente está presente pero no se pudo configurar correctamente" y el registro de seguimiento incluye otra sugerencia útil, "el equipo no se ha activado." Esto es un indicador que el cliente RMS de Active Directory esté todavía en la jerarquía de producción. Puede comprobarlo en el Editor del registro. Compruebe las claves del registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy y HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\uDRM\Hierarchy. Un valor de 0 designa la jerarquía de producción. Cambiar estos valores a 1 activa la jerarquía de preproducción. El código siguiente muestra un archivo .reg para aplicar los cambios de configuración 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
Sin embargo, no se sorprenda de que los cambios del registro no efectivos inmediatamente. El error permanece porque el cliente RMS de Active Directory ya ha generado un certificado de equipo incorrecto durante el primer intento incorrecto y continúa usar este certificado. En el servidor WSS, abra la carpeta C:\ProgramData\Microsoft\DRM\Server y elimine todas las subcarpetas y archivos. Es posible que también desea comprobar la carpeta %LOCALAPPDATA%\Microsoft. Si incluye una subcarpeta \DRM, elimine la subcarpeta porque almacena las licencias de cliente que no se puedan utilizables ya en la jerarquía de preproducción. El cliente RMS de Active Directory vuelve a crear estas subcarpetas y archivos de certificado dentro de ellos como sea necesario.
Cambiar volver a Administración central de SharePoint 3.0, vuelva a intentar configurar IRM y no permita que la siguiente mensaje de error le engañen: es el mismo mensaje de error como antes pero el motivo del error es realmente diferente. El registro de seguimiento y encontrará que "produjo un problema al crear y inicializar un environment… segura" de comprobación Ahora éste es un problema de manifiesto. SharePoint sigue el manifiesto de producción como la revela de herramienta de cadena de certificados AD RMS si abre el archivo stsprtid.xml ubicado en la carpeta %PROGRAMFILES%\Common comunes\Microsoft Shared\Web Server Extensions\12\Bin (consulte la figura 5 ).
La figura 5 el manifiesto de producción doesn’t trabajar en la jerarquía de preproducción.
Debe eliminar (o cambiar el nombre de) la producción stsprtid.xml archivo, generar un nuevo manifiesto mediante la herramienta Genmanifest.exe incluida en el SDK del RMS de Active Directory, así como en el paquete de descarga protectores de formato de archivo de Microsoft Office y, a continuación, reinicie IIS. Incluso el paquete de descarga incluye un archivo de configuración de SharePoint (sharepoint.mcf) y archivos por lotes (genmft.bat y genmft.64.bat) para simplificar esta tarea. No obstante, el archivo por lotes para entornos de 64 bits sólo firma de aplicaciones de Microsoft Office en la jerarquía de preproducción y omite SharePoint. Para iniciar sesión en SharePoint en un servidor de 64 bits, utilice el archivo Sharepoint.bat incluido en el material complementario o utilice la herramienta Genmanifest.exe directamente. La sintaxis del comando es la siguiente
Genmanifest.exe -chain isvtier5appsignsdk_client.xml sharepoint.mcf
Stsprtid.xml
Consulte también la página Genmanifest.exe en aspx msdn.microsoft.com/en-us/library/aa362621 (VS.85).
Compilación y de registro
Necesidad de reemplazar el archivo de manifiesto de SharePoint, puede completar correctamente la configuración de IRM. Se ha terminado la parte difícil. Ahora es tiempo disfrutan de los incentivos compilar y probar los componentes del protector. Se trata de una tarea sencilla. El código fuente incluye proyectos de Visual Studio 2005 que se pueden actualizar a Visual Studio 2008 sin problemas. Sin embargo, tenga en cuenta que trabaja en un servidor de 64 bits. Los proyectos de Visual Studio están configurados para un entorno de 32 bits. Debe cambiar esta configuración para compilar los componentes de la plataforma x 64, como se muestra en la figura 6 . Consulte también la hoja de cálculo complementario "Compiling, pruebas y protectores de formato de implementar Microsoft Office archivos".
Figura 6 para utilizar los protectores IRM en un servidor WSS de 64 bits, compile el código fuente para la plataforma de x 64.
Visual Studio se encarga del registro de componentes COM en tiempo de compilación, pero todavía debe registrar los protectores IRM en WSS 3.0. Registrar los componentes con los identificadores de clase (CLSID) en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\IrmProtectors. Aquí es un archivo de registro que lleva a cabo este paso:
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"
También puede comprobar el contenido del archivo IrmProtectors.reg en el material complementario. Contiene claves adicionales fines informativos. Incluyen estas claves porque los protectores IRM de MOSS 2007 tienen entradas similares. La única diferencia es que MOSS protectores realmente utilizan su configuración mientras nuestros protectores IRM utilizan valores codificados en su lugar.
El protector IRM pruebas
Ahora que WSS es consciente de los protectores IRM, puede reiniciar IIS, abra el sitio de SharePoint, configurar una directiva AD RMS de una biblioteca de documentos y, a continuación, crear, cargar y descargar los documentos para comprobar que funcionan los protectores IRM. Sin embargo, esto puede ser mucho tiempo si se esfuerzan con problemas de registro COM básicos. Por ejemplo, si ha olvidado activar la x 64, plataforma de bits en Visual Studio, el proceso de compilación finaliza sin errores, pero el registro de COM permanece incompleto, WSS no puede cargar los protectores de, y no podrá comprobar protección AD RMS. Puede ahorrar tiempo comprobando el registro de COM en primer lugar y realizar pruebas en SharePoint sólo si la comprobación de registro muestra éxito completa. Figura 7 muestra un script básico para comprobar el registro de COM. Simplemente se carga los componentes COM y se muestra un cuadro de mensaje con los 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
La figura 7 hacer seguro IRM protectores están registrados correctamente como componentes COM antes de comprobar los protectores en 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
Con configuración de registro adecuada, el componente de OpcIrmProtector para formatos de documento de Office 2007 está la de la inmediatamente funcional. Sin embargo, el componente MsoIrmProtector para formatos de Office antiguos tiene un requisito adicional. La carpeta que contiene el MsoIrmProtector.dll también debe contener una subcarpeta \1033 con archivos de plantilla. Los archivos de plantilla incluyen el código fuente y se encuentran en la carpeta \MsoIrmProtector\Templates. Debe copiar estos archivos en la subcarpeta \1033 para que el componente MsoIrmProtector puede incluirlos en documentos RMS–protected de Active Directory para la compatibilidad con versiones anteriores con las aplicaciones de Office que no admiten RMS de Active Directory, como Office 2000 y Office XP. De lo contrario, no podrá abrir documentos de Office antiguos. Por ejemplo, recibirá el error que aparece en la figura 8 cuando intenta crear un nuevo documento de Word en una biblioteca de documentos.
Figura 8 que Word can’t leer este documento porque el MsoIrmProtector está no se puede crear el documento en formato correcto sin los archivos de plantilla.
Implementar protectores de documentos IRM personalizados
¡ Enhorabuena! Ha correctamente integrado, registrado y probado personalizados protectores IRM para WSS 3.0. Ahora, ¿cómo se obtener estos componentes en los servidores de producción de WSS 3.0? Después de todo, debe instalar los protectores IRM en todos los servidores si desea utilizar estos componentes en el entorno de producción. Realizar manualmente la implementación sería tediosas y propensas. Es más conveniente generar un proyecto de instalación, incluir los archivos DLL y documentos de plantilla dentro de la estructura del archivo requerido, importar la configuración del registro necesarias para integrar los componentes en WSS 3.0 y, a continuación, utilizar el archivo de Microsoft Windows Installer (.msi) resultante para implementación.
También es una buena idea probar la implementación en un sistema de referencia. Entre otras cosas, la tales pruebas revelan importantes los requisitos previos que debe cumplir antes de implementar los componentes. En concreto, Visual Studio 2008 agrega las dependencias de Service Pack 1 de Microsoft .NET Framework 3.5 a Setup.exe y los componentes del protector requieren un paquete redistribuible de Microsoft Visual C++. Esto es un requisito estándar para archivos ejecutables y DLL compiladas con Visual C++. Asegúrese de que el paquete redistribuible coincide con la versión que utilice en su entorno de desarrollo. Por ejemplo, si usa Microsoft Visual Studio 2008 SP1, a continuación, implementar los de Microsoft Visual C++ con SP1 en 2008 Redistributable (x 64). La hoja de cálculo complementario "probar la Microsoft Office archivos formato protectores de implementación" muestra cómo probar la implementación de protector IRM en un único servidor.
Conclusión
Protección de IRM, en función de los documentos de Microsoft Office utiliza para requerir MOSS 2007, pero al compilar el protectores de formato de archivo de Microsoft Office código fuente disponible en la galería de código MSDN puede integrar componentes adecuados de protector IRM en WSS 3.0, así. También puede modificar el código de origen para implementar características personalizadas si tiene conocimientos de C/C ++ y han implementado SharePoint en un entorno de preproducción AD RMS. Tenga en cuenta que las modificaciones afectan a todos los bibliotecas de documentos RMS–enabled de Active Directory. SE recomienda dejar el código fuente sin modificaciones y la comprobación de la galería de código de MSDN de forma regular para las actualizaciones y versiones nuevas, quizás, con características adicionales, a menos que sea un desarrollador buscar un ejemplo excelente para integrar sus propias aplicaciones con el marco IRM. En este caso, el código de origen es un excelente punto de partida.
Recuerde que Microsoft no diseñar el marco IRM para proteger los elementos de contenido de las bases de datos de SharePoint. Por ejemplo, no debe cambiar las rutinas de descifrado, o es posible que los usuarios de SharePoint no pueda abrir los documentos porque el marco IRM concede sólo la cuenta del grupo de aplicaciones y el usuario actual AD RMS permisos de acceso al proteger el contenido. También tenga presente que algunos protectores requieren otros protectores crear un sistema completamente funcional. Por ejemplo, el protector MsoIrmProtector para formatos de documento de Office antiguos y el protector OpcIrmProtector para formatos de 2007 de Office pertenecer juntos. Si ha implementado el protector MsoIrmProtector sin la OpcIrmProtector, un usuario de Word 2007 puede crear un nuevo documento mediante la plantilla de contenido plantilla.doc en SharePoint, base de datos al guardar el archivo como Doc1.docx. El protector MsoIrmProtector aplica protección AD RMS a plantilla.doc, por lo que Doc1.docx podría acabar en la biblioteca de documentos en formulario rights-protected porque no hay ningún protector OpcIrmProtector para descifrar el contenido en la carga. La cuenta del grupo de aplicaciones y los del usuario actual se conservan las entidades sólo que pueden abrir este documento. Hay otras formas para proteger documentos en bases de datos contenidos de SharePoint a través de RMS de Active Directory, como mediante la interfaz COM de ISPExternalBinaryStorage.
Pav Cherny es un experto en TI y el autor especializado en tecnologías de Microsoft para la colaboración y comunicación unificada. Sus publicaciones incluyen notas del producto, manuales de producto y libros con un foco sobre las operaciones y administración del sistema. Pav es presidente de Biblioso Corporation, una empresa que está especializada en servicios administrados de documentación y localización.