Fwd: [OpenAFS] Manually Creating Cross Realm Users

[Douglas E. Engert]

Chris McClimans wrote:
> 
> >>> There is no way to create a openafs server keytab from a password eh?
> >>
> >> Shouldn't be hard to write, instead of reading a key from input, read
> >> a
> >> password and apply string_to_key to it. You should be able to steal
> >> the
> >> code you need from klog or whatever and stick in bos.

The AFS "bos_util adddes" can take a kvno, password+salt and add a key to
the AFS KeyFile. 

The trick is to know what salt was used on the other side. 

> >>
> >>> authority over the afs/cell. If they create the keytab and send it to
> >>> us. They could connect
> >>
> >> Oh, well, if what you have is actually a krb5 keytab, heimdal has a
> >> utility (ktutil, in fact) which will read a keytab and write an AFS
> >> KeyFile)
> >
> > 'asetkey' does this...
> >
> > However, also note that if they administer the kerberos realm they can
> > print themselves a ticket as any user.  Not understanding your threat
> > model it's hard to give you advice.
> 
>  From my previous email:
> """
> One thing here is that the kerberos realm administrators should not
> have administrative
> authority over the afs/cell. If they create the keytab and send it to
> us. They could connect
> to any of our afs services with administrative privileges. 

It is true that anyone who has access to the keys in the AFS KeyFile can 
impersonate any AFS user in the cell. And this is also true for
a Kerberos admin of his realm as the admin has access to the keys for
his realm.   

So one way to setup the AFS cell (lets call it afs.cell.net) using Kerbeors 5 
is to make a special Kerberos realm for the AFS cell (lets call it AFS.CELL.NET). 
You would then do cross realm trust between the AFS cell realm, the user's 
realm (Lets call it USER.REALM.NET) where you don't trust the admins.
But then all of the users look like foreign users to AFS. (Which may bethe
way you want to go.) The kerberos admins you don't trust could only impersonate
the user's in thier realm, and not the cell admins, as the cell admins are only 
in AFS.CELL.NET realm.  

Another way to to do this is to use something like gssklog or aklog,
where the gssklogd or krb524d uses seperate keys for authnetication to 
the daemon then it uses to encrypt the AFS token. The gssklogd uses a 
service principal of gssklog/<server>@<realm> but produces AFS tokens for afs@<cell>   

The deamon then gets to examine and map the Kerberos principal to an AFS user 
and would only map selected users. The gssklogd or ak5log in effect has 
access the the AFS KeyFile, so can create its own AFS tokens, rewriting 
any information it wants. The deamon is under control of the AFS cell admins.  
 
By having this mapping, there is distinction between the cell 
and a realm. The cell then becomes a file server resource domain,
which is willing to accept authnetication from the Kerbeors realm(s),
and the principal names in the realm are mapped to cell principal names.


Thus it is possible to set up a mapping like this:

  admin@AFS.REALM.NET  -> celladmin@afs.cell.net  
  user@AFS.REALM.NET   -> user@afs.cell.net
  user@USER.REALM.NET  -> user@afs.cell.net
  userx@USER.REALM.NET -> usery@afs.cell.net

Note that there is no mapping for:
  <any>@USER.REALM.NET -> celladmin@afs.cell.net


Since you don't want to trust the USER.REALM.NET admins, you
will still need a way for the cell admins to authenticate   
You would still need a way for the cell admin to authenticate, so
would have to keep the old kaserver or setup the AFS.REALM.NET.   
  
> In our
> scenario we only trust the other kerberos
> realm as an authentication source for users, not an administrative
> authority for anything else.
> """
> 
> In our environment we have different roles/organizations which steward
> different resources. In this case
> a central organization handles all campus accounts for
> students/faculty/staff. They are not stewards of the resources
> (like AFS) within a department. I am trying to make sure that in
> trusting them for authentication for users (via kerberos) I
> am not providing them with a method to log in a root onto my AFS cells.
> This would be possible if they had a copy of the
> afs/department.university.edu
> password or keytab.
> 
> Cross realm trust seems to address this issue, but I'll have to hack
> ptserver to allow me to specify unix UID's. A better method would be to
> use nss_ldap or something
> for afs UIDs and groups. Has anyone looked at that before? Are there
> any large barriers to implementing it?

If you have AFS trust the LDAP for group and UID information, you would 
now appear to  have the same trust problem, with the ldap admins
as you have with the user's kerberos admins. 



> -chris
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444