Am 04.10.2016 um 17:05 schrieb Rowland Penny via samba:> On Tue, 4 Oct 2016 16:09:40 +0200
> Achim Gottinger via samba <samba at lists.samba.org> wrote:
>
>>
>> Am 04.10.2016 um 15:43 schrieb Rowland Penny via samba:
>>> On Tue, 4 Oct 2016 15:16:17 +0200
>>> Achim Gottinger via samba <samba at lists.samba.org> wrote:
>>>
>>>> Am 04.10.2016 um 10:21 schrieb Rowland Penny:
>>>>> On Tue, 4 Oct 2016 02:35:21 +0200
>>>>> Achim Gottinger via samba <samba at lists.samba.org>
wrote:
>>>>>
>>>>>> Am 03.10.2016 um 18:57 schrieb Rob via samba:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've been experiencing an intermittent problem
where some UIDs
>>>>>>> on a member server spontaneously change from being
their
>>>>>>> AD-derived values to being allocated from the
default idmap
>>>>>>> space, even when there is no change to the AD user
information.
>>>>>>>
>>>>>>> Specifically, I have a member server running Samba
4.4.5 on
>>>>>>> CentOS 6.8. AD service is provided by two Samba
4.4.5 servers.
>>>>>>>
>>>>>>> The member server's smb.conf has (in part):
>>>>>>>
>>>>>>> [global]
>>>>>>> netbios name = memberserver
>>>>>>> security = ADS
>>>>>>> workgroup = MYDOMAIN
>>>>>>> realm = MY.AD.REALM.COM
>>>>>>> server role = member server
>>>>>>>
>>>>>>> interfaces = em1 127.0.0.1
>>>>>>> bind interfaces only = yes
>>>>>>>
>>>>>>> idmap config *:backend = tdb
>>>>>>> idmap config *:range = 2000-9999
>>>>>>>
>>>>>>> # idmap config for domain
>>>>>>> idmap config MY.AD.REALM.COM:backend =
ad
>>>>>>> idmap config MY.AD.REALM.COM:schema_mode
= rfc2307
>>>>>>> idmap config MY.AD.REALM.COM:range =
10000-99999
>>>>>>>
>>>>>>> # Use template settings for login shell
and home
>>>>>>> directory winbind nss info = template
>>>>>>> template shell = /bin/bash
>>>>>>> template homedir = /home/%U
>>>>>>>
>>>>>>> winbind use default domain = yes
>>>>>>> [...]
>>>>>>>
>>>>>>> This generally works fine... user mappings are
like:
>>>>>>>
>>>>>>> $ wbinfo -i auser
>>>>>>> auser:*:10028:10000:User Name:/home/auser:/bin/bash
>>>>>>> $ id auser
>>>>>>> uid=10028(auser) gid=10000(agroup)
>>>>>>> groups=10000(agroup),10007(othergroup)
>>>>>>>
>>>>>>> After a while (generally a couple days, though
sometimes much
>>>>>>> sooner), this starts happening:
>>>>>>>
>>>>>>> $ wbinfo -i auser
>>>>>>> auser:*:2018:10000:User Name:/home/auser:/bin/bash
>>>>>>> $ id auser
>>>>>>> uid=2018(auser) gid=10000(agroup)
>>>>>>> groups=10000(agroup),10007(othergroup)
>>>>>>>
>>>>>>> and this persists until I do "net cache
flush" on the member!
>>>>>>>
>>>>>>> Any thoughts on why the winbindd cache is getting
corrupted? I
>>>>>>> tried running winbindd with log level 7, but
nothing jumped out
>>>>>>> at me: just normal queries returning 10028 and then
normal
>>>>>>> queries returning 2018. Other suggestions to try?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> -Rob
>>>>>>>
>>>>>>> PS. At one point in the past, this member server
was also a DC
>>>>>>> and this problem never happened then.
>>>>>>>
>>>>>> Been having this issue on an dc after i updated from
4.1 to 4.2.
>>>>>> It turned out some users with defined uid also had
mappings from
>>>>>> winbind in idmap.tdb. At firt the uid attributre gets
used but
>>>>>> afetr a while the value fromidmap.tdb was used. The fix
was to
>>>>>> delete the mappings in idmap.tdb.
>>>>>> On an member server you can use net idmap set/get/dump
to test
>>>>>> this.
>>>>>>
>>>>> You are missing the fact that the OP is using the REALM
name
>>>>> instead of the NETBios domain name and for some reason
winbind is
>>>>> starting to allocate the user a UID from the '*'
range.
>>>>>
>>>>> Rowland
>>>> It's jumping from using rfc uid's gid's in ad to
the "*" range.
>>>> Would it dynamic assign from the ad range it would still be an
>>>> error.
>>>>
>>> If you look at the smb.conf the OP posted, you will find the ranges
>>> are set to:
>>>
>>> idmap config *:range = 2000-9999
>>> idmap config MY.AD.REALM.COM:range = 10000-99999
>>>
>>> His user 'auser' intially has this 'uid=10028', it
then changes to
>>> 'uid=2018'
>>>
>>> I do not really understand how he got the first as the second
'idmap
>>> config' line is wrong, the user should have had the second id
all
>>> the time, because the user is outside the domain
'MYDOMAIN'.
>>>
>>> '10028' is inside the second range, but shouldn't have
been used
>>> because the DOMAIN name is wrong.
>>> '2018' is inside the range set for '*' i.e.
everything outside the
>>> DOMAIN
>>>
>>> Rowland
>> I assume he has configured 10028 as uid in the ad for that user.
>> Using the realm as the domain name is not wrong seen from the windows
>> side of things where the netbios name is there for backward
>> compatibility. For example i can use [realm]\[username] or [netbios
>> domain name]\[username] to logon to a windows domain member.
> It might not be wrong from a windows perspective, but it is wrong from
> the 'idmap_ad' side of things, it expects the NETBios domain name
not
> the realm. It is how winbind differentiates between domains, see 'man
> idmap_ad'
>
> Rowland
>
>
Well i'd expect it behaves like windows unless otherwise mentioned. I
can not find the word netbios (domain name) in the man page. It uses the
netbios name in the example but that does not imply the realm can not be
used. :-)
It is also not mentioned in the idmap section of man smb.conf. And under
the realm section the docs say " The realm is used as the ADS equivalent
of the NT4 domain.".
And finaly using the realm seems to work because at first samba picks
the rfc uid's for the domain user. I wonder if the OP still has interest
to fix this issue however.
------
IDMAP_AD(8) System Administration tools IDMAP_AD(8)
NAME
idmap_ad - Samba's idmap_ad Backend for Winbind
DESCRIPTION
The idmap_ad plugin provides a way for Winbind to read id
mappings from an AD server that uses RFC2307/SFU schema extensions. This
module implements only the "idmap" API, and is READONLY. Mappings must
be provided in advance
by the administrator by adding the uidNumber attributes for
users and gidNumber attributes for groups in the AD. Winbind will only
map users that have a uidNumber and whose primary group have a gidNumber
attribute set. It is
however recommended that all groups in use have gidNumber
attributes assigned, otherwise they are not working.
Currently, the ad backend does not work as the default idmap
backend, but one has to configure it separately for each domain for
which one wants to use it, using disjoint ranges. One usually needs to
configure a writeable
default idmap range, using for example the tdb or ldap backend,
in order to be able to map the BUILTIN sids and possibly other trusted
domains. The writeable default config is also needed in order to be able
to create group
mappings. This catch-all default idmap configuration should have
a range that is disjoint from any explicitly configured domain with
idmap backend ad. See the example below.
IDMAP OPTIONS
range = low - high
Defines the available matching UID and GID range for which
the backend is authoritative. Note that the range acts as a filter. If
specified any UID or GID stored in AD that fall outside the range is
ignored and the
corresponding map is discarded. It is intended as a way to
avoid accidental UID/GID overlaps between local and remotely defined IDs.
schema_mode = <rfc2307 | sfu | sfu20>
Defines the schema that idmap_ad should use when querying
Active Directory regarding user and group information. This can be
either the RFC2307 schema support included in Windows 2003 R2 or the
Service for Unix (SFU)
schema. For SFU 3.0 or 3.5 please choose "sfu", for SFU
2.0
please choose "sfu20". Please note that primary group membership is
currently always calculated via the "primaryGroupID" LDAP attribute.
EXAMPLES
The following example shows how to retrieve idmappings from our
principal and trusted AD domains. If trusted domains are present id
conflicts must be resolved beforehand, there is no guarantee on the
order conflicting
mappings would be resolved at this point. This example also
shows how to leave a small non conflicting range for local id allocation
that may be used in internal backends like BUILTIN.
[global]
workgroup = CORP
idmap config * : backend = tdb
idmap config * : range = 1000000-1999999
idmap config CORP : backend = ad
idmap config CORP : range = 1000-999999
AUTHOR
The original Samba software and related utilities were created
by Andrew Tridgell. Samba is now developed by the Samba Team as an Open
Source project similar to the way the Linux kernel is developed.
Samba 4.2 07/06/2016 IDMAP_AD(8)
------