--with-vfs and ACLs problem

[Nir L]

The SID's that are returned to the client are 100% OK.
Proof:
I access an NT server from the client, and watch a file that MYDOM\UserA and MYDOM\UserB have permissions on.

Then, I access the SAMBA server and watch a file that MYDOM\UserA,MYDOM\UserB and MYDOM\UserC have permissions on.

The UserA and B SID's are translated to names correctly (because they are cached on the client machine). UserC's SID remains in SID form.

So - I know for sure that SID's of UserA and UserB are returned from the SAMBA correctly, and probably UserC as well. (the SID that I see matches the exact SID of the user on the PDC).

(if I didn't access the NT server before accessing the samba server, all 3 SID's would not have been translated....)

Could it be that the client does not access the PDC to translate SID's to names, but trying to access the server who gave him the SID's , and the server is supposed to relay the RPC to the PDC ?

more info:
There is only one PDC in out network.
The security management delivers USERNAMES to samba and he translates them to SID's and sends them to the client.
Samba version is 2.2.0
security = DOMAIN or security = SERVER (same result)
(when security = DOMAIN the samba server is joined to the domain ...)

more info 2:
I ran samba with debug level = 10.
I could see that the client asks SAMBA to translate the SID's.
it calls lookup_sid, which tries to activate winbind to translate the SID. I suppose that in this part if winbind had been running, he might have translated the SID correctly for the client.
But since winbind is not running, the SAMBA tries to translate the SID itself, and fails...

log:
2002/06/23 12:09:20.584203, 5] rpc_server/srv_lsa_nt.c:init_lsa_trans_names(219)
  init_lsa_trans_names: looking up sid S-1-5-21-257908509-604318102-2002191721-1106
[2002/06/23 12:09:20.584286, 10] smbd/uid.c:lookup_sid(366)
  lookup_sid: winbind lookup for SID S-1-5-21-257908509-604318102-2002191721-1106 failed - trying local.
[2002/06/23 12:09:20.584368, 5] lib/util_sid.c:map_domain_sid_to_name(151)
  map_domain_sid_to_name: S-1-5-21-257908509-604318102-2002191721
[2002/06/23 12:09:20.584428, 5] lib/util_sid.c:map_domain_sid_to_name(158)
  map_domain_sid_to_name: compare: S-1-5-21-3039204150-1313164136-3871986822
[2002/06/23 12:09:20.584489, 5] lib/util_sid.c:map_domain_sid_to_name(158)
  map_domain_sid_to_name: compare: S-1-5-21-3039204150-1313164136-3871986822
[2002/06/23 12:09:20.584541, 5] lib/util_sid.c:map_domain_sid_to_name(158)
  map_domain_sid_to_name: compare: S-1-5-32
[2002/06/23 12:09:20.584588, 5] lib/util_sid.c:map_domain_sid_to_name(158)
  map_domain_sid_to_name: compare: S-1-1
[2002/06/23 12:09:20.584635, 5] lib/util_sid.c:map_domain_sid_to_name(158)
  map_domain_sid_to_name: compare: S-1-3
[2002/06/23 12:09:20.584682, 5] lib/util_sid.c:map_domain_sid_to_name(158)
  map_domain_sid_to_name: compare: S-1-5
[2002/06/23 12:09:20.584724, 5] lib/util_sid.c:map_domain_sid_to_name(167)
  map_domain_sid_to_name: mapping for S-1-5 not found
[2002/06/23 12:09:20.584769, 5] rpc_server/srv_lsa_nt.c:init_lsa_trans_names(228)
  init_lsa_trans_names: not found
[2002/06/23 12:09:20.584816, 10] rpc_server/srv_lsa_nt.c:init_lsa_trans_names(243)
  init_lsa_trans_names: added user '\' to referenced list.


  ----- Original Message ----- 
  From: Eric Lee Steadle 
  To: Nir L 
  Sent: Thursday, June 20, 2002 8:01 PM
  Subject: RE: --with-vfs and ACLs problem


    Richard Sharpe already responded to you, but his explanation may not be clear. 
     
    After the ACL is retrieved by the Security Editor on the Client Workstation (the machine displaying the security tab), the Security Editor on that machine will contact the domain controller responsible for each SID in the ACL, and attemt to lookup the names of the accounts associated with each SID. This appears to be what is failing. The Client is NOT talking to Samba at this point -- it's talking to the password server. 
     
    If the password server doesn't know about a particular SID, it will ask other domain controllers that it may know about (basically anything with a trust relationship). If it still can't resolve the SID, it gives up. The Client will not be able to display the account names and so it will just show the SIDs instead. I'm not sure if your PDC has the accounts in it or not since you didn't provide details about the external ACL management product. Is it responsible for allocating SIDs too? Or does it just handle ACLs?  
     
    An Ethereal or Netmon trace on the PDC should confirm this for you. Look for MSRPC packets -- the specific function is called lsaLookupNames, but I don't know the OpCode off the top of my head. 
     
    To solve this problem, you need to get the client to talk to something that can resolve the Sids in the ACL into account names. 
     
     
    Is this any clearer now?
    ERX
     
     
     -----Original Message-----
    From: samba-technical-admin at lists.samba.org [mailto:samba-technical-admin at lists.samba.org]On Behalf Of Nir L
    Sent: Thursday, June 20, 2002 12:48 PM
    To: samba-technical at samba.org
    Subject: --with-vfs and ACLs problem



    I am using samba 2.2.0 without winbind, using security = server.
    The samba server is NOT a PDC.
    I've set its password server to my PDC.
     
    I am writing an extention to samba, in order to let it get the ACL's of the shared files from an external security managment product. The security management product decides which DOMAIN users are authorized to which files.
    The users belong to my NT_DOMAIN.
     
    I replace the fget_nt_acl and get_nt_acl functions, in order to return the acl's according to the management product.
     
    The SID's that I return from these functions seem to be OK (I've checked them with several utilities)/
    But somehow, when I choose file->properties->security, I can see the correct SID's , but the SID's are NOT TRANSLATED to the account names in my domain. They remain in their SID form (similar to an SID of a deleted user, if you've ever seen it...)

    This happen both on Win2K clients and WinNT 4.0 clients with the latest service packs.

    Can anyone help me ?

    Currently, I can not upgrade to a version higher than 2.2.2.

    Thanks,
    Nir

-------------- next part --------------
HTML attachment scrubbed and removed