Tenemos un dominio organizacional de Windows xxx.org que proporciona DHCP, puerta de enlace, red, Winbind, firewall, etc. En un sitio remoto tenemos otro dominio yyy.org que administramos y controlamos. Actualmente, todos los usuarios del sitio remoto, como parte del dominio principal, inician sesión y se autentican en consecuencia.
Estrictamente con el fin de crear y autenticar usuarios utilizando la construcción de correo electrónico, es decir[correo electrónico protegido]Configuramos un servidor ubuntu 14.04 con Samba 4.1 Active Directory. Samba AD nos permite crear usuarios con la construcción de correo electrónico. Luego, con suerte, podremos realizar SSO a servicios que requieren inicio de sesión de construcción de correo electrónico.
El problema es lograr que el cliente de Windows se una al dominio yyy.org. Configuramos la IP del DNS para que apunte a samba AD y cambiamos el dominio de la computadora a yyy.org. Pero el cliente aún se vincula al dominio principal.
Anteriormente, en el proceso de experimentación, configuramos Ubuntu para que sirviera DHCP y el enlace del cliente a yyy.org fue exitoso. Quizás tengamos que hacer esto de nuevo, no estoy seguro. Como dijimos en el primer post tenemos conocimientos limitados. Y, por supuesto, queremos que esto sea transparente con el dominio principal.
Respuesta1
sí, debería ser posible obtener el SSO para los clientes Windows y Mac usando Samba 4 y, siempre que el servidor esté en la misma red, no tendrá que realizar cambios en el firewall. Si tiene que tener los servidores en una red diferente, es muy probable que tenga que abrir puertos adicionales.
Los Chromebook no son tan fáciles de integrar. Aquí tienes un proceso de dos pasos. Primero debe conectar su servidor a Google Apps utilizando la herramienta Google Apps Sync.https://support.google.com/a/answer/6123891, esto mantiene los datos del usuario sincronizados y luego adjunta las aplicaciones de Google al servidor usando SAML para la autenticación de contraseña. Posteriormente, cualquier servicio de aplicaciones de Google utilizará los datos que haya proporcionado en el sistema.
En cuanto al dominio, utilice un subdominio no utilizado de yyy.org como internal.yyy.org o algo similar. De esa manera, su DNS interno no bloqueará ningún sitio web externo y podrá estar seguro de que nadie registrará ni reutilizará su dominio, como sucedió con .local.
Si tiene habilidades tecnológicas limitadas, le sugeriría buscar distribuciones empresariales gratuitas que vengan con una interfaz de administración y estén probadas para este propósito, como UCS Core Edition de Univention. Normalmente facilita la configuración y administración.