Reliably looking up user's group membership SIDs

[Isaac Boukris]

Hi Stefan, Volker,

Thanks for your comments!

On Thu, Mar 8, 2018 at 1:39 PM, Stefan Metzmacher <metze at samba.org> wrote:
> Am 04.03.2018 um 21:21 schrieb Isaac Boukris via samba-technical:
>> On Fri, Mar 2, 2018 at 7:55 AM, Isaac Boukris <iboukris at gmail.com> wrote:
>>> Suggestion:
>>>
>>> However I was thinking maybe wbclient library could wrap this up for
>>> the user, to make it easier to use with no need to get hands dirty
>>> with machine creds etc (especially as net api isn't a library call).
>>> Then in turn, wbinfo could use this functionality to display user's SIDs.
>>>
>>> Here is how I suggest the API could look like (wip):
>>> https://github.com/frenche/samba/commit/7dbae128461cb190dac2d10e0c5bd1ee9e992976
>>
>>
>> I think a TLDR version is: would it make sense for
>> wbcAuthenticateUserEx() (or wbclient api) to provide a new
>> 'impersonate' level similar to WBC_AUTH_USER_LEVEL_PAC but only
>> requiring the username instead of a PAC, while the winbindd backend
>> will get the PAC via impersonation using machine account?
>> This could allow wbinfo client (as root) and other services to get
>> user's info and relevant membership SIDs (or are there better
>> alternatives?).
>
> I like the idea!
>
> But I see problems in the S4U2Self implementations
> of Heimdal and MIT. E.g. Heimdal currently only supports S4U2Self for
> services in the primary domain. MIT doesn't support S4U2Self with
> enterprice principals.


IMO it would be ok, if the feature will have some limitations at first
- as long as we document those properly.

AFAI recall, MIT doesn't support enterprise-names in gss-api, but the
krb5 api does allow it.
On the other hand, I am not sure we currently pass UPNs as enterprise names.
I also wonder if it''d be ok for a windbind child to chase referrals
to DCs in other domains.

> In both cases we don't have control over the DCs which are used
> while traversing the trust chain. And DNS misconfiguration, as
> well as firewall could case kerberos library calls to hang forever
> (were only SIGKILL could remove the process).


I think the issue with krb5 being a synced api, is a general issue not
specific to s4u.
While trying improve on my prove-of-concept code (basically by staring
at winbind code for hours), I found a similar flow in PAM_AUTH which
also ends up calling kerberos_return_pac() (see
winbindd_raw_kerberos_login).
So I'd like to model the 'impersonate' flow based on that, which seems
like it could work.

> I think the way to implement S4U2Self reliable would be to use
> krb5_{init,tkt}_creds_step(). This would keep the crypto
> part handled by the kerberos library, while the networking part
> (side aware dns lookups and tcp handling) would be done by samba
> code, which already has the required infrastructure to handle async
> network io and proper timeout handling.


I think it would make sense to start by making it work - even if that
means doing it in a thread of a fork.
Then we could invest on improving it to work async etc (not only for
s4u, but krb5 in general).

With best regards.