One winbindd: Some thoughts

[Colin Simpson]

Hopefully I'm not speaking out of turn by giving my thoughts as an end
user, well sysadmin. I've posted a number of these before.

> rfc2307: (not actually a blocker, but a relevant point) I do regret not
> pushing harder for 'idmap_ldb:use rfc2307' to be the default in the AD
> DC, because I think that for all Samba modes, absent another overriding
> configuration, that if the directory as uidNumber and gidNumber values,
> we should use them.  So many of our users are frutrated that this
> doesn't 'just work' when it does with nss_ldap et al.

I think now my personal bugbear is that the default group in Winbind
(even setting everything to use RFC2307) is to use the Windows default
group. This makes total sense in a mapped UID/GID but makes less sense
in a RFC2307 world where the GID is specified as gidNumber for the
user's account (but ignored by Winbind) and no way to configure this.
This has a bug ID #8694.

I think in a Samba 4 world Winbind should now by default obtain a TGT on
login. Maybe a join should also generate a keytab too?

An overall cleaner and more consistent with AD handling of RFC2307 would
be nice. When people seem to add RFC2307 attributes to Samba they do
things that Windows AD doesn't, for example setting objectClass
"posixAccount" and "posixGroup", this won't inerop easily with a Windows
DC, I'm guessing. Even though Windows uses RFC2307 it isn't pure
RFC2307, (it's been a while since I setup a clean AD forest) Windows
seems to basically puts the RFC2307 attributes into the standard AD
objectClass "Person" and objectClass "group".It would be nice if
samba-tool's user adding did RFC2307 attributes and the "correct" way.

Also Samba could make life easier for Linux winbind clients by
provisioning reverse DNS zone by default (can't remember if an AD forest
does this by default, I think it might) and this is often required for
Linux kererized services to work (SSH being the obvious one).

>
> rfc2307 IDMAP_BOTH schema extension: We should also work out an
> optionally loaded schema extension to on a per-record basis indicate
> that a uidNumber is also a gidNumber, so we can support having a
> gidNumber assigned to the important domain admins group, which needs to
> be IDMAP_BOTH to own files.

This is a bit nasty (and a nasty case) and won't easily interop but I
can't think of a good other way around this.

>
> As we start to deal with parent-child trusts and multiple domains in a
> forest, there may well be aspects of winbindd's design that don't work
> out, but I'm much more confident of dealing with those in the source3/
> winbindd code than adding all the required work in the source4/ code.
> It will be worthwhile for some part of winbindd, dealing with cracknames
> in particular, to have an overall view of the global catalog.

I tried idmap_adex to get get multi domain to work, never really
succeeded with pulling things like home dir from rfc2307 (was adex
removed? I couldn't find it's source in Samba 4's tree to investigate
why it didn't work (only took a quick look)).

The main issue I've found with Winbind on a multi domain environment
(idmap_ad), apart from it not allowing you to overlap each domain's
idmap UID/GID ranges (which is a bad limitation in itself, and why I
looked at adex), is you can only remove (as far as I can tell) the
domain prefix from usernames from the domain you are a member of
("winbind use default domain"), it would be nice to have the option to
flatten these through your whole forest to simple names (okay you have a
possible collision issue) but would be nice to have that option (I think
probably should be the default with rfc2307).

>
> I hope this helps stir some discussion, and even some further
> implementation.
>
> Thanks,
>
> Andrew Bartlett

Hopefully some of this is helpful!

Thanks again

Colin

________________________________


This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.