Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My research has led to me this point -> open "Security Configuration and Analysis" msc snapin, export template into .inf, open .inf in "Security templates" mmc snapin, but here is where I have slowed my progress to a halt.

How does one create custom policies in the .inf file, to to re modularized back into the dbs file? Specifically, I am looking for a policy to prevent a group of users from manipulating other user accounts either through lusrmgr.msc, control userpassword[2] or net user.

share|improve this question

1 Answer 1

There aren't fine-grained permissions to enable you to "lock down" manipulation of "Local Users and Groups" (the old registry SAM hive). It's not a matter of there being no syntax for the Security Template, but rather there's just no functionality to do this. You can't "delegate" or restrict permission to modify the SAM on a machine-- the product just can't do it.

Edit:

Access to the SAM is only "allowed" through APIs that access the SAM and SECURITY hives of the registry. These APIs make the security checks and, to my knowledge, these checks are hard-coded. There isn't somewhere that you can change permissions to alter the behavior of these APIs. All the programs you describe use these APIs to make changes to the registry. You CAN'T delegate control of the SAM to limited users, other groups, etc-- it's hard-coded in the product.

If you don't want users mucking about with things that only "Administrators" are allow to do don't make them "Administrators. Anything else you try to do, so long as they are still members of the "Administrators" group, is a futile attempt and can be un-done by the user.

Some background on the architecture is here: http://technet.microsoft.com/en-us/library/cc961760.aspx?ppud=4

Old Windows NT 4.0 domains used the SAM as their back-end storage for accounts and groups and suffered from these limitations in the ability to delegate control. That was yet one more reason by Active Directory was better than NT 4.0. Insofar as the SAM on individual PCs we're still in the NT 4.0 days, in terms of delegation functionality, even on Windows 7 (and I don't see that ever changing).

share|improve this answer
    
Thanks @Evan Anderson. Sorry, if I may (Happy to start new question), A) So there is no way to control access to the level of the SAM hive through the security policy, but one can still prevent lusrmgr.msc and control userpassword[2] from running via security policy, right? B) Do you know of a way to prevent net user / other derivatives running? C) I presume you can do this the other way around, start with a limited user account and add admin features? –  user66001 May 10 '12 at 10:29
    
D) Anyways, How does one alter the inf file / template file to include allowed functionality? E) Can you point me in the right direction if I wanted to learn more about how Windows stops limited users accessing (presumably) the SAM hive? –  user66001 May 10 '12 at 10:30
    
Thanks @Evan Anderson, shall I start a new question for D)? –  user66001 May 10 '12 at 17:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.