En qué controlador me valido?

Puedes quitarte las dudas
Dandelions, VCR Clocks, and Last Logon Times: These are a Few of Our Least
Favorite Things:
http://www.microsoft.com/technet/sc...logon.mspx



Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna clase,y no
otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no rights.
You assume all risk for your use.



"Desiderio Ondo." wrote in message
news:

Hola, Guillermo:

Es cierto lo que comentas sobre las funciones que desarrollan
los roles RID e Infraestructure... no obstante, lamento volver
a discrepar en cuanto al tema del "logonserver". Existe una
utilidad en el kit de recursos denominada SETX, que permite
establecer una variable de entorno permanente basada en el
%logonserver% (reconozco que es después de iniciar la sesión,
como sabiamente habías indicado). Su uso sería:

C:> setx MylogonServer %logonserver%

Y en cuanto a la no replicación del LastLogonTime... voy a
suponer que tienes razón, pero me reservo mis dudas.
·
Confío haberte servido de "alluda"
==> Desiderio Ondo | Ing. en Informática.
MCSA | MCSE Windows Server 2K3.
http://pantuflo.escet.urjc.es/~desitech


"Guilermo Delprato [MS-MVP]" wrote:

Cuando la máquina reinicia se autentica en el dominio (la máquina) por lo
tanto ya tiene un canal seguro con un determinado DC. A partir de ese
momento todos los pedidos de autenticación van a ir a ese DC, salvo que
el
usuario pertenezca a otro dominio del bosque.
Cuando el usuario inicia sesión, %logonserver% no existe, hasta que no
está
autenticado.

El inicio de sesión no modifica objetos del AD, por lo tanto eso se puede
hacer con cualquier DC, y no produce ningún tráfico de replicación, ni
necesita ninguno de los FSMO Roles.
O en realidad si queremos ser más precisos, sí modifica el LastLogonTime,
pero no es un atributo que se replique.

Ni el RID Master, ni el Infrastructure Master tienen nada que ver con el
proceso de inicio de sesión.
El RID Master se encarga de asignar rangos de SIDs a los controladores de
dominio del propio dominio para asegurarse que éstos no estén repetidos.
Los
SIDs se asignan en el momento de la creación a un Security Principals
(usuarios, grupos y máquinas) sólo durante la creación, análogo a un
número
de documento
El Infrastructure Master, se encarga de actualizar en los grupos las
referencias a cuentas de otros dominios.Esto es, si tienes en un grupo de
un
dominio, una cuenta de usuario de otro dominio, y luego mueves este
usuario
a otro dominio, entonces hay que actualizar la referencia en el grupo

Es para 2000, pero en 2003 no cambió
Windows 2000 Active Directory FSMO roles:
http://support.microsoft.com/kb/197132/en-us

Además que el DC, sea el principal (por tener todos los FSMO Roles), y
también DNS, y además ser GC, es un caso que aunque típico no es
necesario
el último, por lo que no conviene tomarlo como la regla


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna clase,y
no
otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no
rights.
You assume all risk for your use.



"Desiderio Ondo." wrote in
message
news:
> Hola, Guillermo:
>
> Ante todo, gracias por las correcciones, tío. Tendré que tener
> mucho cuidado con lo que escribo !! ;-)
>
> Muchas de las cosas que comentas son ciertas, lo reconozco (no
> había pensado en lo del archivo HOST, la verdad), pero discrepo
> en varios otros. Es cierto que la variable "logonserver" se vuelve
> a restablecer en cuanto se reinicie la máquina, pero si el script
> .BAT está puesto para que se ejecute por GPO al inicio de sesión
> de la cuenta de máquina...
>
> Asimismo, es cierto que cualquier <DC> puede autenticar <users>
> para hacer loggin, pero como decía en el post anterior (aunque
> reconozco no haberlo explicado acompleto), finalmente todas las
> modificaciones son registradas/notificadas al "operations master"
> que le solicitará al "RID master" (por lo general, la misma máquina)
> que le asigne un ticket de edición del AD (lo siento, no recuerdo cuál
> es el nombre exacto), para que cuando se haga la replicación al resto
> de <DC's> todos sepan de su existencia y su identificación. Por tanto,
> mi expreción de que "las peticiones de logon son una tarea que en
> realidad ejecuta el Operations Master", viene a ser correcta.
>
> En cuanto al tema del DNS... es de suponer que las estaciones cliente
> apunta única y exclusivamente al <DC> local y éste, al ser tambien GC,
> tenga todos los datos actualizados, ya que replica con el <DC>
> principal
> (o debería llamarlo Infraestructure Master?). Dicho de otro modo: doy
> por supuesto que tiene <DC> maestro, adicionales y <DNS> configurados
> de forma correcta
> ·
> Confío haberte servido de "alluda"
> ==>> > Desiderio Ondo | Ing. en Informática.
> MCSA | MCSE Windows Server 2K3.
> http://pantuflo.escet.urjc.es/~desitech
>
>
> "Guilermo Delprato [MS-MVP]" wrote:
>
>> Desiderio (con buena forma eh :-)) pero hay algunas cosas que no son
>> así
>>
>> El cliente pregunta al DNS por los DCs del dominio que corresponda en
>> el
>> Site del cliente
>> El DNS devolverá todos los DCs de ese dominio en ese Site
>> El cliente tratará de contactar a todos, y terminará validándose con
>> el
>> que
>> responda primero
>> Puede ser el primer DNS o no, ya que puede preguntar a un DNS que no
>> sea
>> DC
>>
>> Si lo que se desea es que un DC valide a más cantidad de máquinas
>> usuarios
>> que otros DCs que están en el mismo sitio, el tema pasa por cambiar
>> Prioridad y Peso de los registros SRV de dicho controlador respecto a
>> los
>> otros DCs (mediante el registro)
>> Habría que ver si poniendo la entrada a un DC en el archivos HOSTS del
>> cliente se modifica el comportamiento, pero no creo porque el cliente
>> busca
>> DCs por Site, así que aunque lo tenga cargado en el cache de
>> hostnames,
>> no
>> creo que lo use.
>>
>> Por otro lado, la variable %logonserver% se estable recién luego de la
>> autenticación.
>>
>> Cualquier DC puede autenticar usuarios, tenga o no algún rol en
>> particular,
>> con tal que pueda contactar a un catálogo global
>>
>>
>> Guillermo Delprato
>> MVP - MCT - MCSE
>> Buenos Aires, Argentina
>>
>> Este mensaje se proporciona "como está" sin garantías de ninguna
>> clase,y
>> no
>> otorga ningún derecho. Ud. asume los riesgos
>> This posting is provided "AS IS" with no warranties, and confer no
>> rights.
>> You assume all risk for your use.
>>
>>
>>
>> "Desiderio Ondo." wrote in
>> message
>> news:
>> > Hola, Raúl:
>> >
>> > Por lo general, en una configuración óptima de red, las estaciones
>> > de trabajo clientes se logan en el 1º <server> DNS que tengan
>> > configurado (ya sea por DHCP o por IP fija), ya que por lo general
>> > suele ser el <DC>. Ahora bien, silo que deseas es "obligar" a que
>> > sólo un determinado <DC> sea el que responda a las peticiones
>> > de logon (tarea que en realidad sólo ejecuta el llamado "Maestro
>> > de Operaciones") basta con que, desde la línea del prompt del
>> > sistema, ejecutes el comando SET y establezcas un nuevo valor
>> > para la variable:
>> >
>> > C:> set %logonserver%=<P ó FQDN del servidor>
>> >
>> > Podrás verificar que se ejecuta correctamente el comando si
>> > haces una nueva llamada a la variable:
>> >
>> > C:> set %logonserver%
>> >
>> > NOTA. Si ya lo que deseas es aplicar el mismo comando desde
>> > varios equipos pertenecientes a tu red corporativa, te recomiendo
>> > recurrir al GPO. Edita un nuevo .BAT (recomendado guardarlo en
>> > el directorio "NETLOGON" del <DC>) con el código siguiente:
>> >
>> > @echo off
>> > set %logonserver%=<P ó FQDN del servidor>
>> >
>> > Y posteriormente, aplícalo haciéndole una llamada desde la ruta
>> > "Conf. del equipo => Conf. de Windows => Archivos de comandos
>> > de inicio => Inicio => Agregar..."
>> > ·
>> > Confío haberte servido de "alluda"
>> > ==>> >> > Desiderio Ondo | Ing. en Informática.
>> > MCSA | MCSE Windows Server 2K3.
>> > http://pantuflo.escet.urjc.es/~desitech
>> >
>> >
>> > "Raúl" wrote:
>> >
>> >> Sí, Desiderio, gracias, así es muy fácil.
>> >> Ahora bien, el equipo cuando inicias la sesión supongo que elige al
>> >> azar
>> >> el
>> >> CD en el que logearse o el que menos tráfico tenga en ese momento,
>> >> no
>> >> lo
>> >> sé.
>> >> Hay alguna opción en la que yo le diga a mi validación en que DC lo
>> >> quiero
>> >> validar?
>> >> Gracias de nuevo
>> >>
>> >>
>> >> "Desiderio Ondo."
>> >> escribió
>> >> en
>> >> el
>> >> mensaje news:
>> >> > Hola, Raúl:
>> >> >
>> >> > La forma más sencilla que se me ocurre es que abras una
>> >> > consola del prompt del sistema (ejecutar => cmd) y veas
>> >> > el resultado de la variable %logonserver% de comando SET:
>> >> >
>> >> > C:>set %logonserver%
>> >> > ·
>> >> > Confío haberte servido de "alluda"
>> >> > ==>> >> >> > Desiderio Ondo | Ing. en Informática.
>> >> > MCSA | MCSE Windows Server 2K3.
>> >> > http://pantuflo.escet.urjc.es/~desitech
>> >> >
>> >> >
>> >> > "Raúl" wrote:
>> >> >
>> >> >> Buenas tardes, tengo 5 controladores de dominio Windows 2003
>> >> >> Server
>> >> >> y
>> >> >> unas
>> >> >> 100 estaciones de trabajo con Windows Xp. El tema está en que me
>> >> >> gustaría
>> >> >> saber en que controlador de dominio se valida un usuario en
>> >> >> concreto.
>> >> >> Por
>> >> >> ejemplo, existe el gpresult para saber de que controlador está
>> >> >> un
>> >> >> determinado equipo cogiendo las directivas de grupo, pero hay
>> >> >> alguna
>> >> >> utilidad, o algún comando que nos diga donde se ha validad dicho
>> >> >> usuario?
>> >> >> Gracias
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

Vale Guillermo, gracias por todo. Voy a hacer pruebas.
Un saludo.

"Guilermo Delprato [MS-MVP]"
escribió en el mensaje news:%

Puedes quitarte las dudas
Dandelions, VCR Clocks, and Last Logon Times: These are a Few of Our Least
Favorite Things:
http://www.microsoft.com/technet/sc...logon.mspx



Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna clase,y
no otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no rights.
You assume all risk for your use.



"Desiderio Ondo." wrote in
message news:

Hola, Guillermo:

Es cierto lo que comentas sobre las funciones que desarrollan
los roles RID e Infraestructure... no obstante, lamento volver
a discrepar en cuanto al tema del "logonserver". Existe una
utilidad en el kit de recursos denominada SETX, que permite
establecer una variable de entorno permanente basada en el
%logonserver% (reconozco que es después de iniciar la sesión,
como sabiamente habías indicado). Su uso sería:

C:> setx MylogonServer %logonserver%

Y en cuanto a la no replicación del LastLogonTime... voy a
suponer que tienes razón, pero me reservo mis dudas.
·
Confío haberte servido de "alluda"
==>> Desiderio Ondo | Ing. en Informática.
MCSA | MCSE Windows Server 2K3.
http://pantuflo.escet.urjc.es/~desitech


"Guilermo Delprato [MS-MVP]" wrote:

Cuando la máquina reinicia se autentica en el dominio (la máquina) por
lo
tanto ya tiene un canal seguro con un determinado DC. A partir de ese
momento todos los pedidos de autenticación van a ir a ese DC, salvo que
el
usuario pertenezca a otro dominio del bosque.
Cuando el usuario inicia sesión, %logonserver% no existe, hasta que no
está
autenticado.

El inicio de sesión no modifica objetos del AD, por lo tanto eso se
puede
hacer con cualquier DC, y no produce ningún tráfico de replicación, ni
necesita ninguno de los FSMO Roles.
O en realidad si queremos ser más precisos, sí modifica el
LastLogonTime,
pero no es un atributo que se replique.

Ni el RID Master, ni el Infrastructure Master tienen nada que ver con el
proceso de inicio de sesión.
El RID Master se encarga de asignar rangos de SIDs a los controladores
de
dominio del propio dominio para asegurarse que éstos no estén repetidos.
Los
SIDs se asignan en el momento de la creación a un Security Principals
(usuarios, grupos y máquinas) sólo durante la creación, análogo a un
número
de documento
El Infrastructure Master, se encarga de actualizar en los grupos las
referencias a cuentas de otros dominios.Esto es, si tienes en un grupo
de un
dominio, una cuenta de usuario de otro dominio, y luego mueves este
usuario
a otro dominio, entonces hay que actualizar la referencia en el grupo

Es para 2000, pero en 2003 no cambió
Windows 2000 Active Directory FSMO roles:
http://support.microsoft.com/kb/197132/en-us

Además que el DC, sea el principal (por tener todos los FSMO Roles), y
también DNS, y además ser GC, es un caso que aunque típico no es
necesario
el último, por lo que no conviene tomarlo como la regla


Guillermo Delprato
MVP - MCT - MCSE
Buenos Aires, Argentina

Este mensaje se proporciona "como está" sin garantías de ninguna clase,y
no
otorga ningún derecho. Ud. asume los riesgos
This posting is provided "AS IS" with no warranties, and confer no
rights.
You assume all risk for your use.



"Desiderio Ondo." wrote in
message
news:
> Hola, Guillermo:
>
> Ante todo, gracias por las correcciones, tío. Tendré que tener
> mucho cuidado con lo que escribo !! ;-)
>
> Muchas de las cosas que comentas son ciertas, lo reconozco (no
> había pensado en lo del archivo HOST, la verdad), pero discrepo
> en varios otros. Es cierto que la variable "logonserver" se vuelve
> a restablecer en cuanto se reinicie la máquina, pero si el script
> .BAT está puesto para que se ejecute por GPO al inicio de sesión
> de la cuenta de máquina...
>
> Asimismo, es cierto que cualquier <DC> puede autenticar <users>
> para hacer loggin, pero como decía en el post anterior (aunque
> reconozco no haberlo explicado acompleto), finalmente todas las
> modificaciones son registradas/notificadas al "operations master"
> que le solicitará al "RID master" (por lo general, la misma máquina)
> que le asigne un ticket de edición del AD (lo siento, no recuerdo cuál
> es el nombre exacto), para que cuando se haga la replicación al resto
> de <DC's> todos sepan de su existencia y su identificación. Por tanto,
> mi expreción de que "las peticiones de logon son una tarea que en
> realidad ejecuta el Operations Master", viene a ser correcta.
>
> En cuanto al tema del DNS... es de suponer que las estaciones cliente
> apunta única y exclusivamente al <DC> local y éste, al ser tambien GC,
> tenga todos los datos actualizados, ya que replica con el <DC>
> principal
> (o debería llamarlo Infraestructure Master?). Dicho de otro modo: doy
> por supuesto que tiene <DC> maestro, adicionales y <DNS> configurados
> de forma correcta
> ·
> Confío haberte servido de "alluda"
> ==>>> > Desiderio Ondo | Ing. en Informática.
> MCSA | MCSE Windows Server 2K3.
> http://pantuflo.escet.urjc.es/~desitech
>
>
> "Guilermo Delprato [MS-MVP]" wrote:
>
>> Desiderio (con buena forma eh :-)) pero hay algunas cosas que no son
>> así
>>
>> El cliente pregunta al DNS por los DCs del dominio que corresponda en
>> el
>> Site del cliente
>> El DNS devolverá todos los DCs de ese dominio en ese Site
>> El cliente tratará de contactar a todos, y terminará validándose con
>> el
>> que
>> responda primero
>> Puede ser el primer DNS o no, ya que puede preguntar a un DNS que no
>> sea
>> DC
>>
>> Si lo que se desea es que un DC valide a más cantidad de máquinas
>> usuarios
>> que otros DCs que están en el mismo sitio, el tema pasa por cambiar
>> Prioridad y Peso de los registros SRV de dicho controlador respecto a
>> los
>> otros DCs (mediante el registro)
>> Habría que ver si poniendo la entrada a un DC en el archivos HOSTS
>> del
>> cliente se modifica el comportamiento, pero no creo porque el cliente
>> busca
>> DCs por Site, así que aunque lo tenga cargado en el cache de
>> hostnames,
>> no
>> creo que lo use.
>>
>> Por otro lado, la variable %logonserver% se estable recién luego de
>> la
>> autenticación.
>>
>> Cualquier DC puede autenticar usuarios, tenga o no algún rol en
>> particular,
>> con tal que pueda contactar a un catálogo global
>>
>>
>> Guillermo Delprato
>> MVP - MCT - MCSE
>> Buenos Aires, Argentina
>>
>> Este mensaje se proporciona "como está" sin garantías de ninguna
>> clase,y
>> no
>> otorga ningún derecho. Ud. asume los riesgos
>> This posting is provided "AS IS" with no warranties, and confer no
>> rights.
>> You assume all risk for your use.
>>
>>
>>
>> "Desiderio Ondo." wrote in
>> message
>> news:
>> > Hola, Raúl:
>> >
>> > Por lo general, en una configuración óptima de red, las estaciones
>> > de trabajo clientes se logan en el 1º <server> DNS que tengan
>> > configurado (ya sea por DHCP o por IP fija), ya que por lo general
>> > suele ser el <DC>. Ahora bien, silo que deseas es "obligar" a que
>> > sólo un determinado <DC> sea el que responda a las peticiones
>> > de logon (tarea que en realidad sólo ejecuta el llamado "Maestro
>> > de Operaciones") basta con que, desde la línea del prompt del
>> > sistema, ejecutes el comando SET y establezcas un nuevo valor
>> > para la variable:
>> >
>> > C:> set %logonserver%=<P ó FQDN del servidor>
>> >
>> > Podrás verificar que se ejecuta correctamente el comando si
>> > haces una nueva llamada a la variable:
>> >
>> > C:> set %logonserver%
>> >
>> > NOTA. Si ya lo que deseas es aplicar el mismo comando desde
>> > varios equipos pertenecientes a tu red corporativa, te recomiendo
>> > recurrir al GPO. Edita un nuevo .BAT (recomendado guardarlo en
>> > el directorio "NETLOGON" del <DC>) con el código siguiente:
>> >
>> > @echo off
>> > set %logonserver%=<P ó FQDN del servidor>
>> >
>> > Y posteriormente, aplícalo haciéndole una llamada desde la ruta
>> > "Conf. del equipo => Conf. de Windows => Archivos de comandos
>> > de inicio => Inicio => Agregar..."
>> > ·
>> > Confío haberte servido de "alluda"
>> > ==>>> >> > Desiderio Ondo | Ing. en Informática.
>> > MCSA | MCSE Windows Server 2K3.
>> > http://pantuflo.escet.urjc.es/~desitech
>> >
>> >
>> > "Raúl" wrote:
>> >
>> >> Sí, Desiderio, gracias, así es muy fácil.
>> >> Ahora bien, el equipo cuando inicias la sesión supongo que elige
>> >> al
>> >> azar
>> >> el
>> >> CD en el que logearse o el que menos tráfico tenga en ese momento,
>> >> no
>> >> lo
>> >> sé.
>> >> Hay alguna opción en la que yo le diga a mi validación en que DC
>> >> lo
>> >> quiero
>> >> validar?
>> >> Gracias de nuevo
>> >>
>> >>
>> >> "Desiderio Ondo."
>> >> escribió
>> >> en
>> >> el
>> >> mensaje news:
>> >> > Hola, Raúl:
>> >> >
>> >> > La forma más sencilla que se me ocurre es que abras una
>> >> > consola del prompt del sistema (ejecutar => cmd) y veas
>> >> > el resultado de la variable %logonserver% de comando SET:
>> >> >
>> >> > C:>set %logonserver%
>> >> > ·
>> >> > Confío haberte servido de "alluda"
>> >> > ==>>> >> >> > Desiderio Ondo | Ing. en Informática.
>> >> > MCSA | MCSE Windows Server 2K3.
>> >> > http://pantuflo.escet.urjc.es/~desitech
>> >> >
>> >> >
>> >> > "Raúl" wrote:
>> >> >
>> >> >> Buenas tardes, tengo 5 controladores de dominio Windows 2003
>> >> >> Server
>> >> >> y
>> >> >> unas
>> >> >> 100 estaciones de trabajo con Windows Xp. El tema está en que
>> >> >> me
>> >> >> gustaría
>> >> >> saber en que controlador de dominio se valida un usuario en
>> >> >> concreto.
>> >> >> Por
>> >> >> ejemplo, existe el gpresult para saber de que controlador está
>> >> >> un
>> >> >> determinado equipo cogiendo las directivas de grupo, pero hay
>> >> >> alguna
>> >> >> utilidad, o algún comando que nos diga donde se ha validad
>> >> >> dicho
>> >> >> usuario?
>> >> >> Gracias
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

Existe una variable, del lado del cliente llamada %LOGONSERVER% que te
indica sobre que domain controller se valido el usuario en esa sesión en
particular.

desde línea de comando escribe
set LOGONSERVER
para obtener el dato que necesitas...


Saludos

Rodrigo de los Santos



MCSA Messaging - CCA - CNA
Miembro del MUG Argentina (suscribite! http://www.mug.org.ar)

Url: http://www.dlssolutions.net
Blog: http://www.nerdsupport.com.ar
Blog: http://www.lazyadmin.com.ar


"Raúl" wrote in message
news:ut9$%23A%

Buenas tardes, tengo 5 controladores de dominio Windows 2003 Server y unas
100 estaciones de trabajo con Windows Xp. El tema está en que me gustaría
saber en que controlador de dominio se valida un usuario en concreto. Por
ejemplo, existe el gpresult para saber de que controlador está un
determinado equipo cogiendo las directivas de grupo, pero hay alguna
utilidad, o algún comando que nos diga donde se ha validad dicho usuario?
Gracias