Como resolver erros de acesso negado com stsadm -o retractsolution

Question

Temos um farm de 2 servidores executando o MOSS 2007 SP1. Eu sou um membro do grupo Administradores em ambos os servidores.

Eu também sou membro do grupo Administradores de Farm.

Eu precisava atualizar algumas soluções, então comecei naturalmente com o comando stsadm retractsolution nas soluções antigas. Não importa qual solução eu tente executar o comando, eu volto 'Acesso negado'.

O arquivo de log do ULS, felizmente, me fornece um pouco mais de informações:

System.Data.SqlClient.SqlException: Cannot open database "SharePoint_AdminContent" requested by the login. The login failed.  Login failed for user '***My Domain Login***'.

O que parece estranho aqui é o fato de o SharePoint estar tentando se conectar com MY conta usando a Autenticação Integrada do Windows em vez de se conectar com a conta de serviço do Farm configurada. É claro que minha conta não tem acesso ao banco de dados de conteúdo do administrador.

Portanto, a pergunta é: minha conta precisa receber permissões para o banco de dados de conteúdo do administrador para executar tarefas de administração? Espero que não, então algo está terrivelmente errado?

    

Answer 1

A resposta curta é "sim" para a maioria das atividades que você executará via STSADM em bancos de dados SQL.

Para a esmagadora maioria dos comandos STSADM que são executados diretamente na API do SharePoint (em vez de agendar tarefas para executar uma ação), o contexto de segurança dentro do qual os comandos são executados é seu - o usuário conectado. Como você viu no exemplo citado, o contexto da conta do usuário é o que será usado para a retratação. Se você não tiver os direitos apropriados no SQL para executar a operação, ela falhará (como você viu).

Isso contrasta com a maioria das atividades que você realiza por meio da interface do usuário (ou seja, Central Admin). No exemplo citado, a remoção da solução por meio do Central Admin resultaria na execução do comando no contexto da conta de serviço do farm, pois essa conta é a identidade do pool de aplicativos do site do Central Admin. Resultado: a retirada seria bem-sucedida mesmo que você (pessoalmente) não tenha permissões para o banco de dados associado.

Se o seu ambiente for configurado de forma que sua conta não tenha acesso em nível de administrador aos bancos de dados do farm do SharePoint, eu recomendaria realizar o máximo de atividades possível por meio da interface do usuário para evitar o tipo de problemas de contexto de segurança está encontrando. Você verá que pode fazer mais do que precisa fazer dessa maneira. Uma exceção notável que vem à mente, no entanto, é adicionar uma solução (STSADM -o addsolution) ao armazenamento de solução do farm - não existe uma contraparte de interface do usuário com o comando STSADM.

Como alternativa, você pode fazer algo semelhante ao sugerido pelo MadlyAlive (ou seja, efetuar login com a conta de serviço do farm) ... embora o acesso de administrador local da conta de serviço do farm não seja obrigatório nem recomendado pela Microsoft. Você também pode ter sua conta concedida o conjunto mínimo de permissões dentro do SQL Server necessário para realizar suas operações.

Para obter mais informações, consulte o artigo da Microsoft no link .

Recapitulação de regra geral: o STSADM usa o contexto da sua conta, o administrador central usa o contexto da conta de serviço do farm.

Espero que isso ajude!

    

Answer 2

Isso pode estar evitando o problema principal, mas ao tentar executar um comando stsadm similar

stsadm -o preupgradecheck

Eu também estava recebendo o Access Denied. Mas a execução do Prompt de Comando como Administrador me permitiu executá-lo.