Bug 1493 - ADS logins aren't member of all the groups from the ADS
Summary: ADS logins aren't member of all the groups from the ADS
Status: RESOLVED DUPLICATE of bug 2804
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.4
Hardware: x86 Linux
: P2 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-30 07:34 UTC by Ferdinand Hagethorn
Modified: 2005-09-29 09:43 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ferdinand Hagethorn 2004-06-30 07:34:42 UTC
Hi there,

When I log in to our samba server the smbd process doesnt get all groups
correctly, it misses some.

This goes for a number of accounts and i just cannot figure out whats wrong.
Here is what i found:

/////////////////////////////////////////////////////////////////////////
// logged in with smbclient //fp1/export -U mlandzaat -k
// using a kerberos login (kinit mlandzaat)
// using samba 3.0.4 from debian packages from samba debian repository

// status file in /proc/pid
// Please take note ofthe Groups: line
Name:   smbd
State:  S (sleeping)
Tgid:   890
Pid:    890
PPid:   27403
TracerPid:      0
Uid:    10020   10020   0       10020
Gid:    0       10000   0       10000
FDSize: 32
Groups: 10000 10013 10021 10030
// SNIPP

// Now lets have a looksee which groups should be in the Groups: line 
// in above status file;
# getent group -s winbind|grep mlandzaat|cut -f3 -d:
 10013
 10021
 10030
 10102
 10110
// Now repeat after me: "Like... HUH?"

// Here is for the completeness the getent of the user in question:
# getent passwd -s winbind|grep mlandzaat
 mlandzaat:x:10020:10000:M.L.:/cluster/homes/homedirs/mlandzaat:/bin/false
// that looks okay

/////////// a dump of the important things in smb.conf
[global]
        workgroup = WORKGROUP
        realm = WORKGROUP.COM
        netbios name = FILESERVER
        security = ADS
        syslog = 1
        log file = /var/log/samba/log.%m
        printcap name = cups
        os level = 10
        preferred master = No
        local master = No
        domain master = No
        idmap uid = 10000-60000
        idmap gid = 10000-60000
        template homedir = /cluster/homes/homedirs/%U
        winbind separator = @
        winbind use default domain = yes
        winbind enum users = yes
        winbind enum groups = yes
// This looks correct doesnt it? It works for about 80% of the users

My notes in short:
 --1--: smbd process is member of groups:   
 Groups: 10000 10013 10021 10030
 this leaves the following groups not included:
 10102 and 10110
 --2--: This seems like this goes for some users, not all!
 --3--: This looks a lot like the old bug i found in 3.0.1 (bug id: #1165)
 but its not the same. The old bug didnt add any groups to the smbd process.

I hope you can help out here, this is a real show stopper

Thanks & good luck,

  Ferdinand Hagethorn
Comment 1 Ferdinand Hagethorn 2004-08-10 05:07:17 UTC
It seems like a maximum of 4 groups are in the Groups: line in the status file.
This goes for all users
Comment 2 Ferdinand Hagethorn 2004-08-10 05:16:00 UTC
(In reply to comment #1)
> It seems like a maximum of 4 groups are in the Groups: line in the status file.
> This goes for all users

Its true about 80% of the users have =< 4 groups they're a member of.
Comment 3 Mark Roach 2004-09-03 07:28:38 UTC
I've got the same problem, it looks like the "extra" groups are domain local
groups that I am actually a member of (by virtue of my global groups being
members of those local groups)

here's smbd's status file:

cat /proc/6515/status Name:   smbd
State:  S (sleeping)
SleepAVG:       89%
Tgid:   6515
Pid:    6515
PPid:   5250
TracerPid:      0
Uid:    10000   10000   0       10000
Gid:    0       10000   0       10000
FDSize: 32
Groups: 10007 10008 10009 10010 10011 10012 10013 10014 10015 10016 10017 10018
10019 10020 10021 10022 10023 10024 10025 10026 10027 10028 10029 10030 10031
10032 10033 10034 10035 10036 10037 10038
VmSize:    10636 kB
VmLck:         0 kB
VmRSS:      3332 kB
VmData:     1760 kB
VmStk:        24 kB
VmExe:      2548 kB
VmLib:      4200 kB
Threads:        1
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000001880
SigIgn: 0000000000000000
SigCgt: 0000000000014661
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 0000000000000000

getent group -s winbind | grep mrr001|cut -f3 -d:
10001
10000
10051
10003
10004
10005
10012
10007
10008
10006
10011
10009
10002
10010

Is there any workaround for this at all? Domain Admins is, unfortunately, one of
the groups that is not showing in smbd...

Thanks,

Mark Roach
Comment 4 Holger Schmieder 2005-01-05 14:03:48 UTC
is it possible that you are missing the primary-group and recursive groups ?
Comment 5 Svend Sorensen 2005-08-19 08:41:46 UTC
I have noticed this bug as well.  A strange thing is that 'id' yeilds different
results if it is run with or without the user name:

# su - shw -c id shw
uid=15013(shw) gid=15000(domain users) groups=15000(domain users),15026(project1)

# su - shw -c id
uid=15013(shw) gid=15000(domain users) groups=15000(domain users)
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-08-23 08:19:04 UTC
So what version are we really dealing with here?
3.04. seems pretty old.
Comment 7 Svend Sorensen 2005-08-23 13:45:24 UTC
(In reply to comment #6)
> So what version are we really dealing with here?
> 3.04. seems pretty old.

I am seeing this problem with 3.0.14a.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2005-09-29 09:43:54 UTC
I'm guessing this is the PAC issue Guenther has been working on.

*** This bug has been marked as a duplicate of 2804 ***