Re: Qs re: ActiveDirectory authentication & perms

[Kent West]

On Tue, May 23, 2017 at 12:42 PM, George42  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 

Re: Qs re: ActiveDirectory authentication & perms

[George42]

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

> 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.

> 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.

> 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.

> 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.

Hope that helps some.

- george

Re: Qs re: ActiveDirectory authentication & perms

[Kent West]

On Mon, May 22, 2017 at 9:59 AM, 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; most
> of them are using it just as file-storage via Samba from their Windows/Macs
> boxes; a few are ssh'ing into it, etc, for other usages; some have web
> sites on it.
>
> For years their accounts have been maintained as local accounts on that
> Debian box, but as we're swapping out hardware, I'm also thinking it's time
> to swap out account management to let our campus-wide Active Directory
> provide their accounts instead of them (and me) having to maintain two
> separate sets of account credentials (three, if you include the samba
> file-sharing account on the old Debian setup).
>
> After considerable hair-pulling, I've managed to get the box to
> authenticate using their AD credentials, so that a user can simply ssh in
> without having an account on the box, using their AD credentials. But of
> course, their User IDs in AD are different than they were on the old Debian
> box, so their file permissions are different.
>
> 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:
>
> 
>
> 3) Can I limit logins/file-sharing to just a subset of campus users (one
> department, not just anyone having a campus account)?
>
>
To answer my own question on this.

A detail I left out was that I set up my AD-authentication via "realmd", as
per this site:

http://www.alandmoore.com/blog/2015/05/06/joining-debian-8-to-active-directory/

To restrict logins to just certain users/groups, simply 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.



-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: Qs re: ActiveDirectory authentication & perms

[deloptes]

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; most
> of them are using it just as file-storage via Samba from their
> Windows/Macs boxes; a few are ssh'ing into it, etc, for other usages; some
> have web sites on it.
> 
> For years their accounts have been maintained as local accounts on that
> Debian box, but as we're swapping out hardware, I'm also thinking it's
> time to swap out account management to let our campus-wide Active
> Directory provide their accounts instead of them (and me) having to
> maintain two separate sets of account credentials (three, if you include
> the samba file-sharing account on the old Debian setup).
> 
> After considerable hair-pulling, I've managed to get the box to
> authenticate using their AD credentials, so that a user can simply ssh in
> without having an account on the box, using their AD credentials. But of
> course, their User IDs in AD are different than they were on the old
> Debian box, so their file permissions are different.
> 
> 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?
> 
> 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.
> 
> 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?
> 
> 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.)
> 
> 3) Can I limit logins/file-sharing to just a subset of campus users (one
> department, not just anyone having a campus account)?
> 
> 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.
> 
> Thanks!
> 

I think your questions a properl addressed to the samba mailing list.

You can look into the samba configuration options - especially user/group
mapping. For the read/write permissions you can enforce specific or look
into acls. you can not remap group to username AFAIR - the name is not
important - important is the id behind the name. 2b again group mapping
question - but there is nothing wrong with spaces in this context - it
boils down to the gid again. 3) I think you can work with dedicated group
or you would have to maintain a list of allowed users. 4) look carefully in
the samba documentation there are actually a good guides for your scenario,
where almost all of this is explained. You are not discovering the steam
engine

https://www.howtoforge.com/samba_active_directory
https://help.ubuntu.com/lts/serverguide/samba-ad-integration.html
https://help.ubuntu.com/community/ActiveDirectoryWinbindHowto
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory
https://wiki.samba.org/index.php/Samba,_Active_Directory_%26_LDAP

regards

Qs re: ActiveDirectory authentication & perms

[Kent West]

I'm not quite sure what questions to ask...

I have a Debian box used by 10 or 12 people on a university campus; most of
them are using it just as file-storage via Samba from their Windows/Macs
boxes; a few are ssh'ing into it, etc, for other usages; some have web
sites on it.

For years their accounts have been maintained as local accounts on that
Debian box, but as we're swapping out hardware, I'm also thinking it's time
to swap out account management to let our campus-wide Active Directory
provide their accounts instead of them (and me) having to maintain two
separate sets of account credentials (three, if you include the samba
file-sharing account on the old Debian setup).

After considerable hair-pulling, I've managed to get the box to
authenticate using their AD credentials, so that a user can simply ssh in
without having an account on the box, using their AD credentials. But of
course, their User IDs in AD are different than they were on the old Debian
box, so their file permissions are different.

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?

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.

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?

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.)

3) Can I limit logins/file-sharing to just a subset of campus users (one
department, not just anyone having a campus account)?

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.

Thanks!

-- 
Kent


-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com