Configuração Kerberos do servidor LAMP para autenticação em um KDC somente leitura do Windows em um DMZ

Configuração Kerberos do servidor LAMP para autenticação em um KDC somente leitura do Windows em um DMZ

Fundo:

Temos várias redes (domínios) AD conectadas por meio de VPNs e que estabeleceram relações de confiança no AD. Temos um servidor web hospedado externamente e configuramosautenticação perfeitapara qualquer usuário dentro da rede confiável. Isso funciona, mas a presença da VPN em um servidor web externo não gerenciado pelo nosso departamento de TI foi considerada um risco de segurança muito grande pela equipe de rede.

Não tenho acesso de administrador às redes internas, mas tenho acesso total de administrador nos servidores da web.

Quer:

Estabeleça a mesma autenticação contínua sem VPN usando um controlador de domínio somente leitura em uma DMZ para processar todas as solicitações de autenticação.

Detalhes:

  1. Temos vários domínios AD confiáveis ​​entre si e conectados por meio de túneis VPN.
  2. Temos um DC somente leitura em uma DMZ conectada à rede AD principal
  3. Servidores web LAMP externos - estamos usando uma única instância para testar a nova configuração

Tarefas concluídas:

  1. Adicionado o DMZ DC ao arquivo hosts
  2. Atualizado o arquivo krb5.conf e associado um único domínio e domínio (domínio1) ao DMZ DC
  3. Autenticação testada na linha de comando com kinit (funcionou)
  4. Atualizado o arquivo krb5.conf com regiões adicionais e mapeamentos de regiões de domínio com todos os domínios apontando para o DMZ DC
  5. Autenticação testada na linha de comando com um usuário de uma das regiões adicionais e falhou.

Exemplo de configurações atuais

/etc/hosts/ : (substituí o IP real por x's e os nomes de domínio reais por razões de confidencialidade)

xxx.xxx.xxx.xxx  dc01.domain1.com, dc01.domain2.com, dc01.domain3.com, dc01.domain4.com

/etc/krb5.conf:

[libdefaults]
 default_realm = REALM1.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 clockskew = 12000
 kdc_timesync = 1

[realms]
 REALM1.COM = {
  kdc = dc01.domain1.com
  admin_server= dc01.domain1.com
 }
 REALM2.COM = {
  kdc = dc01.domain2.com
  admin_server= dc01.domain2.com
 }
 REALM3.COM = {
  kdc = dc01.domain3.com
  admin_server= dc01.domain3.com
 }
 REALM4.COM = {
  kdc = dc01.domain4.com
  admin_server= dc01.domain4.com
 }

Problemas:

A DMZ não está processando solicitações de autenticação para domínios confiáveis. Não sei se isso é resultado da configuração do DC ou da configuração do Kerberos daí o apelo por ajuda.

Passei algumas horas analisando outras questões sobre serverfault, pesquisando no Google e lendo tutoriais, mas nada parece corresponder ao nosso cenário.

Podemos fazer o que estamos tentando e, em caso afirmativo, o que precisamos fazer para que funcione? É um caso simples de configurar o DMZ como um proxy para os kdcs dos outros domínios?


Em resposta a Nathan C, o log de segurança mostra solicitações de tickets de serviço Kerberos como este:

Sucesso na auditoria 14/05/2014 11:05 Microsoft-Windows-Security-Auditing 4769 Operações de ticket de serviço Kerberos "Um ticket de serviço Kerberos foi solicitado.

Informações da conta: Nome da conta: [e-mail protegido] Domínio da conta: DOMAIN1.COM GUID de logon: {C93D9AAC-6968-6C00-83EF-2C2D54E2363B}

Informações do serviço: Nome do serviço: RODC01$ ID do serviço: DOMAIN1\RODC01$

Informações de rede: Endereço do cliente: ::1 Porta do cliente: 0

Informações adicionais: Opções de ticket: 0x40810000 Tipo de criptografia de ticket: 0x17 Código de falha: 0x0 Serviços transitados: -

Este evento é gerado sempre que o acesso é solicitado a um recurso como um computador ou serviço do Windows. O nome do serviço indica o recurso ao qual o acesso foi solicitado.

Esse evento pode ser correlacionado com eventos de logon do Windows comparando os campos GUID de logon em cada evento. O evento de logon ocorre na máquina que foi acessada, que geralmente é uma máquina diferente da máquina do controlador de domínio que emitiu o tíquete de serviço.

Opções de tickets, tipos de criptografia e códigos de falha são definidos na RFC 4120."

Infelizmente, o extrato do log enviado para mim não corresponde aos horários em que eu estava tentando a autenticação, então não sei a que essa entrada de log realmente se refere. Solicitei outro extrato.


Informação da conta:

Nome da conta: jameel.rahmaa

Nome de domínio fornecido: DOMAIN1.COM

ID do usuário: SID NULO

Serviço de informação:

Nome do serviço: krbtgt/DOMAIN1.COM

ID do serviço: SID NULO

Informações de rede:

Endereço do cliente: [IP WEB OCULTO]

Porta do Cliente: 34567

Informações adicionais:

Opções de ingresso: 0x40800000

Código de resultado: 0x6

Tipo de criptografia de ticket: 0xffffffff

Tipo de pré-autenticação: -

Informações do certificado:

Nome do emissor do certificado:

Número de série do certificado:

Impressão digital do certificado:

As informações do certificado só serão fornecidas se um certificado tiver sido usado para pré-autenticação.

Tipos de pré-autenticação, opções de ticket, tipos de criptografia e códigos de resultado são definidos na RFC 4120.

Não sei por que, mas o caractere final do meu nome foi cortado.

Responder1

0x6. KDC_ERR_C_PRINCIPAL_UNKNOWNaí está... investigue isso. Parece que seus SPNs não estão configurados corretamente ou estão tentando usar uma conta que nem existe. Wireshark é outra boa ferramenta que você pode executar no servidor web para ver o que ele obtém do DC ao fazer solicitações.

informação relacionada