IIS e grupo de usuários

Question

No Windows Server 2012 R2, o IIS está sendo executado como um servidor da Web em condições normais. O conteúdo da Web, no entanto, não é de c:\inetpub\wwwroot\ , mas de alguma outra pasta. Os aplicativos da web ainda estão sendo executados sob seu próprio usuário que é do defaultAppPool.

Na verdade, eu esqueci de dar IIS_IUSRS read / execute direitos para a pasta de conteúdo da web. A pasta deu acesso a users embora. Eu adicionei apenas IIS_IUSRS read / execute / write se uma subpasta precisa ser gravável.

Querendo aumentar um pouco a segurança, passei pelos direitos de acesso da pasta de conteúdo da Web e aprendi por tentativa e erro que agora acesso para IIS_IUSRS estava ausente, é o acesso para o grupo users que é responsável por tudo para continuar funcionando. Porque quando eu removo o acesso ao grupo users , o aplicativo pára de funcionar.

Eu tentei dar acesso a algumas outras contas / grupos e descobri que dar acesso a users e IIS_IUSRS individualmente faz com que meu aplicativo seja executado. Dar acesso apenas a IIS APPPOOL\ não. Mas dar acesso ao meu usuário específico do pool de aplicativos (EG IISAPPPOOL\nl-x-homepage ) faz. E este último bit é o que eu quero, pois não quero que um aplicativo seja capaz de acessar arquivos de algum outro aplicativo.

Mas eu estava pensando ... Como funcionam as contas do IIS? Por que a concessão de acesso a users também funciona para meu pool de aplicativos para acessar a pasta de conteúdo da web? Não consigo ver meu usuário do pool de aplicativos específico no lusrmgr, mas imagino que meu usuário específico do pool de aplicativos esteja no grupo users ou em algum outro grupo que esteja no grupo users . Alguém pode confirmar isso?

E como última pergunta: para ter pastas específicas 'protegidas por senha', criei um usuário normal no Windows, removi esse usuário do grupo users e, no Gerenciador do IIS, fui para essa pasta e Autenticação - > Autenticação básica - > Habilitado e em Regras de autenticação, defini uma regra Permitir 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 em execução no usuário do pool de aplicativos, o usuário do pool de aplicativos só precisa de direitos de leitura (sem direitos de gravação) eo usuário recém-criado do Windows precisa ler e ler. escreva direitos sobre isso para que a pasta seja gravável. Alguém pode ajudar a explicar por que isso funciona dessa maneira?

    

Answer 1

O comportamento que você está encontrando parece bastante lógico para mim.

IIS_IUSRS é um grupo, não uma conta, cuja única finalidade é permitir que seus membros sejam designados como identidades do pool de aplicativos, portanto, adicioná-lo sozinho não é suficiente (como você descobriu).

O grupo Usuários contém a conta ASPNET que tem permissões suficientes para o site funcionar, então adicioná-lo foi suficiente para as permissões padrão. Eu acredito que a conta ASPNET é o usado como DefaultAppPool.

Um arquivo ou pasta criado por um usuário sempre tem permissão de leitura, porque o criador é o proprietário e tem todas as permissões. No caso em que outro usuário criou o arquivo ou pasta - dando apenas permissões de escrita sem leitura nunca funcionou no Windows, já que o acesso de leitura é necessário para verificar as permissões e o espaço disponível e coisas assim antes de poder escrever.

    

Answer 2

IIS_IUSRS é o grupo de contas de processo de trabalho do IIS. Esse grupo integrado tem acesso a todos os recursos de arquivo e sistema necessários para que uma conta, quando adicionada a esse grupo, possa agir perfeitamente como uma identidade de pool de aplicativos.

Se você clicar com o botão direito do mouse no domínio e abrir as permissões de edição, verá os grupos e permissões listados. Na guia Segurança, você verá MACHINE_NAME \ IIS_IUSRS e também os / 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 de administração 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 Windows Security. Deste ponto em diante, os recursos podem ser protegidos usando essa identidade. No entanto, a identidade não é uma conta de usuário real; ele não aparecerá como um usuário no Windows User Management Console . Esse é o comportamento normal. Se você deseja fornecer acesso a uma determinada pasta, basta adicionar isso à pasta editando as permissões. No entanto, você precisa 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 postagem aborda o restante das perguntas. 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. Destina-se a acessar os recursos locais, no entanto.