Steve B
2009-Jul-01 01:43 UTC
[Samba] Problems resolving most users with winbind and AD/SFU (Resolved?)
Problem solved. Sort-of. I just don't know why the solution works. Here's what I found... First, I tried updating SFU 3.5 with the following hotfixes: 913030, 886655, 887531, 932143, 883520, 894186, 931930, 892561, 896428, 888993, 932143, and 939778. No change. Second, I used ADSI Edit from the Win2k support tools to compare side-by-side a working account with a "Could not get info for user ..." account. All AD fields were identical, with the exception of fields expected to be different like name, UID, etc. ADSI Edit also showed nothing out of ordinary in the Schema, groups, etc. Third, I checked the NIS server settings on the SFU side using "ypcat -k -d MYDOM passwd" & group. All accounts were visible with nothing of serious note. Last, I checked various groups for membership. I found that the accounts that resolved belonged to various BUILTIN groups on the AD server. I added a test account to the BUILTIN\Administrators and BUILTIN\Backup Users groups, and in a few minutes the test account started working in winbind. I added another account, and within an hour it was also accessible from winbind. I removed these tests from both BUILTIN groups and they remained functional in winbind. I added all accounts to these BUILTIN groups, and in an hour every account was functional in winbind. I went back in and removed all accounts that shouldn't belong to those groups and they still remained usable by winbind. What the heck? I have no clue what hidden flag got enabled on these accounts to make them work just by temporarily passing them through the BUILTIN groups. On one of the Samba fileservers I had not even performed the createbuiltingroups step to make these groups accesible. The BUILTIN\Users group was already populated with the "Domain Users" security group, of which all accounts were already members of. I've seen a few other posts from folks having problems AD user accounts from winbind. I'm wondering if this same band-aid fix might also work in their situations. Thanks all, Steve On Sun, Jun 28, 2009 at 4:58 PM, Steve B<steveb333@gmail.com> wrote:> 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 >>> >> >
Reasonably Related Threads
Wisdom of the Ancients
