Getting the windows account name associated with the MSIE handle/browser

Started by hdsouza, November 15, 2014, 10:07:53 AM

Previous topic - Next topic

hdsouza

Actually it did read all your posts, but I am not sure you've read mine or understood them. I understand you've trying to help, although the best help would be giving a person what they are asking for instead of a workaround solution which you believe works. And I kept repeating that whatever you are suggesting, I have already done.
Yes, lets someone else answer... if at all.

....IFICantBYTE

OK, I'll chime in...
hdsouza, I think you were missing the crucial bit of info that Jim was trying to convey...

Presuming all your processes are Winbatch scrpts and you have full control over the code that launches IE, then doing something like what Jim was suggesting should work...

What he means is that you programmatically force IE to navigate to your final URL after you get the user account that it is running under (and it could be the same one other user accounts go to).
So when your child process wants to launch IE as a specific user and go to a certain URL, it first writes a local file that contains ALL this info... the USER MAME and the URL you want to ultimately go to.
Then it launches IE with the RunShell command and uses this local file as its URL.

Now, when your other process that scans running IE instances (your GetMSIE routine) finds this IE instance, it can then get a handle on it, and it will then able to read ALL the info you stored in the local file that the child originally wrote, INCLUDING the USER NAME and the URL it really wanted to go to.
Now, knowing this, you can programmatically send this instance of IE to the final wanted URL, and you know the USER it is running under.... it can't be confused with any other one.

Hope this helps clear up the communication between you two.
It not... I fear there is no hope ???

   
Regards,
....IFICantBYTE

Nothing sucks more than that moment during an argument when you realize you're wrong. :)

td

"Abandon all hope, ye who enter here."*

*Divine Comedy - Dante Alighieri
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

....IFICantBYTE

You MIGHT be able to try this in your GetMSIE routine too?

Code (winbatch) Select
strComputer = "."
objWMIService = ObjectGet("winmgmts:\\":strComputer:"\root\cimv2")

;colProcessList = objWMIService.ExecQuery("Select * from Win32_Process")
colProcessList = objWMIService.ExecQuery("Select * from Win32_Process Where Name = 'iexplore.exe'")


     strUserName = ObjectType( 'BSTR', '' )
     strUserDomain = ObjectType( 'BSTR', '' )

ForEach objProcess in colProcessList
    objProcess.GetOwner(strUserName, strUserDomain)
Display(1,objProcess.Name,strUserDomain:"\":strUserName)
Next
Regards,
....IFICantBYTE

Nothing sucks more than that moment during an argument when you realize you're wrong. :)

hdsouza

IFICantBYTE, thanks for your code and earlier comments
When you have several threads (child winbatch processes running together) things are not as straight forward as running a single thread. In theory it all seems fine, although practically its not as straight forward as it seems.

In this scenario, when the child launches a browser with the RUNSHELL command. It DOES NOT HAVE CONTROL over the browser. Alternatively if i did use the objectOpen then YES I would have control over the browser, but not with runshell. That being said the only way the child is going to get a handle to the browser is doing a scan for existing msie instances on the computer (which is with the getmsie loop in the code earlier). So once it does find a browser how does it know that the browser it has found was its own. It could be the browser of any other child wbt running on the same system. the only way it can find that information is correlating the windows account name  which it believe the browser should be launched in to the windows account name that the browser is associated with. Now the child wbt already knows the first part of the  equation which is the windows account that the browser SHOULD be launched in. What it does not know is the windows account that is actually associated with the browser. If it does it can correlate.
So the question is: How does the child get the windows account name that the browser is actually in, at THE TIME WHEN IT GETS A HANDLE TO A BROWSER. Is it using processid, tasklist, invoke or a combination.. or WMI like you mentioned

You are right when you mentioned that your code would need to go into the getmise routine. I believe you are going through all IE instances on the computer and getting the windows account associated with each one. If i am able to associate any of the returned handles of getmsie to that of your code, we could end up with a winner

Presently the script fails on objWMIService = ObjectGet("winmgmts:\\":strComputer:"\root\cimv2"). I am thinking my system is locked down by corporate policies or some files are corrupted. But in the process of troubleshooting winmgmts I discovered  a whole trove of winbatch scripts by Detlev similar to our tech support db (He used to be on this forum ages ago) http://winbatch.hpdd.de/index.html.

td

FWIW, Detlev is still a member here.  He just hasn't contributed for several years and  I certainly do miss those contributions.     
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

chuotpatin


RAK

I solved a similar issue not being able to detect/locate/inspect open browsers due to UAC.
My Solution:

;;;; register browser in shell subroutine
#Definesubroutine shellReg (br)
   objShell = ObjectCreate("Shell.Application")
   SWC_BROWSER = 1
   nCookie = ObjectType("I4", 0)
   errormode (@off)
   xx = objShell.Windows.Register(br, br.hwnd, SWC_BROWSER, nCookie)
   errormode (@cancel)
   objShell  = 0
#EndSubroutine

;;;; early in the script
uacstat = RegExistValue(@REGMACHINE, "Software\Microsoft\Windows\CurrentVersion\Policies\System[EnableLUA]")
if uacstat then uacstat = RegQueryDword(@REGMACHINE, "Software\Microsoft\Windows\CurrentVersion\Policies\System[EnableLUA]",0)

;;;; When wb starts a browser: - check to see if UAC is on - if on then register it and all is well!
if uacstat then shellReg (browser)

I have been using this for many years - since early in UAC release.

Hope this applies/helps
Roy

hdsouza

Rak, I am able to get a handle to the browser but thanks anyway.
I managed to work around the problem by having the parent process a unique url set in a child set to all children running during one instance and placing an identical url if encountered at the bottom of the input file (for the next child batch)

hbgmysite