Eu tenho um aplicativo IIS em execução no Servidor A. Ele precisa da capacidade de gravar em uma pasta em um compartilhamento UNC, atualmente no Servidor B. Eu gostaria de manter o compartilhamento no Servidor B, mas esse ambiente não tem um Domínio do Windows Active Directory - até este ponto, trabalhamos em torno desse problema executando qualquer serviço (BD, por exemplo) em uma conta cujo nome de usuário e senha seriam replicados em quaisquer outros servidores aos quais o serviço precisava de acesso. Até este ponto, não sabíamos que o aplicativo IIS precisava de acesso "estilo de domínio" a quaisquer outros recursos em que ele não tivesse métodos alternativos de autenticação.
O aplicativo IIS tem a configuração Identity: ApplicationPoolIdentity , que, pelo meu entendimento, faz com que seja executado sob o SID IIS AppPool\AppPoolName
Então, depois de algumas pesquisas e descobertas iniciais, descobri as seguintes possibilidades, ordenadas do menos ao mais elegante. Meus comentários em itálico.
Mova o compartilhamento para o Servidor A.
Não é realmente o que eu quero fazer - exigiria um monte de reconfiguração de serviços existentes, inconsistentes com outras infraestruturas.
Mova a pasta em questão para um novo compartilhamento no Servidor B com acesso de gravação anônima.
Isso pelo menos manteria todos os meus compartilhamentos no mesmo servidor, mas a segurança pela obscuridade não é realmente meu estilo.
Reconfigure o aplicativo IIS para ser executado com um nome de usuário e senha explícitos, para ser replicado no Servidor B para conceder acesso ao compartilhamento de arquivos. Pelo menos, acho que conseguiria o que eu quero para, mas mudar a identidade parece arriscado e potencialmente propenso a consequências imprevisíveis para a aplicação.
Forneça à identidade do pool de aplicativos no Servidor A uma credencial armazenada para um nome de usuário e senha que permitirá o acesso ao compartilhamento no Servidor B. Não faz ideia se isso realmente funcionaria ou se você pode até mesmo fornecer credenciais armazenadas para SIDs que não são contas de usuário completas em primeiro lugar. Apenas uma ideia, mas eu gosto, já que ela não afeta a configuração existente do aplicativo IIS.
Use ACLs no compartilhamento para conceder acesso à "Conta de Máquina" do Servidor A.
Isto parece como o Santo Graal, pois é o método recomendado (" as identidades do pool de aplicativos também usam a conta da máquina para acessar os recursos da rede "), mas é claro que essas máquinas não estão vinculadas a um domínio do Windows, o que parece ser um pré-requisito para o uso de uma conta de máquina.
Idealmente, gostaria de encontrar um hack ou um kludge que realizasse o item 5 ou outra forma de conceder acesso somente reconfigurando o Servidor B, novamente sem um domínio do AD. Em qualquer caso, eu também gostaria de saber o que os administradores mais experientes do Windows Server fariam nessa situação (além de apenas configurar um maldito domínio do Active Directory).
Sua única opção sem um domínio do Windows é, de fato, alterar a identidade do pool de aplicativos para uma conta que tenha acesso. Se não houver nada especial acontecendo com a identidade existente, você deve apenas criar uma conta de usuário básica (ela não precisa de um perfil) e atribuí-la como a identidade.
No tempo de execução, ele receberá o grupo IIS_IUSRS e terá o mesmo acesso que a identidade padrão do pool de aplicativos.