Não é possível ver todos os catálogos em um servidor vinculado MSSQL

5

No SqlServer 2000, criei um servidor vinculado a uma máquina SqlServer 2005, com "Server type" definido como "SQL Server" (primeiro botão de opção) e o nome do servidor vinculado definido como hostname da máquina remota.

Mas o SqlServer 2000 só pode ver um dos muitos catálogos que estão no servidor 2005. Eu posso SELECT das tabelas daquele catálogo, mas não consigo acessar nenhum dos outros catálogos no mesmo servidor 2005.

Quais são algumas das configurações que eu poderia procurar para descobrir por que isso está acontecendo, ou há um limite para o número de catálogos que o SqlServer 2000 pode ver em um servidor vinculado?

    
por Chris Wenham 23.07.2009 / 15:55

3 respostas

4

Você precisará editar as configurações de segurança do servidor vinculado para especificar um login na instância do SQL 2005 que tenha permissões para todos os catálogos que você deseja acessar por meio do servidor vinculado. Eu não tenho mais um servidor SQL 2000 para dar-lhe as etapas exatas, mas aqui está um artigo do MSDN descrevendo como estabelecer segurança para servidores vinculados ao SQL 2000 .

EDITAR:
Consulte este artigo no SQL Server Central para configurar a autenticação Kerberos para permitir vinculação servidores para usar as credenciais do usuário atualmente conectado para autenticar no servidor de destino. Veja também as respostas à minha pergunta em configurando a delegação de confiança para o SQL Server .

    
por 23.07.2009 / 16:10
2

Você está recebendo este problema porque o Kerberos está configurado no meio do caminho. Você está enfrentando um problema de duplo salto. Aprendi algumas coisas sobre como configurar servidores vinculados nos últimos dias. Este documento em ' Como implementar a delegação restrita de Kerberos com o SQL Server 2008 ' ajudou-me muito.

Aqui estão alguns pontos-chave sobre o uso de segurança integrada com servidores vinculados (isto é, "Seja feito usando o contexto de segurança atual do login")

  • Sua conta do Windows deve ter acesso ao ServerA e ao ServerB.
  • Os servidores devem usar TCP / IP ou pipes nomeados
  • O ServerA e o ServerB devem ter seu próprio SPN registrado.
    • Você pode ver um login com falha para o erro ANONYMOUS do usuário, se não.
    • Ao usar nomes curtos, ele DEVE ser resolvido para o FQDN com o nome de domínio do diretório ativo. Se você digitar um nome abreviado e ele for resolvido para qualquer outro nome de domínio, mas seu nome de domínio do AD parecer estar interrompido. Como alternativa, use um CNAME no domínio secundário que aponte para o seu nome de domínio do AD.
    • Para verificar o SPN : setspn -l DOMAIN \ SQL_Engine_Svc_Account
    • Para definir o SPN : não sou 100%. Todas essas entradas são necessárias, mas foram adicionadas para abranger todas as maneiras diferentes pelas quais um cliente pode se conectar à instância. Atenção! Esses SPNs diferenciam maiúsculas de minúsculas! . Você deve redefinir a instância depois de definir os SPNs. Você pode deixar o mecanismo registrá-los automaticamente, mas no meu caso, usando aliases de dns, ele nunca seria registrado corretamente.
      • Sintaxe Básica: setspn -A MSSQLSvc / SQLHOSTNAME [FQDN] [: Porta] [: INSTANCE]
      • Instância padrão:
        • setspn -A MSSQLSvc / HOSTNAME DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / HOSTNAME: 1433 DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / HOSTNAME.DOMAIN.ORG DOMÍNIO \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / HOSTNAME.DOMAIN.ORG: 1433 DOMAIN \ SQL_Engine_Svc_Account
      • Instância nomeada:
        • setspn -A MSSQLSvc / HOSTNAME: INSTANCENAME DOMÍNIO \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / HOSTNAME.AD.ORG: INSTANCENAME DOMAIN \ SQL_Engine_Svc_Account
      • Instância nomeada com alias de DNS: (usamos aliases de DNS que são diferentes do nome de host real.)
        • setspn -A MSSQLSvc / ALIAS DOMÍNIO \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS: 1433 DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS: INSTANCENAME DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS.DOMAIN.ORG: 1433 DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS.DOMAIN.ORG: 1433 DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS.DOMAIN.ORG: INSTANCENAME DOMAIN \ SQL_Engine_Svc_Account
  • A conta do mecanismo de sql não deve ter a configuração "A conta é confidencial e não pode ser delegada".
  • Você deve configurar a delegação ao configurar uma conexão do servidor vinculado por salto duplo:
    • Nos usuários do diretório ativo & os computadores encontram a conta de serviço do serviço de mecanismo do SQLServerA (Supondo que você esteja usando uma conta - caso contrário, localize a conta do computador.) Na guia Delegação, selecione 'Confiar neste usuário apenas para delegação a serviços especificados' & 'Use apenas Kerberos' Clique no botão Adicionar. Encontre a conta de serviço para o serviço de mecanismo do SQLServerB. Selecione os SPNs que você configurou anteriormente que pertencem ao servidor vinculado que você está tentando criar.
por 26.08.2015 / 15:09
0

Eu acabei de fazer isso!

O ID de login remoto usado para vincular todo o servidor a outro, precisa ter acesso de leitura / gravação ao banco de dados.

Assim que você der acesso de leitura e gravação ao banco de dados, o banco de dados será exibido na lista de catálogos no servidor vinculado.

Você acessa cada banco de dados > Segurança > usuários e encontrar o Login Remoto. Se não estiver lá, vá para o nível do servidor > Segurança > Usuários > Mapeamento do usuário e verifique o banco de dados a ser vinculado. Agora, certifique-se que o login remoto tem permissões de leitura / gravação, indo para o banco de dados > Segurança > Usuários > Esquema de propriedade verificar o db_datareader e / ou db_datawriter.

Boa sorte!

Jawid

    
por 28.10.2015 / 18:48