[Samba] WBC_ERR_DOMAIN_NOT_FOUND error with RFC2307

Ryan rlichtenwalter at gmail.com
Mon Jul 8 18:48:58 UTC 2019


On Mon, Jul 8, 2019 at 2:32 PM Rowland penny via samba <
samba at lists.samba.org> wrote:

> On 08/07/2019 19:03, Ryan via samba wrote:
> >> 'idmap_rfc2307' got me thinking about the other rarely used backends and
> >> I wonder if you could use 'idmap_script', see 'man idmap_script' for
> >> (limited) info
> >>
> >> Rowland
> >>
> >> Hi Rowland,
> > Indeed, I switched to using the idmap_script back end. For posterity (in
> > case it could ever help you or others), I have included the simple script
> > below. It correctly returns the UID and primary GID, which in our LDAP
> > system is the same, so it gets returned as XID per the man page. Then,
> and
> > this part I don't understand but I verified it in the idmap logs, somehow
> > Samba/winbind becomes aware of the many other GIDs. It subsequently tries
> > to map them back to SIDs (which fails, because there is no mapping, but
> > it's cheap, so whatever).
> >
> > So a few follow-ups, and then I'll be out of your hair:
> >
> > 1. By what mechanism does Samba/winbind go from seeing the UID/GID of the
> > user from the lookup to becoming aware of the other GIDs of the user? I
> am
> > uncomfortable not knowing this, because it seems like it could break.
> > 2. This mechanism *works*. Users can mount shares based on their UNIX
> group
> > membership in the OpenLDAP server. *Thank you!* Now...is there any better
> > way to do this? I love that such a hacky back-end exists, but is this
> what
> > RFC 2307 is supposed to do, but it's truly broken code right now? It
> seems
> > like looking people up by username in a separate LDAP directory after
> > authenticating them with their Kerberos credentials against an AD server
> is
> > quite a common use case (I know many people who do it with older versions
> > of Samba that use the fallback mechanism; I wonder if you are going to
> get
> > lots of questions about this as people transition to EL 7 or 8 with 6
> going
> > EOL).
>
> Your setup is one that hasn't come up before and hopefully will not
> again ;-)
>

The number one thing is that I am very thankful for your help.


> We have had situations where people have had an NT4-style PDC and linux
> fileservers and they have upgraded to AD without problem. You, for
> various reasons, could not, but have found a way around the problem. I
> would urge you to consider this as a reprieve and a breathing point,
> then find a better fix for your problem, it may be that this is done on
> a company basis rather than on a department basis.
>

Exactly this. But isn't this a situation that will come up any time a large
entity (universities of tens of thousands or companies of hundreds of
thousands) deploys an AD server, and the many entities within it want to
piggyback on that server for authentication (so people can use their
institutional accounts) but need to manage their own authorization?

It's not that I can't upgrade to this or that solution. It's that as a
small sub-entity in my organization, I have no permissions on my
organization's AD to do anything (but fortunately join machines), and this
isn't going to change. This situation may be fairly common, being a
many-to-one per AD deployment, than what might be considered the common
case. That's why I say that, in fact, I know of several organizations where
the same thing is going on, and I think I've even read related questions on
the samba lists in the past. You can certainly argue that the organization
should give compartmentalized AD LDAP write access to its various sub-orgs,
but this is always going to be a sticky administrative issue. My only real
alternative to the current solution is to maintain my own authentication
infrastructure, which I already do in parallel for externals to the
university, and which would be vastly easier on me but harder on my users.

Ryan


>
> Rowland
>
>
>


>
> --
> 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