Question

I’ve developed a COM+ server component (dll) that uses the ITaskScheduler and ITask interfaces to create and edit tasks for a specific .exe also created by the company I work for. The component is called from a classic ASP page (VBScript) and is part of an office package we are developing. The whole system uses a web interface. When run under IIS on Windows Server 2003/2008 I get 0x80070005 access denied errors when attempting to call, for instance, ITaskScheduler->Enum. This makes perfect sense, the IUsr_… account shouldn’t have access to the task scheduler. I added fields for the user to enter their credentials on the webpage, and then made calls to LogonUser and then ImpersonateLoggedOnUser in the COM object. However I still get access denied errors. Subsequent calls to IServerSecurity->QueryBlanket show that the COM object is still being run under the IUsr_… account. My logon logic is as follows:

bool SystemUser::LogonUser(const wchar_t* userName, const wchar_t* domain, const wchar_t* password)
{
    if(::LogonUser(userName, domain, password, LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_DEFAULT, &_token))
    {
        return true;
    }
    System::LogSystemError(__W_FILE__, __W_FUNCTION__, __LINE__, L"Unable to logon user: %s domain: %s", userName, domain);
    return false;
}

bool SystemUser::Impersonate()
{
    if(::ImpersonateLoggedOnUser(_token))
    {
        return true;
    }
    System::LogSystemError(__W_FILE__, __W_FUNCTION__, __LINE__, L"Unable to impersonate user");
    return false;
}

SuccessCode::Enum SystemUser::Logon(const wchar_t* userName, const wchar_t* domain, const wchar_t* password)
{
    if(!_token)
    {
        if(!LogonUser(userName, domain, password) || !Impersonate())
        {
            return SuccessCode::ImpersonateError;
        }
        else
        {
            Global::systemLog.Write(LogLevel::Information, L"Successfully logged on as user: '%s' domain: '%s'", userName, domain);
        }
    }
    return SuccessCode::Success;
}

Using LOGON32_LOGON_INTERACTIVE as the logon type makes no difference. Neither does setting up specific roles in the COM+ MMC. Any help or suggestions hugely appreciated.

Answer 1

The solution to this was to move the Logon and Impersonation logic to a separate COM object. An instance of this needs to be created in the ASP and the Logon code called prior to creating an instance of the Task Scheduling object and calling it’s code. This way the impersonation logic is applied to the ASP. ie. the ASP is now seen to run under the impersonated account.