Perl account on windows & Win32::OLE 1

[1DMF]

I'm currently using Win32::OLE to do some account manipulation , I can query the Local Account info and display the accounts with the WinNT:// method (LDAP is no good as this is not a domain server).

However, When trying to add accounts, or place users into groups I am getting the following error...

OLE exception from "Active Directory": General access denied error
Win32::OLE(0.1707) error 0x80070005: "Access is denied"
in METHOD/PROPERTYGET "Add"

I've tried adding IUSR to the administrators group and this hasn't fixed the problem.

So what rights does perl run under and how do I set permissions for perl to execute this type of command.

Also how do i set permissions that are safe and do not leave the server vunerable, (I have now removed IUSR from administrators!)

many thanks

1DMF.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[PaulTEG]

a perl daemon running under the administrator user which processes a file on a cycle and sleeps for say 2 seconds, and have the webserver write to that file

just a thought

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[1DMF]

is it possible to get a script to execute a command and run it under admin privilages ?

ie.

perl c:\path\script.pl [vars]

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[PaulTEG]

google 'perl daemon'

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[1DMF]

so a daemon is a service that sits in the background.

I take it I then write the perl code to say if x=y do z else do nothing.

whats the difference between running a daemon(service) or having a scheduled task run a standard perl scripts?

The main difference I can see is a daemon is a lot more complicated and harder to write ;-)

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[PaulTEG]

a scheduled task isn't suitable for this because it has to fire, and someone could be looking for access prior to it's next fire.

A daemon is available to process effectively on demand

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[1DMF]

hang on you've confused me, are you saying the daemon service sits in the background and the running script fires the daemon at the point I could have called system()?

if so whats the difference between using system() on demand or calling a daemon on demand?

the script will do the same thing which ever way it is called?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[PaulTEG]

Hi I'm a daemon and I continuously read that file over there, between naps, but I'm running under administrator credentials

Hi, I'm a script, and I write to this file here, so my daemon buddy can pick up the details and process them, because I've been socially crippled (diminished responsibilty) because I'm easily led by external factors.


Hope that makes a bit more sense ;-)

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[1DMF]

I get that bit, which I assume is saying that any fork(), system() , exec() is run with the same user account as the parent script making the call, which as you say is no good, poor little social outcast!

But i'm still lost between writing a daemon service opposed to writing a script which does the same job as the service and is scheduled to run every 10 minutes?



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[PaulTEG]

Your call, but I'd go with the daemon, essentially a script that's installed on the box as a service (on windows), it's not that difficult

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[1DMF]

it's not that difficult

for you maybe , don't forget i'm, 1DMF ;-)

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[1DMF]

yeah as I thought, not that easy

use Win32::Daemon;
    Win32::Daemon::RegisterCallbacks( \&CallbackRoutine );
    %Context = (
        count   =>  0,
        start_time => time(),
    );
    # Start the service passing in a context and
    # indicating to callback using the "Running" event
    # every 2000 milliseconds (2 seconds).
    Win32::Daemon::StartService( \%Context, 2000 );
    
    sub CallbackRoutine
    {
        my( $Event, $Context ) = @_;
        
        $Context->{last_event} = $Event;
        if( SERVICE_RUNNING == $Event )
        {
            # ... process your main stuff here...
            # ... note that here there is no need to
            #     change the state
            
        }    
        elsif( SERVICE_START_PENDING == $Event )
        {
            # Initialization code
            # ...do whatever you need to do to start...



            $Context->{last_state} = SERVICE_RUNNING;
            Win32::Daemon::State( SERVICE_RUNNING );
        }
        elsif( SERVICE_PAUSE_PENDING == $Event )
        {
            $Context->{last_state} = SERVICE_PAUSED;
            Win32::Daemon::State( SERVICE_PAUSED );



        }
        elsif( SERVICE_CONTINUE_PENDING == $Event )
        {
            $Context->{last_state} = SERVICE_RUNNING;
            Win32::Daemon::State( SERVICE_RUNNING );
        }
        elsif( SERVICE_STOP_PENDING == $Event )
        {
            $Context->{last_state} = SERVICE_STOPPED;
            Win32::Daemon::State( SERVICE_STOPPED );
            
            # We need to notify the Daemon that we want to stop callbacks and the service.
            Win32::Daemon::StopService();
        }
        else
        {
            # Take care of unhandled states by setting the State()
            # to whatever the last state was we set...
            Win32::Daemon::State( $Context->{last_state} );
        }
        return();
    }

any chance you could help break this down into english? and also I notice there is no shebang line nor is there a use strict or any vars defined , is this correct for a service , do you use different syntax for a service?

I notice to actually put the service into windows you have to write another script...

use Win32::Daemon; 
    # If using a compiled perl script (eg. myPerlService.exe) then 
    # $ServicePath must be the path to the .exe as in:
    #    $ServicePath = 'c:\CompiledPerlScripts\myPerlService.exe';
    # Otherwise it must point to the Perl interpreter (perl.exe) which
    # is conviently provided by the $^X variable...
    my $ServicePath = $^X; 
    
    # If using a compiled perl script then $ServiceParams
    # must be the parameters to pass into your Perl service as in:
    #    $ServiceParams = '-param1 -param2 "c:\\Param2Path"';
    # OTHERWISE
    # it MUST point to the perl script file that is the service such as:
    my $ServiceParams = 'c:\perl\scripts\myPerlService.pl -param1 -param2 "c:\\Param2Path"';
    
    %Hash = (
        machine =>  '',
        name    =>  'PerlTest',
        display =>  'Oh my GOD, Perl is a service!',
        path    =>  $ServicePath,
        user    =>  '',
        pwd     =>  '',
        description => 'Some text description of this service',
        parameters => $ServiceParams
    );
	
	if( Win32::Daemon::CreateService( \%Hash ) )
    {
        print "Successfully added.\n";
    }
    else
    {
        print "Failed to add service: " . Win32::FormatMessage( Win32::Daemon::GetLastError() ) . "\n";
    }

am i to take it you then need to create a batch file that issues 'perl start_my_services.pl' and add to the windows start up folder, should the machine get rebooted?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.