This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 129647 - samba v 3 ads mode loss of share access after upgrade 3.0.4
samba v 3 ads mode loss of share access after upgrade 3.0.4
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: samba (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Simo Sorce
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-11 09:17 EDT by joe goodings
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:21:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description joe goodings 2004-08-11 09:17:21 EDT
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.
Comment 1 David Lawrence 2004-08-11 10:50:36 EDT
Please inform if this problem report is similar to the one stated in
bug  129013.
Comment 2 joe goodings 2004-08-11 11:05:03 EDT
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. 
Comment 3 joe goodings 2004-08-25 10:01:20 EDT
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)
Comment 4 Bastien Nocera 2004-09-30 10:50:14 EDT
The answer from Jerry Carter:
http://lists.samba.org/archive/samba-technical/2004-August/036861.html
Comment 5 RHEL Product and Program Management 2007-10-19 15:21:00 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.