No Windows Server 2012 R2, o IIS está sendo executado como um servidor Web em condições normais. O conteúdo da web, entretanto, não é de c:\inetpub\wwwroot\alguma outra pasta, mas sim de alguma outra pasta. Os aplicativos da web ainda estão em execução com seu próprio usuário, que é do defaultAppPool.
Na verdade, esqueci de conceder IIS_IUSRSdireitos de leitura/execução à pasta de conteúdo da web. A pasta deu acesso a usersisso. Eu só adicionei IIS_IUSRSdireitos de leitura/execução/gravação se uma subpasta precisar ser gravável.
Querendo reforçar um pouco a segurança, passei pelos direitos de acesso da pasta de conteúdo web, e descobri por tentativa e erro que agora IIS_IUSRSfaltava o acesso para, é o acesso para o usersgrupo que é responsável por tudo continuar funcionando. Porque quando eu removo o acesso ao usersgrupo, o aplicativo para de funcionar.
Tentei dar acesso a algumas outras contas/grupos e descobri que dar acesso a ambos userse IIS_IUSRSindividualmente colocar meu aplicativo em execução. Dar acesso simplesmente IIS APPPOOL\não funciona. Mas dar acesso ao meu usuário específico do pool de aplicativos (EG IISAPPPOOL\nl-x-homepage) sim. E esta última parte é o que eu quero, pois não quero que um aplicativo possa acessar arquivos de outro aplicativo.
Mas eu queria saber... Como funcionam exatamente as contas do tipo IIS? Por que conceder acesso userstambém funciona para que meu pool de aplicativos acesse a pasta de conteúdo da web? Não consigo ver meu usuário específico do pool de aplicativos no lusrmgr, mas acho que meu usuário específico do pool de aplicativos está no usersgrupo ou em algum outro grupo que esteja no usersgrupo. alguém pode confirmar isso?
E como última pergunta sobre este assunto: para ter pastas específicas 'protegidas por senha' criei um usuário normal no Windows, removi esse usuário do usersgrupo, e no Gerenciador do IIS fui até essa pasta e fiz Autenticação -> Autenticação Básica - > Ativado e em Regras de autenticação defini uma regra de permissão para minha conta de usuário do Windows recém-criada. Isso funciona. Mas analisando o acesso de leitura/gravação, fiquei surpreso ao saber que, embora o aplicativo esteja sendo executado sob o usuário do pool de aplicativos, o usuário do pool de aplicativos só precisa de direitos de leitura (sem direitos de gravação), e o usuário recém-criado do Windows precisa ter direitos de leitura e gravação. direitos de gravação além disso para que a pasta seja gravável. Alguém pode ajudar a explicar por que isso funciona dessa maneira?
Responder1
O comportamento que você está encontrando parece bastante lógico para mim.
IIS_IUSRS é um grupo, não uma conta, cujo único objetivo é permitir que seus membros sejam atribuídos como identidades de pool de aplicativos, portanto, adicioná-lo por si só não é suficiente (como você descobriu).
O grupo Usuários contém a conta ASPNET que possui permissões suficientes para o site funcionar, portanto, adicioná-la foi suficiente para as permissões padrão. Acredito que a conta ASPNET seja a usada como DefaultAppPool.
Um arquivo ou pasta criado por um usuário sempre tem permissão de leitura, pois o criador é o proprietário e possui todas as permissões. No caso em que outro usuário criou o arquivo ou pasta - conceder apenas permissões de gravação sem leitura nunca funcionou no Windows, pois o acesso de leitura é necessário para verificar as permissões e o espaço disponível e similares antes de poder escrever.
Responder2
IIS_IUSRS é o grupo de contas do processo de trabalho do IIS. Esse grupo interno tem acesso a todos os arquivos e recursos do sistema necessários para que uma conta, quando adicionada a esse grupo, possa atuar perfeitamente como uma identidade de pool de aplicativos.
Se você clicar com o botão direito no domínio e abrir Editar permissões, deverá ver os grupos e permissões listados. Na guia Segurança, você verá MACHINE_NAME\IIS_IUSRS e também /Users. O IIS tem automaticamente permissão somente leitura no diretório.
Para cada pool de aplicativos criado, a propriedade Identity do novo pool de aplicativos é definida como ApplicationPoolIdentity por padrão. O Processo Administrativo do IIS (WAS) criará uma conta virtual com o nome do novo pool de aplicativos e executará os processos de trabalho do pool de aplicativos nessa conta por padrão. Sempre que um novo pool de aplicativos é criado, o processo de gerenciamento do IIS cria um identificador de segurança (SID) que representa o nome do próprio pool de aplicativos. Por exemplo, se você criar um pool de aplicativos com o nome "MyFirstPool", um identificador de segurança com o nome "MyFirstPool" será criado no sistema de Segurança do Windows. Deste ponto em diante, os recursos podem ser protegidos usando esta identidade.Contudo, a identidade não é uma conta de usuário real; ele não aparecerá como usuário no Console de gerenciamento de usuários do Windows. Este é o comportamento normal. Se você deseja fornecer acesso a uma determinada pasta, basta adicioná-la à pasta editando as permissões. Porém, você deve verificar a configuração de autenticação padrão (identidade anônima) e ver se a seleção adequada está disponível, ou configurá-la para evitar erros de acesso.
Mais sobre pools de aplicativos.
Esta postagemaborda o resto das questões. Herança.
Obviamente, o usuário do Windows que você está adicionando aqui requer permissões, pois a conta deve herdar permissões dos grupos necessários. A permissão de leitura aqui é vital. No entanto, destina-se a acessar os recursos locais.