Exe lacks "query information" permission, can't get list of printers.
One of my customers has a VB6 application that tells a Common Dialog box to show the list of printers.
It works without any difficulty -- except on one machine. On that computer, a 64-bit Windows 2003 Server machine running Terminal Server, it displays an error message to the effect that the user does not have permission to get the information.
They have already done a great deal of work on this to isolate the cause.
Using sysinternals process explorer, they find that the instance of the executable lacks the "query information" special permission. Using the tool, they can grant the permission to the user for that instance. But the next time they launch the program, it lacks the permission again.
They can reproduce the issue on other Windows machines by using process explorer to remove the "query information" permission.
If you can answer the following question, you're better than 3 levels of Microsoft tech support:
Where is that permissions set? What in the OS determines that setting?
Thanks!
It works without any difficulty -- except on one machine. On that computer, a 64-bit Windows 2003 Server machine running Terminal Server, it displays an error message to the effect that the user does not have permission to get the information.
They have already done a great deal of work on this to isolate the cause.
Using sysinternals process explorer, they find that the instance of the executable lacks the "query information" special permission. Using the tool, they can grant the permission to the user for that instance. But the next time they launch the program, it lacks the permission again.
They can reproduce the issue on other Windows machines by using process explorer to remove the "query information" permission.
If you can answer the following question, you're better than 3 levels of Microsoft tech support:
Where is that permissions set? What in the OS determines that setting?
Thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
graye
Also, run GPEDIT.MSC on the server, and drill down to Computer Configuration, Windows Sewttings, Security Settings, Local Policies, User Rights Assingments and tell us what's in "Replace a process level token"
ASKER
>>Do you have a programmer handy? I think we could add a few lines of code to your application to alter the processes' securty token
Right here! You've got VB6 code that can do this?
Logging onto that server now to look @ GPEdit ...
Right here! You've got VB6 code that can do this?
Logging onto that server now to look @ GPEdit ...
ASKER
"Replace a process level token" has several system-created users:
IWAM_something
IWAM_<computername>
LOCAL SERVICE
NETWORK SERVICES
SQLServer2005MSFTEUser$<co
SQLServer2005MSSQLUser$<co
SQLServer2005SQLAgentUser$
And the server is running IE7.
We have another executable that runs the exact same code ... has same NTFS permissions ... and it's fine on that server.
More ideas? Or some code to try?
Thanks!
IWAM_something
IWAM_<computername>
LOCAL SERVICE
NETWORK SERVICES
SQLServer2005MSFTEUser$<co
SQLServer2005MSSQLUser$<co
SQLServer2005SQLAgentUser$
And the server is running IE7.
We have another executable that runs the exact same code ... has same NTFS permissions ... and it's fine on that server.
More ideas? Or some code to try?
Thanks!
ASKER
"When a user logs in, the system collects a set of data that uniquely identifies the user during the authentication process, and stores it in an access token. This access token describes the security context of all processes associated with the user. The security context of a process is the set of credentials given to the process or the user account that created the process."
Except that ... the same user is getting one set of access rights applied to one executable and a smaller set applied to another executable in the same session.
"To change a process's security descriptor, call the SetSecurityInfo function."
So, can the process do this for itself?
I guess in psuedocode I'm wishing for something like the following. Does this look at all right or feasible?
Except that ... the same user is getting one set of access rights applied to one executable and a smaller set applied to another executable in the same session.
"To change a process's security descriptor, call the SetSecurityInfo function."
So, can the process do this for itself?
I guess in psuedocode I'm wishing for something like the following. Does this look at all right or feasible?
SecurityInfo si = GetSecurityInfo(MyHandle, other parameters)
SetSecurityInfo (MyHandle, si OR Query_Information_Value, other parameters)
But of course that's wrong as GetSecurityInfo doesn't return a SecurityInfo structure ... but a DWORD success/error value.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks, one of those links was good. And I think I'm really close.
However, GetSecurityInfo is returning an error code 6 ... which appears to mean "Invalid Handle". The handle returned by GetProcessID() matches the PID that Task Manager shows.
Here's the code ... simplified just a little.
Suggestions? thanks!
However, GetSecurityInfo is returning an error code 6 ... which appears to mean "Invalid Handle". The handle returned by GetProcessID() matches the PID that Task Manager shows.
Here's the code ... simplified just a little.
Suggestions? thanks!
1000 Dim ea As EXPLICIT_ACCESS
1010 Dim pCurDacl As Long
1020 Dim pNewDacl As Long
1030 Dim MyHandle As Long
1040 Dim pSD As Long
1050 Dim lErrorCheck As Long
1070 On Error GoTo Err_Handler
'set up the explicit access, that is the specific right that will be granted
1080 With ea
1090 .grfAccessPermissions = lPermission
1100 .grfAccessMode = GRANT_ACCESS
1110 .grfInheritance = NO_INHERITANCE
1120 .TRUSTEE.TrusteeForm = TRUSTEE_IS_NAME
1130 .TRUSTEE.TrusteeType = TRUSTEE_IS_USER
1140 .TRUSTEE.ptstrName = "CURRENT_USER" & vbNullChar 'Perhaps this should actually have the current Windows user name ... not sure
1150 End With
'Get the handle to this process
1160 MyHandle = GetCurrentProcessId()
'Get the current DACL
1170 lErrorCheck = GetSecurityInfo(MyHandle, SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION, _
0, 0, pCurDacl, 0, pSD)
^^^^^^^^^^^^^^^^ lErrorCheck is coming back with 6, not 0 ^^^^^^^^^^^^^^^^^^
ASKER
OK, found the obvious error ... obvious if you know your Win API stuff. A ProcessID is not a Handle. Must use OpenProcess to return the Handle.
http://msdn.microsoft.com/en-us/library/ms684320(VS.85).aspx
HANDLE WINAPI OpenProcess(
__in DWORD dwDesiredAccess,
__in BOOL bInheritHandle,
__in DWORD dwProcessId
);
dwProcessID is the easy parameter. I got that with GetCurrentProcessID.
I don't think I need the handle inherited, so bInheritHandle will be false.
What access should I request in the first parameter?
Thanks!
http://msdn.microsoft.com/en-us/library/ms684320(VS.85).aspx
HANDLE WINAPI OpenProcess(
__in DWORD dwDesiredAccess,
__in BOOL bInheritHandle,
__in DWORD dwProcessId
);
dwProcessID is the easy parameter. I got that with GetCurrentProcessID.
I don't think I need the handle inherited, so bInheritHandle will be false.
What access should I request in the first parameter?
Thanks!
ASKER
READ_CONTROL Or WRITE_DAC gets me past that error.
Now when I get to the SetSecurityInfo call, I'm getting error 1336, Invalid ACL.
Might have to do with the hard-coded "CURRENT USER" ... investigating ... but would still appreciate any pointers :-)
Now when I get to the SetSecurityInfo call, I'm getting error 1336, Invalid ACL.
Might have to do with the hard-coded "CURRENT USER" ... investigating ... but would still appreciate any pointers :-)
'Get the handle to this process
1170 MyPID = GetCurrentProcessId()
1180 MyHandle = OpenProcess(ACCESS_RIGHT_READ_CONTROL Or ACCESS_RIGHT_WRITE_DAC, 0, MyPID)
ASKER
Graye, you got me really close. I'll be asking a follow-up and would welcome your participation in that.
Thanks for the help!
Thanks for the help!