Manage User Privileges Programmatically

  • Thread starter Thread starter ciuly0
  • Start date Start date
C

ciuly0

Hi all,

I am trying to translate the code from the following article into
delphi. I mostly succedded but I cannot seem to find the definition of
3 constants. I looked in the latest platform sdk and they are simply
not there.

the article in question:
http://support.microsoft.com/default.aspx?scid=kb;en-us;132958

the constants:
ACCOUNT_ADJUST_SYSTEM_ACCESS
ACCOUNT_VIEW
ACCOUNT_ADJUST_PRIVILEGES

I did found a file NTSecApi.h but it deosn't contain those definitions.
I think that since the article relates to win nt and 2000 maybe those
definitions are present in the nt or 2000 platform sdk. I couldn't get
a copy of any of the 2 and that is why I am asking for your help.

I also looked into the reactOS and wine sources, but with no luck.

If the above is not possible, then I would like another way of
programatically manage a users privilege.
What I am trying to do is programatically grant the "Logon as a
service" right to a newly created user. I need something that will work
at least on winxp, and it will be better if it will run on all windows
nt platforms.

Thanks in advance for your help.
 
I am not pointing you at a .h here, but rather commenting on what
you seem to be trying to do, which is fool with the user rights.
As a dev I understand the need to make sure that an account has
the needed rights. As an admin I have disgust at installers that fool
with the user rights settings, which generally I have locked down by
use of group policy. On one of my machines your installer would
result in a non-working install as soon as group policy applied from
the AD level. Worse, as your installed thought all was good, I have
no indication that the service account was granted the right, which
later disappears.
Solution: document in the install docs that your installed expects a
group named "x" that is granted the user right to log on as a service,
and give the admin a way to specify "x" if they do not like your
default. Your installer just makes sure the account is in the group.
Everyone is happy. It works with group policy latch down, your
install works and keeps working, and admins do not feel your install
is being sneeky tweaking critical settings behind the scenes.
 
Hmm, this is an interesting thought.

IIS6 sets up its service accounts in a similar manner and is included in a
group which grants the necessary privileges (no, the name of the group is
not configurable), but I still frequently see "IIS issues" resolve down to
some enterprise-wide group policy-based lockdown of user privileges that
kill IIS in some insidious manner.

I'm just looking for a reasonable way for IIS to offer usage of service
accounts that still survive group policy lockdown...

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
I am not pointing you at a .h here, but rather commenting on what
you seem to be trying to do, which is fool with the user rights.
As a dev I understand the need to make sure that an account has
the needed rights. As an admin I have disgust at installers that fool
with the user rights settings, which generally I have locked down by
use of group policy. On one of my machines your installer would
result in a non-working install as soon as group policy applied from
the AD level. Worse, as your installed thought all was good, I have
no indication that the service account was granted the right, which
later disappears.
Solution: document in the install docs that your installed expects a
group named "x" that is granted the user right to log on as a service,
and give the admin a way to specify "x" if they do not like your
default. Your installer just makes sure the account is in the group.
Everyone is happy. It works with group policy latch down, your
install works and keeps working, and admins do not feel your install
is being sneeky tweaking critical settings behind the scenes.
 
Hi David,
Yes, the default behavior of IIS 6 (and for that matter ComAdmin
under default account naming, IIRC) is a pain - well, at least it forces
me to not have the control from policy over the login rights in the way
that I would like for a production server (at least where the app pools
defined and their principals changes). I believe the IIS team is aware
of the requirement although for a different reason (admins failing to
define new app pool accounts fully correctly).
Cheers,
Roger
 
BTW David, I colored the other response for IIS 5 behaviors as
the post is in Windows 2000 group. I believe I can recognized
you (from the Summit two past) but did not see you last week up
at building 20 - but if you would like to drill in on this perhaps you
may want to start a thread in the IIS x Preview site forums ??
I did take bring this issue up during the IIS6 beta, but we just
did not get to the best of all worlds design then.

Roger
 
Solution: document in the install docs that your installed expects a
group named "x" that is granted the user right to log on as a service,
and give the admin a way to specify "x" if they do not like your
default. Your installer just makes sure the account is in the group.
Everyone is happy. It works with group policy latch down, your
install works and keeps working, and admins do not feel your install
is being sneeky tweaking critical settings behind the scenes.
Click to expand...

Your rationale may be that this is a cleaner way of doing it but as for
security, an install program normally needs admin rights in which case it
can pretty much blow your machine up if it wants (let alone play with
criticial settings). There's an element of trust that comes with letting a
program run as an administrator and in practice one can't have it both ways
(allowing an app to run with elevated rights but then trying to lock the
machine down so tight that it can't do its job).
 
Larry Smith said:
Your rationale may be that this is a cleaner way of doing it but as for
security, an install program normally needs admin rights in which case it
can pretty much blow your machine up if it wants (let alone play with
criticial settings). There's an element of trust that comes with letting a
program run as an administrator and in practice one can't have it both
ways (allowing an app to run with elevated rights but then trying to lock
the machine down so tight that it can't do its job).
Click to expand...

What you say is quite true, but understated. It is not just what is done
during install, but what you have granted by allowing the installed to
remain able to run that has been a statement of full trust in the provider
of the code. One may not be able to have both the cake and the full
stomach, but one should not IMO just give the cake away either.

There is a long, long tradition of a lack of understanding of one anothers'
issues between devs and admins, which in my view is really just a result
from non-communication and from taking the short route each to their
own end/interest.

This really needs addressing, especially in light of things like xcopy
deploy of NetFx, etc. etc. etc..
 
Back
Top