[Patches] Expanded group memberships on boundaries of outgoing trusts (bugs #13299, #13300, #13307)
Andrew Bartlett
abartlet at samba.org
Tue Feb 27 18:36:23 UTC 2018
On Tue, 2018-02-27 at 17:54 +0100, Stefan Metzmacher via samba-
technical wrote:
> Hi,
>
> here are patches, which implement the required group membership
> expanding on an AD DC, when we got the users token from a trusted domain.
>
> In order to have tests for this, I've modified
> "samba-tool group {add,remove}members" to accept a sid string
> instead of a user/group name.
>
> Under the hood, a member is specified as
> '<SID=S-1-5-21-222-333-444-555>' and the new fpo_attr module,
> creates a foreignSecurityPrincipal object on the fly.
>
> In order to match the Windows behaviour, it's no longer
> possible to create foreignSecurityPrincipal objects directly.
>
> While being there I had to fix a bug in the "extended_dn_store"
> module, where we allowed linked attributes to deleted objects,
> which should only be allowed for non-linked attributes with
> DN syntax.
>
> In order to protect administrators from believing, we would
> support for "selective authentication" (CROSS_ORIGANIZATION) trusts,
> I added code to ignore these in winbindd and the kdc for now.
>
> I have working code to also implement SID-Filtering and also
> selective authentication, but the patches need more cleanup,
> which is more likely something for the 4.9 release.
>
> With the attached patches (which I'd like to see in 4.8),
> we will be in a very good shape and support a lot of trust
> setups as AD DC. I'll write up a WHATSNEW section about the
> whole trust situation in the next days.
>
> Please review and push:-)
I'll aim this at the perf testing rig, but I already have some
concerns:
The extended dn stuff is pretty performance sensitive (we need to
ensure for replication that we always end up in the 'don't parse the DN
case', so I will want to check those patches.
I'm also concerned about:
> From 3dea1ea7d5c6c8bc95440944a7daa8336f520098 Mon Sep 17 00:00:00 2001
> From: Stefan Metzmacher <metze at samba.org>
> Date: Thu, 22 Feb 2018 23:24:59 +0100
> Subject: [PATCH 08/26] dsdb:unique_object_sids: remove
> unique_object_sids_init() and get the domain_sid during the request
>
> samdb_domain_sid() already has an effective cache, there's no need to
> cache it again.
>
> BUG: https://bugzilla.samba.org/show_bug.cgi?id=13300
>
> Signed-off-by: Stefan Metzmacher <metze at samba.org>
> ---
Yes, we have a cache, but the O(n) behaviour isn't great (at times past
it did feature clearly in profiles, thankfully we have avoided it in a
few key cases), so I wouldn't say it is effective.
That is why that code tried for a startup-time cache.
Finally (and I ask this question genuinely), is this really best
described as a last-moment bug fix? I know incredibly well the
pressure to get features in rather than wait 6 months, but we do have
the feature deadline rules for a reason.
Thanks,
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical
mailing list