valor una tipos tendrá tecnicas reglas que por partes negociador negociación negociacion marco las formales forma fija estrategica estrategias esta elementos ejemplos distribución definicion considerando compiten cantidad actuar security winapi kerberos ntlm

security - una - tecnicas de negociacion definicion



¿Qué TargetName usar cuando se llama a InitializeSecurityContext(Negociar)? (4)

La pregunta

Al llamar a InitializeSecurityContext , ¿qué valor pasa al parámetro TargetName ?

Fondo revisado

Estoy llamando a la función InitializeSecurityContext :

InitializeSecurityContextA( @pAS.hcred, //[in] credentials phContext, //[in] optional] Context handle structure pszTargetName, //[in, optional] Target name 0, //[in] context requirements 0, //[in] reserved1, must be zero SECURITY_NATIVE_DREP, //[in] target data representation pInput, //[in] optional] SecBufferDescription 0, //[in] reserved2, must be zero @pAS.hctxt, //[in, out] pointer to context handle structure @OutBuffDesc, //[in, out] pointer to SecBufferDesc ContextAttributes, //[out] context attributes @lifetime); //[out] expiration timestamp

¿Qué paso a pszTargetName ?

He intentado

  • null : InitializeSecurityContextA(@pAS.hcred, phContext, null, ...);
  • "" : InitializeSecurityContextA(@pAS.hcred, phContext, "", ...);
  • "spn/HOSTNAME" : InitializeSecurityContextA(@pAS.hcred, phContext, "spn/HOSTNAME", ...);
  • spn/HOSTNAME.DOMAIN.COM : InitializeSecurityContextA(@pAS.hcred, phContext, "spn/HOSTNAME.DOMAIN.COM", ...);
  • "cargocult/PROGRAMMING" : InitializeSecurityContextA(@pAS.hcred, phContext, "cargocult/PROGRAMMING", ...);
  • "http/TFS.DOMAIN.COM" : InitializeSecurityContextA(@pAS.hcred, phContext, "http/TFS.DOMAIN.COM", ...);
  • "http/HOSTNAME" : InitializeSecurityContextA(@pAS.hcred, phContext, "http/HOSTNAME", ...);

  • "qwertyasdf" : InitializeSecurityContextA(@pAS.hcred, phContext, "qwertyasdf", ...);

  • "AuthSamp" : InitializeSecurityContextA(@pAS.hcred, phContext, "AuthSamp", ...);

Todos ellos fallan, o bajan a NTLM.

Nota : Mi máquina está unida al dominio, pero el dominio no se llama domain.com , o incluso hostname.domain.com , o incluso qwertyasdf . Así que no me sorprende que esos intentos fracasen. Pero la gente dijo que intentara cosas como http/HOSTNAME , así que puse http/HOSTNAME .

Fondo

La función InitializeSecurityContext tiene un parámetro TargetName opcional :

pszTargetName [en, opcional]

Un puntero a una cadena terminada en nulo que indica el nombre principal del servicio (SPN) o el contexto de seguridad del servidor de destino.
Las aplicaciones deben proporcionar un SPN válido para ayudar a mitigar los ataques de reproducción.

¿Qué se supone que es esto?

Más fondo

estoy tratando de validar un conjunto de credenciales de usuario, por ejemplo:

Boolean ValidateCredentials(String username, String password, String domain) { ... }

La validación de un conjunto de credenciales de usuario requiere el uso de la API SSPI. La primera función a llamar es InitializeSecurityContext . Uno de los parámetros para InitializeSecurityContext es una cadena "TargetName" .

He intentado dejarlo en nulo , pero el Comprobador de aplicaciones activa un punto de interrupción y escribe el error:

PARADA DEL VERIFICADOR 00005003: pid 0xF08:
InitializeSecurityContext utiliza un destino NULL o un destino con formato incorrecto para el servicio Kerberos.
Por favor vea pszTargetName para el valor del objetivo.
00000000: No utilizado.
00000000: No

En este punto, sería útil recordar que el proveedor de Negotiate intentará utilizar Kerberos , pero recurrirá a NTLM . En el caso de Negotiate , Kerberos o NTLM , se documenta que el parámetro TargetName es :

Nombre principal del servicio (SPN) o el contexto de seguridad del servidor de destino.

Pero entonces, ¿qué debo pasar?

Intenté hacer lo que hace el artículo de la base de conocimientos de SSPI, nada (es decir, pasar NULL ):

Cómo validar las credenciales de los usuarios en los sistemas operativos de Microsoft

ss = _InitializeSecurityContext( &pAS->hcred, pAS->fInitialized ? &pAS->hctxt : NULL, NULL, //<-------pszTargetName 0, 0, SECURITY_NATIVE_DREP, pAS->fInitialized ? &sbdIn : NULL, 0, &pAS->hctxt, &sbdOut, &fContextAttr, &tsExpiry);

Pero nada (es decir, NULL ) no funciona.

Nota: El artículo de KB se reescribió masivamente en 2007. En su encarnación original de 1999 pasaron "AuthSamp" como objetivo, pero eso también falla.

Chat de bonificación:

nombre principal del servicio
(SPN) El nombre con el que un cliente identifica de forma única una instancia de un servicio. Si instala varias instancias de un servicio en equipos en todo un bosque, cada instancia debe tener su propio SPN. Una instancia de servicio dada puede tener múltiples SPN si hay varios nombres que los clientes podrían usar para la autenticación

contexto de seguridad
Los atributos o reglas de seguridad que están actualmente vigentes. Por ejemplo, el usuario actual inició sesión en la computadora o el número de identificación personal ingresado por el usuario de la tarjeta inteligente. Para SSPI, un contexto de seguridad es una estructura de datos opaca que contiene datos de seguridad relevantes para una conexión, como una clave de sesión o una indicación de la duración de la sesión.

Bonus Chatter 2

De la documentación del verificador de la aplicación:

El enchufe del verificador detecta los siguientes errores:

  • El paquete NTLM se especifica directamente en la llamada a AcquireCredentialsHandle (o API de envoltorio de nivel superior).

  • El nombre de destino en la llamada a InitializeSecurityContext es NULL.

  • El nombre de destino en la llamada a InitializeSecurityContext no es un nombre de dominio de estilo SPN, UPN o NetBIOS con la forma correcta.

  • Los dos últimos casos obligarán a Negociar a retroceder a NTLM directamente (el primer caso) o indirectamente (el controlador de dominio devolverá un error de "principal no encontrado" en el segundo caso, lo que causará que el Negociado retroceda).

  • El complemento también registra advertencias cuando detecta degradaciones a NTLM; por ejemplo, cuando el controlador de dominio no encuentra un SPN. Estos solo se registran como advertencias ya que a menudo son casos legítimos, por ejemplo, cuando se autentica en un sistema que no está unido a un dominio.

En mi caso, el dominio contra el que estoy validando es null (ya que no conozco el nombre de dominio de la máquina, o incluso si hay un dominio). Pero los resultados son los mismos si el nombre de dominio del código de mi máquina de desarrollo.

Actualización 3

Los valores de pszTargetName que desencadenan el error de AppVerifier, pero el inicio de sesión se realiza correctamente :

  • null
  • ""
  • "AuthSamp"
  • "qwertyasdf"
  • * el nombre del dominio contra el que estoy validando (por ejemplo, "avatopia.com" )
  • * el nombre del dominio al que está unida la máquina (por ejemplo, "avatopia.com" )
  • * el nombre del dominio en el que se encuentra la cuenta de usuario (por ejemplo, "avatopia.com" )

Los valores de pszTargetName que no activan un error de AppVerifier, pero el inicio de sesión falla :

  • "http/HOSTNAME"
  • "http/TFS.DOMAIN.COM"
  • "frob/GROBBER"
  • "cargocult/PROGRAMMING"
  • "spn/HOSTNAME"
  • "spn/HOSTNAME.DOMAIN.COM"

Los valores de pszTargetname que no activan un error de AppVerifier y el inicio de sesión se realizan correctamente:

  • ninguna

Actualización 4

Lo que estoy tratando de hacer: averiguar si un nombre de usuario / contraseña es válido.

  • Tengo un nombre de usuario: por ejemplo, "ian"
  • Tengo una contraseña: por ejemplo, "pass1"

Ahora existe la posibilidad de que la cuenta ian pueda ser una cuenta local o una cuenta de dominio . Y debe decidir si ian es una cuenta local o de dominio antes de que pueda preguntar. Esto es porque ian puede tener dos cuentas:

  • ian en el dominio stackoverflow.com
  • ian en máquina local

Así que necesito especificar si quiero:

  • pedir un dominio particular (por ejemplo, stackoverflow.com ), o
  • pregunte a la máquina local (que representaré como "." )

Ahora podemos llegar a una referencia cruzada:

Username Password Domain Machine on domain? Validate as ======== ======== ================= ================== ============== iboyd pass1 . No Local account iboyd pass1 (empty) No Local account iboyd pass1 stackoverflow.com No Domain account iboyd pass1 . Yes Local account iboyd pass1 (empty) Yes Domain account iboyd pass1 stackoverflow.com Yes Domain account

Actualización 5

Podría ayudar a explicar lo que estoy tratando de hacer, entonces tal vez cómo hacerlo será más fácil. Digamos que entro en un edificio de oficinas al azar, entro en un cubículo aleatorio y escribo un nombre de usuario y contraseña aleatorios:

Voy a intentar iniciar sesión en el dominio TURBOENCABULATOR . Especifiqué que quiero intentar autenticar contra el dominio TURBOENCABULATOR prefijando mi nombre de usuario como:

TURBOENCABULATOR/ian

Nota: dudo mucho que la red tenga un dominio llamado turboencabulator , ya que el nombre solo proviene de la automatización de Rockwell . El intento de inicio de sesión casi seguramente fracasará. Pero, ¿cómo los comprueba Windows?

¿Cómo intenta Windows validar estas credenciales? ¿Cómo valida Windows las credenciales?

  • Nombre de usuario : ian
  • Contraseña : pass1
  • Dominio : TURBOENCABULATOR

¿ Windows utiliza la Interfaz del paquete de soporte de seguridad ? Suponiendo que Windows utiliza Negociar o Kerberos para la autenticación, ¿qué pasa Windows como el parámetro pszTarget ? Es casi seguro que las credenciales que ingrese no serán válidas. ¿Cómo determinará Windows si son válidos? ¿A qué API llamará Windows para validar los credentails?

Windows es capaz de validar credentails. También quiero validar las credenciales.

Tal vez en lugar de intentar conectar con el dominio TURBOENCABULATOR , intento conectarme con el dominio turboencabulator.com añadiendo el dominio a mi nombre de usuario como turboencabulator.com/ian :

La misma pregunta se aplica. ¿Cómo valida Windows las credenciales? Quiero hacer lo que Windows hace. Suponiendo que Windows usa kerberos para la autorización, ¿qué pasa Windows como el parámetro pszTargetName en SSPI?

Quizás en lugar de intentar conectar con el dominio turboencabulator.com , trato de conectarme con el dominio turboencabulator.net :

Tenga en cuenta que en este ejemplo he agregado el nombre de dominio a mi nombre de usuario, en lugar de hacerlo.

Tal vez en lugar de intentar conectarse al dominio turboencabulator.net , intente validar al usuario como una cuenta local (máquina) prefijando mi nombre de usuario con ./ turboencabulator.net :

¿Cómo valida Windows el nombre de usuario y la contraseña en la base de datos de la cuenta local? ¿Utiliza SSPI con el paquete Negociar ? Si es así, ¿qué valor pasa como pszTargetName ?

La gente está hablando de servidores web, http, servidor de fundación de equipo. Realmente no sé de dónde sacan eso. O hablan de editar un usuario en el directorio activo para asegurarse de que haya algo presente. No veo por qué necesito editar nada: Windows no edita nada.

¿Qué TargetName utilizo al llamar a InitializeSecurityContext para validar un conjunto de credenciales?

Bonus Chatter

Aquí hay un capítulo de la documentación de Application Verifier sobre por qué tienen una prueba si alguien está usando por error NTLM:

¿Por qué se necesita el complemento NTLM?

NTLM es un protocolo de autenticación obsoleto con fallas que pueden comprometer la seguridad de las aplicaciones y el sistema operativo. El defecto más importante es la falta de autenticación del servidor, lo que podría permitir a un atacante engañar a los usuarios para que se conecten a un servidor falsificado. Como corolario de la falta de autenticación del servidor, las aplicaciones que usan NTLM también pueden ser vulnerables a un tipo de ataque conocido como un ataque de "reflexión". Este último permite a un atacante secuestrar la conversación de autenticación de un usuario en un servidor legítimo y usarla para autenticar al atacante en la computadora del usuario. Las vulnerabilidades de NTLM y las formas de explotarlas son el objetivo de aumentar la actividad de investigación en la comunidad de seguridad.

Aunque Kerberos ha estado disponible por muchos años, muchas aplicaciones aún están escritas para usar NTLM solamente. Esto reduce innecesariamente la seguridad de las aplicaciones. Sin embargo, Kerberos no puede reemplazar NTLM en todos los escenarios, principalmente aquellos donde un cliente necesita autenticarse en sistemas que no están unidos a un dominio (una red doméstica tal vez sea la más común). El paquete de seguridad Negociar permite un compromiso compatible con versiones anteriores que utiliza Kerberos siempre que sea posible y solo vuelve a NTLM cuando no hay otra opción. Cambiar el código para usar Negociar en lugar de NTLM aumentará significativamente la seguridad para nuestros clientes al tiempo que presenta pocas o ninguna compatibilidad de aplicaciones. Negociar por sí solo no es una bala de plata: hay casos en los que un atacante puede forzar la rebaja a NTLM, pero estos son significativamente más difíciles de explotar. Sin embargo, una mejora inmediata es que las aplicaciones escritas para usar Negociar correctamente son automáticamente inmunes a los ataques de reflexión NTLM.

A modo de advertencia final contra el uso de NTLM: en futuras versiones de Windows será posible desactivar el uso de NTLM en el sistema operativo. Si las aplicaciones tienen una fuerte dependencia de NTLM, simplemente no se autenticarán cuando NTLM esté deshabilitado.

Cómo funciona el plugin

El enchufe del verificador detecta los siguientes errores:

  • El paquete NTLM se especifica directamente en la llamada a AcquireCredentialsHandle (o API de envoltorio de nivel superior).

  • El nombre de destino en la llamada a InitializeSecurityContext es NULL.

  • El nombre de destino en la llamada a InitializeSecurityContext no es un nombre de dominio de estilo SPN, UPN o NetBIOS con la forma correcta.

Los dos últimos casos obligarán a Negociar a retroceder a NTLM directamente (el primer caso) o indirectamente (el controlador de dominio devolverá un error de "principal no encontrado" en el segundo caso, lo que causará que el Negociado retroceda).

El complemento también registra advertencias cuando detecta degradaciones a NTLM; por ejemplo, cuando el controlador de dominio no encuentra un SPN. Estos solo se registran como advertencias ya que a menudo son casos legítimos, por ejemplo, cuando se autentica en un sistema que no está unido a un dominio.

NTLM se detiene

5000 - La aplicación ha seleccionado explícitamente el paquete NTLM

Severidad - Error

La aplicación o subsistema selecciona explícitamente NTLM en lugar de Negociar en la llamada a AcquireCredentialsHandle. Aunque es posible que el cliente y el servidor se autentiquen utilizando Kerberos, esto se evita mediante la selección explícita de NTLM.

Cómo arreglar este error

La solución para este error es seleccionar el paquete Negociar en lugar de NTLM. La forma en que se haga esto dependerá del subsistema de red en particular que esté utilizando el cliente o el servidor. Algunos ejemplos se dan a continuación. Debería consultar la documentación sobre la biblioteca particular o el conjunto de API que está utilizando.

APIs(parameter) Used by Application Incorrect Value Correct Value ===================================== =============== ======================== AcquireCredentialsHandle (pszPackage) “NTLM” NEGOSSP_NAME “Negotiate”

Ver también

Respuesta corta

TargetName es el nombre de usuario con el que se ejecutará el código del "servidor" .

Fondo

El paquete de autenticación de Negotiate intentará utilizar Kerberos . Si no puede, intentará retroceder a NTLM .

  • Quieres usar Kerberos .
  • No quieres usar NTLM; Es viejo, está en desuso, es débil, está roto y no debe usarse.
  • Para utilizar Kerberos debes proporcionar un TargetName
  • Sin un TargetName , Kerberos es fundamentalmente incapaz de la función

La pregunta es: dado que todas las partes involucradas en mí ( Ian ) se autentican con Steve , ¿qué TargetName debo especificar?

Aquí es donde es importante saber qué significa TargetName para Kerberos:

  • Quiero demostrar mi identidad a [email protected]
  • El controlador de dominio me entrega un blob encriptado que prueba mi identidad.
  • el blob está encriptado, de modo que solo [email protected] puede descifrarlo
  • el controlador de dominio sabía que debía cifrarlo para [email protected] porque lo especifiqué en TargetName
  • Steve es el objetivo

Así es como Steve sabe que el blob es válido, se cifró para que solo él pueda descifrarlo.

Tengo que decirle a Kerberos a quién le daré el blob cifrado, para que el controlador de dominio sepa para quién cifrarlo.

Así que en la lista anterior de nombres posibles, funcionan tres valores:

InitializeSecurityContext(credHandle, context, "[email protected]", ...); InitializeSecurityContext(credHandle, context, ".local/steve", ...); InitializeSecurityContext(credHandle, context, "steve", ...); //if we''re in the same forest

Confusión extra debido a la flexibilidad (bienvenido a SPN)

SPNs versión corta

  • cuando utilice Kerberos, debe especificar un nombre de usuario como su TargetName
  • un SPN es un "alias" para un nombre de usuario
  • por lo tanto, puede especificar un SPN como su TargetName

Versión larga SPNs

En el caso anterior, tuve que saber que el código del "servidor" se ejecutará como [email protected] .

Eso es un dolor. Quiero decir que está bien cuando sé que es Steve. Pero si estoy hablando con una máquina remota, ¿debo averiguar la cuenta de usuario con la que se ejecuta el código?

  • Tengo que averiguar que IIS se ejecuta como [email protected] ?
  • Tengo que averiguar que SQL Server se ejecuta como [email protected] ?
  • y qué pasa si el servicio se está ejecutando en el servicio local ; que no es un usuario de dominio en absoluto

Afortunadamente (?), Kerberos creó alias (llamados nombres de principios de servicio o SPN):

  • si necesito autenticarme en el servidor web http://bugtracker..local
  • y el servicio IIS se ejecuta bajo la cuenta de dominio [email protected]
  • en lugar de tener que especificar el nombre de [email protected] de [email protected]
  • Puedo especificar HTTP/bugtracker..local
  • eso es porque IIS registró un alias con el controlador de dominio
  • HTTP/bugtracker..local -> [email protected]

Todo esto requiere que conozca el SPN si desea usarlo como TargetName . Varios productos estándar de Microsoft registran SPN cuando se instalan:

  • IIS : HTTP/[servername]
  • SQL Server : MSSQLSvc/[servername]:1433
  • SMTP : SMTPSVC/[servername]
  • Intercambio de archivos : HOST/[servername]

Todos estos son indocumentados, y hacen de tu vida un infierno cuando uno no está configurado correctamente.

Depende un poco del SPN contra el que intenta autentificarse. Realizamos la autenticación NTLM / SPNEGO para servidores HTTP (solo), y the guidance suggests que el servidor HTTP / HTTPS debería registrar un SPN como http/HOSTNAME . Entonces, cuando nos autenticamos, simplemente añadimos http/ al nombre de host en mayúsculas. Por ejemplo, pasamos:

http/TFS.DOMAIN.COM

como destino de InitializeSecurityContext , donde TFS.DOMAIN.COM es el nombre de host en mayúsculas que el usuario escribió para acceder a su servidor TFS.

No intentamos hacer ninguna búsqueda de DNS o coincidencia de FQDN. Si el usuario simplemente escribe http://foo/ entonces nuestro SPN es http/FOO . Esto significa que el administrador del servidor debe haber configurado http/FOO como un SPN.

No es imposible que un administrador del servidor configure una máquina, FOO y configure el SPN http/FOO , luego expone esta máquina en Internet como extranet.domain.com . En ese caso, también deben configurar http/EXTRANET.DOMAIN.COM como un SPN. Esto puede complicarse con los balanceadores de carga, etc., pero esto debería ser responsabilidad del administrador del servidor.

Ian, creo que todavía no entendemos lo que estás tratando de hacer exactamente. Para ayudarlo a brindarnos más información sobre lo que está tratando de hacer, aquí hay un poco de información sobre el SSPI. Es posible que ya lo sepa, pero solo para asegurarse de que estamos en la misma página.

SSPI se usa generalmente para autenticar a un usuario a través de la red. El cliente llama a AcquireCredentialsHandle para obtener un identificador de credenciales y luego crea un contexto de seguridad llamando a InitializeSecurityContext . Pase el búfer de seguridad al servidor. Tenga en cuenta que SSPI no dicta cómo pasar el búfer de seguridad. Puedes usar http, tcp, canalización con el nombre que desees. Una vez que el servidor recibe el búfer de seguridad. Del mismo modo, llama primero a AcquireCredentialsHandle . Luego pasa el búfer de seguridad recibido a AcceptSecurityContext y genera un nuevo búfer de seguridad. En algunos casos, el búfer de seguridad recién generado debe enviarse de vuelta al cliente y el cliente lo pasa a InitializeSecurityContext y genera otro nuevo contexto de seguridad nuevamente. Este proceso de AcceptSecurityContext SSPI continúa hasta que InitializeSecurityContext y AcceptSecurityContext devuelven SEC_E_OK

Si bien el SSPI se diseñó para la autenticación a través de la red, muchas aplicaciones en realidad están realizando el protocolo de enlace del SSPI, lo que significa que tanto el cliente como el servidor están en la misma caja. Esto es realmente un caso especial de autenticación de red. El resultado final de un handshaking SSPI de bucle invertido es un contexto de seguridad SSPI autenticado. Con este SSPI autenticado, la aplicación puede realizar QueryContextAttributes e ImpersonateSecurityContext . Ya que parece que no tienes idea de lo que significa targetName , supongo que estás tratando de hacer un apretón de manos de retroceso. Aunque podría estar equivocado, pero necesitas decirnos qué estás tratando de hacer.

Para comprender por targetName se necesita targetName en Kerberos pero no en NTLM, debe comprender una implementación más subyacente.

Hay dos formas diferentes de adquirir un identificador de credenciales. Normalmente, las personas especifican usar el contexto de seguridad actual. (es decir, la cuenta que utilizó para iniciar sesión en su máquina). También puede proporcionar otro conjunto de nombre de usuario / contraseña. Paquete de seguridad diferente tiene diferentes significados en las credentials término. NTLM significa que va a guardar un hash de su contraseña. Kerberos significa que se va a guardar un Ticket Granting Ticket (TGT). Para el programador de SSPI, no necesita preocuparse por esto.

Ahora, cuando el cliente pasa el identificador de credenciales adquiridas a InitializeSecurityContext , de manera similar, un paquete de seguridad diferente hará cosas diferentes. NTLM generará un paquete NEGOCIADO en la primera llamada a InitializeSecurityContext . Ninguna otra máquina está involucrada en el proceso de generar el paquete de NEGOCIACIÓN. El paquete de Kerberos es muy diferente. Hablará con KDC para solicitar un ticket de servicio para el servicio solicitado. El servicio se identifica con el nombre principal del servicio (SPN) en Kerberos. No puedo cubrir todos los detalles aquí. La red neta es que la solicitud de servicio para NTLM no está dirigida mientras que la solicitud de servicio para Kerberos está dirigida. Puede usar el mismo paquete NTLM NEGOCIAR para diferentes servicios usando el método de autenticación NTLM. Sin embargo, debe utilizar diferentes tickets de servicio de Kerberos para diferentes servicios utilizando el método de autenticación de Kerberos. Es por eso que al llamar a InitializeSecurityContext para Kerberos / Negociar, debe proporcionar el targetName .

Cuando KDC recibe la solicitud de un ticket de servicio, realiza una búsqueda en su base de datos LDAP y descubre qué cuenta está asociada con el servicePrincipalName especificado. La cuenta puede ser cuenta de usuario AD o cuenta de computadora AD. El KDC utilizará la clave maestra de la cuenta de servicio de destino (generada por la contraseña de la cuenta) para cifrar una clave de sesión. Esta clave de sesión cifrada se pasará del cliente al servidor más adelante.

Ahora, recuerde que dije que el servidor también tiene que hacer AcquireCredentialsHandle y dije que hay dos enfoques principales para manejar las credenciales. Supongo que está utilizando el primer enfoque para adquirir los identificadores de credenciales. Eso significa que va a utilizar el contexto de seguridad actual. En un caso de autenticación de red normal, esto se puede ilustrar con el siguiente ejemplo. Si su servidor es un servidor HTTP, será la cuenta de servicio de su servidor IIS. El servidor IIS utilizará la clave maestra de su cuenta de servicio para descifrar la clave de sesión cifrada. Una vez que se obtiene la clave de sesión, el cliente y el servidor continúan la comunicación utilizando la clave de sesión para realizar el cifrado y descifrado.

Si se trata de un escenario SSPI de bucle invertido, es más complicado. Si está ejecutando domain/jane y haciendo un bucle en usted mismo. Debe especificar un SPN para domain / jane. ¿Cuál es el SPN para domain / jane. Si verifica el objeto de usuario AD, no hay ninguno por defecto. Necesitas arreglarlo manualmente.

Hay una cosa que solía funcionar para mí, pero no está documentada. Puede especificar el UPN del usuario (es decir, [email protected]) como el SPN. Esto funciona para mi Puedes probarlo.

Si eso no funciona, otra forma de solucionarlo es utilizar el segundo método para realizar la parte del servidor AcquireCredentialsHandle . En lugar de utilizar el identificador de credenciales de domain/jane , especifique otras credenciales de cuenta de servicio . Puede asegurarse de que la cuenta de servicio tenga un SPN correcto. Luego, puede usar el SPN de esa cuenta de servicio en su InitializeSecurityContext . Por supuesto, eso también significa que debe codificar la contraseña de su cuenta de servicio en el código. Debe tener cuidado y asegurarse de bloquear completamente esta cuenta de servicio para que, aunque la contraseña sea robada, su entorno de AD no sea un gran riesgo.

Llego un par de años tarde a esta fiesta ... Ayer, me encontré con tu pregunta mientras investigaba mi propio problema de SSPI. Esta mañana, mientras continuaba mi investigación, encontré un artículo que parece ofrecer una solución a su pregunta:

El artículo de Keith Brown en la revista MSDN de abril de 2001 titulado "Informes de seguridad: La interfaz del proveedor de asistencia de seguridad revisada" contiene un código de ejemplo que revela que el nombre de destino (para la validación de la contraseña) debe ser una cadena con el formato "Máquina / Usuario" o "Dominio / Usuario".

El artículo se encuentra aquí: http://msdn.microsoft.com/en-us/magazine/cc301890.aspx

Las "Figuras" a las que se hace referencia en el artículo (incluido el código de ejemplo) se encuentran aquí: http://msdn.microsoft.com/en-us/magazine/bb985825.aspx

Me doy cuenta de que es probable que haya encontrado una solución a este problema hace mucho tiempo. Además, no puedo certificar que el código del autor funcione correctamente en las plataformas modernas de Windows (sospecho que lo haría, pero no he validado el comportamiento). Espero que el artículo de MSDN también sea un recurso útil para otros.