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":
AD, Administrators groupYet 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).
Workstation Manage UsersWhat 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.
LVL 1
jmarkfoleyAsked:
Who is Participating?
 
McKnifeCommented:
Alright. You will be able to script-solve this, there is no domain GPO for this.
You need to setup a list file (make it \\server\share\admins.txt) and make it look like
user1 computer1
user2 computer2
(or JohnDoe JohnDoesPC)
...

Then simply add the following line to your domain startup script:
for /f %%a in ('findstr /i /E %computername% \\server\share\admins.txt') do net localgroup /add administrators %%a

Open in new window

This will work, unless your list happens to look like (for example)

user1 computer1
user2 labcomputer1
...

That's because the findstr /E command looks at the end of the line. Now imagine that script would execute on computer1: user1 AND user2 would both get added to the admin group of computer1, which is not desirable. So see if that works out with your naming conventions or we'll have to do something else.

The reason why this is all but easy is because this should not be done in the first place.
0
 
McKnifeCommented:
jmarkfoley, frankly, every security aware person would frown over what you are planning to do and even more about what you already did: you already made that person a member of built-in\administrators and therefore gave her full access to your domain. Undo that.

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.
0
 
jmarkfoleyAuthor Commented:
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.
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
McKnifeCommented:
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.
0
 
jmarkfoleyAuthor Commented:
whether: anyone should be admin on any client
No
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, it is for an unusual reason: someone needs to substitute at the front desk; their computer has crashed; their office is being painted; they need to run a special app on a COMMON workstations, etc. They do not need to be admins on the temporary-use workstations, only their own.
0
 
jmarkfoleyAuthor Commented:
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 place
OK, point taken ... trusted users, no developers ... moving on ...
0
 
jmarkfoleyAuthor Commented:
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.
0
 
McKnifeCommented:
"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.
0
 
jmarkfoleyAuthor Commented:
I plan on testing this this evening. Having trouble coordinating times.
0
 
jmarkfoleyAuthor Commented:
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.local\Policies\{7344B080-596C-4973-8731-9C89546F9FDF}\User\Scripts\Logon. Does the script go there? What file type? .BAT?

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
0
 
McKnifeCommented:
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
for /f %%a in ('findstr /i /E %computername% \\server\share\admins.txt') do net localgroup /add administrators %%a

Open in new window

into a batch file addadmins.bat and configure it as startup script, located in your test policies folder (like \\yourDC\sysVOL\yourdomain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Scripts\Startup\addadmins.bat
To configure a startup script, use this guide: https://technet.microsoft.com/en-us/library/cc770556.aspx?
0
 
jmarkfoleyAuthor Commented:
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?
0
 
McKnifeCommented:
Just edit a GPO like you always do, don't worry.
0
 
jmarkfoleyAuthor Commented:
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.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\MACHINE\Scripts\Startup, so I put the script there, with appropriate (hopefully) name changes:

for /f %%a in ('findstr /i /E %computername% \\mail.hprs.local\share\localadmins.txt') do net localgroup /add administrators %%a

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?
0
 
McKnifeCommented:
Take a new policy. Yours is for domain controllers, not for clients. Yes, reboot the test client.
0
 
jmarkfoleyAuthor Commented:
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
0
 
McKnifeCommented:
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.
0
 
jmarkfoleyAuthor Commented:
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.local\Policies\{BCA8FAF8-6904-44C4-9D32-28400BE61028}\Machine\Scripts\Startup, so I moved my addadmins.bat script to that folder, selected it, then clicked OK.

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

Open in new window

How can I tell if this script is even running? I've added the 1st 'echo' line to the script, but no testing.txt file gets created.
0
 
McKnifeCommented:
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.
0
 
jmarkfoleyAuthor Commented:
-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 ...
0
 
McKnifeCommented:
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.
0
 
jmarkfoleyAuthor Commented:
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\testing.txt (the target of my "echo"). So, at least it ran! I changed the echo to: echo %computername% %USERNAME% > \\mail.hprs.local\share\testing.txt and saw that the %computername% echoed was uppercase, so I changed my localadmins.txt file to:

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 %%a

Open in new window

Replacing "net localgroup ..." with "echo %%a >> \\mail.hprs.local\share\testing.txt" gave no 2nd line to the testing.txt file, so perhaps the findstr is not working?
0
 
jmarkfoleyAuthor Commented:
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.
0
 
jmarkfoleyAuthor Commented:
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?
0
 
McKnifeCommented:
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.local\Policies\{BCA8FAF8-6904-44C4-9D32-28400BE61028}\Machine\Scripts\Startup\yourbatch.bat
and see what output comes.
0
 
jmarkfoleyAuthor Commented:
Results:
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.

Open in new window

Yet, see attached image. Account does exists, this user logs in all the time as 'doris'.
user-doris.jpg
0
 
McKnifeCommented:
Ah, ok.
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\%%a

Open in new window

0
 
jmarkfoleyAuthor Commented:
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.
0
 
McKnifeCommented:
My bad. Just your domain, be it FQDN notation or netbios domain name, so make it hprs.local
0
 
jmarkfoleyAuthor Commented:
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
0
 
McKnifeCommented:
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).
0
 
jmarkfoleyAuthor Commented:
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.
0
 
jmarkfoleyAuthor Commented:
Excellent solution. I hope McKnife responds to my future GPO issues, very knowledgeable!
0
 
McKnifeCommented:
You are welcome.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.