On Tue, May 23, 2017 at 12:42 PM, George42 <georg...@protonmail.com> wrote:
> Kent West wrote:
>
> > I'm not quite sure what questions to ask...
> >
> > I have a Debian box used by 10 or 12 people on a university campus;
>
> ... snip...
>
> > After considerable hair-pulling, I've managed to get the box to
> > authenticate using their AD credentials,
>
> ... snip ...
>
> > Since it's just a dozen users or so, I can easily "id" their AD UID
> > and "chown -R" their files in their home directory (which have been
> > copied over manually from the old Debian box) to their AD UID.
> >
> > But that leaves several questions:
> >
> > 1) If I just "chown -R", that changes the ownership of all the files,
> > regardless how the files may have been set-up on the old box. For
> > example, I notice in at least one web directory for one user, the
> > files were owned by www-data, with the group ownership set to the
> > group name corresponding to the user's name on the old box. Changing that
> > ownership from "www-data" to "joe_user" might break things. Is there a
> way
> > to just chown the ownership of files already owned by the old username?
>
> You should be able to use a combination of find and xargs to chown only
> files
> owned by a certain user. This command should be approximately what you
> want:
>
> find /home/username -user local_user -print0 | xargs -0 chown ad_user
>
I found this same (essentially) answer about an hour ago, in this form:
find /home -user local_user -exec chown ad_user {} \;
This seems to have worked. I'm not sure if your method might or might not
be better, but I appreciate you giving a good answer.
> > 2) The group that all the AD-authenticated users are in is "domain
> users".
> > That means that any files formerly owned by suzy:suzy are now owned by
> > suzy:"domain users", and if a file is set to 770 (or similar), any one
> > of the people logging in can access any other person's files as a
> > member of that group. Not good.
>
> In that case, you will have to either change the file permissions to 700
> or change the group on the files.
>
> > 2a) What's the best route for dealing with this group ownership issue?
> > Can I remap the group for all AD-authenticated users to be their own
> > username, like it was in the old Debian setup? Is that even a good idea?
>
> If the files should be accessible only by the user who owns them, then you
> could set the permissions to 700. No need to create groups. That is what I
> would do. The main thing will be to set up a create mask for new files.
> Changing owner on the existing files shouldn't set the group to "domain
> users"
> unless you tell it to.
>
> In order to have groups that match the usernames, you would have to create
> them manually. AD setups that I am familiar with do not have a group for
> each user like a local Linux system typically does. I would recommend
> against this. It will be extra work, extra clutter and not as clear from
> an admin point of view since it is not normally done.
>
Again, I found out about an hour ago that AD doesn't have a group for each
user:
from
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/groupmapping.html
"Windows does not permit user and group accounts to have the same name.
This has serious implications for all sites that use private group
accounts. A private group account is an administrative practice whereby
users are each given their own group account. Red Hat Linux, as well as
several free distributions of Linux, by default create private groups."
I at first tried to manually create a group for each user (using only a
couple as tests), but found that doesn't work because the group name in
/etc/groups is not recognized when using the AD setup.
So I decided I'd have to chown the ownership of all the files to 700 (just
as you've now suggested, which validates that I'm thinking along the right
direction) and figure out how to set the perms by default on new files
created. Your mentioning of a "mask for new files" sounds just like what I
need to look up next (from vague memory from long ago, it seems it's an
easy fix - ah, 30 seconds of googling just now points me to "umask"; I'll
study another few minutes in a few minutes, and have it working in a few
minutes, I bet).
Not having group membership the same as the owner membership will be a new
way of thinking for me, but I bet I can wrap my brain around it.
> > 2b) I'm skittish of having spaces in group names (or files, etc), and
> > would rather that "domain users" be something like "domain_users";
> > does the AD authentication process have some way of remapping that
> > name to one without spaces? (Or this may be a moot question, depending
> > on the answer to 2a above.)
>
> You would have to look at the documentation for the AD authentication
> process that you are using. I have never seen such a thing. I have been
> using
> sssd to authenticate against AD for a little while now and the only issue I
> have run into with the spaces was trying to limit ssh access based on a
> group
> that had a space. For the most part, don't worry about the spaces. If
> something
> doesn't work with a group that has a space, check the documentation for the
> particular command. Usually you either enclose it in quotes or use a \ to
> escape the space.
>
Yeah, the little experience I've had in the past day or so indicates I
won't have to worry too terribly much about it. I'm glad to hear you
confirm that, though.
>
> > 3) Can I limit logins/file-sharing to just a subset of campus users
> > (one department, not just anyone having a campus account)?
>
> It seems based on your next message you figured out a way.
>
Yep. Pretty easy. I'll tack it on here for all-in-one documentation. Just
edit /etc/sssd/sssd.conf, like as in this snippet:
############
#access_provider = ad
access_provider = simple
simple_allow_users = westk
simple_allow_groups = technology support admins,Mathematics
############
I could have left the "= ad" option and used more complex "allow" lines
(see docs for sssd.conf), but the "simple" option was easier. Anyone not
specified in an "allow" line is implicitly denied.
Don't forget you have to restart sssd after making any changes - systemctl
restart sssd
Note that there are other ways of accomplishing this task also (tinkering
with /etc/pam.d/sshd & /etc/pam.d/login & /etc/security/access.conf & etc),
but this route does what I need.
> > 4) I haven't even begun to think about how to tie this into their
> > samba (or is it "cifs" nowadays?) file shares. Any pointers dealing
> > with that would be appreciated.
>
> It all depends on how you set up samba. If you want to know how things
> affect your samba configuration, then you need to learn how to configure
> samba so that you understand the configuration you are using.
>
> After I get my file permissions straightened out, I'll tackle this one.
> Hope that helps some.
>
Yes, quite a bit. Thank you!
>
> - george
>
--
Kent West <")))><
Westing Peacefully - http://kentwest.blogspot.com
