diff options
| author | Rob Crittenden <rcritten@redhat.com> | 2010-09-17 21:23:08 -0400 |
|---|---|---|
| committer | Rob Crittenden <rcritten@redhat.com> | 2010-09-20 16:04:30 -0400 |
| commit | 74e5d8c2af66a90d5cf85d80f7bafd6a21a724d5 (patch) | |
| tree | 2ebbbdeb1732575906e037603ff10c06ec3e4591 /ipa-client/man/ipa-getkeytab.1 | |
| parent | e648e03d0c730e07a55f64e9fb49a2f9bdcf6e52 (diff) | |
| download | freeipa-74e5d8c2af66a90d5cf85d80f7bafd6a21a724d5.tar.gz freeipa-74e5d8c2af66a90d5cf85d80f7bafd6a21a724d5.tar.xz freeipa-74e5d8c2af66a90d5cf85d80f7bafd6a21a724d5.zip | |
Better distinguish between when DNS discovery works and search more domains.
Passing domain and server on the command-line used to be considered as
DNS autodiscovery worked. This was problematic if there was in fact no
SRV records because krb5.conf would be configured without a specific KDC
causing all Kerberos ops to fail.
Now if you pass in a domain/server it still tries to see if they are
discoverable and if so won't hardcode a server, but will fall back to doing
so if necessary.
Also be a lot more aggressive on looking for the SRV records. Use the
search and domain values from /etc/resolv.conf on the chance that the
SRV records aren't in the domain of the hostname of the machine.
An example of this would be if your laptop is in dhcp.example.com and
your company's SRV records are in corp.example.com. Searching
dhcp.example.com and example.com won't find the SRV records but the user
is likely to have corp.redhat.com in the search list, at least.
ticket 234
Diffstat (limited to 'ipa-client/man/ipa-getkeytab.1')
0 files changed, 0 insertions, 0 deletions