I am trying to come up with a way to id how a kix script was started (kix32.exe's parent process).

I have found the program ptree, but it seems that ptree will only work for win2k, and i need a Win2k/NT solution.

One cool thing about ptree is that it adds COM support.

here is what i have found so far using ptree.

a kix32 script launched during logon will have a process thread like the following.

quote:

---

system > smss > winlogon > userinit.exe > cmd > kix32

---

a user launched kix script will be like this.

quote:

---

system > smss > winlogon > userinit.exe > explorer > ....

---

I would like to find a solution that would give me this information for both NT and win2k.

Thanks
Bryce

using the NTreskit tool tlist.exe

tlist kix32 | find /i "cmd"

will display the following.

quote:

---

U:\>tlist kix32.exe | find /i "cmdline"
CmdLine: C:\WINNT\SYSTEM32\KIX32.EXE \\OSHPDC\NETLOGON\logon.bat\..\logon.KIX
CmdLine: kix32 test

---

I had placed a get $nul into my logon script to hold it open, the logon script is the first line.

while the logon script was on hold, i ran another local copy of the logon script, the local script is the 2nd line.

I can make this work.... but i was really wanting to use ptree's COM to query a remote computer....

I will keep looking.

Bryce

I'm thinking maybe tlist from the reskit might help ... do a :

tlist | find /i "kix32" >output.txt

then parser back in and look for a cmd.exe running kix32.exe off your logon share (as opposed to of the workstation ?) - something like that - just an idea ...

-Shanw

That was freaky

yea that is what this thread is about.

What i would really like to do is use some type of COM object to do a query from the server to the client to see if a kix generated request came from the logon script or not.

Ptree looks like it will fit the bill, but ptree has to be installed on the remote client in order to use it (not a big problem). The big problem with ptree is it will not work on a NT computer, and that is a show stopper.

So my current plan of attack is to use tlist.exe (see above) and squirt a kixscript to the remote computer via the rcmd service.

RCMD will have to installed very much like suss.exe... but this is not a problem.

The "squirted" script (logonscript_verification) will then verify the status of the request (logon script or not).

If the logonscript_verification process is ok, the server is notified that the X software install request is a valid request and to start the X software install via the RCMD.

Anything ran via the RCMD command would automatically inherit Admin rights.

hopefully... when the dust clears.... we will have a poor-man's SMS

a secure way to remote install software on a NT/Win2k workstation. With out the risk of using SU, username, and password hardcoded in a script.

Bryce

Since I'm not a programmer, I could be way off base, but what about MSMQ?

quote:

---

MSMQ Triggers
Server-only: This tool is included in the Windows 2000 Server Resource Kit only.

--------------------------------------------------------------------------------

MSMQ Triggers is Message Queuing application that allows you to associate incoming messages in a queue with functionality in a COM component or standalone .exe. As such, business rules can be invoked in response to such messages without any additional programming.

MSMQ Triggers works with Message Queuing for Microsoft® Windows® 2000 and MSMQ 1.0 for Microsoft® Windows NT® version 4.0.

MSMQ Triggers Concepts
Triggers are associated with specific queues on a computer and are invoked every time a Message Queuing message arrives at such queues. A trigger is comprised of one or more rules. These rules are defined by actions that will be invoked when all conditions associated with a rule are true.

A trigger is an automatic action taken in response to a message event. In the context of MSMQ Triggers, an event is defined as one or more conditions being satisfied with respect to a message arriving at a queue. The collection of all triggers on a particular computer is called the trigger set.

A condition is a test that is applied when a message arrives at a monitored queue. The condition can test for a property of a message only. A condition is always paired with an action.

An action is an executable behavior that is taken when a condition is true. An action can be expressed as an executable and argument list; or, a COM component, method, and argument list. Arguments are also called parameters.

A rule is an action-condition pair. A rule describes an action that will be taken when a specific condition is true. The collection of all rules (for all triggers) on a particular computer is called the rule set. A default rule handler, IMSMQRuleHandler, is used to test the condition and implement the action for a rule. This is the only supported rule handler.

An action is an executable behavior that is taken when a condition is true. An action can be expressed as an executable and argument list; or, a COM component, method, and argument list. Arguments are also called parameters.

A rule is an action-condition pair. A rule describes an action that will be taken when a specific condition is true. The collection of all rules (for all triggers) on a particular computer is called the rule set. A default rule handler, IMSMQRuleHandler, is used to test the condition and implement the action for a rule. This is the only supported rule handler.

The MSMQ Triggers Service reads messages from a monitored queue, that is, the service looks at such messages. Messages are not removed from queues by this service. It should be noted that another Message Queuing application may open the queue and remove messages before the MSMQ Triggers Service can looks at the queue.

---

One question on RCMD. Can it be pushed from the server?

I was planning on using waitfor.exe as a go between the client side script and the logon_verification script (both scripts run client side), basicly use waitfor as a second check to make sure that the install request is a valid request called via the logon script. And not a second kix script that a "smart" user has launched to try to trick the system.... (maby this is over kill actual testing will find this out)

RCMD would have to be pushed down to the client from the server side script, but this is easy. copy the exe to the clients %systemroot%\system32 folder, use xnet to install the service under the correct security rights. This is where a choice must be made, run rcmd under the default system account, or run it under a domain account (i am really leaning to the domain account at this time).

If RCMD is ran under the system account, you will be limited to running programs from local resources only, access to network resources would not be allowed. ON the other hand.... running RCMD under a domain account has it's own "challenges". The domain account used will have to be placed in the local admins group, and will need the "LogonAsService" right granted to it on the client PC. Both of these changes could be made from the server side script via ASDI... i think (if not ASDI i know for a fact that it can be done using 3rd party tools) But getting ASDI onto a NT computer... from remote... might be a little tricky. This might require a 2 stage RCMD/ASDI install for NT computers. Install RCMD to run off of service account, install ADSI, modify RCMD using ADSI, to use domain account... All of this would be first time client initialization only....

As you can see i am still putting all of the pieces together in my head... But with the security part licked using tlist.exe... i think that this just might work.

Bryce

if this is the case (and i think it is) then forget all that i typed about running the RCMD service under a domain account. I will know more tomorrow morning.

Bryce

What about Process Explorer from Sysinternals?
http://sysinternals.com/ntw2k/freeware/procexp.shtml

- Kent