Temos um domínio organizacional do Windows xxx.org que fornece DHCP, Gateway, Rede, Winbind, firewall, etc. Em um site remoto, temos outro domínio yyy.org que gerenciamos e controlamos. Atualmente, todos os usuários no site remoto, como parte do domínio pai, fazem login e se autenticam adequadamente.
Estritamente para fins de criação e autenticação de usuários utilizando a construção de e-mail, ou seja[e-mail protegido]configuramos um servidor Ubuntu 14.04 com Samba 4.1 Active Directory. O Samba AD nos permite criar usuários com a construção de email. Podemos então, esperançosamente, fazer SSO para serviços que exigem login de construção de e-mail.
O problema é fazer com que o cliente Windows ingresse no domínio yyy.org. Definimos o IP DNS para apontar para samba AD e alteramos o domínio dos computadores para yyy.org. Mas o cliente ainda está vinculado ao domínio pai.
Anteriormente, no processo de experimentação, configuramos o Ubuntu para servir DHCP e a ligação do cliente a yyy.org foi bem-sucedida. Pode ser que tenhamos que fazer isso de novo, não tenho certeza. Como dissemos no primeiro post temos conhecimento limitado. E, claro, queremos que isso seja perfeito para o domínio pai.
Responder1
sim, deve ser possível obter o SSO para clientes Windows e Mac usando Samba 4 e desde que o servidor esteja na mesma rede você não precisará fazer alterações no firewall. Se você precisar ter servidores em uma rede diferente, há uma boa chance de você ter que abrir portas adicionais.
Os Chromebooks não são tão fáceis de integrar. Aqui você tem um processo de duas etapas. Primeiro você precisa conectar seu servidor ao Google Apps usando a ferramenta Google Apps Synchttps://support.google.com/a/answer/6123891, isso mantém os dados do usuário sincronizados e, em seguida, anexa os aplicativos do Google ao servidor usando SAML para autenticação por senha. Posteriormente, qualquer serviço do Google Apps usará os dados que você provisionou no sistema.
Quanto ao domínio, use um subdomínio não utilizado de yyy.org como internal.yyy.org ou algo semelhante. Dessa forma, seu DNS interno não bloqueará nenhum site externo e você poderá ter certeza de que ninguém registrará ou redirecionará seu domínio, como aconteceu com .local .
Se você tem habilidades técnicas limitadas, sugiro procurar distribuições empresariais gratuitas que vêm com uma interface de gerenciamento e são testadas para essa finalidade, como o UCS Core Edition da Univention. Normalmente facilita a configuração e a administração.