Problemas de autenticação quando os clientes acessam o servidor associado ao domínio a partir do nome DNS do subdomínio não Samba4

4

Temos um problema com o qual estamos lutando há algum tempo desde que implantamos 10 controladores de domínio Samba4 em nosso escritório principal e em todos os sites remotos há cerca de 3 anos.

Configuração atual simplificada:

  • 2 DCs no site principal com o DNS interno usando o subdomínio ad.companyname.com
  • 2 servidores BIND CentOS que atendem a todas as solicitações de DNS da intranet - zona principal: companyname.com
  • 2 servidores BIND CentOS que atendem a todas as solicitações de DNS do site externo - zona principal: companyname.com

Nesta configuração, configuramos os servidores BIND internos para que o DNS interno do S4 AD DCs seja autoritativo para ad.companyname.com, para que os clientes conectados aos servidores BIND possam resolver qualquer coisa que o Samba precise deles. Isso permite que todas as máquinas clientes na LAN resolvam qualquer endereço DNS dinâmico que o AD crie, ingresse no domínio etc. e seja fácil de configurar ao provisionar novos DCs. (Isso é importante com tantos CDs).

Quando provisionamos servidores que estão vinculados ao domínio, os clientes os acessam por meio de entradas DNS configuradas nos servidores DNS principais do BIND, para que eles tenham endereços como hostname.companyname.com, que os clientes usam para se conectar aos servidores / serviços. Eles também têm nomes de host ad.companyname.com criados pelo DNS interno do S4, mas não apontamos clientes com esses nomes.

O problema:

Alguns serviços (principalmente o servidor do OS X que notamos até agora) quando vinculados à AD não parecem gostar de ter os clientes apontados para um nome DNS diferente do subdomínio do samba. Por exemplo:

OS X 10.11 (também experimentado 10.6) Servidor, ligado ao AD, executando o servidor de arquivos SMB:

  • Ao conectar-se ao fileserver.companyname.com
    • O usuário deve se autenticar como ad.companyname.com \ shortname OU
    • O usuário deve autenticar como [email protected]
    • O uso do nome AD \ shortname não funciona
  • Ao conectar-se ao fileserver.ad.companyname.com
    • O usuário pode autenticar como apenas um nome abreviado

Outro exemplo:

OS X Server 10.11, ligado ao AD, executando o Profile Manager:

  • Os usuários podem se autenticar na interface da web do PHP usando apenas nome abreviado
  • Os usuários não podem autenticar durante o registro do dispositivo no dispositivo iOS com suas credenciais do AD

Notas:

No primeiro exemplo, uma solução é simplesmente apontar os clientes em fileserver.ad.companyname.com, mas o gerenciamento é resistente a essa ideia. No segundo exemplo para o MDM do gerenciador de perfil, o servidor reside na DMZ para que os clientes fora do campus ainda se conectem ao MDM e ele tenha entradas DNS internas e externas, portanto, ter um endereço ad.companyname.com voltado para o público não é uma ótima opção.

Perguntas:

  • Configurar uma ajuda do servidor WINS com isso?
  • Definir um domínio de pesquisa padrão da ajuda do DHCP com isso?
  • Existe alguma maneira de um host associado ao AD do Samba4 ter um nome de domínio no domínio base (na verdade, não apenas um registro separado no BIND apontando para o mesmo IP)?
    • Em caso afirmativo, é possível fazer isso com o DNS interno?
  • Existe alguma maneira de integrar o DNS do Samba4 AD diretamente com a configuração DNS do meu BIND de intranet para que os hosts ingressados no domínio obtenham nomes DNS e não o domínio DNS base (companyname.com)?
por Thomas Maerz 05.05.2016 / 23:18

0 respostas