[PATCH] libads: fixes to generation of custom krb5.conf
urisimchoni at gmail.com
Sun Jun 7 23:59:49 MDT 2015
On Sun, Jun 7, 2015 at 9:55 PM, Matthieu Patou <mat at samba.org> wrote:
> On 06/04/2015 12:09 AM, Uri Simchoni wrote:
>> Attached pls find some fixes to generation of custom krb5.conf -
> I'm a bit concerned with patch #2, you want still to have the KDC in your
> site first and then the others.
> Your comment says:
> When building a custom krb5.conf file for a domain, an attempt is
> made to get site-specific as well as site-less records, but the
> search for _ldap records yields a cached site-specific result even
> for the site-less query.
> Did you had a look why is it so ?
The internal_resolve_name() call may return a cached result. However,
the cache key is <domain,name type> tuple, not <site,domain,name
type>, so calling internal_resolve_name with/without a site may yield
the same result. "Luckily", in the case of Kerberos, name resolving
results are NOT cached, so calling internal_resolve_name with a
kerberos name type always yields a correct result.
Incidentally - this caching scheme may seem like a bug. It certainly
allows bugs to creep in (as any caching scheme would - once you
duplicate state you call for bugs), but notice that in the case of
LDAP, a bug is avoided by clearing the cache when moving from a
site-specific search to site-less search (well, maybe not entirely
avoided - there could be race conditions).
> If it can't be really fixed I would still prefer that we get first the KDC
> from the local site and then other KDC, I know products that are kerberos
> heavy and I would like to avoid those products querying the KDC at the other
> side of the globe if one is available nearby.
Patch #5 ensures that, the server from server affinity cache is always
first. Usually this is a server from the local site. The rest of the
servers are the ones which answered first to the CLDAP ping (up to 3
of them, and with a clear bias towards on-site servers). Hopefully
their ability to answer first also means they would give best service.
I have to admit I was focused on branch setups, in which a single
on-site DC is being backed by off-site DCs. In that case, it's
important to get the on-site DC first, and also to get some off-site
DCs as backup, but the order between them is not important. In a HQ
setup, we might have a bunch of DCs on site so we never want to go
off-site (i.e. the chance that all on-site servers would fail is so
small that we don't want any chance of shooting ourselves in the leg
by going off-site). I'm not entirely sure how to balance those two
requirements - I hope the current measures are enough:
1. The "last known good server" from affinity cache is always first.
This is intentionally an on-site server (or closest-site server,
sometimes there's no server on-site).
2. The CLDAP pings for on-site servers are sent before pings to
off-site servers (if more than 3 CLDAP pings in total - there's even a
100ms delay after first three).
3. On-site servers are supposed to answer more quickly.
4. When analyzing the responses, the kdcs which answered are listed in
krb5.conf according to the dns query order, which prefers on-site
servers over off-site.
- Old behavior - look only at on-site servers, do not prefer
session-affinity server over others
- New behavior - allow off-site servers (with bias towards on-site
servers), session-affinity server always first.
What do you think? does it look like a reasonable balance? Do note
that the intent to add off-site servers to the list has been there all
along, it just didn't work properly.
> Also why the first call to internal_resolve_name (line 3119) is not using
> auto_name_type ?
My mistake - it's dead code (look a few lines above - there's
absolutely no way for it to execute). I removed in another patch, but
did some re-ordering the patches for submission to the list so it
crept in. The fallback to SRV query is made in line 3164, so this can
be safely deleted.
Attached is a corrected patch set with added patch that removes this
dead code. Nothing else is changed. I didn't add Jeremy's "reviewed
by" because of this added patch.
> Matthieu Patou
> Samba Team
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 12827 bytes
Desc: not available
More information about the samba-technical