Dentro de SharePoint Actualizar las credenciales de cuenta de seguridad

Pav Cherny

Descarga de código disponible en: ChernySharePoint2009_03.exe(821 KB)

Contenido

Servicios y cuentas de seguridad
Servicios y cuentas de seguridad
Un comando para todos los servicios
Vaya a la distancia total
Implementación y uso de la solución
Conclusión

Microsoft Windows SharePoint Services (WSS) 3.0 y administración de seguridad de Microsoft Office SharePoint Server (MOSS) 2007 inserción al límite con servicios y procesos de trabajo que se basan en cuentas de usuario de dominio para admitir el control de acceso discrecional (DAC) basado modelo de seguridad de Windows Server. En la función de las cuentas de seguridad, cuentas de usuario de dominio siempre han esfuerza satisfacer necesidades empresariales. Esto se aplica a cualquier entorno de cliente/servidor y aún más para conjuntos de servidores de SharePoint, como cada servicio de un conjunto de servidores mantiene su propia información de cuenta y impone sus propios procedimientos de actualización específica, independientemente de otros servicios que puede utilizar las mismas credenciales. La cuenta en cuestión puede ser la cuenta de misma en Active Directory, pero tendrá que seguir actualizar cada uno de los servicios individualmente tras un cambio de contraseña.

Por supuesto, primero debe recordar todos los servicios que utilizan una cuenta. Puede ser difícil de siguen las recomendaciones de seguridad que sugieren utilizando las cuentas de dominio independiente para servicios de SQL Server, servicios de administración central y de temporizador de SharePoint, búsqueda de servicio y del rastreador, compartidos proveedores de servicios (SSP), los grupos de aplicación Web, servicio de inicio de sesión único en, usuario importación de perfiles y las cuentas de servicios de Excel.

Y, por supuesto, hay diferentes contraseñas seguras para cada cuenta y los cambios de contraseña con frecuencia para realizar un seguimiento de. ¿No sería excelente dominar este desafío sin incurrir en carga de trabajo administrativo?

Recursos de seguridad

Sitio Web de las contraseñas a Windows SharePoint Services

En esta la segunda entrega de una serie de dos partes, describen aspectos de seguridad de SharePoint, específicamente seguridad Mantenimiento de cuentas y presentar una solución para automatizar los cambios de contraseña para lograr una mejor seguridad y reducir la carga administrativa.

La idea subyacente es relativamente sencilla: una solución personalizada puede obtener todos los nombres de cuentas de seguridad y contraseñas utilizando el modelo de objetos administrativo de SharePoint. La solución puede utilizar esta información para iniciar sesión en Active Directory, cambiar las contraseñas correspondientes a través de Active Directory Service Interfaces (ADSI) y actualizar afectados todos los servicios en el conjunto de servidores local.

De este modo, los administradores de SharePoint no tienen que tratar las contraseñas de cuentas de seguridad ya. Sin embargo, implementar la idea no era tan sencilla. En el extremo, encuentra yo mismo crear varios componentes, incluidas las extensiones de comandos Stsadm.exe, páginas de aplicación para el sitio de administración central de SharePoint 3.0, un servicio de Windows integrado de SharePoint y una interfaz de programación básica para normalizar los cambios de contraseña a través de todos los tipos de servicios de SharePoint.

No tengo tiempo suficiente para cubrir todos los servicios MOSS aún, pero el prototipo actual es compatible con WSS 3.0. He creado un sitio Web en sppwd.com que, en un futuro próximo, proporcionará los componentes MOSS y otras actualizaciones, así como más documentación de las características e interfaces de programación.

El prototipo actual se utiliza únicamente con fines de prueba y no es utilizarse en entornos de producción. Probado completamente, no obstante muestra que el mantenimiento de cuentas de seguridad de SharePoint no tiene que aumentar la carga administrativa. El material complementario de esta columna, disponible en Descargas de TechNet código 2009, incluye las hojas de cálculo, ensamblados compilados y código fuente.

Servicios y cuentas de seguridad

¿Ha alguna vez preguntado por qué deberá utilizar tantos distintos comandos para actualizar las cuentas de seguridad de SharePoint después de una contraseña de cambio en Active Directory? A continuación, consulte el artículo" Cómo cambiar cuentas de servicio y contraseñas de cuenta de servicio en SharePoint Server 2007 y en Windows SharePoint Services 3.0."

Describen cinco comandos diferentes (updateaccountpassword, spsearch/farmserviceaccount, spsearch/farmcontentaccessaccount, updatefarm­credentials y ssplogin o editssp) y aún no cubre todos los aspectos.

Además, la secuencia de comandos de ejemplo el artículo, aunque útil como una plantilla, muestran una configuración de seguridad débil porque se supone que utilizar la misma cuenta y contraseña para todos los servicios en el conjunto de servidores. Intente adaptar esta secuencia de comandos un entorno de conjunto de servidores en cada servicio y aplicación grupo utiliza una cuenta de usuario diferentes y una contraseña y puede experimentar un gran desafío de secuencias de comandos. No está fácil mantener seguridad del sistema mediante secuencias de comandos en un conjunto de servidores de SharePoint.

El motivo de la complejidad está enterrado profundidad en el diseño de seguridad de SharePoint. Como obtener la información mediante el comando de stsadm -o enumservices, SharePoint se basa en un número de servicios, y cada servicio tiene dependencias de seguridad diferentes.

Si busca el nombre del tipo que el comando enumservices devuelve para cada servicio en el SDK de WSS 3.0, encontrará que algunos de estos servicios utilizan hay cuentas de seguridad, mientras otros usuarios pueden utilizar una cuenta de seguridad único o requieren varias cuentas. Por ejemplo, servicios relacionados con la mensajería y el servicio diagnóstico no están asociados con la información de la cuenta de seguridad, el servicio de temporizador de SharePoint utiliza una cuenta de seguridad único, el servicio de búsqueda tiene una cuenta de servicio, así como una cuenta de rastreador de datos y el servicio de aplicación Web puede tener como muchas cuentas de seguridad como hay grupos de aplicaciones.

Y hay más. El servicio de administración de SharePoint, por ejemplo, debe utilizar la cuenta del sistema local, por lo que no requiere una cuenta de seguridad de dominio incluso en un conjunto de servidores de SharePoint. Algunas soluciones también pueden introducir sus propios servicios, como Microsoft Office Project Server (MOPS) 2007. El cielo es el límite, teniendo en cuenta que también puede tener cualquier número de soluciones personalizadas con distintos requisitos de seguridad.

Por supuesto, no hay ninguna manera exigir comunes procedimientos de actualización a través de una cartera diversa servicios de, por lo que no es sorprendente que SharePoint incluye un amplio conjunto de comandos de actualización. Básicamente, todas las soluciones deben proporcionar sus propia herramientas individuales y actualizar los procedimientos, aumenta la carga administrativa en proporción al número de servicios en el entorno de SharePoint. la figura 1 ilustra la relación entre los servicios de SharePoint y las cuentas de seguridad, así como los comandos de actualización aplicable.

Figura 1 relación entre cuentas de servicios y seguridad de SharePoint

Servicios y cuentas de seguridad

La organización de servicios y cuentas de seguridad puede parecer confusa, pero no hay un orden jerárquico aplica mediante el modelo de objetos SharePoint, como se ilustra en la figura 2 . En la base de todos los servicios de SharePoint es la clase SPService. Esta clase no incluye una cuenta de seguridad porque, como se mencionó anteriormente, no todos los servicios requieren credenciales. Servicios que requieran credenciales pueden heredar una identidad de la clase SPWindowsService o implementar sus propios.

La Figura 2 las jerarquías de herencia de los servicios de SharePoint

La clase de SPSearchService, por ejemplo, si hereda una identidad de proceso de la clase SPWindowsService y también mantiene su propia cuenta del rastreador. La clase SPWebService, por otro lado, no es necesario una identidad de proceso SPWindowsService­based, por lo que hereda directamente de la clase SPService y mantiene sus propia cuentas de seguridad en el formulario de las identidades de grupo de aplicación.

Existen varios hechos importantes fuera de la jerarquía de herencia. En primer lugar y principalmente, hay no realmente que muchas maneras diferentes tratar con las cuentas de seguridad de un conjunto de servidores de SharePoint. Servicios de SharePoint principalmente utilizan identidades de procesos o las identidades de grupo de aplicación. Estos tipos de identidad son muy similares con respecto a la actualización de la información de seguridad, dado que la clase SP­ApplicationPool se deriva de la clase SPProcessIdentity.

En segundo lugar, las identidades de servicios de SharePoint están disponibles en las secuencias de comandos personalizadas y aplicaciones administrativas. Es posible obtener acceso a cada servicio de SharePoint individual a través de la clase base SP­Service para tener acceso a los nombres de inicio de sesión y las contraseñas.

En tercer lugar, el modelo de objetos de SharePoint ya sabe cómo tratar las identidades de procesos y las identidades de grupo de aplicación. Entre otras cosas, el modelo de objetos incluye la lógica para establecer y actualizar las contraseñas, por lo que no es necesario reinventar la rueda al utilizar las herramientas personalizadas. Sólo tiene que llamen a los métodos necesarios, aunque esto no es sin obstáculos porque el SDK de WSS no Explique las dependencias muy bien.

Actualizar las cuentas de seguridad requiere más de establecer las propiedades Nombre de usuario y contraseña (o SecurePassword) de identidades de proceso (SPProcess­Identity) o las identidades de grupo de aplicación (SPApplicationPool) y llamar al método Update. Hacerlo no poner volver el conjunto de servidores en estado operativo. El método Update simplemente actualiza la contraseña en la base de datos de configuración de SharePoint, pero no actualiza los servicios subyacentes o grupos de aplicación.

Es importante tener en cuenta que los recursos afectados existen fuera del entorno de SharePoint. Servicios de Windows mantienen su información de seguridad de la base de datos del control de servicios Manager (SCM), ubicado en el registro en cada servidor bajo HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

Aplicaciones Web, por otro lado, son los recursos de IIS. Para actualizarlos, debe llamar al método de implementación la identidad junto con el método Update. El método de implementación activa de la lógica de SharePoint para actualizar todos los servidores en el conjunto de servidores por medio de llamadas de API locales y los trabajos del temporizador de SharePoint. También cambia clave de credencial del conjunto si los cambios afectan a la contraseña del grupo de aplicación para la aplicación de Web de Administración central (SPWebService.AdministrationService).

Este cambio de contraseña también afectará al servicio de temporizador de SharePoint, que está estrechamente emparejado con la infraestructura administrativa, por lo que no es necesario actualizar el servicio de temporizador de SharePoint directamente. Para obtener más información acerca de los procedimientos estándar para realizar los cambios de contraseña en un entorno de conjunto de servidores con varios servidores, debe leer mi columna del mes pasado " Mantener las credenciales de cuenta de seguridad."

Un comando para todos los servicios

A pesar de la complejidad, la buena noticia es que el modelo de objetos de SharePoint se ocupa de todos los detalles de actualización de esenciales de un conjunto de servidores. Sólo debemos aprovechar las capacidades existentes en una extensión de STSADM personalizada para implementar un comando de actualización única para todos los servicios:

stsadm -o changepwd -user DOMAIN\Account -oldpwd old_p@ssw0rd
 -newpwd new_ p@ssw0rd

No es realmente necesario para por lo que muchos comandos de actualización diferente. Después de todo, es obvio que debe cambiar la contraseña en todas las ubicaciones, incluidos Active Directory, base de datos de configuración, la base de datos de servicios de Windows, IIS y lo que otros repositorios de credencial un servicio determinado puede utilizar.

No es una opción para dejar una contraseña obsoleta detrás. Tener una extensión de comandos se encargan de todas las dependencias implica los cambios de contraseña más coherentes entre todos los recursos afectados y menos problemas de relacionadas con la contraseña en el conjunto de servidores.

Además, la implementación de una extensión de STSADM es fácil y divertido. Sólo siga los pasos descritos en el SDK de WSS debajo del título" Cómo: Extender la utilidad STSADM." También se recomienda que desprotege Blog de Gary Lapointe Para ejemplos grandes y una lista impresionante de extensiones útiles que puede resultarle útil para su trabajo diario como un administrador de SharePoint.

Con los detalles implementación de STSADM fuera de la vista, se pueden concentrar nuestros esfuerzos en la implementación de la solución real, que es difícil suficiente teniendo en cuenta que puede de servicios de SharePoint usar cualquier número de credenciales. Esto puede incluir las identidades de procesos, las identidades de grupo de aplicaciones y otras cuentas.

Sólo no se puede conocer las dependencias de seguridad de cada servicio de SharePoint con antelación. Puede obtener inmediatamente con los servicios estándar de WSS y MOSS, pero una solución realmente útil también debe admite servicios personalizados con requisitos diferentes.

Tratar con diversos se consigue mejor a través de una API. La API decouples la extensión de comandos de los servicios subyacentes y de este modo permite a los desarrolladores conectar en sus propios componentes que contengan la lógica para llevar a cabo los cambios de contraseña para sus servicios.

LLAMO a estos componentes conectables servidores proxy de servicio. Por confiar en estos componentes de servidor proxy, la extensión de comandos puede alojar cualquier servicio, los programadores no tienen que ofrecer herramientas de actualización de contraseña adicional ya y los administradores no tienen que tratar ya complejidades de seguridad de servicios subyacentes. Así se reduce la carga administrativa para mantener cuentas de seguridad en un entorno de SharePoint.

Nuestro proxy de servicio API debe realizar dos acciones básicas: debe habilitar la extensión de comandos para determinar las cuentas de seguridad de cada servicio admitidos, y debe habilitar la extensión de comando para actualizar las contraseñas asociadas. En consecuencia, la API requiere dos métodos: Resolve­Identities y ChangePassword.

En primer lugar, la extensión del comando enumera todos los servicios en el conjunto de servidores mediante la colección SPFarm.Local.Services. Para cada tipo de servicio, la extensión del comando de carga también dinámicamente un proxy de servicio registrado para el servicio en un archivo de configuración basado en XML que sigue la convención de nomenclatura passwordproxies.*.xml (como passwordproxies.WSSProxies.xml).

A continuación, la extensión de comandos llama al método ResolveIdentities del proxy de servicio registrado pasando a lo largo de una referencia al objeto servicio. El componente proxy extrae las cuentas de seguridad deseado desde el servicio subyacente y devuelve esta información a la extensión de comando.

El resultado es una asociación entre las cuentas de seguridad y servicios que es lo contrario de la asociación está establecida en el modelo de objetos de SharePoint. En lugar de los servicios que se los padres de las cuentas de seguridad, las cuentas de seguridad son ahora los elementos primarios de servicios, como se muestra en la figura 3 . Esta arquitectura refleja la relación real entre servicios y cuentas de seguridad mejor.

La figura 3 reversión la relación entre las cuentas de seguridad y servicios de SharePoint

Más importante, la extensión de comandos puede actualizar ahora las cuentas de seguridad de Active Directory y, a continuación, se recorrer en iteración todos los objetos de servicio dependiente para llamar al método ChangePassword de los proxies correspondientes para actualizar la contraseña.

De nuevo, los componentes de servidor proxy contienen la lógica específica del servicio necesario para llevar a cabo los cambios de contraseña. La extensión del comando no tratan los detalles de implementación específica del servicio.

Si está interesado en los detalles, desproteger el archivo de SPPwdServiceProxy.cs en el material complementario. Define el proxy API por medio de una clase de SPPwdServiceProxy abstracta con sus dos métodos, ResolveIdentities y ChangePassword. Para obtener ejemplos de implementación, vea las definiciones de clase en la biblioteca de clase WSSProxies.

La biblioteca WSSProxies ilustra cómo utilizar el proxy de servicio API para realizar los cambios de contraseña de los servicios estándar de WSS 3.0. No es complicado cambiar las contraseñas de cuentas de seguridad mediante programación. Todo lo que necesita son tres líneas de código para las identidades de procesos y las mismas líneas tres de las identidades de grupo de aplicación. El modelo de objetos de SharePoint realiza el resto.

Sólo la cuenta de rastreo de la clase SPSearchService plantea un desafío porque Microsoft marcada la escritura de contraseña de rastreo, por lo que no puede leer con los métodos normales. Así resulta complicado para la solución a los desarrolladores crear soluciones de seguridad.

Vaya a la distancia total

Con una extensión único comando que cubren todos los servicios, permítanos centrar nuestra atención en un par de oportunidades de mejora adicional. La primera es eliminar la necesidad de especificar las contraseñas en texto sin cifrar en un símbolo del sistema, que no es un método seguro. Incluso el cuadro de contraseña más sencillo la interfaz de usuario gráfica de podría enmascarar esta información.

Otra posibilidad es aumentar la complejidad de contraseñas sin aumentar la carga administrativa. Quizás contraseñas con siete caracteres alfanuméricos aleatorios eran una vez que se considera seguro, pero que hipótesis estableció hace mucho tiempo y probablemente no mantiene true para que las cuentas de seguridad ahora.

¿Utilizar 50 o más caracteres para recursos importantes, tales como las cuentas de seguridad de SharePoint: 3ZK2AQUuqZ7/M7­NBIEvc {XKregSMaVmQgiZaZXik­hL8E {dQuwyQ para el conjunto de servidores cuenta; TA3pIa7yUyJikc6FxTFl = K9EQcb8lBn­hp8ej03lt3 + mA = 7aqgKA para la aplicación Web predeterminada; DLj­XYA PXMzzAxrHvO/L9MZyd0SkVuMv9/co0ocluYCq/4TID/n + para la cuenta de servicio búsqueda; y qjoNlEvOX $ 7vbEjrnDd5lXLPYvZEFf­gRpij $8amSbEVpj2O474Q para la cuenta del rastreador?

Produce me tan divertido que suponga un administrador especificar estos tipos de contraseñas manualmente. Otra mejora oportunidad está relacionada con comprobaciones de seguridad. De forma predeterminada, SharePoint no advierte configuraciones de seguridad débil, tales como grupos de aplicaciones tener acceso a la metabase de IIS o utilizando la cuenta de conjunto de servidores como su identidad de seguridad. Una solución personalizada puede realizar estas comprobaciones de forma regular.

Y por último, ¿por qué es administradores de SharePoint necesario que tratar con estas contraseñas de cuentas de seguridad? Los atacantes son, quizás, sólo los interesados en conocer estas contraseñas. Los administradores generalmente no hay que utilizarlas.

Por supuesto, SharePoint ofrece una gran cantidad de opciones para abordar estas oportunidades. Puede utilizar secuencias de comandos, pero las secuencias de comandos suele controlen las contraseñas en texto sin cifrar. Puede utilizar trabajos del temporizador personalizados, que procesa el servicio de temporizador de SharePoint en intervalos programados, pero el servicio de temporizador ya se ocupa de muchas tareas, incluidas las implementaciones de credenciales.

Sería difícil coordinar los trabajos de implementación de credenciales con trabajos de cambio de contraseña. Parecía mejor implementar un servicio independiente de SharePoint que utiliza la cuenta de conjunto de servidores como su identidad de proceso para obtener acceso completo al modelo de objetos administrativo de SharePoint.

Entre otras cosas, puede detener este servicio en cualquier momento sin que afecte a otros procesos, y puede deshabilitar este servicio si lo prefiere cambiar las contraseñas manualmente. La solución incluye varias herramientas para este propósito, tales como las extensiones de comando Stsadm, una aplicación de Windows y páginas de aplicación de administración central personalizadas, como se muestra en la figura 4 .

Figura 4 arquitectura de la solución SPPwd

Básicamente, todas las aplicaciones de SPPwd dependen el mismo conjunto de extensiones de STSADM, por lo que es sólo una ruta de código independientemente de qué herramienta que use. A través de una capa de lógica de negocios comunes, las extensiones de comandos en combinación con servidores proxy de servicio realiza el real proceso, aunque las aplicaciones SPPwd utilizan objetos de código auxiliar para cargar las extensiones de comando dinámicamente durante la ejecución.

Este acoplamiento flexible permite reemplazar determinadas extensiones de comando sin tener que modificar las aplicaciones SPPwd. Por ejemplo, si prefiere utilizar un generador de contraseña diferente, puede crear una extensión de comando, implementarlo en la caché de ensamblados global y, modificar la entrada del comando genpwd en el archivo de configuración stsadmcommands.passwordmanagement.xml. La solución lo coloca en la carpeta % Archivos de programa%\Archivos comunes\Microsoft Shared\Web Server Extensions\12\Config según las convenciones de extensibilidad de Stsadm.

El generador de predeterminada crea esas contraseñas largas, que deberían ser suficientes en la mayoría de los casos. la figura 5 muestra las extensiones de comando SPPwd con una breve descripción de su finalidad. También puede utilizar el stsadm - ayudar a comando de <extension> para mostrar más información acerca de los parámetros disponibles y ejemplos de línea de comandos.

Implementación y uso de la solución

Las hojas en el material complementario describen en detalle cómo implementar y utilizar la solución SPPwd en un entorno de un solo servidor así como en un conjunto de servidores. Sólo necesita implementar la solución en un servidor de SharePoint mediante los comandos de Stsadm addsolution y deploysolution estándar.

SharePoint, a continuación, distribuye la solución a todos los servidores del conjunto a través de trabajos del temporizador. Tan pronto como se han completado estas tareas, puede activar la característica de solución para ampliar el sitio de administración central e instalar el servicio de Windows mediante la extensión del comando sppwdsetup.

El material complementario incluye un archivo DeployTo.bat para automatizar estas tareas. Entre otras cosas, el archivo por lotes muestra cómo se espere a que los trabajos del temporizador completar antes de continuar con más pasos de implementación.

De forma predeterminada, el servicio SPPwd sólo está disponible en el servidor que ejecuta el archivo DeployTo.bat. Se puede configurar el servicio para ejecutar en varios servidores de SharePoint, pero hay sólo una instancia de una cuenta de seguridad en Active Directory y impone los dos siguientes requisitos: se puede autoridad para una cuenta de seguridad sólo una instancia de servicio SPPwd, y la cuenta de seguridad no debe utilizarse en varios conjuntos de servidores.

Tener varias instancias de servicio el mismo proceso cuenta puede conducir a problemas de acceso simultáneo y no es necesario ya que SharePoint propaga automáticamente las actualizaciones de credenciales en el conjunto de servidores local. Compartir cuentas no se admiten porque el servicio SPPwd no puede actualizar información de la cuenta de seguridad a través de varios conjuntos de servidores de seguridad.

El servicio SPPwd sólo actualiza las cuentas de seguridad que especifican el nombre de dominio en el atributo adminDescription más completo del servidor y que confirmar en su atributo de descripción que se sólo utilizan en el conjunto de servidores de SharePoint local, como se indica en la figura 6 . Consulte el material complementario para obtener más información acerca de la configuración de cuentas de seguridad y el servicio de SPPwd para automatizar los cambios de contraseña.

Figura 6 SPPwd implementación y configuración de cuenta de seguridad

Conclusión

Las cuentas de seguridad son los objetivos principales de ataques, ya que pueden proporcionan acceso completo a todas las colecciones de sitios y datos del sitio en un conjunto independientemente de permisos y controles de acceso definidos en el nivel de SharePoint. Una estrategia básica para impedir que estos ataques aceptación es utilizar contraseñas de cuenta de alta seguridad y cambiar con frecuencia.

Este es un desafío para realizar porque las cuentas de usuario de dominio no cambien sus contraseñas por sí solos. Debe realizar los cambios de contraseña manualmente o utilizar una solución automática. Cualquier forma elegir, existen numerosas dependencias que la documentación del SharePoint y el SDK de WSS no describen muy bien.

Debe actualizar y implementar contraseñas modificadas y existen problemas adicionales relacionados con la cuenta de conjunto de servidores. Por ejemplo, cuando se cambia la contraseña de la cuenta del conjunto de servidores, que se cambie credencial clave el conjunto de servidores, y esto afecta a la recuperación de la base de datos de configuración de copia de seguridad.

No obstante, no hay alternativa a cambiar la contraseña de cuenta de conjunto de servidores con regularidad si desea mantener la seguridad del sistema en un conjunto de SharePoint. Asegúrese de que realizar una copia de seguridad después de cambiar la contraseña de cuenta de conjunto de servidores.

Automatizar los cambios de contraseña es complicado a pesar del hecho de que el modelo de objetos SharePoint incluye la lógica necesaria para llevar a cabo las actualizaciones de credenciales. Podría parecer sencillo primera vista, pero incluso una solución basada en secuencias de comandos puede convertir rápidamente en un gran desafío. Una solución completa se basa en Microsoft .NET Framework y el modelo de objetos administrativo de SharePoint es una buena elección, pero la mejor solución sólo puede proceder directamente de Microsoft en forma de innovaciones de cuenta adicionales del sistema.

Casi 10 hace años, Microsoft modificó la cuenta del sistema local para adaptarse a las necesidades de los clientes de empresa utilizando Microsoft Exchange Server. Esto causó finalmente de la cuenta de servicio de red con Windows Server 2003. Pero la cuenta de servicio de red no es adecuada para conjuntos de servidores, por lo que aún se debe utilizar cuentas de usuario de dominio y tratar el mantenimiento asociado y problemas de seguridad a lo mejor de nuestras capacidades.

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.