added/new functionality? (long)

[Phil Mayers]

This is a long one. It's by no means correct. But, as I understand it,
this is the situation (I hope I'm answering the question you asked
here...)



Fundamentally, Unix and NT security models are very different - unix has
no concept of a non-local UID, whereas SID's can easily be non-local
(usually are in a domain environment). Not to mention that SIDs are a
much larger namespace than most Unices' UID/GID namespace...(etc., etc.)

What you're talking about is a "proper" SURS implementation (S-id to
U-id R-esolution S-ystem, I think). TNG has the stubs for one in place,
but IIRC it doesn't do a huge amount at the moment.

The whole user/group mapping thing in earlier versions is simply a hacky
way of doing the same thing.

But, you're *ALWAYS* going to have to have a local user on the unix box,
one way or another. Samba *needs* to switch from root (uid=0) to the
user (uid=somenumber), and without a local username, samba has no way of
associating that user *NAME* with the actual number (the real
identifier).

However, TNG has a program called "winbindd" - what ypbind is to NIS,
winbindd is to NT domains. The concept of "having a local user" amounts
to the getpw* calls knowing about that users. Most Unix operating
systems support a thing called NSS (NameService Switch) which allows
user-defined modules to add new sources to these calls.

The default (on my Linux machine, for example) is usually libnss_files,
which gets user/group (amongst others) info from /etc/passwd and
/etc/group. winbindd (and the associated library) will get them from the
NT domain, and using a local SURS configuration, map NT SIDs (from the
servers home domain, or trusted domains of that domain) into UIDs or
GIDs, whichever is appropriate.

So you see, it's not quite that simple.

To narrow it down some, you have two options:

1) Create local users (maybe even only a few) and local groups (maybe
even only a few) and use the user/group name mapping (possibly using a
many-one mapping - does this work anyone?) to do what you want.

2) Use winbindd from TNG (I guess it should be relatively self
contained) with a configured SURS implementation to do this. If you only
have one domain of interest (where "of interest" means "containing the
users and groups concerned") this latter step should be straighforward.
Then, adding and subtracting users from domains will be automatically
propagated out to the Unix machines running winbindd, and assuming you
either

a) Don't use mapping, and use compatible names (no spaces, right length)
b) Use mapping, and don't jerk the thing around too much

You admin effort will be low.

Personally I recommend 1) for production environments, because it's
known to work. 2) might sound like less work, but TNG is not stable as
of yet, and the full implications of winbindd and SURS haven't made
themselves apparent.

However, you sound like you want to do 1) anyway. You're going to have
to use a many-one NT-unix username and groupname map, but I'm by no
means sure that will work - I avoid mapping like the plague.

There is a force user and force group option, but that will only give
you one user and one group under which access is granted, per share.

I'm sure it's possible, you just have to recognise it's not going to
work perfectly.

Cheers,
Phil

ccoupal at justice.gov.sk.ca wrote:
> 
> Kevin,
> 
> I am looking to reduce the overhead of managing UNIX groups and UNIX users,
> so your solution doesn't really help. The groups and users already exist on
> the NT domain, so why do I have to create the user accounts and the groups
> over again on the unix machine?
> 
> I want to, on connection, eval the connecting user's NT groups (get them
> from the PDC/BDC) and based on the user's group membership, map the user to
> one of the few defined Samba/Unix accounts for all file IO operations
> (through a map file?)
> 
> This would mean the user never has to authenicate to the Samba box. After
> the user has been authenicated by the authentication authority (PDC/BDC),
> Samba would get the list of groups for the user, and just map across. No
> account has to be created for the individual user on the Samba/Unix box,
> they just have to be added to a group with access.
> 
> Perhaps... there is some functionality out there that does this already, but
> I haven't found it. I could use work arounds that provide the same effect.
> 
> Chris
> 
> > -----Original Message-----
> > From: Kevin Colby [SMTP:kevinc at grainsystems.com]
> > Sent: Wednesday, March 08, 2000 4:20 PM
> > To:   ccoupal at justice.gov.sk.ca
> > Subject:      Re: added/new functionality?
> >
> >
> > Perhaps I am missing the point here, but I would think that you
> > could map your NT groups to Unix user groups, and then use
> > normal unix file permission restrictions.
> >
> > If it is share-wide, you can restrict by group in the share definition.
> >
> >       - Kevin Colby
> >         kevinc at grainsystems.com
> >
> >
> > ccoupal at justice.gov.sk.ca wrote:
> > >
> > > Greetings,
> > >
> > > I am currently working on a land management system. We are using a
> > typical
> > > Microsoft three-tier development environment (MTS, SQL7.0). However, in
> > the
> > > midst of all this Microsoft influence, we are using samba as the back
> > end
> > > data store. We are using samba on a large IBM box to store images, with
> > > image details stored on an SQL7.0 box. Transactional ability is
> > preserved
> > > for writing the images through MTS. An MTS component is given the
> > location
> > > of the file, and it them moves the file to the data store (samba) on
> > behalf
> > > of the user. We want the users to retrieve the file direct through a
> > UNC.
> > > Samba is configured as a member of the NT domain
> > >
> > > Configuring samba and the component to allow writing is fairly easy; we
> > have
> > > a typical samba set up with one UNIX, Samaba, and NT account configured
> > for
> > > this purpose.
> > > Configuring samba to allow read has been done through the use of a guest
> > > account and guest ok priviledges on the shares.
> > >
> > > Here is where samba's abilities seem to be falling short:
> > >
> > > We would like to have read shares created (ie. RS1, RS2, RS3) with read
> > > permissions for specific NT groups of users (ie. NTUG1, NTUG2, NTUG3).
> > > We would like user management to be done on the NT side with minimal
> > > accounts on the samba/UNIX side.
> > >
> > > Our thoughts:
> > >
> > > - Samba knows how to authenticate with an NT domain.
> > > - Samba suid's to the UNIX account before performing file operations, so
> > > what if we map user groups to specific samba/unix accounts (removing the
> > > requirement for individual user groups) through another map file
> > >
> > > for example:
> > >
> > > We map 1 NT user group to 1 samba account such that on a user's request
> > for
> > > access to a share, samba checks the user's group membership to see if
> > the
> > > user's membership includes a group which matches a mapping, and then all
> > > access to the share is provided as that account. (Notice that with this,
> > > there would be no authentication between the client and samba/unix).
> > >
> > > If someone knows of current direction to this ends, or another way to
> > > provide this functionality, please let me know, else I'll start fighting
> > my
> > > way through the source and see how difficult it would be to do (but I
> > don't
> > > really want to do this).
> > >
> > > Chris Coupal