In order to use SPTI calls using IOCTL_SCSI_PASS_THROUGH_DIRECT, my plain C
program needs administrative rights. Similar functionality in Unix uses
getuid() but that’s not available under Windows. What is the easiest way to
find out in at runtime if my program runs with “Run As Administartor”
rights? Any code samples would be really handy…
Easiest method I know of is to try to open a handle to the service control manager with rights to create a service.
OpenSCManager(NULL, NULL, SC_MANAGER_CREATE_SERVICE)- if it returns non-NULL, call CloseServiceHandle on the returned handle, and you’re an administrator. If it returns NULL, you’re not.
Write helper application playing with ACLs. Similar to BurnRights by
Nero. I personally don’t like this way as it opens raw device access to ALL
of the applications. Sounds like security hole to me…
Write very simple kernel mode driver doing
ZwOpenFile/ZwDuplicateObject/ZwClose from application thread context
(IRP_MJ_DEVICE_CONTROL handler for example) and passing open device
duplicated handle back to user mode caller. This is what we do for years…
Drop
me a message to xxxxx@rocketdivision.com and I’d issue you with complete
driver source code. If you’d promise to keep original copyright strings at
their
place
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
P.S. I guess next step would be writing filter driver just above device PDO
with private SPTI-like interface. And with overlapped I/O support MS skipped
for some reason for IOCTL_SCSI_PASS_THROUGH_XXX calls.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rob Turk
Sent: Wednesday, November 15, 2006 12:07 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to detect if I have administrative rights?
In order to use SPTI calls using IOCTL_SCSI_PASS_THROUGH_DIRECT, my plain C
program needs administrative rights. Similar functionality in Unix uses
getuid() but that’s not available under Windows. What is the easiest way to
find out in at runtime if my program runs with “Run As Administartor”
rights? Any code samples would be really handy…
The “as administrator” is a common misconception. You should determine the
specific privileges you need and ascertain if these are available to you at
runtime using Win32 API functions if you are in usermode.
Cheers
Lyndon
“Rob Turk” wrote in message news:xxxxx@ntdev… > In order to use SPTI calls using IOCTL_SCSI_PASS_THROUGH_DIRECT, my plain > C program needs administrative rights. Similar functionality in Unix uses > getuid() but that’s not available under Windows. What is the easiest way > to find out in at runtime if my program runs with “Run As Administartor” > rights? Any code samples would be really handy… > > Thanks, > Rob > >
IsNtAdmin is undocumented, but has been present and unchanged since 4.0.
Rob Turk wrote:
In order to use SPTI calls using IOCTL_SCSI_PASS_THROUGH_DIRECT, my plain C
program needs administrative rights. Similar functionality in Unix uses
getuid() but that’s not available under Windows. What is the easiest way to
find out in at runtime if my program runs with “Run As Administartor”
rights? Any code samples would be really handy…
The classic way to do this is to create a DACL with an allow entry for
builtin administrators and perform an access check given the current token.
This is described in kb118626 < http://support.microsoft.com/kb/118626/en-us
> and requires no undocumented function hackery (“IsNtAdmin”) or relying on
the state of the SC manager DACL (trying to open the service database - note
that the SCM DACL has changed between OS releases before and is certainly
subject to future change).
The kb article provides complete sample code that uses the documented
solution. I would highly recommend using the correct and documented
approach, especially since it is readily available.
“Rob Turk” wrote in message news:xxxxx@ntdev… > In order to use SPTI calls using IOCTL_SCSI_PASS_THROUGH_DIRECT, my plain > C program needs administrative rights. Similar functionality in Unix uses > getuid() but that’s not available under Windows. What is the easiest way > to find out in at runtime if my program runs with “Run As Administartor” > rights? Any code samples would be really handy… > > Thanks, > Rob > >
Since I love to thread-hijack, I hope you don’t mind me running this
thread off road. I keep searching for
a way to authenticate users, but can figure out how too.
I’m looking for a way to display a dialog box where one can enter a
username and pass, and then while
running in a Guest accout(for ex.) I can authenticate the user has
supplied admin credintials. Given the architecture
of NT, is this possible?
I don’t want to elevate priveledges on anything, I just want to verify
the right person is making changes too my
config., would like to make it so the admin can do so while JoeBlow is
logged in.
Any Ideas?
Skywing wrote:
> and requires no undocumented function hackery (“IsNtAdmin”) or relying on
note that the SCM DACL has changed between OS releases before and is certainly
subject to future change).
“Rob Turk” wrote in message news:xxxxx@ntdev… > In order to use SPTI calls using IOCTL_SCSI_PASS_THROUGH_DIRECT, my plain > C program needs administrative rights. Similar functionality in Unix uses > getuid() but that’s not available under Windows. What is the easiest way > to find out in at runtime if my program runs with “Run As Administartor” > rights? Any code samples would be really handy… > > Thanks, > Rob
Thanks everyone for the hints and tips, certainly enough to get me going And thanks Anton for the generous offer, I will keep that in mind as a ‘backup plan’.
What you want to do is often a bad idea. As the KB article says:
| Collecting user credentials from a User-mode application
| can be annoying to the users and can provide a possible
| security hole in the enterprise computing environment.
| The Unified Logon requirement (a requirement that the user
| should only be required to type their credentials one time
| at the CTRL+ALT+DEL screen), was added to the Microsoft
| BackOffice logo requirements for these very reasons.
| It is important to make sure that you really need to
| gather credentials and that some other method of
| client/server validation is not more appropriate.
| Consult the security documentation in the Platform SDK
| for more information on impersonation and programming
| secured servers.
-----Original Message-----
From: MM
Sent: Wednesday, November 15, 2006 9:27 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to detect if I have administrative rights?
Thank you for providing the link.
Since I love to thread-hijack, I hope you don’t mind me running this
thread off road. I keep searching for
a way to authenticate users, but can figure out how too.
I’m looking for a way to display a dialog box where one can enter a
username and pass, and then while
running in a Guest accout(for ex.) I can authenticate the user has
supplied admin credintials. Given the architecture
of NT, is this possible?
I don’t want to elevate priveledges on anything, I just want to verify
the right person is making changes too my
config., would like to make it so the admin can do so while JoeBlow is
logged in.
For XP and later, you should use the CredUI* functions for credential input
prompts. The reason there is that you will automagically get support for
alternative authentication mechanisms as the OS provides support. For
example, when using CredUI, you instantly get support for allowing users to
use smart cards for secondary logon to your application for free, which
might otherwise take quite a lot of work to support (as opposed to allowing
just plain password authentication).
To validate supplied credentials, you should pass them to LogonUser. On
Windows XP and beyond, LogonUser does not require any special privileges
that a “plain” user would not have. On Windows 2000, this function requires
SeTcbPrivilege, which is typically only granted to localsystem by default.
If this is a problem, you might use a small helper service to do the
LogonUser call on your behalf on Win2K (if you even need to support it);
otherwise, I would just call LogonUser directly on XP and beyond.
“MM” wrote in message news:xxxxx@ntdev… > Thank you for providing the link. > > Since I love to thread-hijack, I hope you don’t mind me running this > thread off road. I keep searching for > a way to authenticate users, but can figure out how too. > > I’m looking for a way to display a dialog box where one can enter a > username and pass, and then while > running in a Guest accout(for ex.) I can authenticate the user has > supplied admin credintials. Given the architecture > of NT, is this possible? > > I don’t want to elevate priveledges on anything, I just want to verify the > right person is making changes too my > config., would like to make it so the admin can do so while JoeBlow is > logged in. > > Any Ideas? > > > > Skywing wrote: > >> > and requires no undocumented function hackery (“IsNtAdmin”) or relying >> > on >> > >>note that the SCM DACL has changed between OS releases before and is >>certainly subject to future change). >> >> >> >
I wish there was a simple way too ask the system if
UserName + Password = LocalAdministrator…
Skywing wrote:
For XP and later, you should use the CredUI* functions for credential input
prompts. The reason there is that you will automagically get support for
alternative authentication mechanisms as the OS provides support. For
example, when using CredUI, you instantly get support for allowing users to
use smart cards for secondary logon to your application for free, which
might otherwise take quite a lot of work to support (as opposed to allowing
just plain password authentication).
To validate supplied credentials, you should pass them to LogonUser. On
Windows XP and beyond, LogonUser does not require any special privileges
that a “plain” user would not have. On Windows 2000, this function requires
SeTcbPrivilege, which is typically only granted to localsystem by default.
If this is a problem, you might use a small helper service to do the
LogonUser call on your behalf on Win2K (if you even need to support it);
otherwise, I would just call LogonUser directly on XP and beyond.