Por que um usuário pode conceder-se o direito Fazer logon como um serviço?

7

Este artigo descreve as etapas (relativamente trabalhosas) que você deve seguir passar para conceder a um usuário do Active Directory o direito Fazer logon como um serviço. No entanto, se eu instalar um serviço e especificar manualmente as credenciais de logon da minha conta AD (propriedades de serviço | Logon), o Windows informará que 'A conta [myaccount] recebeu o direito Fazer logon como um serviço.' Em seguida, posso executar o serviço com as credenciais da minha conta. No entanto, em uma reinstalação posterior do serviço (ou às vezes na reinicialização), o serviço é novamente incapaz de iniciar devido a uma falha de login ... até que eu entre e insira manualmente minhas credenciais novamente, e a conta é magicamente 'concedida o direito de fazer logon como serviço. Depois disso, o serviço pode começar novamente com as credenciais da minha conta.

O que está acontecendo aqui? Por que eu aparentemente tenho permissão para conceder esse direito para mim mesmo na hora? Se eu puder conceder isso imediatamente, por que ele não fica garantido e eu tenho que continuar concedendo novamente? Lembre-se de que não estou perguntando como conceder a alguém esse direito através do Active Directory - estou falando do fato de que esse direito parece ser 'concedido automaticamente' pelo Windows quando você insere suas credenciais na janela Logon.

    
por Jez 10.06.2011 / 17:21

4 respostas

8

Parece que há uma política de grupo que define as contas que recebem o Log on como um serviço. Como você é um administrador, você tem permissão para conceder esse privilégio, mas quando a política de grupo reaplicar o privilégio, ele será removido. A próxima vez que o serviço parar, ele não poderá ser iniciado.

Você deve alterar o escopo / filtragem da política para que essa máquina seja isenta ou use a política para conceder o privilégio necessário.

INFORMAÇÕES DOS COMENTÁRIOS: Para verificar se uma política de grupo está aplicando a configuração, use o conjunto resultante do assistente de política (rsop.msc)
Se você quiser aplicar essa configuração a vários computadores ou não puder remover uma política existente que defina essa configuração, use a diretiva de grupo para defini-la. Há um artigo de technet que explica como fazer isso.
Para verificar as configurações de segurança locais atuais, use secpol.msc - expanda Políticas locais e, em seguida, selecione Atribuições de direitos do usuário. Isso mostrará as configurações aplicadas no momento. Se você tiver acesso suficiente e não houver uma política de grupo em vigor, isso permitirá que você edite a política atual. Se os botões de adição / remoção estiverem com falhas, então uma política atualmente define essa configuração.

Se não houver uma política em vigor, permitir que o Windows conceda ao usuário o direito está perfeitamente correto e é apenas um recurso de conveniência fornecido pelo Windows. Como Jez descobriu, se uma política está em vigor, é inútil combatê-la. A política geralmente é reaplicada a cada poucas horas e continuará impedindo quaisquer alterações que você tenha conseguido fazer. (Embora o serviço continue funcionando até que pare por algum outro motivo). Jez mencionou que as coisas que um serviço é identificado por um LUID gerado no momento da instalação. Não sei se esse é o caso ou não, mas o direito de usuário Fazer logon como um serviço não está restrito a nenhum serviço específico. Portanto, não fará diferença QUALQUER serviço no qual você deseja fazer logon. Um perigo de permitir que o Windows atribua o direito para você é que você pode esquecer de remover as contas anteriores e acabar com uma lista enorme de contas que têm o privilégio de fazer logon como um serviço e não há necessidade disso.

Então, para responder ao comentário de Jez um pouco mais diretamente, se houver uma política em vigor, não há sentido em encontrar maneiras de contornar a interface desativada secpol.msc. A interface do usuário é desativada como um aviso para você de que as alterações que você fizer não serão mantidas. Nesse caso, editar a política é o caminho a seguir, seja para conceder o privilégio ou parar de fazer essa configuração, para que ela possa ser atribuída localmente.

EDITAR: Você parece pensar que conceder a um usuário de domínio esse privilégio é de alguma forma diferente de concedê-lo a um usuário local. Não é. Se o PC / Servidor em questão não tiver nenhuma política de grupo aplicada, abra secpol.msc, vá para o privilégio em questão, clique duas vezes, clique em adicionar e selecione a conta desejada. Acabei de tentar isso em um laptop do domínio e a caixa de diálogo Adicionar usuário foi padronizada para o domínio. Se eu quisesse escolher um grupo local, teria que mudar a localização.

Se você clicar duas vezes no privilégio, presumo que veja a lista e os botões adicionar / remover, mas os botões são diasabilizados para que você não possa editar a lista. Isso não pode ser porque você está adicionando uma conta de domínio porque você ainda não selecionou se deseja adicionar uma conta local ou de domínio.

Eu me deparei com exatamente esse problema no trabalho, o serviço que eu estava instalando só estava acontecendo em um PC, então alterar a política não era uma opção. Nós movemos o PC em questão para uma OU onde nenhuma política foi aplicada, então eu poderia conceder o privilégio sem problemas.

O motivo pelo qual você pode conceder o privilégio da forma arredondada é que a política apenas desativa a interface do usuário; na verdade, ela não altera as permissões que você tem. No entanto, reaplica-se periodicamente, e é por isso que a configuração é sobrescrita.

    
por 10.06.2011 / 18:46
3

Esse artigo está descrevendo o ADAM (Modo de Aplicativo do Active Directory), que é bem diferente de sua instalação padrão do Active Directory ... Vale a pena considerar.

Tempo de opinião - Eu também acredito que quando você instala (ou reinstala) um serviço, ele gera um UID para ele no registro. Algumas de suas configurações provavelmente estão ligadas a isso, incluindo a autenticação.

    
por 13.06.2011 / 09:55
1

Vamos ver se entendi -

  1. Você tem um serviço em execução sob sua conta de usuário (em services.msc ele exibe sua conta de usuário ao lado deste serviço)
  2. Para que isso funcione, você atribuiu à sua conta os direitos Fazer logon como um serviço
  3. Após uma reinicialização ou reinstalação do serviço, o serviço falha ao iniciar com um erro de falha de login
  4. Para corrigir isso, basta digitar novamente suas credenciais na configuração do serviço e iniciá-lo

Isso implica que há um problema com suas credenciais salvas, NÃO com a perda periódica do login como um direito de serviço.

Primeiramente, eu recomendaria criar uma nova conta de usuário para executar este serviço, em vez de usar suas credenciais, definir a senha da conta para nunca expirar e conceder o logon da conta como um direito de serviço. A melhor prática é sempre usar uma conta dedicada para o software executado como um serviço, em vez de redefinir as contas de usuário

Depois, veja se você consegue o problema novamente e, se fizer isso, tente descobrir exatamente o que foi feito para causar falha, ou seja, você precisa inserir novamente as credenciais toda vez que o servidor for reiniciado?

Além disso, por que você está reinstalando o serviço periodicamente? Existe algum outro problema com este software?

    
por 13.06.2011 / 13:48
0

Isso não parece ser um problema certo. Alguma chance de sua senha estar mudando entre as reinicializações desse serviço? Se assim for, você precisará alterar redefinir nas configurações de serviço. Melhor criar uma conta de serviço onde a senha não muda

    
por 10.06.2011 / 17:42