Solo Pascual
asked on
Forced to give admin rights to users in W2K Pro
Forced to give admin rights to users in W2K Pro because the our corporate image uses only one partition which becomes then the system partition. Some programs will not run unless they have write access to the system partition. Also, if users want to temporarily save any files on their hardrive, they have to have write access to it. Has anyone else faced this dilema? Does anyone have any ideas as to how to best solve this problem?
thanks, for your ideas.
thanks, for your ideas.
Not knowing your situation or how many boxes you need to manage...
Are you on an NT domain? Are you giving them admin rights to their own boxes? Or on the domain?
They SHOULD have admin rights to their own boxes, or at least we give them that here. This DOESN'T give them any admin rights on the domain, of course.
If this is what you are wanting, then they need to add their domain name to the local admins group
log in as admin on the local box
Right click on My Computer
go to Manage
under "System Tool" in the left window, select "Local Users and Groups"
select the "Groups" folder
double click "Administrators"
add the local user from the domain so it reads:
<local domain>\<local user>
In our office, each user is responsible for their own machine so we let them add themselves thus I don't know a way to push this process over the network. Maybe someone knows how this may be done?
Are you on an NT domain? Are you giving them admin rights to their own boxes? Or on the domain?
They SHOULD have admin rights to their own boxes, or at least we give them that here. This DOESN'T give them any admin rights on the domain, of course.
If this is what you are wanting, then they need to add their domain name to the local admins group
log in as admin on the local box
Right click on My Computer
go to Manage
under "System Tool" in the left window, select "Local Users and Groups"
select the "Groups" folder
double click "Administrators"
add the local user from the domain so it reads:
<local domain>\<local user>
In our office, each user is responsible for their own machine so we let them add themselves thus I don't know a way to push this process over the network. Maybe someone knows how this may be done?
jhance -
I am trying to understand the process you mention. Can you offer a step-by-step? This might actually help us with an issue WE are having here.
I am trying to understand the process you mention. Can you offer a step-by-step? This might actually help us with an issue WE are having here.
What don't you follow? I'm just saying that in WinNT/2000 ANY securable object can have a DACL. This is essentially a list of WHO can do WHAT to it. I'm sure you've done this, perhaps without knowing it. The permissions properties for a file or folder is an example of something that brings up the "DACL Editor". Here you are presented with a list of local and DOMAIN (if applicable) users and groups and can assign a specific permission (or revoke a default permission) to any degree you like.
The simplest way to approach this is to deal with users on a group basis. That prevents you from having to set and maintain rights to an object for every possible user on the system. Note that users can be a member of multiple groups and this is a very convenient thing.
The simplest way to approach this is to deal with users on a group basis. That prevents you from having to set and maintain rights to an object for every possible user on the system. Note that users can be a member of multiple groups and this is a very convenient thing.
Let me give you a scenario. I don't know if this applies but I suspect it's related (losqados will let us know).
We have a number of people with Win2K boxes. We are running a logon script that will push AV software (and some other monitoring software) to each box. If the user logs into the domain, they do not have admin rights on the domain so the script does not run as an admin logging into the box - thus the application doesn't install (needs admin rights to install). To resolve this, we simply set each user as their local admin (as I described above).
If we didn't want people to have local admin rights, how would one go about installing the app with the logon script? I presume you can give permissions to the program somehow but how?
We have a number of people with Win2K boxes. We are running a logon script that will push AV software (and some other monitoring software) to each box. If the user logs into the domain, they do not have admin rights on the domain so the script does not run as an admin logging into the box - thus the application doesn't install (needs admin rights to install). To resolve this, we simply set each user as their local admin (as I described above).
If we didn't want people to have local admin rights, how would one go about installing the app with the logon script? I presume you can give permissions to the program somehow but how?
Admin rights to the domain are unrelated to admin rights on the workstation. The usual solution is to add users domain accounts to the local administrator group on the workstation.
If this is not an option, you should explore one of the secure software rollout and installation utilities that operate on the local machine via a service account.
The only way for a "program" to have right other than those owned by the account running the program is to use the LogonUser() API from within the appliation. But to use this requires a logon id and password and this is a significant security issue. The service approach is best.
If I'm not mistaken, the W2K Server Resource Kit has some utilities for doing this. If you are managing W2K Servers and clients you really should have this RESKIT.
If this is not an option, you should explore one of the secure software rollout and installation utilities that operate on the local machine via a service account.
The only way for a "program" to have right other than those owned by the account running the program is to use the LogonUser() API from within the appliation. But to use this requires a logon id and password and this is a significant security issue. The service approach is best.
If I'm not mistaken, the W2K Server Resource Kit has some utilities for doing this. If you are managing W2K Servers and clients you really should have this RESKIT.
Thanks. I am helping out the "official MIS" folks until they take me into their fold (and their budget) next quarter. *L* Until then, I have only my own feeble training and experience to guide me...as well as EE folks!
I did the first suggestion (adding the users to the local admin group) but I am sure some companies may not want to do this for security reasons (like keeping people from installing home software on their box). This might be akin to what this thread is about.
I presume our MIS has the RESKIT for Win2K. I'll check it out to see what it offers.
I did the first suggestion (adding the users to the local admin group) but I am sure some companies may not want to do this for security reasons (like keeping people from installing home software on their box). This might be akin to what this thread is about.
I presume our MIS has the RESKIT for Win2K. I'll check it out to see what it offers.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Great answer
The above answers is totally wrong, because for an ordinay Domain User, it makes all his colleagues able to have total power of his pc from their own Windows 2000 pc
And You dont see anything, while Your colleague from his own computer, can read/delete/modify/create files and documents and anything else with all of Your hard disc in his own Explorer.
Why is it so?
If Your Company uses Windows 2000 on a NT-network, and Your IT-System administrator have given You permission to install programs on Your own hard disc, then anybody of Your colleagues can do what they like with Your hard disc, and it happens from their own computer, and You dont see anything, while it happens.
And You can do anything You like with Your colleagues hard discs.
Do You believe it?
Is it a security hole in Windows?
Coming any hotfix from Microsoft?
Can Your IT- System administrator fix this with policy?
Can Your IT- System administrator fix this by allowing DomainUsers 2 hours in GlobalGroups while they install programs?
The answer to these questions is NO!
This is how to do if Youre NOT an IT-System administrator:
1. Choose Start / Run
2. Input \\ComputerName\C$ and press ENTER
3. As ComputerName You must choose on of Your colleagues ComputerName
4. Exit Explorer (without doing anything), and contact Your IT-System administrator.
If You dont know Your colleagues ComputerNames, then do this:
Choose Start / Run
Input CMD and press ENTER
Input NET VIEW and press ENTER
Input EXIT and press ENTER
Please dont destroy anything on Your colleagues hard disc, it could happen to Yourself. Please contact Your IT-System administrator, and ask him to solve this problem.
This is how to do, if You are the IT-System-administrator (2 choices):
1. Remove every other than Local Administrator and Domain Admins from Local Admin Group, and make different passwords on Local Administrator on each computer on Your network. Make sure to lock Your list of these passwords in Your safety box, making it possible to logon the computer, if the network fails on the computer.
Then add the Domain User, who daily uses each computer, to Local Admin Group, and make sure, that he is not in any other Local Admin Group on a computer in Your Companys network.
Make sure, if a colleague suddenly has to use the computer, that You removes the first Domain User, and adds 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 computer, he uses each day.
You must pay attention on all computers on Your network. Remember to check all Local Admin Group's a couple of times each year.
With this annoying work from You, Your users can install programs and defrag their hard disc, without being able to gain access to each others hard discs.
2. Remove every other than Local Administrator and Domain Admins from Local Admin Group, and make different passwords on Local Administrator on each computer on Your network. Make sure to lock Your list of these passwords in Your safety box, making it possible to logon the computer, if the network fails on the computer.
Make sure to remove all Domain Groups on all Local Admin Groups (but not the Domain Admins Group), if You had some, to grant to Domain Users for som hours, while they install programs.
With this annoying work from You, Your users cannot install programs and cannot defrag their hard disc, and the cannot gain access to each others hard discs.
You must install all programs on each computer on Your network, as Your users time to another must have installed. And You must defrag all the computers on Your network, when its necessary.
All this is a problem because Microsoft created the Windows 2000 operating system this way. Read more about it on http://support.microsoft.com/?kbid=182734
If You choose to follow Microsofts recommendations, it the same as choosing my second explanation above.
Many Regards
Jorgen Malmgren
IT-supervisor
Denmark
And You dont see anything, while Your colleague from his own computer, can read/delete/modify/create files and documents and anything else with all of Your hard disc in his own Explorer.
Why is it so?
If Your Company uses Windows 2000 on a NT-network, and Your IT-System administrator have given You permission to install programs on Your own hard disc, then anybody of Your colleagues can do what they like with Your hard disc, and it happens from their own computer, and You dont see anything, while it happens.
And You can do anything You like with Your colleagues hard discs.
Do You believe it?
Is it a security hole in Windows?
Coming any hotfix from Microsoft?
Can Your IT- System administrator fix this with policy?
Can Your IT- System administrator fix this by allowing DomainUsers 2 hours in GlobalGroups while they install programs?
The answer to these questions is NO!
This is how to do if Youre NOT an IT-System administrator:
1. Choose Start / Run
2. Input \\ComputerName\C$ and press ENTER
3. As ComputerName You must choose on of Your colleagues ComputerName
4. Exit Explorer (without doing anything), and contact Your IT-System administrator.
If You dont know Your colleagues ComputerNames, then do this:
Choose Start / Run
Input CMD and press ENTER
Input NET VIEW and press ENTER
Input EXIT and press ENTER
Please dont destroy anything on Your colleagues hard disc, it could happen to Yourself. Please contact Your IT-System administrator, and ask him to solve this problem.
This is how to do, if You are the IT-System-administrator (2 choices):
1. Remove every other than Local Administrator and Domain Admins from Local Admin Group, and make different passwords on Local Administrator on each computer on Your network. Make sure to lock Your list of these passwords in Your safety box, making it possible to logon the computer, if the network fails on the computer.
Then add the Domain User, who daily uses each computer, to Local Admin Group, and make sure, that he is not in any other Local Admin Group on a computer in Your Companys network.
Make sure, if a colleague suddenly has to use the computer, that You removes the first Domain User, and adds 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 computer, he uses each day.
You must pay attention on all computers on Your network. Remember to check all Local Admin Group's a couple of times each year.
With this annoying work from You, Your users can install programs and defrag their hard disc, without being able to gain access to each others hard discs.
2. Remove every other than Local Administrator and Domain Admins from Local Admin Group, and make different passwords on Local Administrator on each computer on Your network. Make sure to lock Your list of these passwords in Your safety box, making it possible to logon the computer, if the network fails on the computer.
Make sure to remove all Domain Groups on all Local Admin Groups (but not the Domain Admins Group), if You had some, to grant to Domain Users for som hours, while they install programs.
With this annoying work from You, Your users cannot install programs and cannot defrag their hard disc, and the cannot gain access to each others hard discs.
You must install all programs on each computer on Your network, as Your users time to another must have installed. And You must defrag all the computers on Your network, when its necessary.
All this is a problem because Microsoft created the Windows 2000 operating system this way. Read more about it on http://support.microsoft.com/?kbid=182734
If You choose to follow Microsofts recommendations, it the same as choosing my second explanation above.
Many Regards
Jorgen Malmgren
IT-supervisor
Denmark
>>The above answers is totally wrong
You're a bit late and a lot unoriginal. This SOUND advice was already given and IGNORED!
Just be glad this clown is not working for you or your organization!
You're a bit late and a lot unoriginal. This SOUND advice was already given and IGNORED!
Just be glad this clown is not working for you or your organization!
Well - I'm a little late, because I registered on Experts Exchange to day.
And I did read Your advice of 09/19/2001 09:15 that "Admin rights to the domain are unrelated to admin rights on the workstation. The usual solution is to add users domain accounts to the local administrator group on the workstation."
But apparantly You did not read my answer. If You did, You would have noticed, that "adding users domain accounts to the local administrator group" is a very bad solution, because it makes it possible for Domain Users to gain total power of other DomainUsers hard disc using \\ComputerName\C$
And I did read Your advice of 09/19/2001 09:15 that "Admin rights to the domain are unrelated to admin rights on the workstation. The usual solution is to add users domain accounts to the local administrator group on the workstation."
But apparantly You did not read my answer. If You did, You would have noticed, that "adding users domain accounts to the local administrator group" is a very bad solution, because it makes it possible for Domain Users to gain total power of other DomainUsers hard disc using \\ComputerName\C$
I disagree! Local Admins have ABSOLUTELY no rights on other machines. Local is just that, local.
If a local admin on one workstation were able to gain total power over a remote share via the C$ administrative share, then ANY user could do the same thing.
If a local admin on one workstation were able to gain total power over a remote share via the C$ administrative share, then ANY user could do the same thing.
It depends on how You add the DomainUser to the LocalAdminGroup
Suppose You got 500 w2k-clients and 500 w2k-DomainUsers:
Do You add each DomainUser to the one and only LocalAdminGroup the DomainUser uses?
Or do You add a DomainGroup to each LocalAdminGroup on all the 500 w2k-clients?
Suppose You got 500 w2k-clients and 500 w2k-DomainUsers:
Do You add each DomainUser to the one and only LocalAdminGroup the DomainUser uses?
Or do You add a DomainGroup to each LocalAdminGroup on all the 500 w2k-clients?
It depends on what you're trying to accomplish.
I generally add users to the local admin group on their (and ONLY their) workstation. They should NOT be local admin on ANY other workstation.
I generally add users to the local admin group on their (and ONLY their) workstation. They should NOT be local admin on ANY other workstation.
Do You have any DomainUsers using each others workstation sometimes, or do You have any workstation used by several DomainUsers each day?
Then I hope, that You remember to remove the DomainUser everytime they leaves the workstation, and checks, that they did not create a new local user, and made this one member of the LocalAdminGroup while having the access to do it. If they did, they still can use \\computername\c$ from their own workstatin after You removed them.
As You can se, this is very troublesome with 500 or more workstations. Are You sure, that every LocalAdminGroup are safe?
Then I hope, that You remember to remove the DomainUser everytime they leaves the workstation, and checks, that they did not create a new local user, and made this one member of the LocalAdminGroup while having the access to do it. If they did, they still can use \\computername\c$ from their own workstatin after You removed them.
As You can se, this is very troublesome with 500 or more workstations. Are You sure, that every LocalAdminGroup are safe?
Do You have any DomainUsers using each others workstation sometimes, or do You have any workstation used by several DomainUsers each day?
Then I hope, that You remember to remove the DomainUser everytime they leaves the workstation, and checks, that they did not create a new local user, and made this one member of the LocalAdminGroup while having the access to do it. If they did, they still can use \\computername\c$ from their own workstatin after You removed them.
As You can se, this is very troublesome with 500 or more workstations. Are You sure, that every LocalAdminGroup are safe?
Then I hope, that You remember to remove the DomainUser everytime they leaves the workstation, and checks, that they did not create a new local user, and made this one member of the LocalAdminGroup while having the access to do it. If they did, they still can use \\computername\c$ from their own workstatin after You removed them.
As You can se, this is very troublesome with 500 or more workstations. Are You sure, that every LocalAdminGroup are safe?
Sometimes I do but if they do that, they are "guests" and DO NOT have local admin rights.
Yes, I can see your side. If you have a large number of users and they share workstations it could be a nightmare from an admin point of view. It also depends on how much you permit users to do. If the company policy is NO UNAPPROVED INSTALLATIONS or CONFIG CHANGES, then by all means, lock 'em down. In my case, it's not that restrictive and users have a great deal of latitude over what then install and use. But then my environment is a very professional group where I'm not at all concerned about a lot of things that may be a big problem in another environment.
Yes, I can see your side. If you have a large number of users and they share workstations it could be a nightmare from an admin point of view. It also depends on how much you permit users to do. If the company policy is NO UNAPPROVED INSTALLATIONS or CONFIG CHANGES, then by all means, lock 'em down. In my case, it's not that restrictive and users have a great deal of latitude over what then install and use. But then my environment is a very professional group where I'm not at all concerned about a lot of things that may be a big problem in another environment.
The answer to "NO UNAPPROVED INSTALLATIONS" means that You have to use ManagementSystems, and install whatever neaded to each and every workstation.
In my oppinion, this problem is not known/solved in many W2k-installations, and more and more programs updates themselfes through internet-connection.
:o) Hope You informed Your professional users, that they are able to "sneak" on each others hard disc.
Many Regards
Jorgen Malmgren
IT-supervisor
Denmark
In my oppinion, this problem is not known/solved in many W2k-installations, and more and more programs updates themselfes through internet-connection.
:o) Hope You informed Your professional users, that they are able to "sneak" on each others hard disc.
Many Regards
Jorgen Malmgren
IT-supervisor
Denmark
>>that they are able to "sneak" on each others hard disc
No, they cannot do it. Local admin rights on one workstation DOES NOT provide it for others.
As I already said, your understanding of this process is incorrect.
No, they cannot do it. Local admin rights on one workstation DOES NOT provide it for others.
As I already said, your understanding of this process is incorrect.
:o) Sorry, I forgot to read Your answer:
"Sometimes I do but if they do that, they are "guests" and DO NOT have local admin rights."
I hope we agree, that my understanding of this issue is correct:
IF a DomainUser is member of LocalAdminGroup on more than one workstation on a Domain, they have total control over theese other workstations, where they are member of the LocalAdminGroup?
"Sometimes I do but if they do that, they are "guests" and DO NOT have local admin rights."
I hope we agree, that my understanding of this issue is correct:
IF a DomainUser is member of LocalAdminGroup on more than one workstation on a Domain, they have total control over theese other workstations, where they are member of the LocalAdminGroup?
Of course! Any user who is a local admin has TOTAL control over any workstation for which he is a local administrator. That's a GIVEN and IMHO, quite obvious.
What I'm saying is that giving users local admin group membership on THEIR OWN workstation DOES NOT compromise the security of any other workstation or server on the network.
What I'm saying is that giving users local admin group membership on THEIR OWN workstation DOES NOT compromise the security of any other workstation or server on the network.
:o) I'm happy we agree.
There is another issue maybee making this a problem for some it-sysadms, not aware of this problem:
Upgrading a W9x-workstation to W2k automatically adds all W9x user accounts to the LocalAdminGroup
There is another issue maybee making this a problem for some it-sysadms, not aware of this problem:
Upgrading a W9x-workstation to W2k automatically adds all W9x user accounts to the LocalAdminGroup
If you modify the DACLs for the objects that your users (who don't have admin group membership) then you will NOT have to add them to the admin group.
Your method is the "open the barn door" solution. Yes, it solves it but you end up giving users much more privilege than they need.
BTW, DACL is Discretionary Access Control List and you access it for file and folder objects by opening the properties on the object and choosing "PERMISSIONS".