&author.jht; &author.jerry; Please read this chapter carefully before update or upgrading Samba. You should expect to find only critical or very important information here. Comprehensive change notes and guidance information can be found in the section Updating and Upgrading Samba. !!!!!!!!!!!!Add all critical update notes here!!!!!!!!!!!!! These following notes pertain in particular to Samba 3.0.23 through Samba 3.0.25c (or more recent 3.0.25 update). Samba is a fluid and ever changing project. Changes throughout the 3.0.x series release are documented in this documention - See Upgrading from Samba-2.x to Samba-3.0.25. Sometimes it is difficult to figure out which part, or parts, of the HOWTO documentation should be updated to reflect the impact of new or modified features. At other times it becomes clear that the documentation is in need of being restructured. In recent times a group of Samba users has joined the thrust to create a new Samba Wiki that is slated to become the all-singing and all-dancing new face of Samba documentation. Hopefully, the Wiki will benefit from greater community input and thus may be kept more up to date. Until that golden dream materializes and matures it is necessary to continue to maintain the HOWTO. This chapter will document major departures from earlier behavior until such time as the body of this HOWTO is restructured or modified. This chapter is new to the release of the HOWTO for Samba 3.0.23. It includes much of the notes provided in the WHATSNEW.txt file that is included with the Samba source code release tarball. The change documented here affects unmapped user and group accounts only. user group Relative IdentifiersRID netgroupmap netrpcvampire 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 by executing: net rpc vampire. SID SAM RID netgetlocalsid 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 assigned a RID within the SAM on the Samba server. For a domain controller this would have been under the authority of the domain SID where as on a member server or standalone server, this would have been under the authority of the local SAM (see the man page for net getlocalsid). unmapped users unmapped groups SID NTFS GID 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 Windows client 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. An example helps to illustrate the change: group mapping GID ACL SID Assume that a group named developers exists with a UNIX GID of 782. In this case 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 Samba-3.0.23, the group SID might appear as S-1-5-21-647511796-4126122067-3123570092-2565. SID NTFS access group permissions With the release of Samba-3.0.23, the group SID would be reported as S-1-22-2-782. Any security descriptors associated with files stored on a Windows NTFS disk partition will 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 is S-1-22-2-782 and not reported in a user's token, Windows would fail the authorization check even though both SIDs in some respect refer to the same UNIX group. group mapping SID The workaround for versions of Samba prior to 3.0.23, 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. With the release of Samba-3.0.23 this workaround is no longer needed. Samba 3.0.x series releases before 3.0.23 automatically created group mappings for the essential Windows domain groups Domain Admins, Domain Users, Domain Guests. Commencing with Samba 3.0.23 these mappings need to be created by the Samba administrator. Failure to do this may result in a failure to correctly authenticate and recoognize valid domain users. When this happens users will not be able to log onto the Windows client. Group mappings are essentail only if the Samba servers is running as a PDC/BDC. Stand-alone servers do not require these group mappings. The following mappings are required: Domain GroupRIDExample UNIX GroupDomain Admins512rootDomain Users513usersDomain Guests514nobody When the POSIX (UNIX) groups are stored in LDAP, it may be desirable to call these domadmins, domusers, domguests respectively. For further information regarding group mappings see Group Mapping: MS Windows and UNIX. backends GID SQL XML The parameter no long accepts multiple passdb backends in a chained configuration. Also be aware that the SQL and XML based passdb modules have been removed in the Samba-3.0.23 release. More information regarding external support for a SQL passdb module can be found on the pdbsql web site. default mapping Domain Admins smbpasswd tdbsam passdb backend group mappings GID SID IDMAP winbindd domain groups The default mapping entries for groups such as Domain Admins are no longer created when using an smbpasswd file or a tdbsam passdb backend. This means that it is necessary to explicitly execute the net groupmap add to create group mappings, rather than use the net groupmap modify method to create the Windows group SID to UNIX GID mappings. This change has no effect on winbindd's IDMAP functionality for domain groups. LDAP schema sambaSID OpenLDAP slapindex slapd.conf There has been a minor update the Samba LDAP schema file. A substring matching rule has been added to the sambaSID attribute definition. For OpenLDAP servers, this will require the addition of index sambaSID sub to the slapd.conf configuration file. It will be necessary to execute the slapindex command after making this change. There has been no change to the actual data storage schema.