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

Reply via email to