On 1/22/2013 12:33 AM, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of PA3MEP
Sent: Sunday, 20 January, 2013 11:13
I`am creating a Custom Credentials Provider for Windows 7/8,
which uses
axis2c library with openSSL support to communicate with SOAP
service, which
provides authentification information.
I created a sample program (prototype EXE) which performs
authentification
successully, without any issues.
But when I moved this code to Windows Credentials provider I get
OPENSSL_Uplink<10111000,08> no OpenSSL_Applink error.
Things I allready tried:
1. included openssl\applink.c like so
extern "C"
{
#include "openssl\applink.c"
}
In code that is linked into the .exe?
I don't know about Windows Custom Credential Providers, but
a quick google suggests they are DLLs loaded by Winlogon.
OpenSSL_Applink must be in the .exe not in a .dll, and
if the .exe is Winlogon you probably can't modify it.
<snip rest>
Possibly you can write your code to run in a separate process,
such as a Windows Service or other autorun, and have the credential
plugin(?) talk to that process. I didn't understand the Windows
security model even before the last three rounds of "enhancement"
and complexification, so I can't say how well this would work.
The standard way to do this for log on mechanisms is to write it as
a plugin for the LSASS process (the only process with legitimate
access to the password database and the only process with any
ability to generate a "Possession of this handle represents
a process being authenticated as user X" "token handles").
The only "autorun" processes that are available during normal
winlogon processing are those started as or by services (the other
"autorun" mechanisms are like the *N*X /etc/profile etc. and run
per user *after* login.
Alternatively, perhaps you can persuade axis2 not to make any
OpenSSL calls that need Applink. If -- and I'm guessing here --
it only makes SSL client connections to someplace you specify,
and it doesn't use engine(s) in OpenSSL, there should be no need
for an OpenSSL config file, and probably no need for any files
other than a local truststore (file and/or directory) which
normally are accessed without passing a FILE* and needing Applink.
But "not needed" doesn't mean someone didn't think it would
be a kewl feature and toss it in anyway.
If it's difficult debugging a core Windows security process --
and I'd guess (even hope) it might be -- probably you can create
a test .exe which calls your code in the same way as Winlogon
does (but discards the result), and debug using that.
There is an official way to do this, it requires two computes,
a cable (serial null modem, standard firewire or USB debug) and
a bunch of administrator only options described in the "Debugging
tools for Windows" help file. This setup also makes the target
computer barely usable without constant assistance from the
person at the debugger computer. I guess the OP already knows
this as well as I do.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
