Executando um programa administrativo em conta de usuário - edição de domínio

1

Estou arrancando meu cabelo aqui - poderia usar uma pequena ajuda.

Parece que o RUNAS clássico não funciona em um ambiente de domínio. Pelo menos, não consigo executá-lo em um ambiente baseado em domínio do Windows Server 2012 R2 e do Windows 8.1.

Inicialmente, tentei configurar as Contas de serviço gerenciadas de acordo com este artigo , para criar uma conta administrativa que poderia ser usado para escalada de privilégios para um programa que é muito mandão para suas próprias braces, mas enquanto eu era capaz de fazer tudo no servidor, as etapas finais (a operação na estação de trabalho Win8,1Ent que precisa da conta) não bem. Essencialmente, o comando requerido, Install-ADServiceAccount gera um erro porque não pode ser encontrado:

PS C:\Users\René Kåbis.DOMAIN> Install-ADServiceAccount Services
Install-ADServiceAccount : The term 'Install-ADServiceAccount' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is
correct and try again.
At line:1 char:1
+ Install-ADServiceAccount Services
+ ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Install-ADServiceAccount:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Então, fui forçado a abandonar esse método e voltar às contas administrativas padrão. Oh, alegre êxtase de contas potencialmente hackáveis!

O problema é que esses não funcionam também. Bem, eles fazem, apenas não da maneira que eu preciso deles.

Eu criei uma conta administrativa com um nome diferente (apenas no caso de haver uma colisão entre a conta de serviço existente e essa nova conta de administrador). Quando eu vou para a estação de trabalho, faça o login com um nome de usuário limitado, e dê um duplo clique no aplicativo prima-donna Eu recebo o padrão "este programa requer acesso de administrador" yaddah, yaddah, yaddah. E na caixa de login resultante, posso colocar as novas credenciais da conta de administrador e fazer login. Até agora, tudo bem, mas isso NÃO É SEGURO porque qualquer um que conheça essas credenciais pode usá-las para obter acesso administrativo a qualquer máquina. p>

Então eu tento runas . Bem, eu uso a seguinte string:

C:\Program Files (x86)\Microsoft Retail Management System\Store Operations>runas
 /user:rms@domain /savecred SOMANAGER.exe
Attempting to start SOMANAGER.exe as user "rms@domain" ...
Enter the password for rms@domain:
Attempting to start SOMANAGER.exe as user "rms@domain" ...
RUNAS ERROR: Unable to run - SOMANAGER.exe
1783: The stub received bad data.

Ummm ... tudo bem. Mas uma verificação de rundll32.exe keymgr.dll, KRShowKeyMgr mostra as credenciais existentes na máquina! Então eu tento novamente,

C:\Program Files (x86)\Microsoft Retail Management System\Store Operations>runas
 /user:rms@domain /savecred SOMANAGER.exe
Attempting to start SOMANAGER.exe as user "rms@domain" ...
RUNAS ERROR: Unable to run - SOMANAGER.exe
740: The requested operation requires elevation.

Uísque. Tango. Foxtrot.

A conta que estou usando tem a capacidade de elevar o programa. Eu provei isso abrindo o programa normalmente e colocando exatamente as mesmas credenciais na caixa de login que apareceu. Então, por que diabos isso está acontecendo?

    
por René Kåbis 21.11.2013 / 18:34

2 respostas

1

A única maneira que descobri para fazer com que o Sistema de Gerenciamento de Varejo do Microsoft Dynamics funcione corretamente em uma conta de domínio de usuário limitada é de uma forma e apenas uma maneira: Voltagem do UAC.

Tenho certeza de que o Controle de Acesso do Usuário é uma ideia maravilhosa e melhorou drasticamente a segurança no ecossistema Windows desde o Vista, mas o Dynamics RMS parece ser um software baseado em COM / DCOM que foi escrito antes de 2007. Como tal, funciona apenas adequadamente em uma conta baseada em domínio não administrativo quando o UAC é desativado completamente.

Contas com e sem base em domínio são algo totalmente diferente. Se você tiver um computador autônomo, fazer com que o RUNAS inicie o Dynamics RMS corretamente é uma caminhada no parque. Sob um sistema baseado em domínio, é um pesadelo dos piores medos de um administrador de sistema.

Eu fiz várias coisas para colocar o RMS em funcionamento, no entanto, na trilha selvagem e lanosa que chamei durante meus esforços, não sei exatamente o que foi efetivo e o que não fez muita coisa. Portanto, aqui está uma lista das coisas que eu não “desenrolei” para suas configurações padrão (eu sempre tive o cuidado de desanuviar um cenário, uma vez que eu estava certo de que não estava fazendo nada produtivo - mas esse é o problema. não tinha certeza sobre).

  • Acesse as propriedades dos executáveis do programa e, para "todos os usuários" (o botão extra na parte inferior quando estiver em um ambiente de domínio), defina a compatibilidade com o Windows XP SP3 e defina como administrador.
  • Entre no arquivo de manifesto de cada executável do programa (sim, eles têm arquivos de manifesto) e comente os níveis de execução administrativa exigentes declarativos de XML.
  • Entre na Política de Grupo para o domínio e altere o seguinte:
    • Controle de conta de usuário: comportamento do prompt de elevação para administradores no modo Aprovação de administrador - Elevar sem solicitar
    • Controle de conta de usuário: detecta instalações de aplicativos e solicita a elevação - Desativado
    • Controle de conta de usuário: apenas eleve aplicativos UIAccess instalados em locais seguros - Desativado
    • Controle de conta de usuário: execute todos os administradores no modo de aprovação de administrador - desativado

Depois que essas configurações foram totalmente configuradas (e os computadores reinicializados, para que o GPO do computador pudesse entrar em vigor), o RMS pôde iniciar a partir do próprio executável sem solicitar qualquer tipo de credencial de login, mesmo a partir de um limite confirmado conta de usuário no domínio.

Se alguém seguir meus passos, recomendo strongmente que você não tente isso primeiro. Faça tudo ao seu alcance para evitar desligar o UAC. O UAC é de fato uma parte muito importante do Windows Security, e é apenas com o mais pesado dos corações que o desabilitei. É somente porque estou lidando com um programa relativamente antigo (sem equivalente atual - espera-se uma variação completamente nova e reconstruída em algum momento de 2014) que estou fazendo isso.

    
por 27.11.2013 / 02:02
2

Para instalar o módulo do PowerShell do diretório ativo:

Em um servidor, instale o recurso de ferramentas administrativas do servidor remoto.

Em um cliente, instale as ferramentas rsat após fazer o download do instalador rsat.

Em seguida, execute o 'diretório ativo do módulo de importação'.

Isso torna o diretório ativo cmd-lets disponível para uso.

Link de referência: link

É um processo um pouco complicado, se o único objetivo for uma conta de serviço e deixar um resíduo para ser limpo.

[EDITAR com base na sua nova mensagem de erro no comentário] Eu não tenho acesso a um domínio de 2012 no momento, por isso só posso adivinhar e olhar com cuidado. Parece que o comando no guia é executado com a conta de administrador do domínio, presumivelmente em um console ps elevado. A conta que você está usando tem o nível de acesso correspondente?

Além disso, você cumpre o requisito "O uso do gMSA é restrito apenas aos computadores especificados no descritor de segurança, msDS-GroupMSAMembership"?

Por fim, parece que o guia que você está seguindo é uma cópia em grande parte copiada / colada, mas também muito simplificada, da postagem do blog original da Microsoft. Sem examiná-lo muito, sugiro que você encontre instruções muito mais completas no original: link

    
por 21.11.2013 / 20:05