COM+ Security
I still have a Delphi problem with COM+ security. This is the situation:
Machine A: (W2000 or XP) COM+ server running with a local account which is connected to a database server. Roles and security are enabled. The local account is a special account that cannot be used as interactive user.
Machine B: (W95/W98/ME/NT/W2000/XP) Client application that might or might not connect to machine A. The user on this system is a domain user and should be in the roles of the COM+ server.
However, the following situation can happen:
Cindy is using the application on machine B but she is not part of the roles. However, she needs to use the COM+ component on machine A and cannot log out and log in again as a different user. So, the application will need to switch to a different user account internally. The application detects that Cindy has no access rights to the server thus a logon dialog should pop up. Then Cindy could log in using a different Windows account, connect to the COM+ server, do whatever is requiren and finally log out again.
Question is, what is the best way to let Cindy log in as a different user?
Keep in mind that the client should be working on NT and at least Windows '98. If this is absolutely impossible on these Windows versions, a W2000 solution can still be useful for me.) Also important, Cindy will have opened several files and other objects using her normal account and should still have access to these objects while she is impersonating an account that is part of those roles.
Machine A: (W2000 or XP) COM+ server running with a local account which is connected to a database server. Roles and security are enabled. The local account is a special account that cannot be used as interactive user.
Machine B: (W95/W98/ME/NT/W2000/XP) Client application that might or might not connect to machine A. The user on this system is a domain user and should be in the roles of the COM+ server.
However, the following situation can happen:
Cindy is using the application on machine B but she is not part of the roles. However, she needs to use the COM+ component on machine A and cannot log out and log in again as a different user. So, the application will need to switch to a different user account internally. The application detects that Cindy has no access rights to the server thus a logon dialog should pop up. Then Cindy could log in using a different Windows account, connect to the COM+ server, do whatever is requiren and finally log out again.
Question is, what is the best way to let Cindy log in as a different user?
Keep in mind that the client should be working on NT and at least Windows '98. If this is absolutely impossible on these Windows versions, a W2000 solution can still be useful for me.) Also important, Cindy will have opened several files and other objects using her normal account and should still have access to these objects while she is impersonating an account that is part of those roles.
ASKER
On the client the COM object is stored in an OleVariant variable. It is created by using the CreateRemoteComObject() API. The COM+ server can be the local machine itself, a remote machine or an URL to a webserver. (In the latter case no anonimous logons are allowed.)
I don't use any COMConnection component or whatever. Just the plain old Windows API.
I don't use any COMConnection component or whatever. Just the plain old Windows API.
well, i made some tests and found out what i think you have already experienced :
There is no way to configure an MTS package in a way that it is possible to use the authenification, but login as another user then the one you are logged in at the client mashiene.
There is also no way to create the object in a way to say you are a different user.
After all i know it is impossible in all Windows versions to change the current user without logging out like it is possible in unix/linux with the su command. I am not absolutly sure but there was really nothing i was able to find that would indicate that it might be possible.
This sounds like bad news, i am sorry.
The only thing i found that could probably be able to be the base of a workaround is the following MSDN Article.
It discribes how you can add/delete useres to mts roles within a program. Maybe you could write another "authenification" object, where cindy can log in, enter the user data of another user and if they are correct you add her to the mts role temporary ... or something like this (it is just an idea ;-)
HOWTO: Add Users and Groups to MTS Roles Programmatically(Q241345) --> http://support.microsoft.com/default.aspx?scid=kb;en-us;241345
Anyhow, why is cindy not in the mts role? does it really make sense in your application? Wouldn't it probably be easer to add all users to the role that shall be able to use the object?
There is no way to configure an MTS package in a way that it is possible to use the authenification, but login as another user then the one you are logged in at the client mashiene.
There is also no way to create the object in a way to say you are a different user.
After all i know it is impossible in all Windows versions to change the current user without logging out like it is possible in unix/linux with the su command. I am not absolutly sure but there was really nothing i was able to find that would indicate that it might be possible.
This sounds like bad news, i am sorry.
The only thing i found that could probably be able to be the base of a workaround is the following MSDN Article.
It discribes how you can add/delete useres to mts roles within a program. Maybe you could write another "authenification" object, where cindy can log in, enter the user data of another user and if they are correct you add her to the mts role temporary ... or something like this (it is just an idea ;-)
HOWTO: Add Users and Groups to MTS Roles Programmatically(Q241345) --> http://support.microsoft.com/default.aspx?scid=kb;en-us;241345
Anyhow, why is cindy not in the mts role? does it really make sense in your application? Wouldn't it probably be easer to add all users to the role that shall be able to use the object?
hi alex
i have just found a win api function, that might be able to help you take a look at the win sdk help for CreateProcessAsUse
in this way it might be possible 4 cindy to create the new process on her local mashiene and connecting with the new process to the mts ...
i have just found a win api function, that might be able to help you take a look at the win sdk help for CreateProcessAsUse
in this way it might be possible 4 cindy to create the new process on her local mashiene and connecting with the new process to the mts ...
CreateProcessAsUser only works on the NT family and there only if you have the "act as part of the OS" privilege, which is normally only available for services.
However, the solution is quite similar to this: In 2k and xp you can use CreateProcessWithLogonW, which works very nicely and doesn't need any special privileges. I'm using it myself and it works fine. However, you can't this way switch the logged on user for a specific process, instead you have to restart a new instance of your process. Alternatively you can try LogonUser + ImpersonateLoggedOnUser on the NT family, but I'm not sure whether this works well enough. CreateProcessWithLogonW was introduced with 2k, so it's not available on NT4.
In win9x you can use NPLogon (exported by msnp32.dll) to log on a different user dynamically. However, this way you're totally switching the user for all processes. Don't know whether this is acceptable for you.
Regards, Madshi.
However, the solution is quite similar to this: In 2k and xp you can use CreateProcessWithLogonW, which works very nicely and doesn't need any special privileges. I'm using it myself and it works fine. However, you can't this way switch the logged on user for a specific process, instead you have to restart a new instance of your process. Alternatively you can try LogonUser + ImpersonateLoggedOnUser on the NT family, but I'm not sure whether this works well enough. CreateProcessWithLogonW was introduced with 2k, so it's not available on NT4.
In win9x you can use NPLogon (exported by msnp32.dll) to log on a different user dynamically. However, this way you're totally switching the user for all processes. Don't know whether this is acceptable for you.
Regards, Madshi.
Hi Alex,
What you are trying to do is called cloaking. This is done at a proxy level on the client. You can QueryInterface the objects proxy (i.e. your clients reference to the object) for IClientSecurity, then use the SetBlanket method to override the identity of the outgoing calls. One of the parameters (pAuthInfo) takes a structure that that specifies the username, password, and domain. For a detailed description of the method see IClient security on the MSDN web site.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/cmi_c_2sqh.asp
One downside of this approach is that your application captures the password, and this is generally percieved as a security loophole.
Hope this helps.
What you are trying to do is called cloaking. This is done at a proxy level on the client. You can QueryInterface the objects proxy (i.e. your clients reference to the object) for IClientSecurity, then use the SetBlanket method to override the identity of the outgoing calls. One of the parameters (pAuthInfo) takes a structure that that specifies the username, password, and domain. For a detailed description of the method see IClient security on the MSDN web site.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/cmi_c_2sqh.asp
One downside of this approach is that your application captures the password, and this is generally percieved as a security loophole.
Hope this helps.
ASKER
Hi Tony,
That cloaking trick could be what I'm looking for. Too bad I don't have anything Delphi-like to work with. No problem. I'll try to get it working and if it works, you're the Man! ;-)
The possibility for the application to capture the password is not a real problem. For the application this is just an extra service. The user can always log out and log in as a different user on their system if they don't trust it. But more importantly, it allows the user to use special user accounts that have only access to the COM+ application and not to the rest of the system.
The use of special user accounts for the COM+ application while using normal account for the rest of the client process is what I'm looking for.
That cloaking trick could be what I'm looking for. Too bad I don't have anything Delphi-like to work with. No problem. I'll try to get it working and if it works, you're the Man! ;-)
The possibility for the application to capture the password is not a real problem. For the application this is just an extra service. The user can always log out and log in as a different user on their system if they don't trust it. But more importantly, it allows the user to use special user accounts that have only access to the COM+ application and not to the rest of the system.
The use of special user accounts for the COM+ application while using normal account for the rest of the client process is what I'm looking for.
ASKER
Hi Tony,
That cloaking trick could be what I'm looking for. Too bad I don't have anything Delphi-like to work with. No problem. I'll try to get it working and if it works, you're the Man! ;-)
The possibility for the application to capture the password is not a real problem. For the application this is just an extra service. The user can always log out and log in as a different user on their system if they don't trust it. But more importantly, it allows the user to use special user accounts that have only access to the COM+ application and not to the rest of the system.
The use of special user accounts for the COM+ application while using normal account for the rest of the client process is what I'm looking for.
That cloaking trick could be what I'm looking for. Too bad I don't have anything Delphi-like to work with. No problem. I'll try to get it working and if it works, you're the Man! ;-)
The possibility for the application to capture the password is not a real problem. For the application this is just an extra service. The user can always log out and log in as a different user on their system if they don't trust it. But more importantly, it allows the user to use special user accounts that have only access to the COM+ application and not to the rest of the system.
The use of special user accounts for the COM+ application while using normal account for the rest of the client process is what I'm looking for.
ASKER
Grrr... I pressed 'Refresh' by accident. Now my remark is posted twice...
ASKER
After some experimenting (And some personal problems like my father being hospitalized after a heart attack) I still have no solution for this problem.
My test environment is very simple. I have a desktop that is part of a domain and a laptop that's not. The desktop is my middle-tier and the COM+ components run on this system using a local account.
The user on the desktop is no part of the domain but through a logon dialog he must still be able to connect to the middle-tier, logging in using a domain account. This is the other situation I have to take into account.
My test environment is very simple. I have a desktop that is part of a domain and a laptop that's not. The desktop is my middle-tier and the COM+ components run on this system using a local account.
The user on the desktop is no part of the domain but through a logon dialog he must still be able to connect to the middle-tier, logging in using a domain account. This is the other situation I have to take into account.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
how do you connect to your COM+ objects?