• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 346
  • Last Modified:

How to call LogonUser from an EXE, not a service.

When my software is running from a regular User account it needs to do stuff that requires Admin privilages.  So I ask the user to log in as Admin and prompt them to type a user name, password and Domain.  I then call LoginUser to get a token that has Admin privileges.  The problem is that the code only works when the user is logged on as Admin, which defeats the whole puprose.  When the LoginUser function is called while the user is logged in as a regulard user, that is, it does not have SE_TCB_NAME privilege set, the function doesn't work.  In the NT User Manager program, the SE_TCB_NAME privilege is known as the "Act as the operating system" user right.  I must give the user this right, or else LoginUser doesn't work.  Microsoft recommends that LoginUser be called from a service, which is usually run from the LocalSystem account, which always has the SE_TCB_NAME privilege set.
0
shrif
Asked:
shrif
  • 8
  • 7
1 Solution
 
jhanceCommented:
The NT security model requires that a user account have the SE_TCB_NAME privilege before you can call LogonUser().

You have two options:

1) Create a service which a user GUI program will interact with and that will take the information, run LogonUser() and do the work on the user's behalf.  This is the MS recommended procedure.

2) Give the user account the SE_TCB_NAME privilege.  This is NOT recommended as it's a major security hole!  

Unfortunately, there are no other options.  This is by design and is the way NT security works.
0
 
shrifAuthor Commented:
Question about option 1:
If I create a service that the user must run, does that mean that the service must be installed by an Admin?  That is, this is this catch-22 case?  Or can a service be installed with that same low privilage.
Also, if you can install a service in that way, can you do it on the fly?  For instance, can a regular EXE running under a standard "User" account, install a service, call it to do various things and then uninstall it without having the user reboot or require that they reboot with Admin privilages?

Thank you.

0
 
jhanceCommented:
Installing a service requires the SE_TCB_NAME privilege as well so it is a "catch-22".  I think you misunderstand the whole point of why this is not really a "Catch-22".  If a user has the SE_TCB_NAME priv, you may as well give them administrative rights as well, since having one will allow you to get the other.  LogonUser() is a security risk that cannot be allowed to be run by just anyone.  
0
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

 
shrifAuthor Commented:
Thanks.  So, if I want to replace a DLL that's currently in use, and I'm a regular User, I cannot do it unless I go through a service.  I tried a simple test with InstallShield and found that it does all the right things with MoveFileEx when it runs under Admin, but if it's under a regular user, it doesn't complete the install, and doesn't complain about it.  It just leaves the temporary there and that's it.  Very odd.

So, then under Windows NT, you *cannot* update the system DLL's or even other DLL's not in the system directory, if they are in use because you can't use MoveFileEx as a regular user.  Does this seem odd to you?  Shouldn't users be able to install software on their computers without an Admin, or is that also a point that I've missed.
0
 
shrifAuthor Commented:
Also, several people have given me the following workaround.  I tested it to work, although I question its use.

Let's say you have to update MFC42.DLL (or even kernel32.dll).  It's currently in use.  You rename it to MFC42.OLD.  Copy the new one there and call it MFC42.DLL and then reboot.  Am I right to think that this is bad?


0
 
jhanceCommented:
What has this to do with your question about LogonUser()?
0
 
shrifAuthor Commented:
I thought it was clear.  The purpose of calling LogonUser is so that a regular User account can call MoveFileEx in the context of an admin.  However, LogonUser is failing because you cannot use it from a regular User account.
0
 
jhanceCommented:
No, it's not clear at all.  You only said "it needs to do stuff that requires Admin privilages".  That could be anything.

Anyway, with your MoveFileEx() issue, you're likely to run into the same situation using that method unless you open up the protections on the \WINNT\ directory tree.  Normally, on a properly secured system, a regular user will not be able to write or rename files in this directory.  If a regular user can do this, then the whole system is compromised as he would be able to replace any of the Windows NT system files with modified versions, they would eventually get run by the system or the Administrator and the system is "lost".
0
 
shrifAuthor Commented:
The docs for LogonUser also indicate that SE_CHANGE_NOTIFY_NAME  is required, so you want add that to your list?

I have to make a comment here.  I can understand all the security stuff is important.  However, I don't see why a regular user is not allowed admin privileges in the case when they are asked to login as admin and they provide the proper credentials.  It seems to me, if they can logout and logon as admin and do what they need to do, they should be able to do that while they're still logged in as themselves into the system, but perform admin functions after they've been verified with LogonUser().
0
 
jhanceCommented:
We could debate the pros/cons of the way MS implemented NT security all day.  The fact is, the way they did it is the way it is.  Unlike unix where you can 'su' interactively or suid() programmatically, MS decided that additional "gates" were needed.  Their idea is that any admin access needs to be granted in advance through the user's logon rights or managed through interaction with a service that must have been installed by an admin.

The nasty thing about security is that the tighter it is, the more it also interferes with legitimate uses of the computer.
0
 
shrifAuthor Commented:
Okay, well, there's not much more we can do about this issue.  I am hesitant in accepting your answer because it simply indicates that I what I'd like to do can't be done.  I am not sure if you've added anything to the discussion.  If you feel that you have, then please let me know and what point score you feel that your input is worth.

Thanks.
0
 
jhanceCommented:
In my defense, just because something cannot be done doesn't mean that knowing that isn't valuable.  
0
 
shrifAuthor Commented:
I don't know.  Not trying to be cheap here, but the question was clear as to what the problem was.  I described the exact issue, which was that I was running into a catch-22 situation with LogonUser and if there is a way around it.

Perhaps I should have been more clear that the points are only worth it if there is a solution not a confirmation that it can't be done.
0
 
shrifAuthor Commented:
Thanks for your help.
0
 
jhanceCommented:
Are you perhaps confusing this question with another one you asked in another area?  That one mentions the specific problem of installing a new DLL over an in-user one.  This one only asks about how to call the LogonUser() function from a non-privileged account.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

  • 8
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now