[Samba] Problems resolving most users with winbind and AD/SFU

[Steve B]

I think I've been approaching this from the wrong angle.  I spent the
last few weeks with different samba builds and configurations, but the
result was always the same.  The same 9 accounts would resolve, while
all others "Could not get unix ID".

I think the problem might be on the SFU side.  The requests for
account info is received from the fileserver, but isn't available for
most of the accounts.

There's a pretty good site which talks about various hotfixes for SFU
3.5:  http://debian-interix.net/hotfixes/tv.html.  I've downloaded
most of the applicable patches and will apply them tomorrow.

Secondly, I'm going to use the ADSI Edit utility to inspect the AD
account attributes in details.  With any luck I'll find which keys are
in place for the accounts that resolve and are missing for the
accounts that won't.  With more luck I won't fry my AD.

Will post if I find anything of value

Steve

>
>> Hello all,
>>
>> I'm having a problem with Winbind resolving some users from AD on a W2KSP4
>> server running SFU 3.5 [8.0.1969.1].  All users and groups in the AD domain
>> have been assigned UIDs and GIDs via SFU.  The Linux fileserver is running
>> CentOS 5.3 with Samba 3.0.33-3.7.el5.  The fileserver has been joined to the
>> domain using authconfig with proper modifications made to nsswitch and pam.
>> My smb.conf is attached below.
>>
>> wbinfo -u will show all users.  What I'm seeing is that out of the 90 or so
>> users, only 6 will respond to id or winbind -i requests.  The rest respond
>> with "no such user" or similar.  The following error appears in
>> my /var/log/samba/winbindd-idmap.log file when an attempt is made to resolve
>> one of these users:
>>
>> [2009/06/23 13:59:13, 3] nsswitch/winbindd_async.c:winbindd_dual_sid2uid(374)
>>  [11577]: sid to uid S-1-5-21-1060284298-861567501-682003330-1277
>> [2009/06/23 13:59:13, 1] nsswitch/idmap_ad.c:idmap_ad_sids_to_unixids(613)
>>  Could not get unix ID
>>
>> An additional symptom is as such, where wbinfo -n works for all users, but
>> only a few can be resolved with wbinfo -S:
>>
>> # wbinfo -n user1
>> S-1-5-21-1060284298-861567501-682003330-1241 User (1)
>> # wbinfo -S S-1-5-21-1060284298-861567501-682003330-1241
>> 2241
>> # wbinfo -n user2
>> S-1-5-21-1060284298-861567501-682003330-1260 User (1)
>> # wbinfo -S S-1-5-21-1060284298-861567501-682003330-1260
>> Could not convert sid S-1-5-21-1060284298-861567501-682003330-1260 to uid
>>
>> This problem directly affects attempts to 'xcopy /o' files from Windows to the
>> Linux file server, or in the following example an attempt to use subinacl to
>> set ownership of a file on the fileserver to one of the users who will not
>> resolve:
>>
>> [2009/06/24 16:38:27, 3] smbd/posix_acls.c:unpack_nt_owners(966)
>>  unpack_nt_owners: unable to validate owner sid for
>> S-1-5-21-1060284298-861567501-682003330-1260
>> [2009/06/24 16:38:27, 3] smbd/error.c:error_packet_set(106)
>>  error packet at smbd/nttrans.c(2207) cmd=160 (SMBnttrans)
>> NT_STATUS_ACCESS_DENIED
>>
>> This type of error also appears when I use subinacl to set group permissions
>> on files owned by a user who does respond to id or wbinfo -i.  I've added the
>> BUILTIN groups using net sam createbuiltingroup example_group -w MYDOM:
>>
>> [2009/06/24 16:51:22, 3] passdb/lookup_sid.c:fetch_gid_from_cache(1107)
>>  fetch gid from cache 50000 -> S-1-5-32-544
>> [2009/06/24 16:51:22, 3] smbd/posix_acls.c:unpack_nt_owners(966)
>>  unpack_nt_owners: unable to validate owner sid for S-1-5-32-544
>> [2009/06/24 16:51:22, 3] smbd/error.c:error_packet_set(106)
>>  error packet at smbd/nttrans.c(2207) cmd=160 (SMBnttrans)
>> NT_STATUS_ACCESS_DENIED
>>
>> I've searched high and low, and found several also complaining about winbind
>> resolving only a subset of users.  None of the suggestions or fixes have
>> affected my situation.  I'm not running nscd.  I've stopped winbind,
>> deleted /etc/samba/secrets.tdb, deleted /var/cache/samba/*.tdb, rejoined the
>> domain and restarted winbind.  I swapped schema_mode from sfu to rfc2307 and
>> back.  Nothing helps.  The same 6 users resolve, but the others will not.
>> Frankly I'm stumped, but feel I'm so close to the answer.  I'm hoping someone
>> can suggest something that might work here.
>>
>> smb.conf
>> --------
>> [global]
>>   security = ads
>>   auth methods = winbind guest sam
>>   realm = MYDOM.DOMAIN.NET
>>   netbios name = FILESERVE1
>>   workgroup = MYDOM
>>   use kerberos keytab = true
>>   password server = 192.168.1.23
>>   encrypt passwords = yes
>>   server string = Samba 3.0.33-3.7.el5
>>
>> # winbind configuration
>>   winbind refresh tickets = true
>>   winbind nested groups = yes
>>   winbind enum groups = yes
>>   winbind enum users = yes
>>   winbind use default domain = yes
>>   winbind nss info = sfu
>>   winbind separator = +
>>   winbind cache time = 0
>>   idmap domains = MYDOM
>>   idmap config MYDOM:backend = ad
>>   idmap config MYDOM:default = yes
>>   idmap config MYDOM:range = 200-49999
>>   idmap config MYDOM:schema_mode = sfu
>>   idmap alloc backend = tdb
>>   idmap alloc config:range = 50000-99999
>>
>>   invalid users = root bin daemon lp sys tty
>>
>>   log file = /var/log/samba/log.%m
>>   log level = 3 printdrivers: 0 lanman: 0 smb: 1 rpc_parse: 0 rpc_srv: 0
>> rpc_cli: 0 passdb: 1 sam: 0 auth: 5 winbind: 5 vfs: 0 idmap: 0 quota: 0 acls:
>> 0 locking: 0 msdfs: 0 dmapi: 0
>>   max log size = 1024
>>
>>   wins server = 192.168.1.23
>>   wins support = no
>>
>>   socket options = TCP_NODELAY
>>
>> [printers]
>>   printable = no
>>
>> [Public]
>>   path = /data/Public
>>   comment = Public data
>>   read only = no
>>   browseable = yes
>>   dos filemode = yes
>>   inherit permissions = Yes
>>   inherit acls = Yes
>>   ea support = yes
>>   map acl inherit = yes
>>   store dos attributes = yes
>>   nfs4: mode = simple
>>   nfs4: acedup = merge
>>
>>
>> Thanks for bearing with me,
>> Steve
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>