Description of problem: After upgrading to Samba RPM version: 3.0.4-6.3e on RH ES server version 3 Using Samba in ADS mode previously accessable shares were unavailable to some users (windows 2000 and windows 98) Version-Release number of selected component (if applicable): Samba 3.0.4-6.3e How reproducible: Onsite: can be easily reproduced Steps to Reproduce: 1.Use a windows 2000 or 98 PC 2.Attempt to access share which has windbind group control 3.User (although logged in) is prompted for username/password Actual results: See 3. above Expected results: Prior to upgrade user could access the share. Additional info: Research has shown only some users affected. Tracing various log files has shown a wrong SID being queried and thus unable to be resolved to a valid user. From winbindd log this shows the failed attempt to attach share [2004/08/11 11:50:02, 1] nsswitch/winbindd_ads.c:query_user(412) query_user(sid=S-1-5-21-898982964-859271383-464344438-1336): Not found [2004/08/11 11:50:02, 1] nsswitch/winbindd_user.c:winbindd_getpwnam(182) error getting user info for user '[UKGL3]\[joeg]' [2004/08/11 11:50:02, 1] nsswitch/winbindd_ads.c:query_user(412) query_user(sid=S-1-5-21-898982964-859271383-464344438-1336): Not found [2004/08/11 11:50:02, 1] nsswitch/winbindd_user.c:winbindd_getpwnam(182) error getting user info for user '[UKGL3]\[joeg]' [2004/08/11 11:50:02, 1] nsswitch/winbindd_ads.c:query_user(412) query_user(sid=S-1-5-21-898982964-859271383-464344438-1336): Not found [2004/08/11 11:50:02, 1] nsswitch/winbindd_user.c:winbindd_getpwnam(182) error getting user info for user '[UKGL3]\[JOEG]' Further investigation showed that the sid value being used was incorrect, the value being used was a group. From whoami /all run on win2k machine [User] = "UKGL3\joeg" S-1-5-21-343818398-492894223-XXXXXXXXXX-1928 [Group 1] = "UKGL3\Domain Users" S-1-5-21-343818398-492894223-XXXXXXXXXX-513 [Group 2] = "Everyone" S-1-1-0 [Group 3] = "BUILTIN\Administrators" S-1-5-32-544 [Group 4] = "BUILTIN\Users" S-1-5-32-545 [Group 5] = "NT AUTHORITY\INTERACTIVE" S-1-5-4 [Group 6] = "NT AUTHORITY\Authenticated Users" S-1-5-11 [Group 7] = "LOCAL" S-1-2-0 [Group 8] = "UKGL3\PUB_P" S-1-5-21-343818398-492894223-XXXXXXXXXX-2062 [Group 9] = "UKGL3\IS_G" S-1-5-21-343818398-492894223-XXXXXXXXXX-2126 [Group 10] = "UKGL3\E-Com_P" S-1-5-21-343818398-492894223-XXXXXXXXXX-2053 [Group 11] = "UKGL3\RES_U" S-1-5-21-343818398-492894223-XXXXXXXXXX-1470 [Group 12] = "UKGL3\ITS_G" S-1-5-21-343818398-492894223-XXXXXXXXXX-2037 [Group 13] = "UKGL3\ITS_UPDATE" S-1-5-21-343818398-492894223-XXXXXXXXXX-2085 [Group 14] = "UKGL3\Domain Admins" S-1-5-21-343818398-492894223-XXXXXXXXXX-512 [Group 15] = "UKGL3\PICL_TR" S-1-5-21-343818398-492894223-XXXXXXXXXX-1527 [Group 16] = "UKGL3\PICL_U" S-1-5-21-343818398-492894223-XXXXXXXXXX-2058 [Group 17] = "UKGL3\joeg" S-1-5-21-898982964-859271383-464344438-1336 [Group 18] = "UKGL3\ALL" S-1-5-21-343818398-492894223-XXXXXXXXXX-1371 [Group 19] = "UKGL3\ITS_U" S-1-5-21-343818398-492894223-XXXXXXXXXX-1350 wbinfo -n of ukgl3+usertest can produce either sid when run on the server. as do other accounts. [it-support@Fiordland it-support]$ wbinfo -n louc S-1-5-21-343818398-492894223-xxxxxxxxxx-1941 User (1) [it-support@Fiordland it-support]$ wbinfo -n Louc S-1-5-21-343818398-492894223-xxxxxxxxxx-1941 User (1) [it-support@Fiordland it-support]$ wbinfo -n usertest S-1-5-21-898982964-859271383-464344438-1174 User (1) [it-support@Fiordland it-support]$ wbinfo -n Usertest S-1-5-21-343818398-492894223-xxxxxxxxxx-1989 User (1) [it-support@Fiordland it-support]$ wbinfo -n ukgl3+louc S-1-5-21-343818398-492894223-xxxxxxxxxx-1941 User (1) [it-support@Fiordland it-support]$ wbinfo -n ukgl3+Louc S-1-5-21-343818398-492894223-xxxxxxxxxx-1941 User (1) [it-support@Fiordland it-support]$ wbinfo -n ukgl3+Usertest S-1-5-21-343818398-492894223-xxxxxxxxxx-1989 User (1) [it-support@Fiordland it-support]$ wbinfo -n ukgl3+usertest S-1-5-21-343818398-492894223-xxxxxxxxxx-1989 User (1) [it-support@Fiordland it-support]$ wbinfo -n usertest S-1-5-21-343818398-492894223-xxxxxxxxxx-1989 User (1) [it-support@Fiordland it-support]$ wbinfo -n Usertest S-1-5-21-343818398-492894223-xxxxxxxxxx-1989 User (1) assumption: the sid: S-1-5-21-898982964-859271383-464344438-xxxx is the old nt4 domain sid prior to upgrade to ADS over 4 year ago Users experiencing no problems have accounts created only in ads, with no old infomation. Tested on a random sample and proved to be true.
Please inform if this problem report is similar to the one stated in bug 129013.
Have aplied this patch all ready unless there is some other file database being afected no. Probly sounds closer to 128683 As Valid Users= is used with ads groups. the public groups seam to work.
The problem seems to be associated with the caching of SID -> Name mappings. When there is more than one SID associated with a name, the wrong mapping can be stored. This is a problem on systems that have migrated from NT4 domains to Active Directory based ones. If winbindd is run with caching disabled (-n option) the problem seems to go away. Rebuilding Samba with the patch from http://lists.samba.org/archive/samba-technical/attachments/20040820/14762abc/name_sid.obj also seems to fix it. (WARNING: There are missing packages in the BuildDepends in the spec file that make recompiling the code difficult)
The answer from Jerry Carter: http://lists.samba.org/archive/samba-technical/2004-August/036861.html
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.