Utilizando recursos no território do Kerberos externo do Windows sem confiança entre domínios?

Question

Eu não sou uma pessoa do Windows, mas entendo a idéia básica de que um Active Directory é o molho especial do LDAP + Kerberos 5 + microsoft. Então, em uma situação onde eu tenho uma máquina windows sobre a qual eu não tenho controle que está em um Domínio Active Directory existente, é possível fazer com que uma pessoa nesta máquina adquira explicitamente um tíquete Kerberos para uma região estrangeira e então obtenha recursos em o servidor Linux que eu tenho controle sobre qual está em uma região Kerberos / LDAP que eu controlo?

Especificamente, suponha que eu tenha em meu reino um usuário "[email protected]", e este usuário faça login em uma máquina Windows aleatória em "BAR.COM" que é um domínio do AD do Microsoft usando o nome de usuário "baz". Agora, eles querem pegar arquivos de um compartilhamento em minha máquina quux.myrealm.com via Samba ou NFSv4 ou acessar uma página da web que requer autenticação Kerberos, e eles precisam fazer isso como [email protected] ao invés de baz @ BAR. COM que é a identidade que eles usaram para acessar o Windows.

o caminho do Linux / Unix / MIT Kerberos seria "kinit [email protected]" e depois ir para ele. Existe um equivalente no windows? Existe um equivalente que não requer a instalação de algo incomum (por exemplo, o MIT Kerberos para Windows).

A confiança entre territórios não é uma opção aqui, porque duvido que os administradores do AD existentes coloquem as entradas TGT apropriadas mesmo para autenticação unidirecional e, além disso, não tenho nenhum desejo de confiar neste domínio.

    

Answer 1

Eu não sou uma pessoa do Unix, mas posso dizer-lhe que a Microsoft tem várias tecnologias para isso (e suspeito que o Unix também o faça).

O primeiro é o Serviços de Federação do Active Directory, que, de acordo com o artigo da Wikipedia, pode

"provide users with single sign-on access to systems and applications located across organizational boundaries"

Isso, como os outros produtos que mencionarei, usa a nova abordagem "Baseada em Declarações", na qual você pode ter esses vários Security Token Services (STS) transformando suas "declarações" de autenticação no formato que seu servidor ou serviço precisa para autenticação (SAML, JWT, etc.).

Os Serviços de Federação do Active Directory devem ser instalados no domínio do Windows, portanto, isso pode não funcionar para você. No entanto, a Microsoft também possui alguns produtos "transformação de declarações" baseados em nuvem que você pode usar. Um é Serviços do Active Directory do Azure , que é um "Provedor de identidade" e também um "Serviço de Token de Segurança". O link anterior informa que os Serviços do Active Directory do Azure fornecem

"single sign-on to thousands of cloud apps and access to web apps that you run on-premises".

Eu realmente não recomendo soluções LDAP, mas se esta é a rota que você deseja seguir, você precisará usar a "API de gráfico" de substituição para acessar o "banco de dados" deste serviço. Observe também que esse serviço tem uma opção de "sincronização" que pode sincronizar contas de um Active Directory local para esse serviço de nuvem.

Finalmente, há o Serviço de Controle de Acesso do Azure, que oferece um "Serviço de Token de Segurança" (sem provedor de identidade). Eu pessoalmente acho que este serviço é mais adequado para aplicativos móveis que precisam se autorizar em nome de um usuário (OAuth2), mas há alguma sobreposição com os Serviços do Active Directory do Azure, e você pode querer verificá-lo.

PluralSight tem vários cursos sobre essas tecnologias, e sugiro que você os veja se quiser aprender mais sobre essas tecnologias.

    

Answer 2

Ok, então aqui estão algumas coisas que descobri.

Primeiramente, muitas das pessoas que querem usar meus recursos têm máquinas com Windows que não fazem parte do Active Domain, apenas máquinas pessoais. Então, com isso o que é necessário é rodar um terminal como administrador e

"ksetup / setrealm MYREALM_GOES_HERE "

Sem o privilégio de administrador, o ksetup não funcionará.

Após a reinicialização, a máquina cliente do Windows pensará que deve falar com o meu KDC ao obter ingressos (meu KDC é o DNS detectável).

O ksetup é mais ou menos uma interface de linha de comando para alterar as informações que seriam armazenadas em uma máquina Linux / Unix em /etc/krb5.conf, para que você possa especificar a região padrão com / setrealm e você pode dizer ao sistema sobre outras realms usando / addkdc e definir um mapeamento entre os principais kerberos e os usuários locais do windows usando / mapuser e soforth como detalhado aqui:

link

o que eu não vi é uma maneira de configurar o que estaria na seção [capaths] do arquivo krb5.conf, ou seja, dizer à máquina como obter relações de confiança transitivas entre domínios que não estão obviamente relacionados em uma hierarquia (ou seja, não ABC.EXAMPLE.COM vs EXAMPLE.COM, mas sim ABC.EXAMPLE.COM vs FOOBAR.COM)

Eu não tenho certeza do que aconteceria se você tentar fazer ksetup em um membro do AD, eu suspeito que seria mais bloqueado.