Have you ensured that the account you are running under when you do the impersonation has the appropriate privaleges to do the impersonation?

From the win32::AdminMisc docs (snipped)

LogonAsUser( $Domain, $User, $Password [, $LogonType ] )

<snip>
Any script that uses this function requires the following privileges (
+you can set these in the User Manager):

Privilege
      Description

SeTcbPrivilege
      Act as part of the operating system.

SeChangeNotify
      Bypass traverse checking. This privilege is needed only if the a
+count the script runs under is neither the local system nor a member 
+of the Administrators group.

SeAssignPrimaryToken
      Replace a process level token.
[download]

HTH.

Actually I did. Those are the three rights I mentioned.

As I mentioned I am beginning to think this option will not work with a Server OS.

I would email Dave Roth but somebody told me he is a PM at Microsoft now and does not have time to maintain AdminMisc :(

I guess I will have to experiment and possible find some other way to do this.

Hi Monks,

I am replying to this message months later just so somebody can find it with SuperSearch (or Google) and not waste the time I did this week.

Problem: I built a tool to allow users to selectively synchronize files on two servers, but was unable to access the files. The idea was to just mount one server on the other as a mapped drive, but for some reason it didn't work.

The solution: (it is so simple it is sick..)

• Create the same name account on both computers with the same password.
• In the Computer Management console (right click on My Computer) find the web server settings and click on your perl program.
• Open its properties and in Anonymous Access and Authentication Control, Click Edit, leave Anonymous Access checked, and click Edit next to it.
• Here it says something like IUSR_YOURCOMPUTER which is the user IIS runs as, and a mysterious password you don't know.
• Change this to your newly create account (like COMPUTERNAME\loginname) and password.
• Note: You cannot change it back because somewhere it is cached and even if you delete it or try copying something over it, the new login is remembered for that file's name.
• Then set permissions of various folders as necessary so you can read/write as needed.
• Make sure you have got some good security on that program (I used SSL and a good login/password, plus encryption of a block of data which persists through forms) since that is a powerful user now.
• This could also be done if you have a single user belonging to a domain which includes both computers.

There is some information about setuid in unix and windows here.

Hope this helps you.

Regards,

Matt Rosin (mattr .__AT__. telebody.com)

Here are some keywords and ideas of what I tried and heard about. Keywords: impersonation, Win32::AdminMisc, logonasuser, logon as user, login as another user, createprocessasuser, create process as another user, mapping drives over ftp, filesystem over ftp, emulation of copy, mkdir, and stat, parsing ftp dates with parse_dir in libwwwnet by Gisle Aas, Net::FTP::Common, and other things. Some more keywords might be: How do I access files on another computer, W2K, Win32, Windows NT, remote access, remote login, run cgi as another user, access another computer without a domain controller, setuid, suid, cgi permissions, IUSER Internet Guest Account, wwwuser in IIS, change web server user, wwwrun, nobody, access privileges, cgi login.

Thanks that actually did explain the problem! You can't do this with win2k. It is an adminmisc problem. Man I do wish Dave had time to maintain it.

LOGON32_LOGON_NETWORK_CLEARTEXT Windows 2000/XP: This logon type preserves the name and password in the authentication packages, allowing the server to make connections to other network servers while impersonating the client. This allows a server to accept clear text credentials from a client, call LogonUser, verify that the user can access the system across the network, and still communicate with other servers.

LOGON32_LOGON_NEW_CREDENTIALS Windows 2000/XP: This logon type allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections. This logon type is supported only by the LOGON32_PROVIDER_WINNT50 logon provider.

Shoot. I will have to firgure out another method!

#!/usr/bin/perl

use strict;
use warnings;

package Win32::LSA;
use base qw/Win32::API::Interface/;

__PACKAGE__->generate( "Advapi32.dll", "LogonUserA", "PPPIIP", "I", "l
+ogon_user" );
__PACKAGE__->generate( "Advapi32.dll", "ImpersonateLoggedOnUser", "I",
+ "I", "impersonate_as" );
__PACKAGE__->generate( "Advapi32.dll", "RevertToSelf", "", "I", "rever
+t" );

1;

use Win32 ();

my $token = "\0" x 4;
my $lsa = Win32::LSA->new;
my $rc = $lsa->logon_user( $ENV{USER}, $ENV{DOMAIN}, $ENV{PASS}, 5, 0,
+ $token);
die Win32::FormatMessage( Win32::GetLastError ) unless $rc;

print "Logon success\n";
$rc = $lsa->impersonate_as( unpack 'L', $token );
die Win32::FormatMessage( Win32::GetLastError ) unless $rc;
print "Impersonate success.\n";

# Place your code here

$rc = $lsa->revert;
die Win32::FormatMessage( Win32::GetLastError ) unless $rc;
[download]

Is there any reason you don't report what is printed after the "Failed Logon" line? BTW, you can shorten that entire line to be simply print $^E,$/;.

Sorry about that. I didn't because it is not a helpful message. It simply states: The operation completed successfully

As to the code suggestion. Thanks! Shorter code good! ;)