[Samba] Problems resolving most users with winbind and AD/SFU
(Resolved?)
Steve B
steveb333 at gmail.com
Wed Jul 1 01:43:13 GMT 2009
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 at 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
>>>
>>
>
More information about the samba
mailing list