Cómo configurar la seguridad para SQL Server trasvase de registros

Seleccione idioma Seleccione idioma
Id. de artículo: 321247 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

Este artículo proporciona información acerca de cómo configurar la seguridad de trasvase de registros. Hay varios problemas a considerar cuando se va a configurar seguridad para SQL Server trasvase ese intervalo de la cuenta de inicio para SQL Server compartir permisos para el recurso compartido de red donde residen las copias de seguridad del registro de transacciones. Estos problemas se describen en este artículo.

Cuenta de inicio para SQL Server y servicios de Agente SQL Server en servidores de trasvase de registros

Cuenta de dominio

Si SQL Server se ha colocado en un dominio, Microsoft recomienda que utilice una cuenta de dominio para iniciar servicios de SQL Server. Debe utilizar una cuenta de dominio si va a configurar SQL Server para ejecutarse como un servidor virtual en clúster de Windows. Una cuenta de dominio proporciona la ventaja de mantenimiento mínimo en el caso de los cambios de contraseña. Sin embargo, es posible que no pueda iniciar SQL bajo una cuenta de dominio si SQL Server reside en un servidor que está en un grupo de trabajo.

Cuenta de red local

Puede utilizar SQL Server para iniciar bajo una cuenta de red creadas localmente. En la situación donde no hay acceso a la red requerida por un proceso de SQL Server, que es el caso si se ha configurado SQL Server para utilizar el trasvase de registros, puede utilizar seguridad de paso a través de la red. Con seguridad de paso a través, todos los equipos que tendrán acceso a SQL Server deben tener la misma cuenta de red con la misma contraseña y permisos apropiados, configurados localmente. Además, cuando el proceso de SQL Server solicita recursos desde el segundo equipo, la seguridad de red tradicional se omite si la cuenta misma (bajo la que se inició el servicio de SQL Server solicitante) existe con la misma contraseña. Como largo la cuenta en el segundo equipo está configurada con permisos suficientes para llevar a cabo la tarea que se solicita mediante una llamada a SQL Server, la tarea será correcta.

Cuenta de sistema local

También puede configurar SQL Server para iniciar en la cuenta sistema local. Modificar la contraseña de la cuenta LocalSystem, puede producir el error de algunos servicios que son críticas para la estabilidad del sistema. Esta cuenta es local en el equipo donde reside, lo que significa que el contexto de seguridad que utiliza servicios de SQL Server es local. Como se indicó en la sección cuenta de red local, no puede utilizar seguridad de paso a través de la red cuando inicie SQL Server bajo la cuenta LocalSystem, porque las contraseñas para la cuenta LocalSystem en diferentes equipos son diferentes. El inicio de SQL Server bajo esta cuenta cuando se requiere acceso a recursos de red probablemente dará como resultado el final fallido de tareas.

Para obtener información acerca los derechos necesarios mínimos para una cuenta de red para iniciar y ejecutar servicios de SQL Server y Agente SQL Server correctamente, vea el tema siguiente en los libros en pantalla de SQL Server:
Setting up Windows Service Accounts

Descripción del modelo de seguridad SQL Server

Para comprender completamente las implicaciones de seguridad, es importante entender el modelo de seguridad que Microsoft implementó en SQL Server 2000. Cuando crea un inicio de sesión, se agrega a la tabla syslogins de la base de datos MASTER . Para cada base de datos que este inicio de sesión recién agregadas se proporciona acceso a, se agrega a la tabla sysusers de esa base de datos. La asignación entre tabla syslogins y la tabla sysusers está en el campo de SID.

Si una base de datos de usuario se mueve a un servidor diferente, los valores SID se transfieren desde el servidor anterior. Saltos de seguridad de cualquier base de datos cuando no se crean inicios de sesión en el segundo servidor con los mismos valores de SID o si la seguridad está configurada incorrectamente debido de no coinciden los valores de SID.

Para obtener información adicional, haga clic en el número de artículo siguiente para ver el artículo en Microsoft Knowledge Base:
240872INF: Cómo resolver problemas de permisos cuando se traslada una base de datos

Configuración de trasvase de registros

Requisitos de seguridad

recurso compartido de copia de seguridad

Configurar el recurso compartido de red está configurado para almacenar las copias de seguridad de registro de transacciones para tener read/change permisos para la cuenta en qué SQL Server están iniciando los servicios (en el servidor secundario configurada para trasvase de registros).

Recurso compartido de red está configurado para almacenar las copias de seguridad del registro de transacciones, debe configurarse para tener read/change permisos para la cuenta en qué SQL Server están iniciando los servicios, en el servidor secundario configurado para log-shipping. El trabajo de copia en el servidor secundario para copiar las copias de seguridad del registro de transacciones a la carpeta local en el servidor secundario respectivo tener acceso a este recurso compartido. El trabajo de carga, a continuación, carga estas copias de seguridad desde la carpeta local.

entre el trasvase de dominio

Si los equipos que ejecutan SQL Server se colocan en un entorno con varios dominios, Microsoft recomienda que configure confianzas bidireccionales entre todos los dominios implicados en el trasvase de registros. Sin embargo, si no puede establecer confianzas entre dominios, puede utilizar seguridad de paso a través de la red para el trasvase de registros. Consulte la sección de este artículo se describe la opción de inicio de cuenta de red de LocalSystem para los servicios relacionados con SQL Server.

Seleccionar el modo de autenticación para conectarse a servidor de supervisión

Puede seleccionar autenticación de Windows o autenticación de SQL (mediante servidores principales y secundario) para conectarse al servidor de supervisión y actualizar las tablas monitor. Puede seleccionar esto cualquiera mientras la configuración de trasvase de registros o una vez haya configurado el trasvase de registros y es funcional. De forma predeterminada, SQL Server utiliza autenticación de Windows; sin embargo, si selecciona autenticación de SQL, se crea un nuevo de inicio de sesión SQL log_shipping_monitor_probe en el principal, secundaria, y supervisar los servidores si no existe. Si selecciona autenticación de SQL para este propósito, configurar SQL Server para utilizar la opción SQL y la autenticación de Windows .

Configuración de seguridad al servidor secundario de bases de datos de espera

Si configura la base de datos secundaria en modo de espera, puede obtener acceso a esta base de datos en estado de sólo lectura. Al restaurar la base de datos secundaria en este modo, esto puede proporcionar un medio ejecutar informes sin conexión, con lo que se descarga parte del trabajo del sistema de producción. Sin embargo, para que la reserva base de datos admitir la funcionalidad de sólo lectura, quizás tenga que aplicar la misma configuración de seguridad en el servidor secundario. Como la base de datos está en estado de espera, no puede realizar modificaciones incluso a fin de configurar la seguridad. En este caso, tiene que crear todos los inicios de sesión SQL Server con los mismos valores SID en el servidor secundario. Inicios de sesión de Windows conservan automáticamente los mismos SID porque el GUID de Windows es globalmente único, incluso cuando se utilizan varios dominios.

Para obtener información adicional acerca de cómo crear los inicios de sesión de SQL con el mismo SID en diferentes servidores, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
303722Cómo conceder acceso a inicios de sesión de SQL en una base de datos en espera cuando "Invitado" usuario está deshabilitado

Configuración de seguridad al realizar el cambio de función

El procedimiento de cambio de función de trasvase de registros implica promover un servidor secundario a asumir como el principal. Puede hacerlo con o sin el servidor principal está en línea. Como parte del cambio de función, son hay hasta cuatro procedimientos almacenados que se ejecutan. Uno de estos procedimientos almacenados, sp_resolve_logins , ayuda a corregir los valores SID para los inicios de sesión residen en la base de datos espera justo antes de que estará disponible para su uso como la base de datos principal.

Como parte de este procedimiento almacenado, se carga un archivo .bcp de la tabla syslogins del servidor principal anterior en una tabla temporal. A continuación, se compara cada inicio de sesión que está presente en esta tabla temporal a la tabla de syslogins de la base de datos MASTER del servidor secundario y a la tabla sysusers de la base de datos secundaria. Para cada inicio de sesión en la tabla temporal que tiene un inicio de sesión con el mismo nombre en la tabla syslogins y el mismo SID que uno en la tabla sysusers de la base de datos secundario, el SID está corregido (en la base de datos secundario) mediante el uso sp_change_users_login para coincidir con uno que esté en la tabla syslogins.

Configuración de seguridad utilizando este procedimiento almacenado requiere lo siguiente:
  • Inicios de sesión de SQL deben estar ya creados en el servidor secundario. Para ello, utilice la tarea DTS de inicios de sesión de transferencia (que se explica en el tema de libros en pantalla de SQL Server, "Cómo configurar y realizar el cambio de función trasvase de registros".
  • Debe proporcionar un archivo .bcp de la tabla syslogins del servidor principal. Este archivo debe ser actual porque podría producir un archivo obsoleto sp_resolve_logins imposibilidad de resolver los inicios de sesión.
Antes sp_resolve_logins realmente puede corregir los inicios de sesión en la base de datos secundario debe cumplir las tres condiciones siguientes:
  1. El nombre de inicio de sesión desde el archivo .bcp de la tabla syslogins debe coincidir con el nombre de la tabla syslogins del servidor principal.
  2. El valor SID debe coincidir con entre el inicio de sesión el archivo .bcp y la tabla sysusers de la base de datos secundaria
  3. El valor de SID de la base de datos secundario debe ser diferente del valor de SID en la tabla syslogins de la base de datos MASTER del servidor secundario.
Si crea inicios de sesión de SQL Server como se describe en Q303722, no es necesario que ejecutar este procedimiento almacenado, porque todos los inicios de sesión está ya presente con el mismo valor SID en la tabla syslogins (en MASTER base de datos en el servidor secundario) y la tabla sysusers (en la base de datos secundario).

Preguntas más frecuentes

¿pregunta : es trasvase propagar los cambios relacionados con la seguridad a un servidor secundario automáticamente?

respuesta : Sí. Dado que todos los cambios en las tablas del sistema son operaciones registradas, estos se propagan mediante el servidor secundario (o servidores) automáticamente.

¿pregunta : puede tiene dos inicios de sesión en el servidor secundario el mismo SID? Es necesario porque estoy utilizando el mismo equipo de SQL Server para mantener varias bases de datos espera de varios servidores.

respuesta : no. Modelo de seguridad de SQL Server no permite tener dos inicios de sesión con el mismo SID. Si hay un conflicto en SID mientras utiliza el trasvase de registros con varios servidores, la sólo para corregir este problema consiste en colocar el inicio de sesión en conflicto en el servidor principal y después de crearlo con un SID que no existe en el servidor secundario.
Para obtener información adicional acerca del cambio de función de trasvase de registros, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
314515INF: Trasvase - SQL Server 2000 - preguntas más frecuentes

Propiedades

Id. de artículo: 321247 - Última revisión: miércoles, 21 de diciembre de 2005 - Versión: 3.5
La información de este artículo se refiere a:
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Palabras clave: 
kbmt kbhowtomaster KB321247 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 321247

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com