Estás trabajando sin conexión, espera a que vuelva la conexión a Internet

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

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
Resumen
Este artículo proporciona información acerca de cómo configurar la seguridad de trasvase de registros. Hay varias cuestiones a considerar cuando configure la seguridad para SQL Server trasvase de registros que van desde la cuenta de inicio de 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.

back to the top

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

Cuenta de dominio

Si ha colocado de SQL Server en un dominio, Microsoft recomienda que utilice una cuenta de dominio para iniciar los servicios de SQL Server. Debe utilizar una cuenta de dominio si va a configurar SQL Server para ejecutarse como un servidor Virtual en organización por clústeres de Windows. Una cuenta de dominio proporciona la ventaja de un mantenimiento mínimo en caso de cambios de contraseña. Sin embargo, no puede iniciar SQL con 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 ha configurado SQL Server para utilizar el trasvase de registros, puede utilizar seguridad de paso a través de la red. Con la 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 del segundo equipo, seguridad de red tradicional no se ejecuta si existe la misma cuenta (en la que se inicia el servicio SQL Server solicitante) con la misma contraseña. Como mucho tiempo la cuenta en el segundo equipo está configurada con suficientes permisos para llevar a cabo la tarea que se solicita mediante una llamada a SQL Server, la tarea tendrá éxito.

Cuenta del sistema local

También puede configurar SQL Server para iniciar bajo la cuenta Sistema Local. Modificar la contraseña de la cuenta LocalSystem puede resultar en la falla de algunos servicios que son esenciales para la estabilidad del sistema. Esta cuenta es local en el equipo donde reside, lo que significa que el contexto de seguridad que utilizan los servicios de SQL Server 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 se inicia SQL Server bajo la cuenta LocalSystem ya que las contraseñas de 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 producirá el final fallido de tareas.

Para obtener información acerca de los derechos mínimos necesarios para una cuenta de red iniciar correctamente y ejecutar servicios de SQL Server y agente de SQL Server, vea el tema siguiente en los libros en pantalla de SQL Server:back to the top

Descripción del modelo de seguridad de SQL Server

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

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

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

Configuración del trasvase de registros

Requisitos de seguridad

Recurso compartido de copia de seguridad

Configurar el recurso compartido de red que está configurado para almacenar las copias de seguridad del registro de transacciones tiene permisos de lectura y modificación de la cuenta en la que SQL Server están iniciando servicios (en el servidor secundario que está configurada para trasvase de registros).

El recurso compartido de red que está configurado para almacenar las copias de seguridad del registro de transacciones, debe configurarse para tener permisos de lectura y modificación de la cuenta en que SQL Server va a iniciar servicios en el servidor secundario configurados para el trasvase de registros. Se tiene acceso a este recurso compartido por 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. El trabajo de carga, a continuación, carga estas copias de seguridad de la carpeta local.

Cruzar dominio de trasvase de registros

Si se colocan los equipos que ejecutan SQL Server en un entorno de dominios múltiples, Microsoft recomienda configurar confianzas bidireccionales entre todos los dominios que están implicadas en el trasvase de registros. Sin embargo, si no se 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 que describe la opción de inicio de cuenta de red LocalSystem para servicios relacionados con SQL Server.

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

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

back to the top

Configuración de seguridad en el servidor secundario para bases de datos en espera

Si configura la base de datos secundaria en modo de espera, puede tener 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 por el que se va a ejecutar informes sin conexión, con lo que se descarga parte del trabajo del sistema de producción. Sin embargo, la base de datos de reserva admitir la funcionalidad de sólo lectura, tendrá que aplicar la misma configuración de seguridad en el servidor secundario. Dado que la base de datos está en estado de espera, ni siquiera pueden hacerse modificaciones a efectos de la configuración de seguridad. En este caso, deberá crear todos los inicios de sesión de SQL Server con los mismos valores de SID en el servidor secundario. Inicios de sesión de Windows conservan automáticamente el mismo 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 inicios de sesión SQL con el mismo SID en diferentes servidores, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
303722 Cómo conceder acceso a inicios de sesión de SQL en una base de datos en espera cuando "Invitado" usuario está deshabilitado
back to the top

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 para que asuma como la principal. Puede hacerlo con o sin el servidor principal está en línea. Como parte del cambio de función, hay hasta cuatro procedimientos almacenados que se ejecutan. Uno de estos procedimientos almacenados, sp_resolve_logins, ayuda a corregir los valores de SID para los inicios de sesión que residen en la base de datos en espera antes de ponerlo a disposición para su uso como 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 se encuentra en esta tabla temporal a la tabla syslogins de la base de datos MASTER del servidor secundario y 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 secundaria, se corrige el SID (en la base de datos secundaria) con sp_change_users_login para que coincida con uno que se encuentra en la tabla syslogins.

Configuración de seguridad mediante este procedimiento almacenado requiere lo siguiente:
  • Inicios de sesión 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 de 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 errores corregir los inicios de sesión.
Antes sp_resolve_logins realmente puede resolver los inicios de sesión en la base de datos secundaria 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 de SID debe coincidir entre el inicio de sesión, el archivo .bcp y la tabla sysusers de la base de datos secundaria
  3. El valor del SID de la base de datos secundaria debe ser diferente del valor de SID en la tabla syslogins de la base de datos MASTER en el servidor secundario.
Si crea inicios de sesión de SQL Server como se describe en Q303722, no tiene que ejecutar este procedimiento almacenado, porque todos los inicios de sesión son estar ya presentes con el mismo valor de SID en la tabla syslogins (en la base de datos MASTER en el servidor secundario) y la tabla sysusers (de la base de datos secundaria).

back to the top

Preguntas más frecuentes

¿Pregunta: propaga el trasvase de registros 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, éstas se propagan a través al servidor secundario (o servidores) automáticamente.

¿Pregunta: puede tiene dos inicios de sesión en el servidor secundario con el mismo SID? Esto es necesario ya que estoy usando el mismo equipo de SQL Server para mantener varias bases de datos de reserva 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 se utiliza el trasvase de registros con varios servidores, la única forma de corregirlo es quitar 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 de cambio de función de trasvase de registros, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
314515 INF: Preguntas - SQL Server 2000 - más el trasvase de registros
back to the top

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 321247 - Última revisión: 02/01/2016 00:10:00 - Revisión: 4.0

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

  • kbhowtomaster kbmt KB321247 KbMtes
Comentarios
/html>xx-4xxx-Rxxx-xxxxxxxxxxxx".replace(/x/g, function () { return Math.floor(Math.random() * 16).toString(16); })).replace("R", (8 | Math.floor(Math.random() * 3)).toString(16)); var m = document.createElement("meta"); m.content = guid; m.name = "ms.dqid"; document.getElementsByTagName("head")[0].appendChild(m);