Mark
asked on
Samba4, RSAT - setting Administrator privilege to users
I am running Samba4 4.1.11 on Slackware64 14.1, kernel 3.10.17. The host is configured as domain controller / Active Directory and for the most part works fine.
However, I would like domain users to be system administrators on their own workstations. It is quite a pain to log into their computers for simple things like updating installed software, or changing the workstation date/time. I really don't want to give out the domain administrator password!
In 'Active Directory Users and Computers' the user is a member of "Administrators":
Yet doing things like date/time setting, etc. prompts the user with the dialog "To continue, type an administrator password, and then click Yes."
When logged into this user's workstation as the Administrator and going to Control Panel > User Accounts > Manage User Accounts, the only user shown is the non-domain computer user (Domain 'holly' is the machine name).
What I would expect to see is User Name: hcarr, Domain: hprs.local, Group: Administrators. But of course, even the actual domain Administrator isn't listed here.
How can I accomplish this? Do I need to do something with a Group Policy? Add the user explicitly to the workstation with the hprs.local domain? There has to be a way to fix this.
However, I would like domain users to be system administrators on their own workstations. It is quite a pain to log into their computers for simple things like updating installed software, or changing the workstation date/time. I really don't want to give out the domain administrator password!
In 'Active Directory Users and Computers' the user is a member of "Administrators":
Yet doing things like date/time setting, etc. prompts the user with the dialog "To continue, type an administrator password, and then click Yes."When logged into this user's workstation as the Administrator and going to Control Panel > User Accounts > Manage User Accounts, the only user shown is the non-domain computer user (Domain 'holly' is the machine name).
What I would expect to see is User Name: hcarr, Domain: hprs.local, Group: Administrators. But of course, even the actual domain Administrator isn't listed here.How can I accomplish this? Do I need to do something with a Group Policy? Add the user explicitly to the workstation with the hprs.local domain? There has to be a way to fix this.
ASKER
Thank you for your "gentle" rebukes! :) This is a small office of trusted people. Their workstations timeout and require login after a period of inactivity. The non-domain administrator logins (e.g. hcarr/holly) are for use if/when the workstation is not on the network and that password is not the same as the user's domain password.
Making this user a member of domain built-in\administrators was an experiment and appears to have no effect at all. This user cannot do any admin functions.
These users are not likely to install keyloggers.
We are not going to implement software deployment -- we are not that strict about software users install on their workstations, nor do we have the sysadmin time available for implementing deployment schemes at this time. If rogue or suspect software appears, I remove it during occasional, routine checking of workstations. Again, small office of trusted people.
These users need local admin privilege for various reasons. For example, one user's workstation's date somehow reverted to 12 years ago. She was unable to reset the date and had issues that day with incorrect timestamps on documents and email. Many 3rd party software programs will not permit updating except by an administrator -- we had that problem with Adobe Standard for a while when the Administrator installed the software, but the user was solicited to install updates. Some software (Traverse) is old enough that user access to the Program Files folder is necessary. Upgrading FoxIT requires Admin priv., etc. The alternative is that I personally log into user's computers and do these things for them or, as you mentioned implement some kind of software distro mechanism. For a variety of reasons, that's not in the cards.
So, what do you recommend?
Note that I can manually add the domain user to the local user list as an Administrator and that does work. But, I would a) rather not manually do that on all workstations and b) rather this be centrally located in the AD. The former SBS 2008 AD did let me specify that users could be administrators of their own computer. Possibly this was a policy that SBS 2008 pre-setup, but is one I have to now manally configure for non-SBS DC/ADs.
Making this user a member of domain built-in\administrators was an experiment and appears to have no effect at all. This user cannot do any admin functions.
These users are not likely to install keyloggers.
We are not going to implement software deployment -- we are not that strict about software users install on their workstations, nor do we have the sysadmin time available for implementing deployment schemes at this time. If rogue or suspect software appears, I remove it during occasional, routine checking of workstations. Again, small office of trusted people.
These users need local admin privilege for various reasons. For example, one user's workstation's date somehow reverted to 12 years ago. She was unable to reset the date and had issues that day with incorrect timestamps on documents and email. Many 3rd party software programs will not permit updating except by an administrator -- we had that problem with Adobe Standard for a while when the Administrator installed the software, but the user was solicited to install updates. Some software (Traverse) is old enough that user access to the Program Files folder is necessary. Upgrading FoxIT requires Admin priv., etc. The alternative is that I personally log into user's computers and do these things for them or, as you mentioned implement some kind of software distro mechanism. For a variety of reasons, that's not in the cards.
So, what do you recommend?
Note that I can manually add the domain user to the local user list as an Administrator and that does work. But, I would a) rather not manually do that on all workstations and b) rather this be centrally located in the AD. The former SBS 2008 AD did let me specify that users could be administrators of their own computer. Possibly this was a policy that SBS 2008 pre-setup, but is one I have to now manally configure for non-SBS DC/ADs.
Hi.
Some comments:
"Making this user a member of domain built-in\administrators was an experiment and appears to have no effect at all. This user cannot do any admin functions" - believe me, he can. You should read at MS to realize what that group is able to do, https://technet.microsoft.com/en-us/library/cc756898(WS.10).aspx
"These users are not likely to install keyloggers" - it is by far better to feel good saying this than not to trust your users...nevertheless it only holds true until someone does. I would not advise you to trust your users since they cannot be as technically savvy as admins. And when they install malware, the malware acts as them, as local admins. And the end of story? You never know. So try to avoid it anytime you can.
"These users need local admin privilege for various reasons" - then consider your network a very special network. At our company, only some developers are granted local admin privs, all others don't need them. And those that get those privs get "caged" in virtual machines even. But I understand, it is not always that easy if we haven't got the time to plan it thoroughly.
About my recommendation: please answer the mentioned detail question
"whether:
-anyone should be admin on any client
-anyone should be admin on "his" client (if there is a fixed relation of person and machine)
-some people should be admins on more than one machine"
->when we know that, we can find a solution.
Some comments:
"Making this user a member of domain built-in\administrators was an experiment and appears to have no effect at all. This user cannot do any admin functions" - believe me, he can. You should read at MS to realize what that group is able to do, https://technet.microsoft.com/en-us/library/cc756898(WS.10).aspx
"These users are not likely to install keyloggers" - it is by far better to feel good saying this than not to trust your users...nevertheless it only holds true until someone does. I would not advise you to trust your users since they cannot be as technically savvy as admins. And when they install malware, the malware acts as them, as local admins. And the end of story? You never know. So try to avoid it anytime you can.
"These users need local admin privilege for various reasons" - then consider your network a very special network. At our company, only some developers are granted local admin privs, all others don't need them. And those that get those privs get "caged" in virtual machines even. But I understand, it is not always that easy if we haven't got the time to plan it thoroughly.
About my recommendation: please answer the mentioned detail question
"whether:
-anyone should be admin on any client
-anyone should be admin on "his" client (if there is a fixed relation of person and machine)
-some people should be admins on more than one machine"
->when we know that, we can find a solution.
ASKER
whether: anyone should be admin on any clientNo
anyone should be admin on "his" client (if there is a fixed relation of person and machine)Yes
-some people should be admins on more than one machine"No. There is a fixed relationship between user and machine. The user only has to be admin on their own workstation. If user needs to log on to not-their-own-workstations
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I find little in the DC/AD world "easy". I'll try a variation on that script. The DC/AD is Samba4 on Linux, but the samba-tool facility should be able to do this. I'll post back.
... because this should not be done in the first placeOK, point taken ... trusted users, no developers ... moving on ...
ASKER
OK, I've sorted some things out. First of all, your script runs on the workstation, not the DC. That had me a bit confused. Next issue:
Then simply add the following line to your domain startup script ...Where is the "domain startup script"? This link says it is stored in a GPO: https://technet.microsoft.com/en-us/magazine/dd630947.aspx, unless that is describing something entirely different. But you say, "there is no domain GPO for this." So, please straighten me out.
"First of all, your script runs on the workstation, not the DC" - I wrote "domain startup script". That means, it is running at the startup of all clients and needs to be deployed via domain GPO.
"But you say, "there is no domain GPO for this." So, please straighten me out." - sure. For your settings, there is no GPO. So you need to script it AND that script can be deployed via GPO.
"But you say, "there is no domain GPO for this." So, please straighten me out." - sure. For your settings, there is no GPO. So you need to script it AND that script can be deployed via GPO.
ASKER
I plan on testing this this evening. Having trouble coordinating times.
ASKER
Getting back to this ... getting more needful.
Script: I'm going to keep it simple and create a single script for a single workstation to test. Using your example script, I think the following is what I need to make user 'joe' an administrator on the machine where the script is run.
net localgroup /add administrators joe
I've tested this command running cmd as Administrator and it seemed to work ("The command completed successfully."), but I was still prompted for administrator credentials when I tried, for example, to 'Uninstall or change a program'. So, I'm a bit skeptical, but willing to move on.
As to deploying a script via GPO, that's new territory for me. I've come across instructions various places. See if this is right:
Group Policy Management > right click domain > Create a GPO in this domain and link it here > right click new GPO > Edit (Opens Group Policy Management Editor) > User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff) > double-click Logon > click 'Scripts' tab > Add
here, I'm stuck. (see image). What goes in "name" and "parameters"? Do I embed the script somewhere? Does it go in a particular folder?
Clicking 'Show files' gives me the folder: \\hprs.local\SysVol\hprs.l
As I'm writing this, I'm beginning to think that this script DOES NOT reside on the local workstations, but on the AD server ... and furthermore, it will be run for ALL users loging into ALL workstations on the domain, right? Hence your \\server\share\admins.txt file of users and computers.
Am I heading it the right direction? This is the first time I've tried creating any kind of GPO script.
localAdmin.jpg
Script: I'm going to keep it simple and create a single script for a single workstation to test. Using your example script, I think the following is what I need to make user 'joe' an administrator on the machine where the script is run.
net localgroup /add administrators joe
I've tested this command running cmd as Administrator and it seemed to work ("The command completed successfully."), but I was still prompted for administrator credentials when I tried, for example, to 'Uninstall or change a program'. So, I'm a bit skeptical, but willing to move on.
As to deploying a script via GPO, that's new territory for me. I've come across instructions various places. See if this is right:
Group Policy Management > right click domain > Create a GPO in this domain and link it here > right click new GPO > Edit (Opens Group Policy Management Editor) > User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff) > double-click Logon > click 'Scripts' tab > Add
here, I'm stuck. (see image). What goes in "name" and "parameters"? Do I embed the script somewhere? Does it go in a particular folder?
Clicking 'Show files' gives me the folder: \\hprs.local\SysVol\hprs.l
As I'm writing this, I'm beginning to think that this script DOES NOT reside on the local workstations, but on the AD server ... and furthermore, it will be run for ALL users loging into ALL workstations on the domain, right? Hence your \\server\share\admins.txt file of users and computers.
Am I heading it the right direction? This is the first time I've tried creating any kind of GPO script.
localAdmin.jpg
jmarkfoley, you finally started.
The command "net localgroup /add administrators joe" cannot be used. You should use my startup script in a GPO and, for a test, assign that GPO to a test OU with one computer inside (for example "testpc").
What you did is heading for a logon script. Logon scripts run in the privilege context of users, while startup scripts use the computer account (=system account aka computername$). Logon scripts cannot be used.
So do as I told you, put a text fileadmins.txt on \\server\share and write inside
testuser1 testpc1
then write that line
To configure a startup script, use this guide: https://technet.microsoft.com/en-us/library/cc770556.aspx?
The command "net localgroup /add administrators joe" cannot be used. You should use my startup script in a GPO and, for a test, assign that GPO to a test OU with one computer inside (for example "testpc").
What you did is heading for a logon script. Logon scripts run in the privilege context of users, while startup scripts use the computer account (=system account aka computername$). Logon scripts cannot be used.
So do as I told you, put a text fileadmins.txt on \\server\share and write inside
testuser1 testpc1
then write that line
for /f %%a in ('findstr /i /E %computername% \\server\share\admins.txt') do net localgroup /add administrators %%aTo configure a startup script, use this guide: https://technet.microsoft.com/en-us/library/cc770556.aspx?
ASKER
I've created the \\DC\share folder, given appropriate permissions and created a localadmins.txt file with:
common mark
where "common" is the workstation name and "mark" is the user to be local sysadmin.
You link, step 1, says: "Open the Local Group Policy Editor.". Stuck again. I've never just "opened" the group policy editor just like that. I've always right-clicked on an existing policy and selected 'edit'. I've clicked on File, Action, View, Window and don't see an 'Open Editor' option. I've googled, no luck. How do I do this?
common mark
where "common" is the workstation name and "mark" is the user to be local sysadmin.
You link, step 1, says: "Open the Local Group Policy Editor.". Stuck again. I've never just "opened" the group policy editor just like that. I've always right-clicked on an existing policy and selected 'edit'. I've clicked on File, Action, View, Window and don't see an 'Open Editor' option. I've googled, no luck. How do I do this?
Just edit a GPO like you always do, don't worry.
ASKER
OK, I arbitrarily selected 'Default Domain Controllers Policies', right clicked on that and edited, but this doesn't "feel" right (you're sure I don't have to create a new policy for this?) I put the script in Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown) > Startup. I clicked Browse to see where the dialog is expecting to find the script. It was in: \\hprs.local\sysvol\hprs.l
for /f %%a in ('findstr /i /E %computername% \\mail.hprs.local\share\loca
Now what? Does the workstation have to be rebooted for this to work? Simply logging off/on does not seem to work. Is there a way to log possible script errors?
for /f %%a in ('findstr /i /E %computername% \\mail.hprs.local\share\loca
Now what? Does the workstation have to be rebooted for this to work? Simply logging off/on does not seem to work. Is there a way to log possible script errors?
Take a new policy. Yours is for domain controllers, not for clients. Yes, reboot the test client.
ASKER
First off, let's get explicit. Do I create a new GPO or start with an existing GPO?
Neither our discussion nor your link are clear on that. The link simply says, "1. Open the Local Group Policy Editor", which, as far as my knowledge extends, can only be done once an existing GPO has been selected.
If I should open the Editor via an existing policy, which one? Obviously my choice of "Default Domain Controllers Policy" was a bad guess. The attached images show the policies I have configured.
GPOs.jpg
Neither our discussion nor your link are clear on that. The link simply says, "1. Open the Local Group Policy Editor", which, as far as my knowledge extends, can only be done once an existing GPO has been selected.
If I should open the Editor via an existing policy, which one? Obviously my choice of "Default Domain Controllers Policy" was a bad guess. The attached images show the policies I have configured.
GPOs.jpg
We are talking about a test. For tests, you create a test OU, and move the client into it. Linked to that OU, you will then create a test policy and within create that startup script. Sorry, I didn't know this wouldn't be clear. If that link talks about a local policy while we are talking about a domain policy, there still is no difference for the result, both do the same, both are ok for testing. So you can use the local group policy editor (gpedit.msc is the command to start it), or use a domain GPO.
ASKER
Let's see if I've got the procedure straight:
Create OU: Administrative Tools > Group Policy Management > (expand) Domain > (expand) hprs.local > righ-click hprs.local > New Organizational Unit. I'll call it "HPRS Local Admin".
Create policy: right-click "HPRS Local Admin" OU > Create a GPO in this domain and Link it here. I named the new GPO "HPRS Local Admin Policy".
Edit Policy: right-click on "HPRS Local Admin Policy" GPO > Edit > Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown) > Startup > Add > Browse.
The 'Browse' button looks in the folder \\hprs.local\SysVol\hprs.l
I also removed the script from 'Default Domain Controllers Policies' startup scripts (created previous during the course of this question).
It that it? Probably not. I restarted the test workstation (common) and the user designated in the localadmins.txt file is not logging in as an adminstrator.
The localadmins.txt file is located in \\mail.hprs.local\share. It contains:
common mark
mike mpress
where the 1st token is the computer name and the 2nd token is the user to become Administrator.
My script, addadmins.bat, is:
Create OU: Administrative Tools > Group Policy Management > (expand) Domain > (expand) hprs.local > righ-click hprs.local > New Organizational Unit. I'll call it "HPRS Local Admin".
Create policy: right-click "HPRS Local Admin" OU > Create a GPO in this domain and Link it here. I named the new GPO "HPRS Local Admin Policy".
Edit Policy: right-click on "HPRS Local Admin Policy" GPO > Edit > Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown) > Startup > Add > Browse.
The 'Browse' button looks in the folder \\hprs.local\SysVol\hprs.l
I also removed the script from 'Default Domain Controllers Policies' startup scripts (created previous during the course of this question).
It that it? Probably not. I restarted the test workstation (common) and the user designated in the localadmins.txt file is not logging in as an adminstrator.
The localadmins.txt file is located in \\mail.hprs.local\share. It contains:
common mark
mike mpress
where the 1st token is the computer name and the 2nd token is the user to become Administrator.
My script, addadmins.bat, is:
echo hello >\\mail.hprs.local\share\testing.txt
for /f %%a in ('findstr /i /E %computername% \\mail.hprs.local\share\localadmins.txt') do net localgroup /add administrators %%a
You did right.
Please check:
-is the test Computer common (and mike) in the newly created OU?
-is the test Computer Windows 8.x? If yes, you ned to disable fast Startup.
-has the group authorized users write access on both the share permissions and the NTFS permissions?
(besides: NEVER give someone write access to something that's part of a script. NEVER. Because they could modify the commands and gain administrative access). But that doesn't matter here because it's just a test.
Please check:
-is the test Computer common (and mike) in the newly created OU?
-is the test Computer Windows 8.x? If yes, you ned to disable fast Startup.
-has the group authorized users write access on both the share permissions and the NTFS permissions?
(besides: NEVER give someone write access to something that's part of a script. NEVER. Because they could modify the commands and gain administrative access). But that doesn't matter here because it's just a test.
ASKER
-is the test Computer common (and mike) in the newly created OU?No. I followed some web instructions on doing this: Active Directory Computers and Users > computers; drag COMMON to 'HPRS Local Admins' OU. Is that right? I backed this out because it removed the COMMON workstation from the 'Computers' OU, which I'm not sure is what I want. That seems like it would break other things. Please advise.
-is the test Computer Windows 8.x? If yes, you ned to disable fast Startup.No, WIN7
-has the group authorized users write access on both the share permissions and the NTFS permissions?I believe so. As Administrator on COMMON I used Windows Explorer to navigate to mail.hprs.local, right-clicked on the newly created 'share' folder > Security > Everyone > Allow full control. As you noted, I'll worry about universal 'Modify' permission later.
btw - this procedure is getting wildly complex ...
If the test policy is linked to the OU 'HPRS Local Admins' but the computers are not inside, no wonder it does not get applied. It will not break anything to move it.
Then: did you check both the share- and the NTFS-permissions? Both need to let the group authorized users modify that shared folder. What you describe are the NTFS permissions.
Then: did you check both the share- and the NTFS-permissions? Both need to let the group authorized users modify that shared folder. What you describe are the NTFS permissions.
ASKER
If the test policy is linked to the OU 'HPRS Local Admins' but the computers are not inside, no wonder it does not get applied. It will not break anything to move it.OK, will try that and see. Apparently, all workstations will end up the the 'HPRS Loal Admin' OU, right?
did you check both the share- and the NTFS-permissions? Both need to let the group authorized users modify that shared folder. What you describe are the NTFS permissions.Where are the 'share' permissions? I've shared volumes before, but not folders. Right-clicking on the \\mail.hprs.local\share folder does not show a 'Share' option. Typing 'Share' in the command bar after selecting the share folder gives me a message about enabling workgroups.
Nevertheless - non-admin users are, in fact, able to modify files in this folder, so perhaps it is already shared.
After moving the COMMON computer to the OU and rebooting, I did get a message in \\mail.hprs.local\share\te
COMMON mark
Now the echo gives me: "COMMON COMMON$", and I still don't have admin priv. My current .bat file:
echo %computername% %USERNAME% > \\mail.hprs.local\share\testing.txt
for /f %%a in ('findstr /i /E %computername% \\mail.hprs.local\share\localadmins.txt') do net localgroup /add administrators %%aASKER
more info ... working!!!!
I noticed that I had the username and computername reversed in my localadmins.txt file (the /E switch on the findstr command). I switched them around and now it appears to work. User 'mark' has admin access on workstation COMMON.
I'll experiment a bit more and post back.
I noticed that I had the username and computername reversed in my localadmins.txt file (the /E switch on the findstr command). I switched them around and now it appears to work. User 'mark' has admin access on workstation COMMON.
I'll experiment a bit more and post back.
ASKER
Hmmm, well I've tried another user on another computer; localadmins.txt is:
mark COMMON
doris DORIS
I've moved computer DORIS to the 'HPRS Loca Amin' OU. I've rebooted DORIS, but when I log in as user doris, no admin priv. The script is running because I get the computer name in the echo message, but apparently some part of the script is failing. How can I trap error codes or messages out of this script, or otherwise debug?
mark COMMON
doris DORIS
I've moved computer DORIS to the 'HPRS Loca Amin' OU. I've rebooted DORIS, but when I log in as user doris, no admin priv. The script is running because I get the computer name in the echo message, but apparently some part of the script is failing. How can I trap error codes or messages out of this script, or otherwise debug?
To see what is going on, do it like this:
1 download pstools from microsoft. It contains psexec.exe
2 on "Doris" open an elevated command prompt (by rightclicking cmd.exe and selecting "run as administrator") and start the following:
psexec -s -i cmd
3 on the newly appearing command prompt (which runs as system account), launch your batch, so enter
\\hprs.local\SysVol\hprs.l
and see what output comes.
1 download pstools from microsoft. It contains psexec.exe
2 on "Doris" open an elevated command prompt (by rightclicking cmd.exe and selecting "run as administrator") and start the following:
psexec -s -i cmd
3 on the newly appearing command prompt (which runs as system account), launch your batch, so enter
\\hprs.local\SysVol\hprs.l
and see what output comes.
ASKER
Results:
user-doris.jpg
C:\Windows\system32>\\hprs.local\SysVol\hprs.local\Policies\{BCA8FAF8-6904-44C4-
9D32-28400BE61028}\Machine\Scripts\Startup\addadmins.bat
C:\Windows\system32>echo DORIS 1>\\mail.hprs.local\share\testing.txt
C:\Windows\system32>for /F %a in ('findstr /I /E DORIS \\mail.hprs.local\share\localadmins.txt') do net localgroup /add administrators %a
C:\Windows\system32>net localgroup /add administrators doris
System error 1317 has occurred.
The specified account does not exist.user-doris.jpg
Ah, ok.
Problem: the user doris does not exist locally but is a domain user. You would have to modify the batch file slightly:
Problem: the user doris does not exist locally but is a domain user. You would have to modify the batch file slightly:
for /f %%a in ('findstr /i /E %computername% \\mail.hprs.local\share\localadmins.txt') do net localgroup /add administrators mail.hprs.local\%%aASKER
Will try that when the user leaves this afternoon.
Do I want mail.hprs.local\%%a as you've shown or just hprs.local\%%a? Seems like normally when I reference the domain\user I don't include the DC hostname.
Do I want mail.hprs.local\%%a as you've shown or just hprs.local\%%a? Seems like normally when I reference the domain\user I don't include the DC hostname.
My bad. Just your domain, be it FQDN notation or netbios domain name, so make it hprs.local
ASKER
Yup! That did the trick!!
Looking back over this question, this is a fairly elaborate and complex solution; at least to people not well versed in domain GPO scripting - which includes me, obviously, but likely my eventual successor who will have no knowledge of this process unless he/she is proactive about looking for my documentation.
Before calling this potato baked, I'd like your opinion, as objectively as possible ...
Why is the procedure we have assembled herein a better way of accomplishing this "local admin" objective than simply creating a local user account on each workstation as HPRS\%username% and making that account an administrator? That seems rather intuitive to non-AD gurus and is the route I had naturally taken before making this post. I do have one workstation and user configured that way and if that user remote-connects to another workstation that user is not admin on the target workstation.
Thanks
Looking back over this question, this is a fairly elaborate and complex solution; at least to people not well versed in domain GPO scripting - which includes me, obviously, but likely my eventual successor who will have no knowledge of this process unless he/she is proactive about looking for my documentation.
Before calling this potato baked, I'd like your opinion, as objectively as possible ...
Why is the procedure we have assembled herein a better way of accomplishing this "local admin" objective than simply creating a local user account on each workstation as HPRS\%username% and making that account an administrator? That seems rather intuitive to non-AD gurus and is the route I had naturally taken before making this post. I do have one workstation and user configured that way and if that user remote-connects to another workstation that user is not admin on the target workstation.
Thanks
Initially, you wrote "I would like domain users to be system administrators on their own workstations" - which is what we did. The way involves establishing a one line startup script, so the effort is minimal. (You'll not have to move the workstations to another OU, but simply move your policy).
Doing it manually one way or the other is more effort - normally. If you look at what GPOs offer: they don't offer that functionality at all.
What you introduce now, "simply creating a local user account on each workstation as HPRS\%username% and making that account an administrator" is something totally different, as it involved using different accounts for working and admin-usage (which is a good-thing, security-wise). But even that would have to be done manually (and I don't know how many computers we are talking about, I thought not only some).
Doing it manually one way or the other is more effort - normally. If you look at what GPOs offer: they don't offer that functionality at all.
What you introduce now, "simply creating a local user account on each workstation as HPRS\%username% and making that account an administrator" is something totally different, as it involved using different accounts for working and admin-usage (which is a good-thing, security-wise). But even that would have to be done manually (and I don't know how many computers we are talking about, I thought not only some).
ASKER
What you introduce now, "simply creating a local user account on each workstation as HPRS\%username% and making that account an administrator" is something totally different,In the course of our experimentation, I tried this idea as a solution before we came up with the startup script idea, but it did work.
Now that I have a working script, it is rather simple to move the user's workstation to the 'HPRS Local Admins' OU and add the user/computer to the addadmins.bat, but it was a lot of work getting there. On the other hand there are only 10 user workstations in this domain, and each new or upgraded workstations is hand-configured with Office and other add-ons (no auto-deployment), so setting the primary user's domain account to Administrator is not that big a deal while in there.
So, I guess I need to weight the respective efforts involves and particularly the ease of comprehension by someone other than me.
In any case, this was a great exercise. I learned a lot. Many thanks for your time and knowledge.
ASKER
Excellent solution. I hope McKnife responds to my future GPO issues, very knowledgeable!
You are welcome.
What you are planning to do, to make anyone admin on his own machine, is a dangerous thing. As soon as you logon to their machines for any service - can you be sure they did not already install keyloggers to get your password? They cannot install keyloggers without administrative rights.
Doing that can be justified with your reasons, but never, for security's sake, should one need to do that. Better approach would be to establish software deployment. You could centrally deploy the updates or use software assignment, if you want people to be able to on-demand-install things.
The user hcarr is a local account. You have setup a local account, not a domain account. Undo that.
Then: to make people admins on their machines, you would first have to chose whether:
-anyone should be admin on any client
-anyone should be admin on "his" client (if there is a fixed relation of person and machine)
-some people should be admins on more than one machine
->when we know that, we can find a solution.
Finally: if you are not sure what you are doing, get someone to help you. Forums are not the way. These errors suggest that you might already have done a lot of things without knowing.