Entender identidades no IIS

Este artigo fornece informações em segundo plano sobre identidades no IIS (Serviços de Informações da Internet).

Versão original do produto: Serviços de Informações da Internet
Número de KB original: 4466942

Identidades do pool de aplicativos

Para entender as identidades do pool de aplicativos, você precisa entender o que é uma identidade. Em termos simples, uma identidade é uma conta do Windows. Cada processo executado no Windows é executado em uma identidade. Os aplicativos são executados pelo processo de trabalho usando uma identidade do Windows. A identidade do Windows usada depende da identidade do pool de aplicativos, que pode ser qualquer uma das seguintes contas:

• Sistema Local: Conta confiável que tem privilégios elevados e também tem acesso a recursos de rede.
• Serviço de Rede: Conta de serviço restrita ou limitada que é usada para executar serviços padrão e com privilégios mínimos. Essa conta tem menos privilégios do que uma conta do Sistema Local. Essa conta tem acesso aos recursos de rede.
• Serviço Local: Conta de serviço restrita ou limitada que é semelhante ao Serviço de Rede e destina-se a executar serviços padrão e com privilégios mínimos. Essa conta não tem acesso aos recursos de rede.
• ApplicationPoolIdentity: Quando um novo pool de aplicativos é criado, o IIS cria uma conta virtual que tem o nome do novo pool de aplicativos e que executa o processo de trabalho do pool de aplicativos nessa conta. Essa também é uma conta menos privilegiada.
• Conta personalizada: Além dessas contas internas, você também pode usar uma conta personalizada especificando o nome de usuário e a senha.

Diferenças entre identidades do pool de aplicativos

• Cenário 1: acesso ao log de eventos

  Nesse cenário, você tem um aplicativo Web que cria um log de eventos personalizado (MyWebAppZone) e uma fonte de log de eventos (MyWebAppZone.com) no runtime. Aplicativos executados usando qualquer uma das identidades podem gravar no log de eventos usando fontes de evento existentes. No entanto, se eles estiverem em execução sob uma identidade diferente do Sistema Local, não poderão criar novas fontes de eventos devido a permissões insuficientes do registro.

  

  Por exemplo, se você executar o aplicativo no Serviço de Rede, receberá a seguinte exceção de segurança:

  

  Ao executar o rastreamento ProcMon simultaneamente, muitas vezes você descobre que o NT AUTHORITY\NETWORK SERVICE não tem os privilégios de acesso de leitura e gravação necessários para a seguinte subchave de registro:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\

  Esse é o local no registro em que todas as configurações de um log de eventos são armazenadas.

  

• Cenário 2: Acesso ao Registro

  Além do Sistema Local, nenhuma outra identidade do pool de aplicativos tem acesso de gravação ao registro. Nesse cenário, você desenvolveu um aplicativo Web simples que pode alterar e exibir o nome do servidor de tempo da Internet com o qual o Windows é sincronizado automaticamente. Se você executar esse aplicativo no Serviço Local, obterá uma exceção. Se você marcar o rastreamento ProcMon, você descobrirá que a identidade do pool de aplicativos "NT AUTHORITY\LOCAL SERVICE" não tem acesso de leitura e gravação na seguinte subchave de registro:

  HKEY_LOCAL_MACHINE** **\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers

  

  Se você marcar o log de eventos MyWebAppZone (do cenário 1), você encontrará o evento de erro a seguir registrado. Ele contém uma mensagem de Requested registry access is not allowed erro.

  Exception Type: SecurityException  
  Message: Requested registry access is not allowed.  
  Stack Trace  
  at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)  
  at Identities.ChangeTimeServer.Page_Load(Object sender, EventArgs e)  
  at System.Web.UI.Control.LoadRecursive()  
  at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
  at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
  at System.Web.UI.Page.ProcessRequest()  
  at System.Web.UI.Page.ProcessRequest(HttpContext context)  
  at ASP.changetimeserver_aspx.ProcessRequest(HttpContext context) in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\fd06117a\f8c94323\App_Web_ysqbhk00.2.cs:line 0  
  at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()  
  at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
  

• Cenário 3: conta personalizada na autenticação kerberos e ambiente balanceado por carga

  Você já viu nos cenários 1 e 2 algumas das diferenças entre as contas internas. Agora, vamos discutir o que é uma conta personalizada e como ela tem vantagens sobre contas internas quando você trabalha com a autenticação Kerberos em um ambiente balanceado de carga.

  Usando essa abordagem, você executa seu aplicativo em um pool de aplicativos que está configurado para ser executado usando uma identidade específica do Windows. Considere o diagrama a seguir, no qual um aplicativo é hospedado em um ambiente com balanceamento de carga que inclui dois servidores e usa a autenticação Kerberos para identificar o cliente.

  

  Para que a autenticação Kerberos funcione, você precisa configurar o SPN para ambos os servidores usando a conta do computador. Se o pool de aplicativos estiver em execução em uma conta interna, ele apresentará as credenciais do computador na rede. Por exemplo, se o nome do computador for Server1, ele se apresentará como 'Server1$'. Essa conta do computador é criada automaticamente quando um computador ingressa em um domínio. Portanto, se houver servidores N, você deverá definir n número de SPNs que correspondam à respectiva conta do computador.

  Registrando um SPN em uma conta de computador:

  setspn -a HTTP/HOSTNAME MachineAccount$
  

  Exemplo:

  setspn -a HTTP/MyWebAppZone.com Server1$
  

  Para superar essa desvantagem, você pode executar o aplicativo em uma identidade personalizada do Windows (domínio) e, em seguida, definir o SPN como apenas aquela conta de domínio específica no controlador de domínio.

  Registrar um SPN em uma conta de domínio:

  setspn -a HTTP/HOSTNAME domain\account
  

  Exemplo:

  setspn -a HTTP/MyWebAppZone.com contoso.com\account_alias
  

Permissões padrão e direitos do usuário em wwwroot

As versões do IIS 7.0 e posteriores também facilitam a configuração de uma identidade do pool de aplicativos e fazer todas as alterações necessárias. Quando o IIS inicia um processo de trabalho, ele deve criar um token que o processo usará. Quando esse token é criado, o IIS adiciona automaticamente a IIS_IUSRS associação ao token de processos de trabalho no runtime. As contas que são executadas como identidades do pool de aplicativos não precisam mais ser uma parte explícita do IIS_IUSRS grupo. Se você criar um site e apontar o local físico para C:\inetpub\wwwroot, os usuários e grupos a seguir serão adicionados automaticamente às listas de controle de acesso do site.

Usuários / grupos	Permissões aceitas
PROPRIETÁRIO CRIADOR	Permissões especiais
SISTEMA	Controle total
Administradores	Controle total
Usuários	Ler & executar, Listar conteúdo da pasta, Ler
IIS_USRS	Ler e executar
Trustedinstaller	Controle total

Se você quiser desabilitar esse recurso e adicionar manualmente contas ao IIS_IUSRS grupo, defina o valor manualGroupMembership como true no arquivo ApplicationHost.config . O exemplo a seguir mostra como isso pode ser feito no pool de aplicativos padrão:

<applicationPools> 
    <add name="DefaultAppPool"> 
        <processModel manualGroupMembership="true" />
    </add>
</applicationPools>

Entender o isolamento de configuração

Os processos de trabalho do IIS não têm acesso de leitura ao arquivo ApplicationHost.config . Portanto, você pode se perguntar como eles podem ler qualquer um dos conjuntos de configurações neste arquivo.

A resposta é usando o recurso de isolamento de configuração nas versões IIS 7.0 e posteriores. Em vez de habilitar os processos de trabalho do IIS para ler ApplicationHost.config diretamente quando lêem a hierarquia de arquivos de configuração, o WAS (Serviço de Ativação de Processo do Windows) gera cópias filtradas desse arquivo. Cada processo de trabalho do IIS usa essas cópias como uma substituição de ApplicationHost.config quando a configuração é lida dentro do processo de trabalho do IIS. Esses arquivos são gerados por padrão no %SystemDrive%\inetpub\Temp\appPools diretório e são chamados {AppPoolName}.config. Esses arquivos são configurados para permitir o acesso apenas aos processos de trabalho do IIS no pool de aplicativos correspondente usando o SID (Identificador de Segurança do IIS APPPOOL\AppPoolName pool de aplicativos).

Observação

Para saber mais sobre o SID, consulte Identificadores de Segurança.

Isso é feito para impedir que os processos de trabalho do IIS do pool de aplicativos A possam ler informações de configuração no arquivo ApplicationHost.config destinado ao pool de aplicativos B.

ApplicationHost.config podem conter informações pessoais confidenciais, como o nome de usuário e a senha para identidades personalizadas do pool de aplicativos ou o nome de usuário e a senha para diretórios virtuais. Portanto, permitir que todos os pools de aplicativos acessemApplicationHost.config interromperia o isolamento do pool de aplicativos. Se cada pool de aplicativos tiver acesso direto ao arquivo ApplicationHost.config , esses pools poderão facilmente cortar informações confidenciais de outros pools de aplicativos executando o seguinte comando:

appcmd list APPPOOL "DefaultAppPool" /text:*

IUSR – autenticação anônima

A autenticação anônima permite que os usuários acessem áreas públicas do site sem solicitação de um nome de usuário ou senha. No IIS 7.0 e versões posteriores, uma conta interna, IUSR, é usada para fornecer acesso anônimo. Essa conta interna não requer uma senha. Ela será a identidade padrão usada quando a autenticação anônima estiver habilitada. No arquivo ApplicationHost.config , você pode ver a seguinte definição:

<authentication>
     <anonymousAuthentication enabled="true" userName="IUSR" />
 </authentication>

Isso informa ao IIS para usar a nova conta interna para todas as solicitações de autenticação anônimas. As maiores vantagens de fazer isso são as seguintes:

• Você não precisa mais se preocupar com senhas expirando para essa conta.
• Você pode usar xcopy /o para copiar arquivos junto com suas informações de propriedade e ACL para computadores diferentes perfeitamente.

Você também pode fornecer autenticação anônima ao seu site usando uma conta específica do Windows ou uma identidade do pool de aplicativos em vez de uma IUSR conta.

IUSR versus Connect como

Conectar como é uma opção no IIS que permite que você decida quais credenciais deseja usar para acessar o site. Você pode usar as credenciais de usuário autenticadas ou credenciais de usuário específicas. Para entender a diferença, considere o seguinte cenário:

Você tem um site padrão que está configurado para usar a autenticação anônima. No entanto, o conteúdo do site está em outro servidor e você está usando a seção Conectar como para acessar esse recurso por meio de um Test usuário de domínio. Quando o usuário faz logon, ele é autenticado usando uma conta IUSR. No entanto, o conteúdo do site é acessado por meio das credenciais do usuário mencionadas na seção Conectar como .

Para simplificar, a autenticação anônima é o mecanismo usado pelo site para identificar um usuário. Mas quando você usa esse recurso, o usuário não precisa fornecer credenciais. No entanto, pode haver um cenário semelhante em que o conteúdo está em um compartilhamento de rede. Nesses casos, você não pode usar contas internas para acessar o compartilhamento de rede. Em vez disso, você deve usar uma conta específica (domínio) para fazer isso.

ASP.NET representação

Literalmente, representação significa o ato de fingir ser outra pessoa. Em termos técnicos, é um recurso de segurança ASP.NET que fornece a capacidade de controlar a identidade sob a qual o código do aplicativo é executado. A representação ocorre quando ASP.NET executa o código no contexto de um cliente autenticado e autorizado. O IIS fornece acesso anônimo aos recursos usando uma IUSR conta. Depois que a solicitação é passada para ASP.NET, o código do aplicativo é executado usando a identidade do pool de aplicativos.

A representação pode ser habilitada por meio do IIS e ASP.NET código se o aplicativo usar autenticação anônima e se uma das seguintes condições for verdadeira:

• Se IMPERSONATION estiver desabilitada, a identidade do pool de aplicativos será usada para executar o código do aplicativo.
• Se IMPERSONATION estiver habilitado, NT AUTHORITY\IUSR será usado para executar o código do aplicativo.

Quando impersonation é habilitado por meio do IIS, ele adiciona a seguinte marca no arquivo Web.config do aplicativo para representar a Conta Autenticada do IIS ou Usuário: <representação de identidade="true" />

Para representar um usuário específico para todas as solicitações em todas as páginas de um aplicativo ASP.NET, você pode especificar o nome de usuário e os <identity> atributos de senha na marca do arquivo Web.config para esse aplicativo.

<identity impersonate="true" userName="accountname" password="password" />

Para implementar a representação por meio de ASP.NET código, consulte Implementar representação em um aplicativo ASP.NET

Abra o processo de trabalho do IIS de um site de teste que está representando um Test usuário local e marcar se você pode encontrar a conta de representação na qual o código do aplicativo é executado.

A identidade do pool de aplicativos do aplicativo é definida como ApplicationPoolIdentity e a autenticação anônima é fornecida usando IUSR a conta. Você pode rastrear facilmente a identidade de representação usando o ProcMon. Por exemplo, se você examinar um dos eventos CreateFile que correspondem ao processo w3wp.exe que você está examinando, você poderá encontrar a conta de representação, conforme mostrado na captura de tela a seguir.