Solved

Create read only user in AD that can not connect to any connect to any shares

Posted on 2014-01-30
13
282 Views
Last Modified: 2014-02-21
Experts,

We are working with a vendor that hosts Sharepoint. We are planning to set up a one way trust from our doamin (with an ipsec tunnel), so that our users can authenticate to the hosted Sharepoint site. I have to share a domain user name and passoword with the vendor, to complet the AD integration.

My concern is that this user will be part of the domain users group, have visability to the shares on the network, and the third party vendor will know the password.
Is there a way to set up a user in AD that is read only and can not hit any of the shares on the network? Would I have to go to each server providing network resources and deny this one user access to the drives on the server?

Thank you in advance
0
Comment
Question by:dwesolowicz
  • 5
  • 5
  • 2
  • +1
13 Comments
 
LVL 53

Expert Comment

by:McKnife
ID: 39820878
Hi.

There is a GPO that you could distribute: http://technet.microsoft.com/en-us/library/cc758316(v=ws.10).aspx - wherever it applies, that user cannot use shares nor network logons.
0
 
LVL 78

Expert Comment

by:David Johnson, CD, MVP
ID: 39821793
add that user to its own security group and don't give that security group access to the shares
0
 

Author Comment

by:dwesolowicz
ID: 39821862
Sorry for the delay and thanks for the reply. I tried your suggestion and it worked just fine.
The only concern is that they still have access to the sysvol folder on the DC. Should a deny permission be set up on the sysvol folder for this specific user?
0
 
LVL 78

Expert Comment

by:David Johnson, CD, MVP
ID: 39821933
If you want but sysvol is used for a lot of things ie. Group policy
0
 
LVL 53

Expert Comment

by:McKnife
ID: 39822422
>  I tried your suggestion and it worked just fine
Who's suggestion, there were two :)
About sysvol: what do you fear he could get his hands at? I assume you don't know what's inside? Then please consult Microsoft TechNet to get an impression.
0
 
LVL 35

Expert Comment

by:Mahesh
ID: 39828095
Its not better idea to modify permissions on Sysvol. please keep it as is.
Sysvol is the folder where all users and computers are looking for domain policies
Its already shared as read only for standard users

If you set deny perms on Sysvol, i believe you will break basic connectivity to domain for those user accounts

Mahesh
0
 

Author Comment

by:dwesolowicz
ID: 39829345
Sorry for the delay.....was out sick for severeal days. MckKnife's suggestion was the first to be used. I am aware of whats inside, and have used several policy scripts to create new local admin users. These scripts contain passwords for those newly created local users in plain text. My thouhgts were that if found, you would then have a user that could log into a device as a local admin.

One thing I could do would be to deny access to this specific policy from the thrid party vendor. Or, after I make the global local user change anc confirm it has been applied, delete the policy al together.

Just do not want to leave access to an area where someone could determine credetials of a user.
0
 
LVL 53

Expert Comment

by:McKnife
ID: 39829464
> These scripts contain passwords for those newly created local users in plain text. My thouhgts were that if found, you would then have a user that could log into a device as a local admin.
Those scripts are start scripts and get executed by the computer accounts, not the user accounts. They are not readable for non-admins.
0
 

Author Comment

by:dwesolowicz
ID: 39829895
Thanks for the reply. I guess I have two scenarios here:

1.  If I log in as a user that is part of the domain user group, this particular user is able to see the policies in sysvol. If they started to click on the unique id's the sysvol share policies, they can navigate to the user folder, scripts, and logon.

I have a logon script that runs so that when a user logs on, it adds a new user to the local admin group. If they right click the script and select edit, you can see the code and password in the script.

I also looked at a computer account gpo, and was able to look at the sysvol\uid\machine\scripts\startup, and could view the script with no problem.

2. If a user logs in as a local admin, they would have to provide credentials to gain access.

Where are the permissions being controlled so that domain users are unable to see sysvol computer account data?
0
 
LVL 53

Expert Comment

by:McKnife
ID: 39829949
"I have a logon script that runs so that when a user logs on, it adds a new user to the local admin group." - No, I bet you don't have that. Logon scripts run with user privileges. Users CANNOT add other users to certain groups. It would need to be a startup script and that's unreadable for users.

Please let's clear that up, first.
0
 

Author Comment

by:dwesolowicz
ID: 39833491
I my appologies...... my oversight.......you are correct. I have a startup script that is used. This script is located in GP under computer configuration, policies, windows settings,scripts startup.

Is there a way to protect sysvol from being viewed from a specific domain user?
0
 

Author Comment

by:dwesolowicz
ID: 39833501
Perhaps I should just protect the specific policies that contain username and password info?
0
 
LVL 53

Accepted Solution

by:
McKnife earned 500 total points
ID: 39833562
Yes, exactly, as I told you before: If you use policies that change passwords using GPP ("group policy preference items"), you need to make that policies accessible only to computer accounts (=the group "domain computers", NOT "authenticated users" and of course not "everyone") - and all is well.....AS LONG, as no user has local admin rights.

IF users are local admins, they can impersonate the system account (using for example psexec -s -i cmd) AND will be able to read out those passwords from the policy. And what that would mean, I hope you can imagine: if for example you would distribute a local administrator (or just a password to an existent, common local administrator), then they would get full access to ALL workstations the policy gets applied to. You surely don't want that.
0

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
scripting 6 54
Binding MAC To Active Directory Domain 1 26
Multi Azure tenant question 7 44
Folder NTFS Permissions 14 71
Using in-flight Wi-Fi when you travel? Business travelers beware! In-flight Wi-Fi networks could rip the door right off your digital privacy portal. That’s no joke either, as it might also provide a convenient entrance for bad threat actors.
Phishing is at the top of most security top 10 efforts you should be pursuing in 2016 and beyond. If you don't have phishing incorporated into your Security Awareness Program yet, now is the time. Phishers, and the scams they use, are only going to …
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now