Eu tenho um webservice que está escrito em ASP clássico. Neste serviço da Web, ele tenta criar um objeto VirtualServer.Application em outro servidor por meio do DCOM. Isso falha com a permissão negada. No entanto, tenho outro componente instanciado neste mesmo serviço web no mesmo servidor remoto, que é criado sem problemas. Este componente é um componente personalizado.
O webservice é chamado de um programa EXE autônomo que o chama via WinHTTP. Foi verificado que o WinHTTP está autenticando com o Kerberos para o serviço da Web com êxito. O usuário autenticado no serviço da Web é o usuário Administrador. A etapa de autenticação do EXE para o serviço da web é bem-sucedida e com o kerberos.
Eu verifiquei as permissões do DCOM no computador remoto com o DCOMCNFG. Os limites padrão permitem aos administradores ativação local e remota, acesso local e remoto e inicialização local e remota. As permissões do componente padrão permitem o mesmo. Isso foi verificado. As permissões de componentes individuais para o componente de trabalho são definidas como padrões. As permissões de componentes individuais para o componente VirtualServer.Application também são definidas como padrões. Com base nessas configurações, o serviço da Web deve poder instanciar e acessar os componentes no computador remoto.
A configuração de um rastreio Wireshark durante a execução de ambos os testes, um com o componente de trabalho e outro com o componente VirtualServer.Application revela um comportamento intresting. Quando o webservice está instanciando o componente funcional, customizado, posso ver a solicitação na ligação para o mapeador de ponto de extremidade RPCSS executar primeiro a sequência de conexão TCP. Então eu vejo executar o pedido de ligação com o pacote de segurança apropriado, neste caso o kerberos. Depois de obter o ponto de extremidade para o componente DCOM em funcionamento, ele se conecta ao endpoint DCOM que está sendo autenticado novamente por meio do Kerberos e pode instanciar e comunicar-se com êxito.
No componente VirtualServer.Application com falha, vejo novamente a solicitação de ligação com o kerberos ir para o mapeador de fim de RPCC com êxito. No entanto, quando tenta se conectar ao ponto de extremidade no processo do Virtual Server, ele não consegue se conectar porque tenta autenticar com o NTLM, o que acaba falhando, porque o serviço da Web não tem acesso às credenciais para executar o hash do NTLM.
Por que está tentando autenticar via NTLM?
Informações adicionais:
- Ambos os componentes são executados no mesmo servidor via DCOM
- Ambos os componentes são executados como sistema local no servidor
- Ambos os componentes são componentes do serviço Win32
- Os dois componentes têm as mesmas permissões de início / acesso / ativação do DCOM
- Os dois serviços Win32 estão definidos para serem executados como sistema local
- A permissão negada não é um problema de permissões, tanto quanto eu posso dizer, é um problema de autenticação. A permissão é negada porque a autenticação NTLM é usada com um nome de usuário NULL em vez da delegação do Kerberos
- A delegação restrita é configurada no servidor que hospeda o serviço da web.
- O servidor que hospeda o serviço da Web pode delegar para rpcss / dcom-server-name
- O servidor que hospeda o serviço da Web pode delegar para vssvc / dcom-server-name
- O servidor dcom tem permissão para delegar a rpcss / webservice-server
- Os SPNs registrados no servidor dcom incluem rpcss / dcom-server-name e vssvc / dcom-server-name, bem como os SPNs relacionados ao HOST / dcom-server-name
- Os SPNs registrados no servidor webservice incluem o rpcss / webservice-server e os SPNs relacionados ao servidor HOST / webservice
Alguém tem alguma idéia de por que a tentativa de criar um objeto VirtualServer.Application em um servidor remoto está voltando à autenticação NTLM, fazendo com que ele falhe e obtenha permissão negada?
Informação adicional:
Quando o código a seguir é executado no contexto do serviço da Web, diretamente por meio de um componente COM recém-desenvolvido e somente de teste, ele falha na linha especificada com Acesso Negado.
COSERVERINFO csi;
csi.dwReserved1=0;
csi.pwszName=L"terahnee.rivin.net";
csi.pAuthInfo=NULL;
csi.dwReserved2=NULL;
hr=CoGetClassObject(CLSID_VirtualServer, CLSCTX_ALL, &csi, IID_IClassFactory, (void **) &pClsFact);
if(FAILED( hr )) goto error1;
// Fails here with HRESULT_FROM_WIN32(ERROR_ACCESS_DENIED)
hr=pClsFact->CreateInstance(NULL, IID_IUnknown, (void **) &pUnk);
if(FAILED( hr )) goto error2;
Eu também notei que no Wireshark Traces, eu vejo a tentativa de se conectar ao componente do processo de serviço somente solicita a autenticação NTLMSSP, ele nem mesmo tenta usar o kerberos. Isto sugere que, por alguma razão, o webservice acha que não pode usar o kerberos ...