[PATCHES] authenticating users during short disconnects from AD

[Uri Simchoni]

I just hit that race myself (my QA did - told them to wait a little
longer for winbindd to initialize before they start harassing it)...

Just to make sure we're on the same page:

#1 - if the special code is returned, we invoke, say,
wbint_IDMapSetDomainSid and retry xid2sid.

#2 - we optimistically try sid2xid with type unspecified, The question
is what to do if that fails - resolve the SIDs only for that call or for
all later calls? Making a mental note that this backend needs sid lookup
before mapping is good for backends which require this by their nature,
such as rfc2307 - avoid the double lookup. OTOH some backends only need
the SID type for allocation of new SIDs, so avoiding the "mental note"
might result in better offline operation with those backends.

Thanks,
Uri.

On 12/28/2016 02:18 PM, Volker Lendecke wrote:
> Hi!
> 
> Sorry for the long post, but if we start working on this I would like
> to really get it right (or as good as we can get it) :-)
> 
> On Wed, Dec 28, 2016 at 12:41:08PM +0200, Uri Simchoni wrote:
>  
>> Sure. I don't know if there are formal requirements as such, I was only
>> thinking "if the client has a ticket, then we should be able to
>> authenticate it and serve files, even if the AD connection is down
>> (having obtained some initial info while it was up)".
> 
> The separate wbint_IDMapInitDomain call looks very good. However, I
> would avoid the tdc cache at very high cost. We can never be sure this
> is complete. idmap_rid already has the problem that the idmap child can
> be forked before the domain list has been queried at all. Using the tdc
> cache makes the window smaller, but the race still exists. We rely on
> the cache to be filled asynchronously for an idmap operation. The cache
> might be filled late or for forest trusts might never be filled.
> 
> What purposes does the IDMapInitDomain call serve?
> 
> Purpose #1 is to solve the idmap_rid xid2sid problem to find the
> domain sid. I've just come across this trying to remove all callers
> of find_domain_from_foo.
> 
> Purpose #2 is to find whether the sid2xid call needs the type of
> object. This is purely local, but it is the parent which needs it.
> 
> Would it be possible to do the idmap initialization purely on demand?
> 
> For the #1 rid backend xid2sid problem we could define another error code,
> just like the ad backend uses DOMAIN_CONTROLLER_NOT_FOUND to request a DC
> name from the parent. We could pick one error message like INVALID_SID to
> make the parent send down the SID and retry. The parent already knows the
> idmap domain name and then can try to query its sources. In the "offline"
> logon case we can rely on the netsamlogon cache. The info3 struct has
> the domain sid, and it also has a base.logon_domain.string. This to
> me looks like a valid mapping from domain name to sid, we could use
> that. netsamlogon_cache_store could pick that mapping from the info3
> and store it in gencache.
> 
> The #2 problem might equally be solved with a special error code. The
> first try could just pass down ID_TYPE_NOT_SPECIFIED. If we have a backend
> like tdb which needs the information, it could return OBJECT_TYPE_MISMATCH
> or some specific message. The parent would then do the lsa call and save
> type requirement for this SID.
> 
> Volker
>