Problema de permisos con el publicador...

30/04/2004 - 15:53 por Juan Rosell | Informe spam
Hola,

estoy intentando crear un suscriptor y un publicador para una prueba con
dos máquinas corriendo SQLServer. El problema es que al intentar habilitar
uno de los dos servidores como publicador el asistente da un error. Se queja
de que el SQLAgent está utilizando la cuenta del sistema y me pide que
intente arrancar el servicio con otra; lo intento pero lo único que consigo
es una lista de errores que no me acaban de ayudar demasiado. ¿alguien me
puede echar una mano con esto?

Gracias,

Juan

Preguntas similare

Leer las respuestas

#6 Juan Rosell
03/05/2004 - 09:24 | Informe spam
Gracias a todos. Yo al final usé una cuenta de usuario avanzado para
activar los servicios, pero aún así, tenía un problema en el ordenador que
hacía de suscriptor, daba un error a la hora de hacer la conexión. Intenté
hacer lo mismo pero desde el publicador, forzar al otro servidor a ser
suscriptor, pero el error entonces cambiaba y me decía que el usuario "null"
que intentaba abrir la conexión no tenía permisos en el servidor destino.
No he podido volver a probar (cosas de los proyectos solapados), pero
intentaré seguir los consejos que me habeis dado.

Gracias otra vez a todos,

Juan

"Javier Loria" escribió en el mensaje
news:
Hola:
Yo recomendaria ni una (Administrador de Dominio), ni otra (Miembro de
Administradores Locales).
Si el sistema no requiere de muchisima seguridad, usaria la misma


cuenta
para ambos servicios (Servicio del SQL, Agente de SQL). Esta cuenta es un
usuario de Dominio. No requiere ser miembro del grupo de Administradores


(ni
Locales ni de Dominio) y debe asignarle una clave bien larga (+15
caracteres, con letras, numeros, signos). Esta clave debe cambiarse
regularmente.
Requiere permisos de archivo y en el registro de Windows para poder
iniciar:
> Archivo-> Folder Instalacion de SQL -> Todos los Permisos

Archivo-> Rutas de Base de Datos -> Todos los Permisos

Registry HKEY_LOCAL_MACHINE
-> \Software\Microsoft\MSSQLServer
-> \System\CurrentControlset\Services\MSSQLServer
-> \Software\Microsoft\Windows NT\CurrentVersion\Perflib
Lect/Esc

Derecho
Usuario -> Iniciar Sesion como Servicio.

SQL -> Pertenecer a SysAdmin
=> Los respaldos y DTS es posible que requieran permisos adicionales de
archivos.
Si usas la misma cuenta en ambos SQL la replicacion debe funcionar sin
mayor configuracion. Si usas cuentas diferentes en cada uno de los
servidores el rollo es un poco mas largo.


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.



Maxi escribio:
> mmm Administrador local y no de dominio? y como accedes a las
> unidades de una red por ej? yo no digo de usar el Administrator sino
> una cuenta con los mismos privilegios, en mi experiencia si no usas
> una cuenta de este tipo en SqlServer y Agent tenes algunas
> limitaciones como las que te mencione.
>
> Suerte
>
>
> "Emilio Boucau (en casa)" escribió en el mensaje
> news:
>> Maxi,
>>
>> hay que tener MUCHO cuidado con la cuenta que se utiliza para iniciar
>> servicios de SQL Server (o de cualquier otro producto server). Es
>> recomendable que SQL Server 2000 inicie sobre una cuenta del grupo
>> Administradores Locales (no del dominio) por el solo hecho que es la
>> unica forma en que pueda hacer un bind exclusivo del puerto TCP que
>> use para trabajar (normalmente el 1433). Si no pertenece a este
>> grupo, lo hara en modo shared con lo cual otra aplicacion tambien
>> puede escuchar lo que le llegue a SQL. De ser este caso, se veran en
>> el Event Viewer errores indicando que no pudo hacer un bind
>> exclusivo del port al momento de iniciar el servicio.
>>
>> Naturalmente, esa cuenta tendra una password que no se pueda cambiar
>> ni caduque. La politica de Microsoft con respecto a las cuentas es
>> evitar el bloqueo por reintento ya que esto evidencia una politica
>> debil de passwords. Es decir, en mi PC podras intentar todo lo que
>> quieras forzar la password que no lo lograras y mi cuenta no se
>> bloqueara ...
>>
>>
>> Saludos !
>>
>> Emilio Boucau
>> Buenos Aires - Argentina
>> http://www.portalsql.com


Respuesta Responder a este mensaje
#7 Emilio Boucau \(en casa\)
04/05/2004 - 01:12 | Informe spam
Javier,

estoy totalmente de acuerdo con lo que expones de derechos y privilegios,
pero si necesitas que SQL Server haga un bind exclusivo del port TCP que
use, la unica forma de hacerlo es esa. No hay otra. Cuando se te plantee el
caso, te vas a acordar ... Pero con asegurar esa cuenta con una politica de
password como la que decis, se duerme tranquilo.


Saludos !

Emilio Boucau
Buenos Aires - Argentina
http://www.portalsql.com
Respuesta Responder a este mensaje
#8 Javier Loria
04/05/2004 - 05:11 | Informe spam
Hola Emilio:
Alguna razon por la que este preocupado por el Bind Exclusivo?
La recomendacion de no usar una cuenta con permisos de Administrador, no
es mia es de MS y de algunos otros gurus de SQL. La intencion es que si
algun hacker logra acceder al servidor de SQL no necesariamente logre
control de la maquina. Por eso queria saber de donde viene esta
preocupacion?

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda..
Emilio Boucau (en casa) escribio:
Javier,

estoy totalmente de acuerdo con lo que expones de derechos y
privilegios, pero si necesitas que SQL Server haga un bind exclusivo
del port TCP que use, la unica forma de hacerlo es esa. No hay otra.
Cuando se te plantee el caso, te vas a acordar ... Pero con asegurar
esa cuenta con una politica de password como la que decis, se duerme
tranquilo.


Saludos !

Emilio Boucau
Buenos Aires - Argentina
http://www.portalsql.com
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida