The implementation has the following components:
Several sets of names have special meanings:
(In the general case, realm/ksu/hostname/username would be used.)
The additional internal interfaces include
For dbm, when a direct acl gets too large it becomes a temporary indirect acl with two half lists. Adding to a temporary indirect acl is done by adding to the last member; removing searches all of them. For other systems, temporary indirect won't be necessary.
It will have support for reading bulk data from files, possibly generated by other utilities.
The base form of all names is "realm/service". The realm is included to allow a server to support queries for multiple realms; this also permits an error response of "incorrect realm" if an authserver doesn't actually support a particular realm. The service name should be unique to the service provided, overloading as is used by the "host" service in V5 (or equivalent "rcmd" in V4) is to be avoided.
The service can be subdivided into general and more specific classes. A common one will be "service/hostname" where the hostname is a fully qualified domain name, and describes a particular instance of that service. "rootaccess/ftp.cygnus.com" is an example; "wwwrestart/www.mit.edu" might be another.
These are only conventions, but they are highly recommended. Slashes should be considered component separators. Services with finer breakdown of detail should generally use "service/host/tag" to provide such detail. Since acls can be added to other acls by reference, administration can be simplified by creating specific acls that contain generic ones, and putting the appropriate real principals on the more generic ones.
One possible way to permit encoding of names containing slashes (such as complete kerberos 5 principal names) is to encode the slashes (and other offending characters) using the %XX used in web url's. Thus slash becomes %2F, and percent sign becomes %37. This permits encoding of the zero byte as well, and if newline is encoded as well (%0A), can permit simple line-oriented protocols to pass around aclnames otherwise unencoded.
are sufficient for first implementation. Any of these commands can return success, not permitted, or other failure. (Permission on lists is managed by some AdminMetaLists, which can themselves be managed.)
Each command is committed on the master and propagated to all connected slaves. The client gets a response when the master has the transaction committed, and an additional response when the slaves have all responded or been dropped. If a slave is dropped, the client is informed, as is syslog. (The slave will get the record when it reconnects.)
Later extensions would likely include
There are also special wildcard prinicipals. The simplest is "*" for "all authenticated prinicipals." More restrictive (probably more common) is "*@realm" for all authenticated prinicipals in this realm." The backslash convention is extended to permit the use of "*" as an actual character in a principal name.
Further, the trailing match case of "name/*@realm" indicates a principal with that name but any instances (likely to be a convenience for user with multiple principals.)
First, it causes the whole database to be transmitted in a compact form.
Then it causes the connection to "turn around". The slave starts listening, and the master starts sending commands. In this mode, the slave has a command set that includes the commands in the AdministrationProtocol, but may also support some diagnostic commands.
The slave command set also includes an "accept full dump" command, so that if a slave loses touch with its master and must reconnect and get a new full dump, it can inform all of its children likewise. (A simpler version which would need no specification would simply be for any server which lost it's master to drop all of its slaves; this might lead to unfortunate load redistribution, but remains an option.)
Combining the two makes sure the slave gets complete data, as the server can begin accumulating incremental commands at the time of the dump.
The server commands include an increasing sequence number (possibly a timestamp). A future extension could have the slave record the last seen sequence number, and send it along with the dump command, so that it can receive an incremental update instead of a full dump even after downtime.
If the query succeeds, the client reports such and exits.
If the query fails, the client looks up the current index number and hash (which may be stored in the clear) and prompts the user with the index; if the user produces a value which hashes to the current one, it is stored and the user is let in. (The index number should be updated in a way that doesn't rely on additional disk space being available.)
When the user is accepted, it should prompt for what program to run, giving a default of /bin/sh (or a value taken from krb5.conf.) This makes it easier to deal with local installation problems.
A later version of SendAuthQuery could parse the reply directly and attempt to connect to other slaves in the case of certain types of failure.
MakeAuthQuery provides a packet for delivery to the authserver.
Additional information may be reported, especially in case of a failure.
In Kerberos 4 there were admin_acl.add, del, get, cpw; in Kerberos 5, there are similar acls.
The simplest case would be an overall acl, of the form "realm/authserver/servername/feature" where feature is one of
Specific acl's could later be placed on lists themselves, possibly by using "listname/feature" or better "feature/listname" directly.