it must join the domain, which, as I understand it, involves a) creating a principal for the host, b) adding an entry into the device's keytab, and c) adding a corresponding entry on the domain controllers keytab.
Yes, although it's not exactly a single "keytab" on the domain controller's side – it's setting the keys associated with the host principal's entry specifically. In AD, it means setting the (computer or user) account's password and letting it derive keys from that; then you locally use the same procedure to derive keys and store them in a keytab file.
For AD, you only need a true "computer" account if you want to accept Kerberos tickets for the services usually associated with one in AD, e.g host/ (SSH) or cifs/ (SMB). In many other cases, however, it is sufficient to create a "user" account and assign it 'servicePrincipalName' attribute with the particular service principal you want. For example, a web server accepting SPNEGO for HTTP/ can just as easily be tied to a "user" account.
Also note that in the case of Active Directory, it is impossible to actually "export a keytab" from the KDC, as that would be basically equal to retrieving an account's password hash. Instead, the process is reverse: you would set the account's password to a randomly generated value, then locally generate the keytab using the same password as input to the hashing algorithm.
If you want to do everything using Linux tools, the adcli tool (part of realmd) could be used to provision a computer account in Active Directory, as an alternative to samba-tool. It can create a keytab file if necessary, or you could provide it a strong and randomly-generated password for the computer account and use ktutil to manually generate a keytab for it.
However, adcli does not use any unusual RPC interfaces, so you could do the same using a generic LDAP client too – e.g. you could use python-ldap to create a user or computer account and set its password.
Finally, could just have the AD admin pre-create an account and generate a keytab for you.
Second question: How do I import a keytab entry?
This depends very much on the Kerberos implementation that you're using, but in most cases there is no "import" procedure – the keytab file stays a keytab file, you just place it at the correct location (/etc/krb5.keytab being the traditional "system-wide" default on Unix-like systems).
Recent versions of MIT Krb5 and Heimdal have the "credential store" extension to the GSS API interface to acquire credentials from a specified path, so the "correct location" can be entirely up to you.
(In older versions, it needed to be done through raw libkrb5 APIs or by setting KRB5_KTNAME in the environment.)
Similarly, other Kerberos or GSSAPI implementations (e.g. the Java one) will generally let you load the server keys from a specified path.
