Alguém pode explicar os SPNs (Nomes de Princípios de Serviço) do Windows sem simplificar demais?

Já lutei com os nomes dos princípios de serviço algumas vezes e a explicação da Microsoft simplesmente não é suficiente. Estou configurando um aplicativo IIS para funcionar em nosso domínio e parece que alguns dos meus problemas estão relacionados à minha necessidade de configurar SPNs específicos de http na conta de serviço do Windows que está executando o pool de aplicativos que hospeda o meu site.

Tudo isso me fez perceber que simplesmente não entendo completamente o relacionamento entre os tipos de serviço (MSSQL, http, host, termsrv, wsman etc.), autenticação Kerberos, contas de computador do Active Directory (PCName $), contas de serviços do Windows, SPNs , e a conta de usuário que estou usando para tentar acessar um serviço.

Alguém pode explicar os SPNs (nomes de princípios de serviço) do Windows sem simplificar demais a explicação?

Pontos de bônus por uma analogia criativa que ressoaria com um administrador / desenvolvedor de sistema com experiência moderada.

Um nome principal de serviço é um conceito de Kerberos. É um identificador para um serviço específico oferecido por um host específico em um domínio de autenticação. O formulário comum para SPNs é service class/ fqdn@ REALM(por exemplo IMAP/[email protected]). Também existem nomes principais de usuário que identificam usuários, na forma de user@ REALM(ou user1/ user2@ REALM, que identifica um relacionamento de fala ). O service classpode livremente ser pensado como o protocolo para o serviço. A lista de classes de serviço incorporadas ao Windows está listada neste artigo da Microsoft .

Cada SPN deve ser registrado no REALM's Key Distribution Center (KDC) e emitiu uma chave de serviço . O setspn.exeutilitário que está disponível na \Support\Toolspasta na mídia de instalação do Windows ou como um download do Resource Kit, manipula atribuições de SPNs a computadores ou outras contas no AD.

Quando um usuário acessa um serviço que usa o Kerberos para autenticação (um serviço "Kerberizado"), ele apresenta um ticket criptografado obtido do KDC (em um ambiente Windows, um Controlador de Domínio Active Directory). O ticket é criptografado com a chave de serviço . Ao descriptografar o ticket, o serviço comprova que possui a chave para o SPN fornecido. Os serviços em execução nos hosts do Windows usam a chave associada à conta do computador AD, mas para estar em conformidade com os SPNs do protocolo Kerberos devem ser adicionados ao Active Directory para cada serviço kerberizado em execução no host - exceto os SPNs internos mencionados acima. No Active Directory, os SPNs são armazenados no servicePrincipalNameatributo do objeto de computador do host.

Para obter mais informações, consulte: Artigo do Microsoft TechNet sobre SPN , Perguntas frequentes sobre Kerberos de Ken Hornstein.

A resposta de yarek foi ótima, e eu a votei, mas também queria fornecer um pouco mais de informações específicas do Windows sobre o tópico, ou melhor, vindo da perspectiva de alguém que esteja mais familiarizado com o AD do que apenas Kerberos em geral, apenas porque este é um tópico que me interessa muito.

Eu senti que esse cara fez um excelente trabalho para explicá-lo, e eu recomendo que você leia o artigo dele, mas aqui está um parágrafo especialmente conciso diretamente para sua pergunta:

"Os nomes principais de serviço definem quais serviços são executados no contexto de segurança das contas. Por exemplo, alguns dos serviços que um computador pode ter são servidor de arquivos / CIFS (Common Internet File System); se for um controlador de domínio, terá um LDAP SPN e SPN de replicação do Active Directory e SPN do FRS. Os nomes principais de serviço podem ser definidos nas contas de usuário quando um serviço ou aplicativo está sendo executado no contexto de segurança desse usuário. Geralmente, esses tipos de contas de usuário são conhecidos como "contas de serviço". É muito importante que você entenda que os Nomes Principais de Serviço DEVEM ser únicos em toda a floresta do Active Directory. "

O artigo inteiro está aqui: http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx