Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

how to set admin privilege

25 views
Skip to first unread message

Ashish

unread,
Dec 16, 2009, 5:19:07 AM12/16/09
to
How to set admin privilege for a windows user

In windows7 i login to a user which admin right. when i use CreateFile to
open a device say hard drive then it's fail. While if i login to
administrator and use CreateFile then it's succeed.
So i think i need to set admin privilege to current user.
Please suggest.


David Lowndes

unread,
Dec 16, 2009, 10:36:57 AM12/16/09
to
>In windows7 i login to a user which admin right. when i use CreateFile to
>open a device say hard drive then it's fail. While if i login to
>administrator and use CreateFile then it's succeed.

It sounds to me as though your application needs to run elevated -
i.e. it needs the "requireAdministrator" setting in its manifest.

Dave

Tom Serface

unread,
Dec 16, 2009, 1:20:06 PM12/16/09
to
Just to add to David's reply, here is a function I wrote that will tell you
the current privileges so you could make the decision programmatically.
You'l have to fill in the way you check the version (I use the XTreme
Toolkit function.

This also works on Win7 (for me so far anyway).

You may also find this link informational:

http://en.wikipedia.org/wiki/User_Account_Control

Tom

bool IsRunningVistaElevated()
{
bool bRet = false;
TOKEN_ELEVATION_TYPE ptet;
if (/* Check OS version here XTOSVersionInfo()->IsWinVistaOrGreater() */) {
HANDLE hToken = NULL;
if (::OpenProcessToken(::GetCurrentProcess(), TOKEN_QUERY, &hToken)) {
DWORD dwReturnLength = 0;
if (::GetTokenInformation(hToken, TokenElevationType, &ptet, sizeof ptet,
&dwReturnLength))
bRet = ptet == TokenElevationTypeFull;
::CloseHandle( hToken );
}
}
return bRet;
}


"Ashish" <akohl...@hotmail.com> wrote in message
news:u0b2Imjf...@TK2MSFTNGP05.phx.gbl...

Pete Delgado

unread,
Dec 16, 2009, 3:27:30 PM12/16/09
to

"Tom Serface" <t...@camaswood.com> wrote in message
news:uLIWkxnf...@TK2MSFTNGP02.phx.gbl...

> Just to add to David's reply, here is a function I wrote that will tell
> you the current privileges so you could make the decision
> programmatically. You'l have to fill in the way you check the version (I
> use the XTreme Toolkit function.
>
> This also works on Win7 (for me so far anyway).
>
> You may also find this link informational:
>
> http://en.wikipedia.org/wiki/User_Account_Control
>
> Tom
>
> bool IsRunningVistaElevated()
> {
> bool bRet = false;
> TOKEN_ELEVATION_TYPE ptet;
> if (/* Check OS version here XTOSVersionInfo()->IsWinVistaOrGreater() */)
> {
> HANDLE hToken = NULL;
> if (::OpenProcessToken(::GetCurrentProcess(), TOKEN_QUERY, &hToken)) {
> DWORD dwReturnLength = 0;
> if (::GetTokenInformation(hToken, TokenElevationType, &ptet, sizeof ptet,
> &dwReturnLength))
> bRet = ptet == TokenElevationTypeFull;
> ::CloseHandle( hToken );
> }
> }
> return bRet;
> }

Tom,
Elevation is not the same as having administrative privileges. The OP asked
for administrative privileges and your code simply tells the elevation
status of the process token which is not the same thing.For example, if i
were to create an account that has the SeImpersonatePrivilege privilege,
then I can launch the process with this elevated token. Your code will
correctly see that this is an elevated token, but yet this is not a user
that is a member of the Administrators group.

With that being said, for most applications like the OP has created, it is
far better for security to only require those permissions that the process
actually needs. Requiring Administrator rights is heavy handed and was done
in the XP days. I suggest that the OP have his code use the PrivilegeCheck
function in conjuction with obtaining the elevation status of the token
rather than using membership to a specific group in order to determine
whether the process has the necessary rights to do something.

-Pete

Tom Serface

unread,
Dec 17, 2009, 2:05:04 AM12/17/09
to
Makes sense. We do anything we need to have administrator privileges for in
the setup/install and anything else that needs admin as a service. I do
understand apps needing it at sometimes, but I think the days of assuming
you can do anything on the system are over.

Tom

"Pete Delgado" <Peter....@NoSpam.com> wrote in message
news:Ofoey4of...@TK2MSFTNGP04.phx.gbl...

Ashish

unread,
Dec 18, 2009, 6:12:38 AM12/18/09
to
Sorry for late reply.
Yes below code tells about status. Can you please give me any link which
contains the code to change provolege at run time.

"Pete Delgado" <Peter....@NoSpam.com> wrote in message
news:Ofoey4of...@TK2MSFTNGP04.phx.gbl...
>

Geoff

unread,
Dec 18, 2009, 12:32:38 PM12/18/09
to
On Wed, 16 Dec 2009 15:49:07 +0530, "Ashish" <akohl...@hotmail.com>
wrote:

It would be a very flawed security and access control system if it
allowed a process to elevate itself to admin above the user's
privilege. A user can run a process as administrator but only if the
user knows the administrator credentials. This must occur before the
process is started. A process can downgrade itself or impersonate an
account of lesser privilege if that account allows impersonation but
it cannot elevate itself above the access level of the account
invoking the process.

The principle of least-privilege dictates your process should write
its files to the user's folder tree, not to a folder requiring
administrator access.

Tom Serface

unread,
Dec 18, 2009, 12:57:05 PM12/18/09
to
There isn't a good way to do that except through the mechanism that tells
the OS to alert the user you want to run as admin. However, at least with
the code I listed you can tell if that's happened or not and act
appropriately. You could put it in your manifest to always force this
condition, but if that's the case (unless you're an install program) I'd
figure out another way to do what you're doing since that would be tedious
for Vista and Win7 users trying to live in the security bounds. I think
we're just living in a different world thanks to the nefarious types that
want to wreck our computers for no good reason.

Tom


"Ashish" <akohl...@hotmail.com> wrote in message

news:#ZXOcN9f...@TK2MSFTNGP05.phx.gbl...

Ashish

unread,
Dec 21, 2009, 7:10:06 AM12/21/09
to
Below code is not working on windows7 client machine.TOKEN_ELEVATION_TYPE
is not recognize.
My problem is when i use CreateFile to open disk/drive then it's fail while
login user is member of Administrator.

"Tom Serface" <t...@camaswood.com> wrote in message

news:epCjDuAg...@TK2MSFTNGP04.phx.gbl...

Pete Delgado

unread,
Jan 4, 2010, 1:03:17 PM1/4/10
to

"Geoff" <ge...@invalid.invalid> wrote in message
news:sleni59s6pb59u5mj...@4ax.com...

> On Wed, 16 Dec 2009 15:49:07 +0530, "Ashish" <akohl...@hotmail.com>
> wrote:
>
>>How to set admin privilege for a windows user
>>
>>In windows7 i login to a user which admin right. when i use CreateFile to
>>open a device say hard drive then it's fail. While if i login to
>>administrator and use CreateFile then it's succeed.
>>So i think i need to set admin privilege to current user.
>>Please suggest.
>>
>
> It would be a very flawed security and access control system if it
> allowed a process to elevate itself to admin above the user's
> privilege.

..and yet impersonation does just that. It allows a thread within a process
started under an account with the SeImpersonatePrivilege right to assume the
security context of any another principal provided that the process was
launched with an unfiltered token or that COM elevation has been used.

>A user can run a process as administrator but only if the
> user knows the administrator credentials. This must occur before the
> process is started.

A given thread within a process may run underneath a different security
context *after* the process has started by using the COM elevation moniker.
Many administrative applets within Windows use this technique to isolate
functional portions of the application that require elevation from those
that do not. See the SDK documentation for CoCreateInstanceAsAdmin(). This
means that a process does not necessarily have to be elevated when
*started*.

>A process can downgrade itself or impersonate an
> account of lesser privilege if that account allows impersonation

I think your understanding of this topic is seriously flawed.

>but
> it cannot elevate itself above the access level of the account
> invoking the process.

I have already given you two instances where the above statement is
incorrect.

>
> The principle of least-privilege dictates your process should write
> its files to the user's folder tree, not to a folder requiring
> administrator access.

It dictates that the application should only request those specific
privileges that it actually needs to perform its authorized tasks. I am
constantly amazed that people would open large security holes in the
operating system just because they lack the desire to learn the basics of
Windows security!

PS: Michael Howard's blog is an excellent source for security related
information:
http://blogs.msdn.com/michael_howard/default.aspx


-Pete


Pete Delgado

unread,
Jan 4, 2010, 1:20:44 PM1/4/10
to

"Ashish" <akohl...@hotmail.com> wrote in message
news:eiAOmbjg...@TK2MSFTNGP04.phx.gbl...

> Below code is not working on windows7 client machine.TOKEN_ELEVATION_TYPE
> is not recognize.
> My problem is when i use CreateFile to open disk/drive then it's fail
> while login user is member of Administrator.

Are you opening a raw device or simply attempting to open a file at the root
level of a drive? Has the process or thread been elevated in some manner?

-Pete


Pete Delgado

unread,
Jan 12, 2010, 11:04:46 AM1/12/10
to

"Pete Delgado" <Peter....@NoSpam.com> wrote in message
news:O$oUygWjK...@TK2MSFTNGP02.phx.gbl...

>> It would be a very flawed security and access control system if it
>> allowed a process to elevate itself to admin above the user's
>> privilege.
>
> ..and yet impersonation does just that. It allows a thread within a
> process started under an account with the SeImpersonatePrivilege right to
> assume the security context of any another principal provided that the
> process was launched with an unfiltered token or that COM elevation has
> been used.

Just wanted to clarify that the impersonation mechanism does not enable a
process to bypass the security mechanisms of the operating system. There are
specific conditions that must be met in order to allow a thread to
impersonate the security context of another principal. These prerequisites
are described in the platform SDK. I noticed that my language in my previous
post implies that an arbitrary process may impersonate the security context
of any other thread with no preconditions and that is not true.

-Pete


0 new messages