Samba 3.0.23pre1 Available for Download

[Ken Stone]

Ok ... functionally broken here :-( ... Its HPUX 11i ... We use
full coporate run NT/domain infrastructure for auth and build a
map to convert to unix user names ... For example on the samba
server I am user ken(10000) and in the NT/domain world I am 
americas\kstone1.  

In lib/smb.conf, I have 

    security = domain
    encrypt passwords = yes
    password server = *
    username map = /local/samba3/lib/name-maps

In lib/name-maps, I have 

    !ken = americas\kstone1

When I try and attach a drive from the 3.0.23pre1 samba server, I get 

    [2006/04/24 11:17:12, 2] smbd/service.c:(557)
      user 'ken' (from session setup) not permitted to access this share (ken)

Prior to 3.0.23pre1 up thru 3.0.21c, this worked just fine ....

Log and config files at whatever level available upon request

Thanks

  -- Ken


> User and Group changes
> ======================
> 
> The user and group internal management routines have been
> rewritten to prevent overlaps of assigned Relative Identifiers
> (RIDs).  In the past the has been a potential problem when
> either manually mapping Unix groups with the 'net groupmap'
> command or when migrating a Windows domain to a Samba domain
> using 'net rpc vampire'.
> 
> Unmapped users are now assigned a SID in the S-1-22-1 domain and
> unmapped groups are assigned a SID in the S-1-22-2 domain.
> Previously they were assign a RID within the SAM on the Samba
> server.  For a DC this would have been under the authority of
> the domain SID where as on a member server or standalone host,
> this would have been under the authority of the local SAM
> (hint: net getlocalsid).
> 
> The result is that any unmapped users or groups on an upgraded
> Samba domain controller may be assigned a new SID.  Because the
> SID rather than a name is stored in Windows security descriptors,
> this can cause a user to no longer have access to a resource
> for example if a file was copied from a Samba file server to
> a local NTFS partition.  Any files stored on the Samba server
> itself will continue to be accessible because Unix stores the
> Unix gid and not the SID for authorization checks.
> 
> A further example will help illustrate the change.  Assume
> that a group named 'developers' exists with a Unix gid of
> 782 but this user does not exist in Samba's group mapping
> table. it would be perfectly normal for this group to be
> appear in an ACL editor.  Prior to 3.0.23, the group SID might
> appear as S-1-5-21-647511796-4126122067-3123570092-2565.
> With 3.0.23, the group SID would be reported as S-1-22-2-782.
> Any security descriptors associated with files stored on
> an NTFS disk partition would not allow access based on the
> group permissions if the user was not a member of the
> S-1-5-21-647511796-4126122067-3123570092-2565 group.
> Because this group SID not reported in a user's token is
> S-1-22-2-782, Windows would fail the authorization check
> even though both SIDs in some respect referred to the same
> Unix group.
> 
> The current workaround is to create a manual domain group
> mapping entry for the group 'developers' to point at the
> S-1-5-21-647511796-4126122067-3123570092-2565 SID.