[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Samba 3.0



On Tue, 8 Jul 2003, Tait Shrum wrote:

>I've got a question about Samba 3.0...  I've got it working, sort of...  
>We have drives that are dependent upon our group membership (of 
>course).  My favorite drive is "tech."  It should be our entire raid 
>array (at least that's how it is supposed to work).  When I look at the 
>logs I see that it doesn't want me to connect to the tech share:
>
>[2003/07/08 15:11:21.500179, 2, pid=29180, effective(0, 0), real(0, 0)] 
>smbd/service.c:make_connection_snum(384)
>  user 'tshrum' (from session setup) not permitted to access this share 
>(tech)
>
>So, in an effort to understand what's going on, I decided I would try 
>another share - fdrive.  This share will give you stuff in a drive based 
>upon group membership.  Samba thinks I'm in our middle school group:
>
>[2003/07/08 15:12:57.108371, 1, pid=29180, effective(1001, 1001), 
>real(0, 0)] smbd/service.c:make_connection_snum(692)
>  d3kcxx11 (10.10.20.157) connect to service fdrive initially as user 
>tshrum (uid=1001, gid=1001) (pid 29180)
>
>Now, my user id is 1002 and my group id should be 1007 or tech.  Why 
>does Samba think I'm in the bms or 1001 group?
>
>All this said, has anyone experienced something like this?  I'm using 
>LDAP and Samba 3.0 Beta 2.
>Any help would be appreciated!

We just brought our first Samba 3.0 box online and ran into a simular
issue.

First, are you using LDAP as the authentication backend? If that is the
case, are you using ldap_compat?

For ldap_compat, we ran into the problem that Samba 2.2 didn't really
care what the "rid" and "primarygroupid" entries were. Samba 3.0 does
care. Samba 3.0 uses the rid/primarygroupid to map backwards to the
unix uid/gid (if you used a random rid in samba 2.2, you'll end up with
a random uid in samba 3.0...)

The value of "rid" must be =  uidnumber * 2 + 1000
and "primarygroupid" must be = gidnumber * 2 + 1001

Rids/groups with the samba 3.0 ldap backend are completely different,
I believe the same is true with the new local backend as well.

here's a little script I wrote to great root & nobody group mappings:

        # get server's SID
        SID=`net getlocalsid | cut -d":" -f2`
        # create the root & nobody group mappings
        net groupmap add sid=${SID}-512 unixgroup=root type=domain
        net groupmap add sid=S-1-5-32-546 unixgroup=nobody


The documentation for this is at...

http://us4.samba.org/samba/devel/docs/html/Samba-HOWTO-Collection.html#groupmapping


-Eric




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]