Carnegie Mellon University School of Computer Science

AFS Cells and Cross-Realm Authentication

AFS Cells

AFS is organized into administrative units called cells. Each cell has its own accounts, file-space organization, and policies. Some of the AFS cells at CMU are: - administered by SCS Facilities. - administered by CMU Computing Services. - administered by ECE Facilities.

Hosts running AFS will belong to a particular cell. To see which cell the host you are on belongs to, run the command:

fs wscell

By convention, on hosts running AFS, files for each cell are located under the directory /afs/<cellname>. For example, files in the cell are located under /afs/ On hosts running the SCS Facilities environment, you can abbreviate the cellname and just use the first component of the name for AFS cells at CMU. For example: /afs/cs/ or /afs/andrew/.

Cross-Realm Authentication

Cross-realm AFS authentication allows users in one Kerberos realm (a Kerberos "realm" is a cell, an administrative domain such as CS or Andrew) to manipulate files in another realm without having to authenticate separately in each one. AFS cells that support cross-realm authentication are:

Setting up cross-realm authentication

To set up cross-realm authentication, you need to run the aklog command, while authenticated to your local cell, giving it the name of the foreign AFS cell that you will be authenticating to. Then you will need to create an entry in the foreign cell's pts database. For example, if you are on a host in the cell and want to do cross-realm authentication with the cell, you should run:


If you are on a host in the cell and want to do cross-realm authentication with, you should run:


Running aklog does two things:

  • It provides cross-realm "tokens" that can be used to access files in the foreign cell.
  • It checks to see that there is an entry for these cross-realm tokens in the protection server (pts) database in the foreign cell. If such an entry doesn't already exist, one is created. The cross-realm entry will have the userid@foreigncell.

After running aklog, run the command:

pts createuser <username>@<localcell> -cell <foreigncell>

This creates an entry for you in a foreign cell's protection database. If you want to verify that an entry for your cross-realm tokens exists in the foreign cell's pts database, you can enter the following command:

pts examine <username>@<localcell> -cell <foreigncell>

To see a list of which Andrew or ECE users have established cross-realm identities in the cell, you can use the command:

pts members system:authuser@{ece or andrew}

To see a list of CS users who have established cross-realm identities in the andrew or ece AFS cells, you can use the command:

pts members -cell {ece or andrew}

Note that you will need to run aklog to get cross-realm tokens before accessing files in the other cell. If you are frequently accessing files in another cell, you may wish to put the following in your .login:

aklog <foreigncell>

Adding a cross-realm ID to ACLs and groups

Once a cross-realm ID has been created, you can add it to AFS ACLs and groups the same way you would add a user in the local cell to ACLs and groups. For example, to add the Andrew username "example" to an ACL:

fs sa my_directory rl

and to a group:

pts adduser example:colleagues


By granting permission to access your files in the cell to your username in another realm, you have created the possibility that somebody could break into your other account and access your CS files. (The same concept applies if the cell is where you keep most of your important files and you have granted cross-realm access to your CS username). For this reason, it is suggested that you only add your other realm's username to directories when it is necessary to do so.