Relaciones de Confianza: SID de organización y Autenticación Selectiva

21/07/2008 - 00:02 por zubero | Informe spam

Buenas noches,

Estoy leyendo información sobre acceso a recursos en dominios unidos por
relaciones de confianza y me encuentro con el siguiente concepto:

"Cuando un usuario se autentica en una confianza con la opción
Autenticación selectiva activada, se agrega otro SID de organización a los
datos de autorización del usuario. La presencia de este SID comprueba el
dominio del recurso para asegurar que el usuario puede autenticarse a ese
servicio particular. Después de autenticar al usuario, si el otro SID de
organización no está presente, el servidor al que se autentica el usuario
agrega este SID de organización. Sólo uno de estos SID especiales puede
estar presente en el contexto de un usuario autenticado."

Y no acabo de entenderlo, en especial las referencias a SID's de
organización. ¿Crea un SID para cada dominio de la relación? ¿El usuario se
presenta con un SID con el que se autentica y, una vez hecho esto, el DC
que lo valida le asigna otro SID? En tal caso, ¿qué SID utilizará cuando
quiera acceder a recursos en su propio dominio?

Agradecería que alguien me pudiera aclarar este concepto.

Gracias de antemano.

Carlos Jiménez
CCNA, CEH
Microsoft Certified Professional

Siga el debate

6 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#6 zubero

01/08/2008 - 00:23 | Informe spam

"Guilermo Delprato [MS-MVP]"
wrote in
news:uzx34C$:

El Access Token, es "la credencial" que presenta el cliente cuando
tiene que ser *autorizado* (que no es lo mismo que autenticado)

En el Access Token se encuentran los SIDs. Estos incluyen los SIDs de:
- La cuenta de usuario
- Grupos de dominio
- Grupos locales
Resumiendo, los SIDs que hayan provisto el controlador de dominio que
autentica.

O sea, que un Access Token contiene varios SIDs

Tengo dudas sobre cuál DC provee el SID "Other Organization", pero
entiendo que es el DC del dominio de cuentas, que luego el DC del
dominio analizará para ver si puede darle acceso al servidor que tiene
el recurso en cuestión.

Utilizando autenticación Kerberos, todo está basado en un sistema de
Tickets. La complejidad se da porque un cliente sólo puede pedirle
Tickets a SU propio DC. Pero sólo un DC del dominio de recursos puede
dar un Ticket para un servidor suyo. Entonces hay varios pasos
intermedios involucrados.

El cliente le pide un Ticket a un DC de su dominio, para acceder a un
servicio en otro dominio. Este DC le provee de un Ticket para acceder
a otro DC de un dominio que esté en el "path" pero más cercano. Con
este Ticket el cliente le pide otro Ticket para acceder al servicio en
cuestión, pero recibirá otro Ticket para acceder a un DC "más
cercano", ... hasta que al final le podrá pedir un Ticket al DC del
servidor en cuestión, y que le permitirá al servidor validar al
usuario.

Muchas gracias por la explicación, Guillermo. Realmente, me ha quedado
claro.
Disculpa por el retraso en mi respuesta.

Saludos,

Carlos Jiménez
CCNA, CEH
Microsoft Certified Professional

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

1 2

Busqueda sugerida