samba - Apr 2003 - ACL group permissions only work on primary group

Intro:
There have been a few postings on this subject with few answers.  If
anyone knows where to point those of us trying to work this out, or will
enlighten us as to the limitations of ACL's and Samba, we would
appreciate your help.  So far, acl.bestbits.at does not have any
information on this particular problem.

Environment:
Samba 3.0 alpha 21 or 23 (I skipped 22, but most likely it had the same
problem)
Red Hat 8.0
Kernel 2.4.20 w/ acl patches from acl.bestbits.at
Ext3 filesystem mounted w/ acl option

Problem:
Samba is successfully authenticating users via a W2K domain using ADS.
Logins and passwords work great, individual file access permissions work
fine.  The problem is when setting group file or directory access
permissions, Samba/Linux only recognizes a user's "primary group".
This
means if a user is a member of more than one group (by default, everyone
is a member of Domain Users which is also their primary group) only
their primary group is looked at for file/directory access permissions
on the Samba server.  

This causes two problems:

1) I have to manually go through every user (250+) a set their default
group to something other than Domain Users (unless, of course, that's
adequate for my needs).  This is time consuming, but I can live with it.

2) The bigger problem is that a person can only receive access to
files/directories based on membership in only one group.  For example,
John is a member of coders and a member of management with coders being
his primary group.  Without assigning individual rights, John will only
be able to access the coders directory and will not have access to the
management directory even though the management group has full access to
it.  Yes, it would be easy to just assign John individual rights to the
management directory, but this becomes an exponential headache when you
multiply this scenario out across a large company of similar situations.

The questions:
1) Is it possible for a user to gain rights to files/directories based
on their membership in multiple groups?  
2) If #1 not now, is this being worked on?
3) If #1 is possible, what additional configuration(s) need to be done?
4) Is there a work around?  I've thought of a couple, but they didn't
pan out.

Any useful ideas, suggestions, links, etc. would be welcome.  More
importantly, please let me know if this is the current limitation so I
can stop spinning my wheels and wasting time trying to figure it out.  I
would really appreciate it.

Thanks.


*****Smb.conf*****
[global]
	workgroup = mydomain
	netbios name = UTINST01 
	remote announce = 10.1.32.255	
	realm = MYDOMAIN.ORG
	ads server = 10.1.30.39
	server string = UTINST01
	security = ADS
	password server = dc1 
#	passwd program = /usr/bin/passwd %u
	encrypt passwords = yes
	unix password sync = Yes
	log file = /var/log/samba/log.%m
	preferred master = No
	local master = No
	
	#Performance enhancements
	socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
	domain master = No
	dns proxy = no
	ldap ssl = no

	# Winbind stuff
	winbind separator = +
	winbind uid = 10000-20000
	winbind gid = 10000-20000
	winbind enum users = yes
	winbind enum groups = yes
	winbind use default domain = No
	template homedir = /home/%U
	template shell = /bin/bash

	#Extras
	time server = yes

######## Volume Shares ########

[Installs]
	path=/data2/installs
	guest ok = no
	read only = no
	nt acl support = Yes
	admin users = MYDOMAIN+rick 

[Archives]
	path=/data2/archives
	guest ok = no
	read only = no
	nt acl support = Yes
	admin users = MYDOMAIN+rick 
	

*******************************************



Rick Segeberg
Provo Site Manager, IT Department
The Waterford Institute
rick.segeberg@waterford.org

*************************************

This e-mail may contain privileged or confidential material intended for the
named recipient only.
If you are not the named recipient, delete this message and all attachments.
Unauthorized reviewing, copying, printing, disclosing, or otherwise using
information in this e-mail is prohibited.
We reserve the right to monitor e-mail sent through our network. 

*************************************