We help IT Professionals succeed at work.

Domain Users in Local Admin Group

trywaredk
trywaredk asked
on
7,688 Views
Last Modified: 2013-12-04
More and more programs updates themselfes while users are logged on, thus requirering, that Domain Users has to be a member of the Local Admin Group, because the Power Users Group is not always enough for some programs. Updating and installing programs means Admin Power. For example to gain access to some parts of the registry, and to gain access to C:\WINNT\SYSTEM32

But being member of the Local Admin Group on more than one workstation on the network means, that Domain Users gets unlimited REMOTE access to the other workstations.

The unlimited REMOTE access involves:
1. Explorer: \\ComputerName\C$
2. Registry
3. Computer Management (Control Panel)

All this is a problem because Microsoft created the Windows 2000 operating system this way.

If you want to know more about this issue:
---------------------------------------------------------
https://www.experts-exchange.com/Security/Win_Security/Q_20506528.html
http://www.tryware.dk/English/W2kLocalGroupPolicy/TotalAdminPower.html
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/evaluate/featfunc/07w2kadc.asp
http://support.microsoft.com/?kbid=182734

If you want to test it:
--------------------------
You have to grant a Domain User Group to the Local Admin Group on BOTH test-workstations, AND logout and logon again.

Important: You have to make a new logon after creating the credentials, because they are given in W2k in the second where You press ENTER to password when logging on.



****************************
* THIS IS WHAT I WANT *
****************************

1. I want Domain Users to be able to install programs, and run defragment, but only on their own workstations.
2. I DON'T want Domain Users to be able to access other workstations from the network via the C$ share.
3. I want Global Domain Admins and Management Systems to be able to access the workstation from the network

Is it possible to make a Domain User member of the Local Admin Group without having the problem, that every Domain User can gain unlimited REMOTE admin power on every other workstation with \\ComputerName\c$, meaning that everybody can read/write every file on every workstation on the network?


************************************
* AND NOW TO MY QUESTION *
************************************

CAN ANYBODY ANSWER A DIFFERENT SOLUTION THAN THESE:

1. Remove every other than Local Administrator and Domain Admins from Local Admin Group, and make different passwords on Local Administrator on each workstation on my network. Make sure to lock my list of these passwords in my safety box, making it possible to logon the workstation, if the network fails on the workstation.

Then add the Domain User, who daily uses each workstation, to Local Admin Group, and make sure, that he is not in any other Local Admin Group on a workstation in my Company's network.

Make sure, if a colleague suddenly must use the workstation, to remove the first Domain User, and add the new Domain User (who has to logon 2 times before it works), and remove the new Domain User from the Local Admin Group on the other workstation, he uses each day.

I must pay attention on all workstations on my network. Remember to check all Local Admin Group's a couple of times each year.

With this annoying work, my users can install programs and defrag their hard disc, without being able to gain access to each others hard disc's.


2. Remove every other than Local Administrator and Domain Admins from Local Admin Group, and make different passwords on Local Administrator on each workstation on my network. Make sure to lock my list of these passwords in my safety box, making it possible to logon the workstation, if the network fails on the workstation.

Make sure to remove all Domain Groups on all Local Admin Groups (but not the Domain Admins Group), if I had some, to grant to Domain Users for som hours, while they install programs.

With this annoying work, my users cannot install programs and cannot defrag their hard disc, and they cannot gain access to each others hard disc's.

But I must install AND UPGRADE all programs on each workstation on my network, as my users time to another must have installed. And I must defrag all the workstation on my network, when it's necessary.


Many Regards

Jorgen Malmgren
IT-supervisor
Denmark

:o) Your brain is like a parachute. It works best when it's open


THIS QUESTION WAS EARLIER POSTED ON
https://www.experts-exchange.com/Security/Win_Security/Q_20506528.html

Comment
Watch Question

Commented:
Okay, I'll bite. On this part:

>Is it possible to make a Domain User member of the Local >Admin Group without having the problem, that every Domain >User can gain unlimited REMOTE admin power on every other >workstation with \\ComputerName\c$, meaning that >everybody can read/write every file on every workstation >on the network?

So you make the Domain Users Group local administrators. You use group policy on the users' machines' OU, changing "Access this computer from the network" to allow only Domain Admins, service accounts, and your help desk group. This prevents the domain users from remotely connecting to any computer in the OU.

They can still log on locally to machines other than their own, so it doesn't entirely solve the problem, but it takes care of the remote access.

You're still going to have to pay attention to the Local Admin Group, because if the users are local admins, they can add as many local admins as they want, on as many machines as they can access via the console.

Commented:
>>> I want Domain Users to be able to install programs, and run defragment, but only on their own workstations.

   You can grant Elevated Rights to MSI Packages, and then Domain Users could install apps that you create with Wise for Windows or WinInstall LE.

   For the Defrag part, you may want to check on running an application as a service.  I think that it's the "Srvany".  Set it to "manual" and if the User wants to Defrag, they can simply start the service.

   This is only in theory, but may be a good start.

   I think that if you have to maintain lists of each Adminintrator PW for every workstation, your going to drive yourself crazy.

Mirfster.

Commented:
I'm generally four-square against allowing your users local admin privileges... But I understand that it requires a lot of work to make the "least-privileges" model work, often more time than you have for smallish networks.

Anyway, you might be able to script something to make this task a bit easier: For example, say you standardize on using the primary user's name as all or part of the machine name, and you determine the machine name when you do the initial PC setup. You could make a script to add the appropriate domain user account to the Local Administrators group, based on the hostname, upon first boot. Then you only need to worry about (a) pre-existing systems, which you'll have to hit anyway, and (b) future workforce changes.

~ewall

Author

Commented:
TARSUL... "Access this computer from the network"

Being member of the local admin group, my DomainUsers can decide 'newer' to reboot their workstations again, after they have done the following:

1. SET Computer refresh in
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System
Or, alternatively SET the following in
SET User refresh in
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
CREATE a DWORD value with a name of GroupPolicyRefreshTime, and SET it to 648000 minutes.
Create a DWORD value with a name of GroupPolicyRefreshTimeOffset, and SET it to 1440 minutes.
2. Create a *.reg-file with nr. 1 and place it in HKLM\Software\Microsoft\Windows\CurrentVersion\Run with C:\winnt\regedit.exe -s in front
3. Remove the LocalLevelPolicy about "Access this computer from network"
4. Wait and see. DomainLevelPolicy does'nt happend again for a long time. (But will happen again at next reboot). Therefore remember to do nr. 3 after each reboot.
5. Visit Your colleguaes workstations now and then, and do the same here.


MIRFSTER... "Elevated Rights to MSI Packages"

Not trying to offend you, but tell the whole world of software developers ONLY to use MSI when creating install-programs.

MIRFSTER... "if the User wants to Defrag, they can simply start the service"

According to http://support.microsoft.com/?kbid=231176
This version is not designed to be run remotely and cannot be scheduled to automatically defragment a volume WITHOUT INTERACTION from a logged-on user.


EVALL... "and (b) future workforce changes"

I have users loggin into more than one workstation,


TARSUL MIRFSTER & EVALL

Yes - I'm driving crazy because Microsoft did'nt make a C:\Programs\SYSTEM32 where other software developers could place their dll's, and a part of registry to. Thus requirering setting ONE path in environment to locate their dll's.
And you're quite right it's a disaster. That's why I asked the question.

Commented:
Just in case you're interested, I'll say a bit here about some tricks I've used to give users a workable, flexible environment while still keeping a tightly "locked-down" system. If you have time and willingness to implement such a plan, you can greatly increase the security of your network while allowing users to logon where and when they wish, while not giving them access to any other users' data or to the local systems.

1.) User Permissions
The easiest way is to put your Domain Users group in the local Power Users group on all workstations. This gives them the rights to update the system time, start & stop services, etc. which can be handy. For Win2k & XP, use the local security policy templates to lock-down the machine at least to the level of a default 2k+ install (not the "upgrade" or "compatible" versions, which give way too many openings). For NT, you have to make your own or modify the templates to something workable.

2.) Program Permissions
As you said, trywaredk, the overwhelming majority of developers do not obey Micro$oft's rules about where in the file system and Registry a program can write to. However--"DLL Hell" aside--the DLL's are not the major concern here: the default for a locked-down system is to provide read/execute access to all of the program files and program-related Registry keys, and only enable write permissions for those places that need it. I have a fairly simple process that I use and teach for finding out where the program needs write access; you do that once for the program, and make a script to set the permissions for any other machine with that software. Let me know if you want me to ellaborate on that here.

3.) HD Defragmentation
Mirfster was right on about starting the free Diskeeper Lite as a service; it's quite simple. Use SRVANY from the Resouce Kit to setup the defrag EXE as a service which runs under SYSTEM context in "manual" start mode; when the user (need Power User perms by default, BTW) starts the service (say from a shortcut you created for them), the Defrag application window appears and the user interracts with it to start the defrag. (The only confusing thing is if the user closes the app and the service is still running, they'll need to stop and restart the service before running it again--the simple trick is to have your start shortcut first stop then restart the service.)

Anyway, that's a start on how the least-permissions mindset works. Again, let me know if you want to hear more--

~ewall

Author

Commented:
I'm looking for 100% secure ways to let Domain Users run W2k-programs without being able to use the unlimited remote access to other workstations, as described in my 3 demands (look above).
In my opinion there's no way out of adding the user (not Domain Users) to the local admin group as described in my question. The reason is, that more and more programs updates themselfes connected to internet, thus requiering admin power, or maybe only require your setup nr. 2. And some programs does require membership of local admin group.


EWALL... "1)"
The Power Users Group is not always enough for some programs.

EWALL... "2) Let me know if you want me to ellaborate on that here"

If it meets my 3 demands above, I am interested.

EWALL... "3)"
I'll have to test that. I will answer you later. Maybe you have a total desciption of this setup. If not, I will create it myself, as part of my test.

Commented:
1.) - I know that Power Users is not enough--that's the base from where to start, then you apply #2...

2.) Try the following process to learn the extra permissions necessary to apply for a particular software package:

- Download & extract the free RegMon and FileMon programs from www.sysinternals.com
- On a PC with the 'target' program installed, login as an unprivileged/normal user
- Use SU.EXE or RUNAS.EXE to start a command-prompt window (CMD.EXE) as a local-admin account
- From the CMD window, start RegMon & FileMon
- Now run the program from the start menu (i.e. as the normal user)and use it until you get the error messages or problems
- Stop the RegMon & FileMon processes and save their results
- Using Excel or Access or the data-munging program of your choice, analyze the results of the log files: you are looking for "ACCESS DENIED" errors in attempts to WRITE (files) or SET VALUEs (Registry)
- Create a script to open up the permissions for those flagged files, directories, or Registry keys, e.g. giving the BUILTIN\Users group "Change" privileges only; and run it on this system
- As the shampoo bottle says, "Rinse and Repeat"... You may need to do this several times until you find all the files which need their permissions opened

Once you have this script made, you can apply it every time you install the software on another PC. Now those users can run their programs just fine, but can only save their data in appropriate directories (like their profile or whatever user-space you've defined), and can't install any other software* (that is, with a few exceptions, such as simple programs which don't write to the Registry and can be installed entirely into their own directory).

3.) The defrag hack that I described above does work... I've set it up for 800+ systems at my old job with no problems and no security risks.

~ewall

Author

Commented:
EWALL... "1) and 2)"
Seems to me, to be a massive lot of work. Maybee we should start a ftp-site, for all those scripts for each version of each program we all have.
:o) Please don't misunderstand me. I'm not trying to make fun of your answer. I will consider it.

EWALL... "3)"
I will answer you later, when I've finished my test.

Commented:
You're right... in some ways, it can be a lot of work to secure your Windoze network. These suggestions are easier if you've got a staff of a handful of sharp, hard-workin' people who are eager to do it. I will tell you two things, though: (1) This kind of lock-down saves you not only from the incidental/"insider"/disgruntled-employee hacker, but also it saves TONS of time in fixing and troubleshooting the stupid problems users cause when they install every d@mn program they can find on the Internet, and (2) The bigger your network, the better results you'll get from these efforts. After taking the time to employ such a task, you may find--along with many others--that you don't need as many desktop techs to keep everybody happy, and you suddenly have more time available to work on other important projects instead of removing the CEO's latest spyware mistake.

Also, after a few tries you get the process of the RegMon & FileMon stuff down pretty good--I can now usually have it complete in 5 minutes or so for one app. And your idea of sharing the permissions findings is great! Maybe I should make a section for that on my website and share the 100+ scripts I have...

And no worries about making fun... What are we in this job for if it's not for the fun?!?

~ewall

Author

Commented:
EWALL... You have a point, and I will consider it.

Great idea with 100+ scripts on your website. Next problem is to tell everybody about it. Remember not to abuse EE's guidelines about advertising and join other services comparable with EE:
https://www.experts-exchange.com/jsp/infoMemberAgreement.jsp

;o) Hope you parachute is open.

Commented:
FYI..For the Defrag part:

http://www.morphasys.com/autodefrag/

Author

Commented:
MIRFSTER... I have 3 considerations about autodefrag:

1. Can autodefrag run dfrg.msc as a AT job, when logged on user is NOT member of local admin group?
2. According to http://www.morphasys.com/autodefrag/
"For the moment I believe that only English language versions of Win2k are supported"
3. Our compagny policy is to use only built-in Microsoft program for the essential parts of OS, including hard disc manipulation.

Author

Commented:
EWALL... "3) Diskeeper Lite as a service; it's quite simple. Use SRVANY"

You are talking about both Diskeeper Lite and srvany. As I told MIRFSTER I don't want to use autodefrag, but now I did my test about srvany (one of your solutions - and I promised to answer you).

I followed http://support.microsoft.com/?kbid=137890 and tried with both %systemroot%\system32\dfrg.msc and c:\winnt\notepad.exe - both with localsystem and domain admin. It did'nt work, and Event ID 7000 was'nt recorded. I did'nt get anything in eventlog.

BTW - I did have trouble with removing the userdefined service again untill I tried with "instsrv /?".


Commented:
It sounds like you're on the right track, but the fact that Notepad didn't show up suggests that something's amiss...

Perhaps it's this: Once you've got your custom service created, go to the Services Control Panel/Console and open up your new service; on the "Logon" tab, make sure that "Local System Account" is selected and "Allow service to interact with desktop" is checked--this makes it visible to the current user.

If you'd already configured it that way and it still doesn't work, check if the process runs when you start the service. If not, then probably something about the Registry parameters for SRVANY is misspelled or something like that.

One more thing: running the DFRG.MSC file from SRVANY might not work as-is; you may need to have ...\MMC.EXE as the executable and DFRG.MSC as the parameter. Testing the above stuff with Notepad first should work, though, then you can change to the slightly more complicated MMC stuff.

And, BTW, as you mentioned, INSTSRV.EXE is handy for installing/deinstalling services, and another helpful ResKit tool is SC.EXE which can do just about anything with services.

~eric

Author

Commented:
EWALL... I thaught I did follow http://support.microsoft.com/?kbid=137890, but actually I did'nt. What I did wrong, was to create a string insted of a key. Now it works with notepad.exe but only with "Allow service to interact with desktop" and run by system account when I was logged on as member of local admin group.

But it does'nt work with %systemroot%\system32\mmc.exe %systemroot%\system32\dfrg.msc or with %systemroot%\system32\mmc.exe dfrg.msc (both of them works with Start / Run)
It returns no error.

BUT - defrag isn't really part of my initial question. It's only my mistake to mentione defrag to get the attention about the really problem, not being able to install programs.

:o) Anyway - you deserve points for the defrag solution IF you can solve it.

Commented:
Ooh, you're so close, as Notepad working is a good sign.

My bet is that you want to configure it with the "Application" value as "%systemroot%\system32\mmc.exe" and the "AppParameters" value as "dfrg.msc". Putting the executable and the parameter in the same entry doesn't work. (I had to look up the name for AppParameters, since the KB article you had found didn't mention it; this one does: http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b193238).

If just plain "dfrg.msc" doesn't work as the AppParameter, then try using the full path as in "%systemroot%\system32\dfrg.msc". Since the system doesn't launch these executables with the benefit of the shell to interpret the input for them, the registry entries referring to programs and parameters must generally be fully qualified (unless it's one of those that has a lookup elsewhere in the registry, but that doesn't apply here).

Also, if you use environment variables like %SYSTEMROOT% then the Registry value has to be of the type "Expandable String" (REG_EXPAND_SZ), not a regular string (REG_SZ). But I bet you already knew that because your Notepad test worked.

~ewall

Oh, BTW--I think when I finish with this job/contract I'm currently at, I'll have to get to work on that website... ;^)

Author

Commented:
EWALL... "But I bet you already knew that because your Notepad test worked".

No - I did'nt - because Notepad worked with REG_SZ without path:
notepad.exe

Now I tried the following REG_SZ with:
Application:  mmc.exe
AppParameter: dfrg.msc

... and it worked running with "Local System Account" selected and "Allow service to interact with desktop"

Shortcut works like this:
%systemroot%\cmd.exe /c net start MYCHOICESERVICENAME



TRYWAREDK... ":o) Anyway - you (EWALL) deserve points for the defrag solution IF you can solve it."
EWALL... "Mirfster was right on about starting the free Diskeeper Lite as a service"
TRYWAREDK... "Defrag isn't really part of my initial question. It's only my mistake to mentione defrag to get the attention about the really problem, not being able to install programs."

Points for EWALL:
https://www.experts-exchange.com/Security/Win_Security/Q_20594245.html
Points for MIRFSTER:
https://www.experts-exchange.com/Security/Win_Security/Q_20594246.html 

Commented:
Local Security Policy -> Local Policy -> User Rights Assignments > ‘Log on Locally'

Does that not work if you only allow local admins?

Author

Commented:
MSMITTTY..."if you only allow local admins?"

That's the whole problem, they are local admins



Commented:
By local admin I mean the actual user name.  Edit the policy to only allow JShorts, Domain Admins, and Hot Bitches 'log on locally'.

And if that don't work try another defrag but this time from a Bart's boot floppy. Edit your HAL to bypass the encryptions and force a transition on the page fault. Rinse and reboot.

Author

Commented:
MSMITTY - "By local admin I mean the actual user name"

In a way I answered you correctly 07/25/2003 09:15PM CEST, and in a way I did'nt answer you correctly:
"That's the whole problem, they are local admins"

It could be misunderstood, so the correct answer to your question 07/23/2003 02:03AM CEST should have been:
"That's the whole problem, they are member of the local admins group"

The users in my question isn't local user, and the administrators in my question isn't local administrator.

The users in my question are domain users being member of the local admin group (more and more programs updates themselfes while domain users are logged on), and the administrators in my question is members of the domain admins group.

Thus the domain admins should be able to log on locally, and the domain user should be able to log on locally on their own workstation, but being member of the local admin group the can (but should'nt be able to) also get unlimited remote access to every other workstation, because of membership of the local admin group.

BTW - being member of the local admin group, they can enable "your solution" about the local policy - log on locally.

the best way to solve this problem is via the GPO

all you have to do is add the INTERACTIVE group to the Administrators group via
     Computer Configuration \ Windows Settings \ Restricted Groups policy

the INTERACTIVE group is a group of which everyone who logs on is automatically a member, in other words: everyone who logs on locally on a specific workstation becomes a local admin (only on this workstation, not on the entire domain, so administrative shares on other workstations cannot be accessed this way)

this way, you cannot define on a user base who is local admin, and who is not, you can however define it on a workstation base
Commented:
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.