Cómo garantizar logon en subdominios remotos con conexión débil

Javier:

OK, desactivaré el caché de pertenencia a Grupos Universales en cada
sitio,
aunque no veo por qué no puede convivir con el GC. Pero este no era el
tema
de mi consulta, que sigue quedando abierto...

El problema es cómo garantizar el inicio de sesión, o el permitir seguir
trabajando con el servidor local, para los usuarios de los sitios remotos
cuando cae la VPN y no existe conectividad con la sede central.

Obviamente, este problema se agrava si existe una total dependencia del
servidor de la sucursal con el de la sede central, haciéndolo ser servidor
miembro de un único dominio como tú sugieres, de ahí la decidión de crear
subdominios.

Debemos tener en cuenta que la conexión entre sitios es lenta (ADSL) y
poco
fiable (cae con cierta frecuencia), y que se intenta reducir el tráfico de
datos entre sitios.

Por otra parte, la sugerencia de administrar AD desde la sede central
cambiando las conexión del DC en la MMC de Usuarios y Equipos de Active
Directory, además de ser lenta, supone distribuir las cuentas de usuarios
entre los diferentes dominios, algo que he quiero evitar por los
requerimientos de validación del servidor Exchange y del servidor FTP, que
tengo en el sistema central.

En definitiva, estamos como al principio.
Te agradecería cualquier sugerencia dirigida a la pregunta fundamental de
la
cuestión que reza el titular.

Salu2 y gracias de nuevo,
Juanma Arnau.


"Javier Inglés [MS MVP]" escribió:

ok, si los DC's ya son GC, entonces no debes activar el Universal Group
Memebership Caching en cada Site, no tiene sentido; o se pone una cosa u
otra, pero no las 2.

No obstante, sigo diciendo que el tner varios subdominios sigue siendo
por
temas muy concretos, ya sean "políticos", por necesitar diferentes
configuraciones de seguridad en password por ejemplo, o por temas
admisitrativos y funcionales.

Para tu caso, teniendo un únicao dominio, con DC's en los sites remotos o
servidores miemrbo para impresión, ficheros, etc...es suficiente.

La adminsitración del AD en la sede la puedes hacer, pero en el AD users
and
computers deberás elegir el DC o dominio al que te quieras conecar para
adminsitrarlo, o crearte una MMC personalziada con dicho complemento y
administrarlo desde ahí

Salu2!!
Javier Inglés
MS MVP, Windows Server-Directory Services





"Juanma Arnau" escribió en el
mensaje news:
> Javier:
>
> Gracias por tu pronta respuesta (le hace a uno sentirse acompañado...)
> pero
> probablemente no me expliqué bien en mi pregunta porque no era la que
> esperaba.
>
> Te contesto matizando algunos términos que por lo visto no he llegado a
> expresar correctamente en mi pregunta:
> - Desde luego que hablabamos de W2K3, eso es lo que tengo en todos los
> servidores.
> - Los Grupos Universales sólo los utilizo para determinados grupos de
> seguridad, pero no son los principalmente utilizados. Lo único que
> quería
> decir con ello es que el caché está activado en cada uno de los sitios
> configurados.
> - Todos los DCs YA son GC, además de asumir otras funciones.
> - He creado varios subdominios porque los Sistemas Informáticos están
> ubicados físicamente en lugares distintos y remotos (por toda la
> geografía
> española) y su conexión con el S.I central se realiza mediante VPNs
> sobre
> ADSL; y dado que esta conexión no es muy fiable, quiero que tengan
> cierta
> autonomía operacional, por ello cada DC de un subdominio es además
> servidor
> de archivos, de impresoras y ofrece otros servicios a los usuarios de
> las
> máquinas del sitio.
> - Al mismo tiempo quiero centralizar la administración de AD y de las
> cuentas de usuarios en el dominio raíz, por razones de comodidad, por
> exigencias del Exchange instalado en uno de los servidores de la
> central,
> y
> por las exigencias de validación de usuarios en la Web de la intranet y
> del
> FTP (AD isolate) alojado también en el S.I central.
>
> Por otra parte, ahora mismo voy a buscar la documentación a la que me
> remites y ya te diré si me ha sido útil.
>
> Una vez más, gracias, pero mira si puedes ayudarme más.
>
> Salu2,
> Juanma Arnau.
>
>
> "Javier Inglés [MS MVP]" wrote:
>
>> La opción de cachear la membresía a grupos universales sólo es
>> funciona
>> en
>> windows 2003.
>>
>> Repasa que lo tengas bien activado; otra posibilidad es que todos los
>> DC's
>> sean Global Catalog directamente en lugar de hacer el caché de los
>> grupos
>> universales.
>>
>> Para lo segundo, no entiendo por qué has creado varios subdominios,
>> cuando
>> teniendo uno te basta de sobra para toda tu infraestructura, sñolo se
>> aconseja hacer subdominios en casos determinados, y ni siquiera Ms lo
>> aconseja salvo las excepciones adecuadas (los documentos de branch
>> office
>> para AD de Ms hablan de cómo montar los dominiosy subdominios, pero
>> con
>> uno
>> sólo te valdría perfectamente). Mira en la web de Ms por el Identity
>> Integration Server.
>> Salu2!!
>> Javier Inglés
>> MS MVP, Windows Server-Directory Services
>>
>>
>>
>>
>>
>> "Juanma Arnau" escribió en el
>> mensaje news:
>> > Buenaaassss!.
>> >
>> > Llevo varios días buscando infructuosamente documentación que me
>> > guíe
>> > en
>> > la
>> > resolución de un problema que tengo con el diseño del S.I. que
>> > administro;
>> > por lo que si algún alma cartitativa arrojara algo de luz al
>> > respecto
>> > le
>> > estaría eternamente agradecido.
>> >
>> > En su día, y siguiendo las recomendaciones de Microsoft que leí en
>> > algún
>> > documento técnico, implemente un bosque de dominios basado en un
>> > dominio
>> > raíz
>> > (S.I ubicado en las oficinas centrales) y varios subdominios remotos
>> > (SS.II
>> > ubicados en diferentes delegaciones interconectadas en estrella
>> > mediante
>> > VPNs
>> > sobre ADSL), con el objeto de mantener una administración de AD
>> > centralizada.
>> >
>> > Cada S.I. dispone de un DC que ofrece los servicios típicos (AD,
>> > DNS,
>> > DHCP,
>> > WINS, servidor de ficheros y de impresoras...) a los usuarios que
>> > trabajan
>> > en
>> > ese sitio, salvo el S.I de las oficinas centrales que dispone de
>> > mayores
>> > recursos (varios DCs redundan los servicios críticos y distribuyen
>> > la
>> > carga
>> > de los típicos: servidor de archivos e impresoras, servidor de
>> > terminales,
>> > servidor de Exchange, servidor Web/FTP...) y mantiene las cuentas de
>> > todos
>> > los usuarios de la corporación.
>> >
>> > Todos los DCs son GC, y al menos un DC por sitio mantiene el caché
>> > de
>> > los
>> > grupos universales.
>> >
>> > Todo parece ir bien hasta que cae alguna VPN (algo bastante
>> > frecuente,
>> > por
>> > desgracia). Entonces, los usuarios del sitio sin conexión no pueden
>> > iniciar
>> > sesión, ni acceder a los recursos de su servidor local (puesto no se
>> > pueden
>> > comprobar sus credenciales), hasta que se restablece la conexión.
>> >
>> > Tenía entendido que los DCs locales mantenían un caché en su GC que
>> > permitiía validar a los usuarios en el dominio raíz aún estando sin
>> > conexión
>> > (similar al inicio de sesión desde un equipo portátil en
>> > desconexión),
>> > pero
>> > debo estar equivocado o no he sabido configurar adecuadamente el
>> > sistema.
>> >
>> > ¿A quién se le ocurre cómo podría solucionar esto?
>> > Teniendo en cuenta lo siguiente:
>> > - Ya estoy buscando una solución de conectividad más robusta, pero
>> > esta
>> > no
>> > debería ser la única solución.
>> > - Me interesa mantener las cuentas de usuario centralizadas para
>> > simplificar
>> > la administración, mantener un único login y password para cada
>> > usuario
>> > y
>> > su
>> > acceso a cualquier recurso del sistema, adecuarme a las dependencias
>> > del
>> > servidor de Exchange y del servidor Web/FTP alojados en el dominio
>> > raíz, y
>> > alguna otra razón que no recuerdo ahora mismo.
>> > - La solución de duplicar las cuentas de usuario en los subdominios
>> > para
>> > los
>> > usuarios del sitio no acaba de convencerme, salvo que hubiera alguna
>> > forma
>> > de
>> > vincularlas con las del raíz de forma que se actualizaran los
>> > cambios
>> > entre
>> > ellas (algo que no se cómo, ni creo que se pueda hacer).
>> >
>> > En fin, agradeceré cualquier consejo al respecto.
>> >
>> > Salu2,
>> > Juanma Arnau.
>>
>>
>>

Javier:

OK, desactivaré el caché de pertenencia a Grupos Universales en cada sitio,
aunque no veo por qué no puede convivir con el GC. Pero este no era el tema
de mi consulta, que sigue quedando abierto...

El problema es cómo garantizar el inicio de sesión, o el permitir seguir
trabajando con el servidor local, para los usuarios de los sitios remotos
cuando cae la VPN y no existe conectividad con la sede central.

Obviamente, este problema se agrava si existe una total dependencia del
servidor de la sucursal con el de la sede central, haciéndolo ser servidor
miembro de un único dominio como tú sugieres, de ahí la decidión de crear
subdominios.

Debemos tener en cuenta que la conexión entre sitios es lenta (ADSL) y poco
fiable (cae con cierta frecuencia), y que se intenta reducir el tráfico de
datos entre sitios.

Por otra parte, la sugerencia de administrar AD desde la sede central
cambiando las conexión del DC en la MMC de Usuarios y Equipos de Active
Directory, además de ser lenta, supone distribuir las cuentas de usuarios
entre los diferentes dominios, algo que he quiero evitar por los
requerimientos de validación del servidor Exchange y del servidor FTP, que
tengo en el sistema central.

En definitiva, estamos como al principio.
Te agradecería cualquier sugerencia dirigida a la pregunta fundamental de la
cuestión que reza el titular.

Salu2 y gracias de nuevo,
Juanma Arnau.


"Javier Inglés [MS MVP]" escribió:

> ok, si los DC's ya son GC, entonces no debes activar el Universal Group
> Memebership Caching en cada Site, no tiene sentido; o se pone una cosa u
> otra, pero no las 2.
>
> No obstante, sigo diciendo que el tner varios subdominios sigue siendo por
> temas muy concretos, ya sean "políticos", por necesitar diferentes
> configuraciones de seguridad en password por ejemplo, o por temas
> admisitrativos y funcionales.
>
> Para tu caso, teniendo un únicao dominio, con DC's en los sites remotos o
> servidores miemrbo para impresión, ficheros, etc...es suficiente.
>
> La adminsitración del AD en la sede la puedes hacer, pero en el AD users and
> computers deberás elegir el DC o dominio al que te quieras conecar para
> adminsitrarlo, o crearte una MMC personalziada con dicho complemento y
> administrarlo desde ahí
>
> Salu2!!
> Javier Inglés
> MS MVP, Windows Server-Directory Services
>
>
>
>
>
> "Juanma Arnau" escribió en el
> mensaje news:
> > Javier:
> >
> > Gracias por tu pronta respuesta (le hace a uno sentirse acompañado...)
> > pero
> > probablemente no me expliqué bien en mi pregunta porque no era la que
> > esperaba.
> >
> > Te contesto matizando algunos términos que por lo visto no he llegado a
> > expresar correctamente en mi pregunta:
> > - Desde luego que hablabamos de W2K3, eso es lo que tengo en todos los
> > servidores.
> > - Los Grupos Universales sólo los utilizo para determinados grupos de
> > seguridad, pero no son los principalmente utilizados. Lo único que quería
> > decir con ello es que el caché está activado en cada uno de los sitios
> > configurados.
> > - Todos los DCs YA son GC, además de asumir otras funciones.
> > - He creado varios subdominios porque los Sistemas Informáticos están
> > ubicados físicamente en lugares distintos y remotos (por toda la geografía
> > española) y su conexión con el S.I central se realiza mediante VPNs sobre
> > ADSL; y dado que esta conexión no es muy fiable, quiero que tengan cierta
> > autonomía operacional, por ello cada DC de un subdominio es además
> > servidor
> > de archivos, de impresoras y ofrece otros servicios a los usuarios de las
> > máquinas del sitio.
> > - Al mismo tiempo quiero centralizar la administración de AD y de las
> > cuentas de usuarios en el dominio raíz, por razones de comodidad, por
> > exigencias del Exchange instalado en uno de los servidores de la central,
> > y
> > por las exigencias de validación de usuarios en la Web de la intranet y
> > del
> > FTP (AD isolate) alojado también en el S.I central.
> >
> > Por otra parte, ahora mismo voy a buscar la documentación a la que me
> > remites y ya te diré si me ha sido útil.
> >
> > Una vez más, gracias, pero mira si puedes ayudarme más.
> >
> > Salu2,
> > Juanma Arnau.
> >
> >
> > "Javier Inglés [MS MVP]" wrote:
> >
> >> La opción de cachear la membresía a grupos universales sólo es funciona
> >> en
> >> windows 2003.
> >>
> >> Repasa que lo tengas bien activado; otra posibilidad es que todos los
> >> DC's
> >> sean Global Catalog directamente en lugar de hacer el caché de los grupos
> >> universales.
> >>
> >> Para lo segundo, no entiendo por qué has creado varios subdominios,
> >> cuando
> >> teniendo uno te basta de sobra para toda tu infraestructura, sñolo se
> >> aconseja hacer subdominios en casos determinados, y ni siquiera Ms lo
> >> aconseja salvo las excepciones adecuadas (los documentos de branch office
> >> para AD de Ms hablan de cómo montar los dominiosy subdominios, pero con
> >> uno
> >> sólo te valdría perfectamente). Mira en la web de Ms por el Identity
> >> Integration Server.
> >> Salu2!!
> >> Javier Inglés
> >> MS MVP, Windows Server-Directory Services
> >>
> >>
> >>
> >>
> >>
> >> "Juanma Arnau" escribió en el
> >> mensaje news:
> >> > Buenaaassss!.
> >> >
> >> > Llevo varios días buscando infructuosamente documentación que me guíe
> >> > en
> >> > la
> >> > resolución de un problema que tengo con el diseño del S.I. que
> >> > administro;
> >> > por lo que si algún alma cartitativa arrojara algo de luz al respecto
> >> > le
> >> > estaría eternamente agradecido.
> >> >
> >> > En su día, y siguiendo las recomendaciones de Microsoft que leí en
> >> > algún
> >> > documento técnico, implemente un bosque de dominios basado en un
> >> > dominio
> >> > raíz
> >> > (S.I ubicado en las oficinas centrales) y varios subdominios remotos
> >> > (SS.II
> >> > ubicados en diferentes delegaciones interconectadas en estrella
> >> > mediante
> >> > VPNs
> >> > sobre ADSL), con el objeto de mantener una administración de AD
> >> > centralizada.
> >> >
> >> > Cada S.I. dispone de un DC que ofrece los servicios típicos (AD, DNS,
> >> > DHCP,
> >> > WINS, servidor de ficheros y de impresoras...) a los usuarios que
> >> > trabajan
> >> > en
> >> > ese sitio, salvo el S.I de las oficinas centrales que dispone de
> >> > mayores
> >> > recursos (varios DCs redundan los servicios críticos y distribuyen la
> >> > carga
> >> > de los típicos: servidor de archivos e impresoras, servidor de
> >> > terminales,
> >> > servidor de Exchange, servidor Web/FTP...) y mantiene las cuentas de
> >> > todos
> >> > los usuarios de la corporación.
> >> >
> >> > Todos los DCs son GC, y al menos un DC por sitio mantiene el caché de
> >> > los
> >> > grupos universales.
> >> >
> >> > Todo parece ir bien hasta que cae alguna VPN (algo bastante frecuente,
> >> > por
> >> > desgracia). Entonces, los usuarios del sitio sin conexión no pueden
> >> > iniciar
> >> > sesión, ni acceder a los recursos de su servidor local (puesto no se
> >> > pueden
> >> > comprobar sus credenciales), hasta que se restablece la conexión.
> >> >
> >> > Tenía entendido que los DCs locales mantenían un caché en su GC que
> >> > permitiía validar a los usuarios en el dominio raíz aún estando sin
> >> > conexión
> >> > (similar al inicio de sesión desde un equipo portátil en desconexión),
> >> > pero
> >> > debo estar equivocado o no he sabido configurar adecuadamente el
> >> > sistema.
> >> >
> >> > ¿A quién se le ocurre cómo podría solucionar esto?
> >> > Teniendo en cuenta lo siguiente:
> >> > - Ya estoy buscando una solución de conectividad más robusta, pero esta
> >> > no
> >> > debería ser la única solución.
> >> > - Me interesa mantener las cuentas de usuario centralizadas para
> >> > simplificar
> >> > la administración, mantener un único login y password para cada usuario
> >> > y
> >> > su
> >> > acceso a cualquier recurso del sistema, adecuarme a las dependencias
> >> > del
> >> > servidor de Exchange y del servidor Web/FTP alojados en el dominio
> >> > raíz, y
> >> > alguna otra razón que no recuerdo ahora mismo.
> >> > - La solución de duplicar las cuentas de usuario en los subdominios
> >> > para
> >> > los
> >> > usuarios del sitio no acaba de convencerme, salvo que hubiera alguna
> >> > forma
> >> > de
> >> > vincularlas con las del raíz de forma que se actualizaran los cambios
> >> > entre
> >> > ellas (algo que no se cómo, ni creo que se pueda hacer).
> >> >
> >> > En fin, agradeceré cualquier consejo al respecto.
> >> >
> >> > Salu2,
> >> > Juanma Arnau.
> >>
> >>
> >>
>
>
>

Para que un usuario pueda inciar sesión cuando no esté la VPN se deben
cumplir estas condiciones:

- Por lo menos un controlador de dominio, *del dominio donde tiene la cuenta
el usuario*
- Que un controlador de dominio sea Catálogo Global, o habilitar el caching
de grupos universales
- Un servidor DNS que resuelva los nombres de dominios involucrados, y
*además* la zona _mscds.dominio.raiz

Opinión personal mía: tienes un problema de diseño. Si haces diferentes
dominios para disminuir el tráfico sobre la WAN, entonces tienes que crear
los usuarios en cada dominio.
Si mantienes los usuarios en el dominio raíz (central) entonces los usuarios
deben iniciar sesión contra un controlador de dominio de *su dominio*, que si
lo tienes sólo en la central, hace tráfico sobre la VPN; y que si lo pones en
cada sucursal para que inicien sesión sin la VPN, entonces el diseño que haz
hecho para dismunuir tráfico carece de sentido porque se replica el dominio
raíz completo

Saludos
Guillermo Delprato
MVP - MCT - MCSE - MCSA

"Juanma Arnau" wrote:

> Javier:
>
> OK, desactivaré el caché de pertenencia a Grupos Universales en cada sitio,
> aunque no veo por qué no puede convivir con el GC. Pero este no era el tema
> de mi consulta, que sigue quedando abierto...
>
> El problema es cómo garantizar el inicio de sesión, o el permitir seguir
> trabajando con el servidor local, para los usuarios de los sitios remotos
> cuando cae la VPN y no existe conectividad con la sede central.
>
> Obviamente, este problema se agrava si existe una total dependencia del
> servidor de la sucursal con el de la sede central, haciéndolo ser servidor
> miembro de un único dominio como tú sugieres, de ahí la decidión de crear
> subdominios.
>
> Debemos tener en cuenta que la conexión entre sitios es lenta (ADSL) y poco
> fiable (cae con cierta frecuencia), y que se intenta reducir el tráfico de
> datos entre sitios.
>
> Por otra parte, la sugerencia de administrar AD desde la sede central
> cambiando las conexión del DC en la MMC de Usuarios y Equipos de Active
> Directory, además de ser lenta, supone distribuir las cuentas de usuarios
> entre los diferentes dominios, algo que he quiero evitar por los
> requerimientos de validación del servidor Exchange y del servidor FTP, que
> tengo en el sistema central.
>
> En definitiva, estamos como al principio.
> Te agradecería cualquier sugerencia dirigida a la pregunta fundamental de la
> cuestión que reza el titular.
>
> Salu2 y gracias de nuevo,
> Juanma Arnau.
>
>
> "Javier Inglés [MS MVP]" escribió:
>
> > ok, si los DC's ya son GC, entonces no debes activar el Universal Group
> > Memebership Caching en cada Site, no tiene sentido; o se pone una cosa u
> > otra, pero no las 2.
> >
> > No obstante, sigo diciendo que el tner varios subdominios sigue siendo por
> > temas muy concretos, ya sean "políticos", por necesitar diferentes
> > configuraciones de seguridad en password por ejemplo, o por temas
> > admisitrativos y funcionales.
> >
> > Para tu caso, teniendo un únicao dominio, con DC's en los sites remotos o
> > servidores miemrbo para impresión, ficheros, etc...es suficiente.
> >
> > La adminsitración del AD en la sede la puedes hacer, pero en el AD users and
> > computers deberás elegir el DC o dominio al que te quieras conecar para
> > adminsitrarlo, o crearte una MMC personalziada con dicho complemento y
> > administrarlo desde ahí
> >
> > Salu2!!
> > Javier Inglés
> > MS MVP, Windows Server-Directory Services
> >
> >
> >
> >
> >
> > "Juanma Arnau" escribió en el
> > mensaje news:
> > > Javier:
> > >
> > > Gracias por tu pronta respuesta (le hace a uno sentirse acompañado...)
> > > pero
> > > probablemente no me expliqué bien en mi pregunta porque no era la que
> > > esperaba.
> > >
> > > Te contesto matizando algunos términos que por lo visto no he llegado a
> > > expresar correctamente en mi pregunta:
> > > - Desde luego que hablabamos de W2K3, eso es lo que tengo en todos los
> > > servidores.
> > > - Los Grupos Universales sólo los utilizo para determinados grupos de
> > > seguridad, pero no son los principalmente utilizados. Lo único que quería
> > > decir con ello es que el caché está activado en cada uno de los sitios
> > > configurados.
> > > - Todos los DCs YA son GC, además de asumir otras funciones.
> > > - He creado varios subdominios porque los Sistemas Informáticos están
> > > ubicados físicamente en lugares distintos y remotos (por toda la geografía
> > > española) y su conexión con el S.I central se realiza mediante VPNs sobre
> > > ADSL; y dado que esta conexión no es muy fiable, quiero que tengan cierta
> > > autonomía operacional, por ello cada DC de un subdominio es además
> > > servidor
> > > de archivos, de impresoras y ofrece otros servicios a los usuarios de las
> > > máquinas del sitio.
> > > - Al mismo tiempo quiero centralizar la administración de AD y de las
> > > cuentas de usuarios en el dominio raíz, por razones de comodidad, por
> > > exigencias del Exchange instalado en uno de los servidores de la central,
> > > y
> > > por las exigencias de validación de usuarios en la Web de la intranet y
> > > del
> > > FTP (AD isolate) alojado también en el S.I central.
> > >
> > > Por otra parte, ahora mismo voy a buscar la documentación a la que me
> > > remites y ya te diré si me ha sido útil.
> > >
> > > Una vez más, gracias, pero mira si puedes ayudarme más.
> > >
> > > Salu2,
> > > Juanma Arnau.
> > >
> > >
> > > "Javier Inglés [MS MVP]" wrote:
> > >
> > >> La opción de cachear la membresía a grupos universales sólo es funciona
> > >> en
> > >> windows 2003.
> > >>
> > >> Repasa que lo tengas bien activado; otra posibilidad es que todos los
> > >> DC's
> > >> sean Global Catalog directamente en lugar de hacer el caché de los grupos
> > >> universales.
> > >>
> > >> Para lo segundo, no entiendo por qué has creado varios subdominios,
> > >> cuando
> > >> teniendo uno te basta de sobra para toda tu infraestructura, sñolo se
> > >> aconseja hacer subdominios en casos determinados, y ni siquiera Ms lo
> > >> aconseja salvo las excepciones adecuadas (los documentos de branch office
> > >> para AD de Ms hablan de cómo montar los dominiosy subdominios, pero con
> > >> uno
> > >> sólo te valdría perfectamente). Mira en la web de Ms por el Identity
> > >> Integration Server.
> > >> Salu2!!
> > >> Javier Inglés
> > >> MS MVP, Windows Server-Directory Services
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> "Juanma Arnau" escribió en el
> > >> mensaje news:
> > >> > Buenaaassss!.
> > >> >
> > >> > Llevo varios días buscando infructuosamente documentación que me guíe
> > >> > en
> > >> > la
> > >> > resolución de un problema que tengo con el diseño del S.I. que
> > >> > administro;
> > >> > por lo que si algún alma cartitativa arrojara algo de luz al respecto
> > >> > le
> > >> > estaría eternamente agradecido.
> > >> >
> > >> > En su día, y siguiendo las recomendaciones de Microsoft que leí en
> > >> > algún
> > >> > documento técnico, implemente un bosque de dominios basado en un
> > >> > dominio
> > >> > raíz
> > >> > (S.I ubicado en las oficinas centrales) y varios subdominios remotos
> > >> > (SS.II
> > >> > ubicados en diferentes delegaciones interconectadas en estrella
> > >> > mediante
> > >> > VPNs
> > >> > sobre ADSL), con el objeto de mantener una administración de AD
> > >> > centralizada.
> > >> >
> > >> > Cada S.I. dispone de un DC que ofrece los servicios típicos (AD, DNS,
> > >> > DHCP,
> > >> > WINS, servidor de ficheros y de impresoras...) a los usuarios que
> > >> > trabajan
> > >> > en
> > >> > ese sitio, salvo el S.I de las oficinas centrales que dispone de
> > >> > mayores
> > >> > recursos (varios DCs redundan los servicios críticos y distribuyen la
> > >> > carga
> > >> > de los típicos: servidor de archivos e impresoras, servidor de
> > >> > terminales,
> > >> > servidor de Exchange, servidor Web/FTP...) y mantiene las cuentas de
> > >> > todos
> > >> > los usuarios de la corporación.
> > >> >
> > >> > Todos los DCs son GC, y al menos un DC por sitio mantiene el caché de
> > >> > los
> > >> > grupos universales.
> > >> >
> > >> > Todo parece ir bien hasta que cae alguna VPN (algo bastante frecuente,
> > >> > por
> > >> > desgracia). Entonces, los usuarios del sitio sin conexión no pueden
> > >> > iniciar
> > >> > sesión, ni acceder a los recursos de su servidor local (puesto no se
> > >> > pueden
> > >> > comprobar sus credenciales), hasta que se restablece la conexión.
> > >> >
> > >> > Tenía entendido que los DCs locales mantenían un caché en su GC que
> > >> > permitiía validar a los usuarios en el dominio raíz aún estando sin
> > >> > conexión
> > >> > (similar al inicio de sesión desde un equipo portátil en desconexión),
> > >> > pero
> > >> > debo estar equivocado o no he sabido configurar adecuadamente el
> > >> > sistema.
> > >> >
> > >> > ¿A quién se le ocurre cómo podría solucionar esto?
> > >> > Teniendo en cuenta lo siguiente:
> > >> > - Ya estoy buscando una solución de conectividad más robusta, pero esta
> > >> > no
> > >> > debería ser la única solución.
> > >> > - Me interesa mantener las cuentas de usuario centralizadas para
> > >> > simplificar
> > >> > la administración, mantener un único login y password para cada usuario
> > >> > y
> > >> > su
> > >> > acceso a cualquier recurso del sistema, adecuarme a las dependencias
> > >> > del
> > >> > servidor de Exchange y del servidor Web/FTP alojados en el dominio
> > >> > raíz, y
> > >> > alguna otra razón que no recuerdo ahora mismo.
> > >> > - La solución de duplicar las cuentas de usuario en los subdominios
> > >> > para
> > >> > los
> > >> > usuarios del sitio no acaba de convencerme, salvo que hubiera alguna
> > >> > forma
> > >> > de
> > >> > vincularlas con las del raíz de forma que se actualizaran los cambios
> > >> > entre
> > >> > ellas (algo que no se cómo, ni creo que se pueda hacer).
> > >> >
> > >> > En fin, agradeceré cualquier consejo al respecto.
> > >> >
> > >> > Salu2,
> > >> > Juanma Arnau.
> > >>
> > >>
> > >>
> >
> >
> >

OK, gracias Guillermo!

Ahora lo veo más claro.
Javier me sugirió también un problema de diseño pero no entendí la razón.

Rediseñaré el sistema para que los servidores de las sucursales sean DC y GC
de un único dominio cuyos maestros FSMO estén en la central, de esté modo
espero que un servidor de la sucursal pueda validar temporalmente a los
usuarios locales en caso de pérdida de conexión.
¿Es correcto el planteamiento?

Salu2,
Juanma Arnau.


"Guillermo Delprato" wrote:

> Para que un usuario pueda inciar sesión cuando no esté la VPN se deben
> cumplir estas condiciones:
>
> - Por lo menos un controlador de dominio, *del dominio donde tiene la cuenta
> el usuario*
> - Que un controlador de dominio sea Catálogo Global, o habilitar el caching
> de grupos universales
> - Un servidor DNS que resuelva los nombres de dominios involucrados, y
> *además* la zona _mscds.dominio.raiz
>
> Opinión personal mía: tienes un problema de diseño. Si haces diferentes
> dominios para disminuir el tráfico sobre la WAN, entonces tienes que crear
> los usuarios en cada dominio.
> Si mantienes los usuarios en el dominio raíz (central) entonces los usuarios
> deben iniciar sesión contra un controlador de dominio de *su dominio*, que si
> lo tienes sólo en la central, hace tráfico sobre la VPN; y que si lo pones en
> cada sucursal para que inicien sesión sin la VPN, entonces el diseño que haz
> hecho para dismunuir tráfico carece de sentido porque se replica el dominio
> raíz completo
>
> Saludos
> Guillermo Delprato
> MVP - MCT - MCSE - MCSA
>
> "Juanma Arnau" wrote:
>
> > Javier:
> >
> > OK, desactivaré el caché de pertenencia a Grupos Universales en cada sitio,
> > aunque no veo por qué no puede convivir con el GC. Pero este no era el tema
> > de mi consulta, que sigue quedando abierto...
> >
> > El problema es cómo garantizar el inicio de sesión, o el permitir seguir
> > trabajando con el servidor local, para los usuarios de los sitios remotos
> > cuando cae la VPN y no existe conectividad con la sede central.
> >
> > Obviamente, este problema se agrava si existe una total dependencia del
> > servidor de la sucursal con el de la sede central, haciéndolo ser servidor
> > miembro de un único dominio como tú sugieres, de ahí la decidión de crear
> > subdominios.
> >
> > Debemos tener en cuenta que la conexión entre sitios es lenta (ADSL) y poco
> > fiable (cae con cierta frecuencia), y que se intenta reducir el tráfico de
> > datos entre sitios.
> >
> > Por otra parte, la sugerencia de administrar AD desde la sede central
> > cambiando las conexión del DC en la MMC de Usuarios y Equipos de Active
> > Directory, además de ser lenta, supone distribuir las cuentas de usuarios
> > entre los diferentes dominios, algo que he quiero evitar por los
> > requerimientos de validación del servidor Exchange y del servidor FTP, que
> > tengo en el sistema central.
> >
> > En definitiva, estamos como al principio.
> > Te agradecería cualquier sugerencia dirigida a la pregunta fundamental de la
> > cuestión que reza el titular.
> >
> > Salu2 y gracias de nuevo,
> > Juanma Arnau.
> >
> >
> > "Javier Inglés [MS MVP]" escribió:
> >
> > > ok, si los DC's ya son GC, entonces no debes activar el Universal Group
> > > Memebership Caching en cada Site, no tiene sentido; o se pone una cosa u
> > > otra, pero no las 2.
> > >
> > > No obstante, sigo diciendo que el tner varios subdominios sigue siendo por
> > > temas muy concretos, ya sean "políticos", por necesitar diferentes
> > > configuraciones de seguridad en password por ejemplo, o por temas
> > > admisitrativos y funcionales.
> > >
> > > Para tu caso, teniendo un únicao dominio, con DC's en los sites remotos o
> > > servidores miemrbo para impresión, ficheros, etc...es suficiente.
> > >
> > > La adminsitración del AD en la sede la puedes hacer, pero en el AD users and
> > > computers deberás elegir el DC o dominio al que te quieras conecar para
> > > adminsitrarlo, o crearte una MMC personalziada con dicho complemento y
> > > administrarlo desde ahí
> > >
> > > Salu2!!
> > > Javier Inglés
> > > MS MVP, Windows Server-Directory Services
> > >
> > >
> > >
> > >
> > >
> > > "Juanma Arnau" escribió en el
> > > mensaje news:
> > > > Javier:
> > > >
> > > > Gracias por tu pronta respuesta (le hace a uno sentirse acompañado...)
> > > > pero
> > > > probablemente no me expliqué bien en mi pregunta porque no era la que
> > > > esperaba.
> > > >
> > > > Te contesto matizando algunos términos que por lo visto no he llegado a
> > > > expresar correctamente en mi pregunta:
> > > > - Desde luego que hablabamos de W2K3, eso es lo que tengo en todos los
> > > > servidores.
> > > > - Los Grupos Universales sólo los utilizo para determinados grupos de
> > > > seguridad, pero no son los principalmente utilizados. Lo único que quería
> > > > decir con ello es que el caché está activado en cada uno de los sitios
> > > > configurados.
> > > > - Todos los DCs YA son GC, además de asumir otras funciones.
> > > > - He creado varios subdominios porque los Sistemas Informáticos están
> > > > ubicados físicamente en lugares distintos y remotos (por toda la geografía
> > > > española) y su conexión con el S.I central se realiza mediante VPNs sobre
> > > > ADSL; y dado que esta conexión no es muy fiable, quiero que tengan cierta
> > > > autonomía operacional, por ello cada DC de un subdominio es además
> > > > servidor
> > > > de archivos, de impresoras y ofrece otros servicios a los usuarios de las
> > > > máquinas del sitio.
> > > > - Al mismo tiempo quiero centralizar la administración de AD y de las
> > > > cuentas de usuarios en el dominio raíz, por razones de comodidad, por
> > > > exigencias del Exchange instalado en uno de los servidores de la central,
> > > > y
> > > > por las exigencias de validación de usuarios en la Web de la intranet y
> > > > del
> > > > FTP (AD isolate) alojado también en el S.I central.
> > > >
> > > > Por otra parte, ahora mismo voy a buscar la documentación a la que me
> > > > remites y ya te diré si me ha sido útil.
> > > >
> > > > Una vez más, gracias, pero mira si puedes ayudarme más.
> > > >
> > > > Salu2,
> > > > Juanma Arnau.
> > > >
> > > >
> > > > "Javier Inglés [MS MVP]" wrote:
> > > >
> > > >> La opción de cachear la membresía a grupos universales sólo es funciona
> > > >> en
> > > >> windows 2003.
> > > >>
> > > >> Repasa que lo tengas bien activado; otra posibilidad es que todos los
> > > >> DC's
> > > >> sean Global Catalog directamente en lugar de hacer el caché de los grupos
> > > >> universales.
> > > >>
> > > >> Para lo segundo, no entiendo por qué has creado varios subdominios,
> > > >> cuando
> > > >> teniendo uno te basta de sobra para toda tu infraestructura, sñolo se
> > > >> aconseja hacer subdominios en casos determinados, y ni siquiera Ms lo
> > > >> aconseja salvo las excepciones adecuadas (los documentos de branch office
> > > >> para AD de Ms hablan de cómo montar los dominiosy subdominios, pero con
> > > >> uno
> > > >> sólo te valdría perfectamente). Mira en la web de Ms por el Identity
> > > >> Integration Server.
> > > >> Salu2!!
> > > >> Javier Inglés
> > > >> MS MVP, Windows Server-Directory Services
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> "Juanma Arnau" escribió en el
> > > >> mensaje news:
> > > >> > Buenaaassss!.
> > > >> >
> > > >> > Llevo varios días buscando infructuosamente documentación que me guíe
> > > >> > en
> > > >> > la
> > > >> > resolución de un problema que tengo con el diseño del S.I. que
> > > >> > administro;
> > > >> > por lo que si algún alma cartitativa arrojara algo de luz al respecto
> > > >> > le
> > > >> > estaría eternamente agradecido.
> > > >> >
> > > >> > En su día, y siguiendo las recomendaciones de Microsoft que leí en
> > > >> > algún
> > > >> > documento técnico, implemente un bosque de dominios basado en un
> > > >> > dominio
> > > >> > raíz
> > > >> > (S.I ubicado en las oficinas centrales) y varios subdominios remotos
> > > >> > (SS.II
> > > >> > ubicados en diferentes delegaciones interconectadas en estrella
> > > >> > mediante
> > > >> > VPNs
> > > >> > sobre ADSL), con el objeto de mantener una administración de AD
> > > >> > centralizada.
> > > >> >
> > > >> > Cada S.I. dispone de un DC que ofrece los servicios típicos (AD, DNS,
> > > >> > DHCP,
> > > >> > WINS, servidor de ficheros y de impresoras...) a los usuarios que
> > > >> > trabajan
> > > >> > en
> > > >> > ese sitio, salvo el S.I de las oficinas centrales que dispone de
> > > >> > mayores
> > > >> > recursos (varios DCs redundan los servicios críticos y distribuyen la
> > > >> > carga
> > > >> > de los típicos: servidor de archivos e impresoras, servidor de
> > > >> > terminales,
> > > >> > servidor de Exchange, servidor Web/FTP...) y mantiene las cuentas de
> > > >> > todos
> > > >> > los usuarios de la corporación.
> > > >> >
> > > >> > Todos los DCs son GC, y al menos un DC por sitio mantiene el caché de
> > > >> > los
> > > >> > grupos universales.
> > > >> >
> > > >> > Todo parece ir bien hasta que cae alguna VPN (algo bastante frecuente,
> > > >> > por
> > > >> > desgracia). Entonces, los usuarios del sitio sin conexión no pueden
> > > >> > iniciar
> > > >> > sesión, ni acceder a los recursos de su servidor local (puesto no se
> > > >> > pueden
> > > >> > comprobar sus credenciales), hasta que se restablece la conexión.
> > > >> >
> > > >> > Tenía entendido que los DCs locales mantenían un caché en su GC que
> > > >> > permitiía validar a los usuarios en el dominio raíz aún estando sin
> > > >> > conexión
> > > >> > (similar al inicio de sesión desde un equipo portátil en desconexión),
> > > >> > pero
> > > >> > debo estar equivocado o no he sabido configurar adecuadamente el
> > > >> > sistema.
> > > >> >
> > > >> > ¿A quién se le ocurre cómo podría solucionar esto?
> > > >> > Teniendo en cuenta lo siguiente:
> > > >> > - Ya estoy buscando una solución de conectividad más robusta, pero esta
> > > >> > no
> > > >> > debería ser la única solución.
> > > >> > - Me interesa mantener las cuentas de usuario centralizadas para
> > > >> > simplificar
> > > >> > la administración, mantener un único login y password para cada usuario
> > > >> > y
> > > >> > su
> > > >> > acceso a cualquier recurso del sistema, adecuarme a las dependencias
> > > >> > del
> > > >> > servidor de Exchange y del servidor Web/FTP alojados en el dominio
> > > >> > raíz, y
> > > >> > alguna otra razón que no recuerdo ahora mismo.
> > > >> > - La solución de duplicar las cuentas de usuario en los subdominios
> > > >> > para
> > > >> > los
> > > >> > usuarios del sitio no acaba de convencerme, salvo que hubiera alguna
> > > >> > forma
> > > >> > de
> > > >> > vincularlas con las del raíz de forma que se actualizaran los cambios
> > > >> > entre
> > > >> > ellas (algo que no se cómo, ni creo que se pueda hacer).
> > > >> >
> > > >> > En fin, agradeceré cualquier consejo al respecto.
> > > >> >
> > > >> > Salu2,
> > > >> > Juanma Arnau.
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >