[Samba] idmap & migration to rfc2307

Rowland Penny rowlandpenny241155 at gmail.com
Sat Nov 7 18:51:35 UTC 2015

On 07/11/15 18:21, Michael Adam wrote:
> On 2015-11-07 at 17:11 +0000, Rowland Penny wrote:
>> On 07/11/15 17:01, Michael Adam wrote:
>>> On 2015-11-07 at 12:37 +0000, Rowland Penny wrote:
>>>> On 07/11/15 11:31, Jonathan Hunter wrote:
>>>>> On 7 November 2015 at 10:11, Rowland Penny <rowlandpenny241155 at gmail.com> wrote:
>>>>>> Is it possible that sssd is failing?
>>>>>> What do you have in /etc/nsswitch?
>>>>> # cat /etc/nsswitch.conf | egrep "(passwd|group)"
>>>>> passwd:     files sss
>>>>> group:      files sss
>>>>> But I don't think this is anything to do with sssd. As I understand it:
>>>>> Local machine UNIX use (i.e. logging in via ssh; looking at files on
>>>>> disk via "ls"; etc.) uses sssd, because this is what I have set in
>>>>> nsswitch.conf. This all works fine, I have no problems with this.
>>>>> "SMB file access" (i.e. a Windows client machine elsewhere on the
>>>>> network, accessing resources via \\server\share\path) does not use
>>>>> sssd, but uses smbd + winbind/winbindd for UID resolution? This is the
>>>>> part that is failing intermittently.
>>>>>> It could be that sssd isn't running or running correctly, so it cannot get
>>>>>> the required info from AD, so winbind is returning the info from idmap.ldb,
>>>>>> hence the '3000000' numbers.
>>>>> Does winbind/wbinfo ever query what is defined in /etc/nsswitch.conf,
>>>>> or does it always use the samba internal UID resolution? I thought it
>>>>> would bypass nsswitch.conf entirely - hence my suspicion that this is
>>>>> nothing to do with sssd.
>>>>> It's hard to reproduce this at will - right now "wbinfo -i myuser" is
>>>>> returning correct UID information. The problem (as far as i can tell)
>>>>> is that, every so often, despite me having "idmap_ldb:use rfc2307 =
>>>>> yes" in smb.conf, this same wbinfo command returns incorrect UID
>>>>> information (as also shown in "net cache list") and therefore this is
>>>>> why I cannot access files via smbd until I clear the idmap cache via
>>>>> "net cache flush".
>>>>> I'm trying to narrow it down to a particular set of circumstances but
>>>>> it's so intermittent, I'm really struggling.
>>>>> I would raise a bug on bugzilla but I'm not sure there's enough
>>>>> information here for someone familiar with the code to resolve it,
>>>>> yet.
>>>>> It is of course possible that I'm doing something wrong - but the
>>>>> thing that makes me convinced it's a bug is that I have /not/ changed
>>>>> my configuration in any way since June (when I last saw this issue).
>>>>> After my recent upgrade to 4.3 the problem came back - I saw it again
>>>>> last night - but has not reoccurred since then until now.. I really do
>>>>> think there is a subtle bug here.
>>>>> Is it worth me putting all this into a bugzilla entry, even though I
>>>>> haven't yet narrowed down the full circumstances under which it
>>>>> happens?
>>>>> Thanks
>>>>> Jonathan
>>>> The problem is, sssd now uses its own version of winbind, this came in (I
>>>> believe) with version 1.12.0 but I 'think' red-hat backport some things to
>>>> earlier versions. As I understand it, you will be probably be using
>>>> 1.11.6-30 and it is the '30' that says what it contains, perhaps you are
>>>> using winbindd and don't realise it.
>>> As of Version 4.2, the Samba AD/DC is using winbindd by default.
>>> It is started by the samba daemon. Samba is designed to work
>>> with winbindd. sssd does not contain its own winbind, but it
>>> implements some parts of the winbind protocol. So my suggestion
>>> is to remove sss from /etc/nsswitch.conf and use winbind instead.
>>> This is how it is designed to work.
>>> Also, for all I know, the DC always has local unix user and group
>>> IDs, and does NOT use the rfc2307 attributes for this. (Unless
>>> this has changed recently, but I can't imagine how.) So there is
>>> nothing wrong with samba not using the rfc ids on the DC -- this is
>>> how it works by design.
>> On the DC the users & groups get xidNumbers from idmap.ldb, but if they are
>> given uidNumbers and gidNumbers, these will be used instead. As far as I am
>> aware, it has always worked like this.
> Possibly. The current sid_to_unixid code works like this:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> if config has "idmap_ldb:use rfc2307 = true":
>    if sam.ldb contains rfc uid/gid in AD object:
>      use it
> # fall through
> if idmap.ldb contains mapping
>    use it
> else:
>    create new mapping in idmap.ldb
>    use it
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> So there is a config option, which default to "false"
> but is set to true in provision if --use-rfc2307 was given
> to the provision cmdline.
> But if this is enabled, this is really bad, especially
> when using the DC extensively as a file server (which
> should avoided anyways, if possible):
> - Assume a user is created in AD.
> - That user is not immediately given a rfc user id.
> - The users accesses the DC as file server.
>    A idmap.ldb entrie is created and these ids end up
>    in the files the user creates.
> - Later the admin gives this user an rfc user id.
>    (different from the idmap.ldb uid)
> - Next time the user accesses the DC as file server, it
>    can not access his previously created files.
> I may have missed somthing in the code, but it looks like
> this to me.  So I would currently suggest to avoid:
> a) using the DC as a file server (I suggest that anyways)

So do I, but people want to do it anyway.

> b) using the rfc attributes on the DC itself.

Again this is what I recommend.

>> The only problem with using the DC as a fileserver is that the users
>> unixhomedirectory and loginshell are ignored,
> Not the only. See above.

Well yes, but they are the two main ones that people want to use.

>> this is why people use sssd
>> etc, if somebody (and don't ask me, to me 'C' comes between 'B' & 'D') would
>> make samba on the DC use all the RFC2307 attributes, there would be no need
>> to use sssd or nlscd.
> It should not be too big a problem to use the homedir etc
> attribs in principle.  I think we could and (should) do that.
> At least controlled by a config option (possibly the same as
> above).

This should have happened from day one, but better three years late than 
never :-D

> But the biggest problem I see is the creation of the unixIDs:
> I do not see how this can be reliably done, at least in a
> multi-DC environment.  And for sure not in a heterogenious one
> (with Samba and Windows DCs):
> Assume that we change the DC to only use the rfc UIDs
> so that the fallback to idmap.ldb described above is not done.
> (I think this is the only reasonable way to go about it.)

Probably the way to go.
> Then a newly created account is useless until it is given a
> unix ID in AD. So my assumption is that this should be done
> automatically when the user / group is created.
> Now the problem with multiple DCs is that this is a local
> operation changing the global database which is later replicated
> with other DCs. There is no mechanism (I am aware of) in AD
> to protect from two admins on two different dcs to set the same
> UID on different users. For RIDs there is the rid master FSMO
> role, and a similar concept would be needed for unixids in order
> to make this reliable. But there is no such thing in AD.

Could something be built around the 'msSFU30MasterServerName' ?

> For a pure Samba domain, we could probably invent our own
> protocol extension for doing this, but it would not be
> possible to use it in a heterogenious environment (which
> may not be too bad), but it is also not trivial to implement.
> Because of these fundamental problems, I repeat my pov:
> - don't use the rfc attrs on the dc (at least not by default)
> - don't use the DC as a file server
> In a small domain, with a single admin who conciously
> creates all users and groups, ideally always on the same DC,
> all these problems can be avoided.
> But when we proved such mechanisms in Samba, the should be rock
> solid, also in a big multi-DC multi-Admin environment.
> So I think what we could do is this:
> - make "idmap_ldb:use rfc2307" strict (no fallback to idmap.ldb)
> - make this parameter (or a new one) use the other unix attrs from ad
> This would then still need manual creation of the unix IDs, but
> it would be a first step.
> Cheers - Michael

Thanks for looking at this Michael


More information about the samba mailing list