Are you a member of the AD domain?  Are you running winbindd?  You 
problem is most likely due to SID<->uid/gid resolution.  Try running 
winbindd and setting "trusted domains only = yes"

Are you running 'winbind use default domain = yes'?
This is possibley related to bug 406.

It seems to be the same problem than bug 406.
But I do not use winbindd I don' need it because all user informations stored 
in AD are both windows and unix and NSS do the job.

I have try to set winbind use default domain = False but this do not change 
anything.

what is the actual group membership that I should 
see for the user in the log (group names and gid's)?

I only see

  NT user token of user S-1-5-21-3343041157-3844517643-2476834904-2404
  contains 5 SIDs
  SID[  0]: S-1-5-21-3343041157-3844517643-2476834904-2404
  SID[  1]: S-1-5-21-3343041157-3844517643-2476834904-2405
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11

  UNIX token of user 702
  Primary group is 702 and contains 2 supplementary groups
  Group[  0]: 702
  Group[  1]: 702

user is member of the following groups

mgrisant.sunos023# id -a mgrisant
uid=702(mgrisant) gid=702(gmgrisant) groups=1005(gvmserver),700(rdisadm),2031
(TopemethoA),2010(TrdisA)

ok.  I still think this is related to bug 406, but 
probably in the opposite fashion.  What I need to finish 
this is a level 10 debug log including the direct 
SMBsesssetup command.

If you set smbd at level 10 and then connect with 
smbclient as the user, that should be enough.
You can mail the log file to me directly instead of
including it here.  

Thanks.

ok.  Sorry for the delay.  I'm back on this one:

Here's what I see....

  NT user token of user S-1-5-21-57989841-776561741-682003330-1117
  contains 13 SIDs
  SID[  0]: S-1-5-21-57989841-776561741-682003330-1117
  SID[  1]: S-1-5-21-57989841-776561741-682003330-1144
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11
  SID[  5]: S-1-5-21-57989841-776561741-682003330-512
  SID[  6]: S-1-5-21-57989841-776561741-682003330-7802
  SID[  7]: S-1-5-21-57989841-776561741-682003330-513
  SID[  8]: S-1-5-21-57989841-776561741-682003330-1140
  SID[  9]: S-1-5-21-57989841-776561741-682003330-519
  SID[ 10]: S-1-5-21-57989841-776561741-682003330-1142
  SID[ 11]: S-1-5-21-57989841-776561741-682003330-3838
  SID[ 12]: S-1-5-21-57989841-776561741-682003330-4890

  UNIX token of user 702
  Primary group is 702 and contains 2 supplementary groups
  Group[  0]: 702
  Group[  1]: 702

Group 702 matches:
  local_gid_to_sid: Fall back to algorithmic mapping: 
     702 -> S-1-5-21-3263274372-2597681947-2126427605-2405
  gid_to_sid: local 702 -> S-1-5-21-3263274372-2597681947-2126427605-2405
  fetch sid from gid cache 
     702 -> S-1-5-21-3263274372-2597681947-2126427605-2405

I'm guessing that getgrouplist_internal() is failing.  

You might want to try the patch for bug 680
that was just checked in.  Just a hunch.

Does this bug still exist in 3.01.pre3 ?  
You've been very helpful, but I need some 
help moving forward.  Just feedback on the current 
CVS code would be good.  Thanks.

Yes, the bug still exist in Solaris environment with 3.01.pre3.
But i tried on Linux x86, the issue seems to be corrected in this environment.

Michael,  

Please take a look at this message and see if any of this 
applies to you.  Thanks.

http://marc.theaimsgroup.com/?l=samba-technical&m=107026747906385&w=2

Just in case the URL for the email mentioned in comment #11 foes bad:

  With patch 112960-03 and below, everything works fine. With patch
  newer than 112960-03, Samba cann't get the supplementary
  group information for a user from directory server.
  Therefore, the user gets access denied when access to
  those files with supplementary group permission.

Moving this one off the must fix list for 3.0.1 since it appears to be a problem
with a Solaris patch.

I cannot access the url.

The patch 112960 is a solaris 9 patch and not solaris 8.

strange about the URL.  I just checked it and it is still valid.

wrt to the patch, i'll write some test code today and see if 
we can narrow the problem.  I'll mail it to you directly.

reseting target milestone.  3.0.1 has been frozen.  WIll have to 
re-evaluate these.

Created attachment 355 [details]
nss winbind patch for Solaris 8 secondary groups

The Solaris 8 wrapper wasn't performing the secondary group initialization. The
enclosed patch adds the appropriate code to call the linux initgroups function.
Preliminary tests are successful, but I'm going to be making further tests to
ensure there were no side effects.

If anyone in the samba team already identified issues, causing this code not to
be added, please let me know.

I'll take the patch but the original bug was a 
problem with nss_ldap (which I think is a solaris
issue).

Michael, is there any update on the original report?

(I got this mail which seems relevant)

I had the same problem today and wrote this testprogramm.
Samba uses the systemcall getgrouplist (in my case)
try this program

#include <unistd.h>
#include <grp.h>
#include <sys/types.h>
#include <stdlib.h>

int main(void)
{
  int ngroups = 16;
  gid_t *groups = (gid_t *) malloc (ngroups * sizeof (gid_t));
  gid_t secondaries[1024];

  printf("%d\n", getgrouplist("your_user", 0, groups, &ngroups));
}

if the user ist in more than one ldap groups and only one 
is find, than nss_switch.conf is not correct like Jerry 
allready noted 

[root@zweigelt source]# ./a.out
7

You can see it with

[root@zweigelt source]# strace ./a.out

/etc/nsswitch.conf is opend
but then it only opens /lib/libnss_files.so.2 (in my case)
which means it looks for groups only in local files

simply try

  group:       files ldap

and in my case it worked (I had

  group:      files  [UNAVAIL=return] ldap

which works with the system tool like getent and id -a , but not with the
systemcall..)

Greetings

Hansjörg



execve("./a.out", ["./a.out"], [/* 30 vars */]) = 0
uname({sys="Linux", node="zweigelt.itsd.de", ...}) = 0
brk(0)                                  = 0x80495d8
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40016000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=80536, ...}) = 0
old_mmap(NULL, 80536, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)                                = 0
open("/lib/tls/libc.so.6", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`V\1B4\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1531064, ...}) = 0
old_mmap(0x42000000, 1257224, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x42000000
old_mmap(0x4212e000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x12e000) = 0x4212e000
old_mmap(0x42131000, 7944, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x42131000
close(3)                                = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0x40016a00, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0x40017000, 80536)               = 0
brk(0)                                  = 0x80495d8
brk(0x804a5d8)                          = 0x804a5d8
brk(0)                                  = 0x804a5d8
brk(0x804b000)                          = 0x804b000
open("/etc/nsswitch.conf", O_RDONLY)    = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1835, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1835
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40017000, 4096)                = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=80536, ...}) = 0
old_mmap(NULL, 80536, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)                                = 0
open("/lib/libnss_files.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\35\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=52472, ...}) = 0
old_mmap(NULL, 47068, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002b000
old_mmap(0x40036000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xa000) = 0x40036000
close(3)                                = 0
munmap(0x40017000, 80536)               = 0
open("/etc/group", O_RDONLY)            = 3





-- 
Dr. Hansjörg Maurer 

Hi!
I have the same problem with Solaris-9 nss_ldap from PADL.com
and samba-3.0.2a. Supplemantary groups from LDAP are not even reguested from 
LDAP Server according to the LDAP server log file. 
However everything is working
under unix enviroment.

[2004/02/25 12:44:48, 5] auth/auth_util.c:(505)
  UNIX token of user 225
  Primary group is 1 and contains 2 supplementary groups
  Group[  0]: 1
  Group[  1]: 1
[2004/02/25 12:44:48, 3] smbd/sec_ctx.c:(256)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2004/02/25 12:44:48, 3] smbd/uid.c:(287)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2004/02/25 12:44:48, 3] smbd/sec_ctx.c:(288)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2004/02/25 12:44:48, 5] auth/auth_util.c:(486)

id -a ssi
uid=225(ssi) gid=1(other) groups=112(support),1000(users)

Everything in this bug report points to a Solaris  problem.  Trying 
to clear out old bugs.

originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.

database cleanup