Bug 2082 - Samba 3.0.8 on Solaris missing AD group with getent
Samba 3.0.8 on Solaris missing AD group with getent
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: winbind
3.0.8
Sparc Solaris
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-23 16:53 UTC by Mark Clarkson
Modified: 2005-08-24 10:22 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Clarkson 2004-11-23 16:53:40 UTC
Solaris 9 (patch 112960-10 applied)
Samba 3.0.8 (configure --with-ads --with-pam --with-winbind)
MIT Kerberos 1.3.5 (configure --enable-dns --enable-dns-for-kdc
--enable-dns-for-realm --without-tcl)

I am using Samba to share Unix files to our Windows users via a Samba share,
security = ads.  All the shares work just fine.

Here is the relevant section of my smb.conf file:

  [global]
            workgroup = FFFC
            realm = FFFC.COM
            server string = Fileshare
            security = ads
            password server = *
            log level = 2
            log file = /var/log/samba/%m.log
            min protocol = NT1
            time server = Yes
            change notify timeout = 300
            deadtime = 7
            socket options = TCP_NODELAY SO_RCVBUF=8192 IPTOS_LOWDELAY
SO_RCVBUF=8192 SO_SNDBUF=8192
            load printers = No
            os level = 99
            domain master = No
            ldap ssl = no
            idmap uid = 50000-59999
            idmap gid = 50000-59999
            winbind separator = +
            winbind cache time = 10
            winbind nested groups = Yes
            hide unreadable = Yes
            delete veto files = Yes
            inherit acls = Yes
            inherit permissions = Yes
            wins server = 10.1.240.90 10.1.240.91
            use spnego = Yes

  [exlist$]
            comment = Test share
            path = /export/smbfiles/exlist
            create mask = 0777
            directory mask = 0777
            security mask = 0777
            force group = root
            force user = root
            writeable = Yes
            read only = No
            valid users = FFFC+Citrix_Base
            write list = FFFC+Citrix_Base
            veto files =
/*.?pg/*.avi/favicon.ico/robots.txt/.htaccess/*.wm*/.rhosts/*.rm/*.mp?/*.asf
/*.wav/*.?peg/*.midi/*.aif*/*.au/*.as?/*.wpl/
            hide files = /Thumbs.db/.*/
            dos filetimes = Yes

The problem that I am having is that some groups can not be accessed by a
`getent group` command.

I can see the group with wbinfo:

  $ wbinfo -g | grep FFFC+Citrix_Base
  FFFC+Citrix_Base

  $ wbinfo -n FFFC+Citrix_Base
  S-1-5-21-393102617-441343358-1233803906-9715 Domain Group (2)

  $ wbinfo -Y S-1-5-21-393102617-441343358-1233803906-9715
  50308

  $ wbinfo -G 50308
  S-1-5-21-393102617-441343358-1233803906-9715

As you can clearly see, FFFC+Citric_Base is a valid Active Directory group.
But when I use `getent`, I get different numbers of groups:

  $ wbinfo -g | wc -l
     327
  $ getent group | awk -F: '{print $1}'|wc -l
     315

Also, when I try to view the group with a `getent` command, winbindd seems
to hang.  

  $ getent group FFFC+Citrix_Base

I left it for a weekend and it still did not return the group.

The group FFFC+Citrix_Base contains a lot of users (more than 500 for sure,
possibly more than 1000).

This is preventing me from using FFFC+Citrix_Base as a way to control access
to this share.
Comment 1 Mark Clarkson 2004-11-23 17:20:49 UTC
Just ran winbindd -d10 -i and found this at the end of the query.  Don't know if
it will help though:

num_mem = 1235, len = 16630, mem =
FFFC+SMazziotti,FFFC+JHandel,FFFC+FShaw,FFFC+LBrinza,FFFC+RPalencia,FFFC+HXaymountry,FFFC+JBelcher,FFFC+JLewis,FFFC+SBrooke,FFFC+KCrutcher,FFFC+ACvetnich,FFFC+JPayne,FFFC+DABrown,FFFC+SMcmurtrey,FFFC+kflake,FFFC+TJewell,FFFC+ANicotra,FFFC+STaylor,FFFC+JHealy,FFFC+BRobbins,FFFC+LHarling,FFFC+CMercado,FFFC+DRodriguez,FFFC+DKay,FFFC+HTaylor,FFFC+LSalmiery,FFFC+JLopez,FFFC+BrMcManus,FFFC+STurriff,FFFC+YGalan,FFFC+JQuinones,FFFC+CDumas,FFFC+THarrison,FFFC+ASharpe,FFFC+KWalsh,FFFC+MRubman,FFFC+JuKaplan,FFFC+LFerraro,FFFC+WBirdsell,FFFC+JHyde,FFFC+NAcker,FFFC+JMoneymaker,FFFC+KIgnagni,FFFC+JWuchte,FFFC+CZith,FFFC+JPoston,FFFC+JWhelan,FFFC+JWeather,FFFC+EBoyd,FFFC+Cmartinez,FFFC+JTuccio,FFFC+ESaxton,FFFC+CPatterson,FFFC+APhan,FFFC+KJenkins,FFFC+SKline,FFFC+JReece,FFFC+VFizer,FFFC+TMayon,FFFC+MMays,FFFC+TLe,FFFC+AMorgan,FFFC+CSpeer,FFFC+JRiechert,FFFC+TNelson,FFFC+RHayes,FFFC+PhCunningham,FFFC+RMills,FFFC+PStLouis,FFFC+MTizzano,FFFC+KKahl,FFFC+DGabriele,FFFC+EEppes,FFFC+EsRobles,FFf
+>
ill_grent_mem returning 1
client_write: wrote 1300 bytes.
client_write: need to write 16630 extra data bytes.
client_write: wrote 16630 bytes.
client_write: client_write: complete response written.
client_read: read 0 bytes. Need 1824 more for a full request.
read failed on sock 18, pid 1611: EOF

Looks like the group size is 1235 members.
Comment 2 Mark Clarkson 2004-11-23 17:26:48 UTC
Actually, scratch that.  I got the 6 lines from the previous post only because I
changed the nsswitch.conf file to read:

group:      files winbind [SUCCESS=return NOTFOUND=continue UNAVAIL=continue TRY
AGAIN=5]

so that it would not hang forever.  Once I changed it back to TRYAGAIN=forever,
the last line I get from the winbindd output is:

ill_grent_mem returning 1
Comment 3 Stephen Rondeau 2005-01-19 08:53:30 UTC
My experience with Samba 2.2.8a on Solaris, as well as someone else's with
3.0.10 compiled on Solaris, is that winbind has a buffering problem with group
members whose combined length exceeds 4096 bytes. 

I discovered this while trying to get winbind to work with my 2.2.8a version on
Solaris (yes, I know I need to update): when I had 625 members in my "Domain
Users" group, whose average user name length was 6.6 characters, winbind would
fail (using "id username" would hang, or "ls -l" would hang on a directory where
the group "Domain Users" should be resolved from the gid -- "ls" worked fine).
Doing the math, this puts the total length over 4K bytes. I deleted some old
accounts: 26 at first, and everything (id and ls -l) started to work again.
Doing the math again, the break-even point for my average user name length would
be about 620... I happened to check it at 599.

I hope this helps! (srondeau@u.washington.edu)
Comment 4 Gerald (Jerry) Carter 2005-02-08 05:58:43 UTC
we've done a lot of work on winbindd for 3.0.11.  Please test 
that release and reopen if the bug still exists.  Thanks.
Comment 5 Gerald (Jerry) Carter 2005-08-24 10:22:15 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.