Como llegar billete de inicio de sesión al aire libre sin contraseña de usuario, sino de hacerse pasar por el usuario con el nombre principal de usuario (UPN)
-
08-10-2019 - |
Pregunta
Estoy escribiendo un archivo DLL que tiene la función de inicio de sesión para obtener boleto al aire libre sin necesidad de utilizar la contraseña de usuario, utilizando sólo un nombre principal de usuario (UPN). Voy a llamar al fresco de servicio API REST / wcservice . Yo uso NTLM en Alfresco.
Estoy hacerse pasar por usuarios que utilizan el constructor WindowsIdentity
como se explica aquí http: / /msdn.microsoft.com/en-us/library/ms998351.aspx#paght000023_impersonatingbyusingwindowsidentity . Lo comprobé y el usuario se suplanta correctamente (comprobé propiedad WindowsIdentity.GetCurrent().Name
).
Después de hacerse pasar por un usuario, que intenta hacer HttpWebRequest
y establecer sus credenciales con CredentialsCache.DefaultNetworkCredentials
. Me sale el error:
The remote server returned an error: (401) Unauthorized.
at System.Net.HttpWebRequest.GetResponse()
Cuando uso new NetworkCredential("username", "P@ssw0rd")
a petición de establecimiento credenciales, consigo billete de inicio de sesión al aire libre (HttpStatusCode.OK
, 200).
¿Hay alguna manera de que puedo conseguir entradas de inicio de sesión al aire libre sin contraseña de usuario?
Este es el código que estoy usando:
private string GetTicket(string UPN) {
WindowsIdentity identity = new WindowsIdentity(UPN);
WindowsImpersonationContext context = null;
try {
context = identity.Impersonate();
MakeWebRequest();
}
catch (Exception e) {
return e.Message + Environment.NewLine + e.StackTrace;
}
finally {
if (context != null) {
context.Undo();
}
}
}
private string MakeWebRequest() {
string URI = "http://alfrescoserver/alfresco/wcservice/mg/util/login";
HttpWebRequest request = WebRequest.Create(URI) as HttpWebRequest;
request.CookieContainer = new CookieContainer(1);
//request.Credentials = new NetworkCredential("username", "p@ssw0rd"); // It works with this
request.Credentials = CredentialCache.DefaultNetworkCredentials; // It doesn’t work with this
//request.Credentials = CredentialCache.DefaultCredentials; // It doesn’t work with this either
try {
using (HttpWebResponse response = request.GetResponse() as HttpWebResponse) {
StreamReader sr = new StreamReader(response.GetResponseStream());
return sr.ReadToEnd();
}
}
catch (Exception e) {
return (e.Message + Environment.NewLine + e.StackTrace);
}
}
Aquí están los registros de Alfresco stdout.log (si ayuda de ninguna manera):
17:18:04,550 DEBUG [app.servlet.NTLMAuthenticationFilter] Processing request: /alfresco/wcservice/mg/util/login SID:7453F7BD4FD2E6A61AD40A31A37733A5
17:18:04,550 DEBUG [web.scripts.DeclarativeRegistry] Web Script index lookup for uri /mg/util/login took 0.526239ms
17:18:04,550 DEBUG [app.servlet.NTLMAuthenticationFilter] New NTLM auth request from 10.**.**.** (10.**.**.**:1229)
17:18:04,566 DEBUG [app.servlet.NTLMAuthenticationFilter] Processing request: /alfresco/wcservice/mg/util/login SID:7453F7BD4FD2E6A61AD40A31A37733A5
17:18:04,566 DEBUG [web.scripts.DeclarativeRegistry] Web Script index lookup for uri /mg/util/login took 0.400909ms
17:18:04,566 DEBUG [app.servlet.NTLMAuthenticationFilter] Received type1 [Type1:0xe20882b7,Domain:<NotSet>,Wks:<NotSet>]
17:18:04,566 DEBUG [app.servlet.NTLMAuthenticationFilter] Client domain null
17:18:04,675 DEBUG [app.servlet.NTLMAuthenticationFilter] Sending NTLM type2 to client - [Type2:0x80000283,Target:AlfrescoServerA,Ch:197e2631cc3f9e0a]
Solución
He resuelto el problema!
Creo que tuvimos un de doble salto problema .
Esto es lo que había que hacer para resolver este problema:
- El usuario que corre mi DLL debe ser dominio de Windows Server 2003 usuario
- servicio que utiliza mi DLL debe tener registrada nombre principal de servicio en cuestión controlador de dominio con el usuario que lo ejecuta (usuario que se ejecuta mi DLL)
- usuario que ejecuta mi DLL no debe tener La cuenta es importante y no puede ser delegado opción seleccionada en el Dominio controlador
- usuario que ejecuta mi DLL debe tener Confiar en este usuario para la delegación a cualquier servicio (sólo Kerberos) o Confianza este usuario para la delegación a servicios especificados seleccionado en el controlador de dominio (si el usuario se encuentra en Windows Server 2003 dominio funcional de esta opción es disponible sólo cuando se registra Nombre principal de servicio con este usuario)
- El usuario que corre mi DLL debe tener juego TrustedToAuthForDelegation Control de cuentas de usuario (UAC) para true
- equipo que ejecuta el servicio que los usos mi DLL debe tener Confianza ordenador para delegación a cualquier servicio (Kerberos solamente) o Confianza ordenador para delegación a los servicios especificados Sólo seleccionado en el dominio Controller
Todo esto (y más) se explica en el documento de Microsoft Solución de problemas de Kerberos Delegación . Contiene:
- lista de comprobación para Active Directory,
- lista de control para la aplicación de cliente,
- lista de comprobación para el Nivel Medio,
- lista de comprobación para el back-end
plus
- ejemplos de configuración para común escenarios.
Configuración TrustedToAuthForDelegation Control de cuentas de usuario (UAC) que se hace en PowerShell cmdlet Active Directory explicó aquí .
Puede leer más sobre autenticación de Windows en ASP.NET 2.0 .
Por supuesto, al aire libre debe tener habilitado Kerberos inicio de sesión.
Otros consejos
creo que no es posible que al aire libre. Sólo si se utiliza el subsistema de autenticación especial donde existe este usuario 'impersonal'.
Trate de esto, porque 'invitado' usuario es transversal para toda la autenticación del subsistema.
request.Credentials = new NetworkCredential ( "huésped", "huésped");
Y el URI, algo como esto:
cadena URI = "http:. // alfrescoserver / al aire libre / s / API / login o lo que sea que usted propone
Buena suerte. Paco