Re: OpenAFS access at login time on MacOS

On 5/11/2023 6:20 AM, Richard Feltstykket ([email protected]) wrote:
> Hello Everyone,
>
> Perhaps it is widely known already, but I just wanted to share a 
> process that I have worked out to get a kerberos ticket and an afs 
> token at login time on MacOS.  It seems to work fine for MacOS Ventura 
> and Monterey;  I have not tested on other versions.
Thanks for posting.
>
> My cell takes FOREVER to log in for some reason, but after aklog 
> completes in the background, I have a token and can access volumes in 
> the cell.

Negative DNS lookups impose an unnecessary time delay.

Assuming the name of your domain example.net is also the name of your 
cell and Kerberos realm (in upper case), and assuming the following 
hostnames for your kdc and afsdb servers

    kdc1.example.net

    afsdb1.example.net

create the following DNS entries

    _kerberos.example.net.  IN TXT   "EXAMPLE.NET"

    _kerberos._afs.example.net. IN TXT "EXAMPLE.NET"

    _kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net.

    _kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net.

    _kerberos._http.example.net. IN SRV 0  0  0 .

    _kerberos._kkdcp.example.net. IN SRV 0 0 0 .

    _afs3-vlserver._udp.example.net. IN SRV 10 0 7003 afsdb1.example.net.

    _afs3-prserver._udp.example.net. IN SRV 10 0 7002 afsdb1.example.net.

If you are using the AFS backup service:

    _afs3-budbserver._udp.example.net. IN SRV 10 0 7021 afsdb1.example.net.

If you are not using the AFS backup service:

    _afs3-budbserver._udp.example.net. IN SRV 0 0 0 .

If there are more than one KDC or AFSDB server, then create one 
_kerberos* SRV record for each KDC and one _afs3-* entry for each AFSDB 
server.

Note that the hostname specified in a SRV record must not be a CNAME; it 
must be A or AAAA records.    For the _afs3-* SRV records for an OpenAFS 
cell which does not support IPv6 the specified hostname should not have 
a AAAA record.   The AuriStorFS cache managers and Linux kernel afs 
(kafs) clients will attempt to contact the location servers via IPv6 if 
there is a AAAA record specified.

A SRV record whose hostname is "." indicates that the service is 
unavailable.

The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens and 
rxkad_k5 tokens.   An OpenAFS cell does not support yfs-rxgk but aklog 
doesn't know that until it is explicitly told by the Kerberos realm that 
there is no yfs-rxgk/[email protected] service principal. 
This requires that GSS-KRB5 be able to quickly resolve the Kerberos 
realm for the name "_afs.unixboxen.net".   The SRV record specified 
above for _kerberos._afs.unixboxen.net is intended to speed up the 
resolution of the hostname to realm mapping if the client is configured 
to do so.

For rxkad_k5 tokens the resolution of which Kerberos realm to use is 
performed by enumerating the hostnames of the location servers, 
performing an A/AAAA DNS query to obtain the IP addresses, then 
performing a PTR record lookup on the IP addresses.  For example

    afsdb1.example.net  A  ->  192.0.2.23

    129.0.2.23 PTR -> host.example.net

    _kerberos.host.example.net TXT -> "EXAMPLE.NET"

    _kerberos.example.net TXT -> "EXAMPLE.NET"  (queried if the
    _kerberos.host.example.net entry is not present)

If there are more than one location service address, then the one that 
is used for resolution of the Kerberos realm can appear to be random 
because whichever is first in the list will be used.

Issuing a "kinit [email protected]" against your realm took a little more 
than six seconds to perform the DNS lookups for the kdc on a macOS 
Ventura 13.4 system.  It then took approximately 180ms to receive the 
expected principal unknown response to the AS-REQ.    I cannot measure 
the time to perform the aklog operations because I cannot obtain a TGT 
to test with.

The time for the AuriStorFS v2021.05-28 cache manager on macOS 13.4 to 
"ls -l /afs/example.net" anonymously was

  * 470ms to resolve the location service via DNS (3 RPCs)
  * 330ms to resolve the location of the "root.cell" volume  (2 RPCs +
    reachability test)
  * 850ms for the fileserver response to the first RPC including the
    fileserver->client callback service TellMeAboutYourself queries (3
    RPCs + reachability tests)
  * 600ms to read the contents of the root directory and obtain status
    info for each entry (3 RPCs)

The ICMP ping rtt from my test system to the location server averages 
115ms.

If the vlserver and fileserver connections were authenticated using 
rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test for each RX 
connection would be replaced by a CHALLENGE|RESPONSE exchange.   If the 
cache manage to fileserver connection was authenticated using yfs-rxgk, 
then the fileserver TellMeAboutYourself query to the cache manager would 
not be performed.

I suspect you can reduce some of the time by adding the DNS records that 
are not present in your domain.   You can observe the DNS, Kerberos and 
AFS queries using wireshark https://www.wireshark.org/download.html.   
Start a capture and set a filter rule of "dns or rx or kerberos or icmp 
or icmpv6".

Feel free to reply privately if you wish to discuss details of your 
actual network configuration.

Jeffrey Altman