[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha6-917-g8e19a28

[Zachary Loafman]

On Mon, Feb 16, 2009 at 04:49:04PM -0800, Volker Lendecke wrote:
> On Mon, Feb 16, 2009 at 09:01:23AM -0800, Zachary Loafman wrote:
> > The short answer is no, this can't be solved today without a code
> > change. The customer has an environment where NSS is hitting LDAP/NIS,
> > and they need the token to represent what comes back from NIS. It adds a
> > prohibitive administration cost to require the customer to add a
> > username map parameter for every new user in this environment.
> 
> It's not possible to do that with a cron job or a
> replicating LDAP server?

Our customer environments are frequently non-negotiable, especially as
we move more and more into the enterprise. I agree that the environment
is fairly broken, but it is an environment that at least one other
vendor handles in this fashion. We've had a half dozen requests for this
exact behavior.

> > There are other possible code changes, but the way I went seemed the
> > cleanest. I also considered adding some sort of wildcarding into the
> > username map itself, but I think the way I implemented it is fairly
> > straightforward.
> > 
> > I do agree that this entire path is too complex.
> 
> Part of this is there for a reason. We have tons of
> scenarios we have to take care of, many of them for
> compatibility. You for sure follow the samba at samba.org
> mailing list, we still get bad complaints that
> security=share works differently than it used to.
> 
> I REALLY don't want to mess with those code paths if there
> are other alternatives around. Can't you hide that in some
> winbind module or so?

The actual mangling of the token has to occur on the Samba side due to
the way the code is structured. In the Kerberos case, we're not getting
the actual token from the wbc calls, so there isn't really an
opportunity to solve it outside Samba in the existing structure.

In theory, we could add a complete module system for "post auth token
mangling" and roll the existing usermap code out into that as well. I'd
rather not until there's a clear need, especially given how complex it
would be to factor out the existing code. (Read: it's nightmare, I'd
break something, you'd be more unhappy!)

I haven't vetted it completely, but I could probably modify the existing
username map code to accept a wildcard, something like "*=*". It has no
real advantages except a decluttering of the configuration option space
at the expense of a somewhat random syntatic addition to the username
map.

...Zach