BXadmin:Dce.psu.edu migration

This would not be a complete migration. Real user accounts would live in dce.psu.edu. All other system accounts and admin accounts would remain in BX.PSU.EDU.

Some thoughts:

• Because of the BX.PSU.EDU -> dce.psu.edu trust, abc123@dce.psu.edu can request afs/bx.psu.edu@BX.PSU.EDU service tickets. To the AFS fileservers and dbservers, they would look like abc123@dce.psu.edu
• would need a bxAFSUserName, similar to bxAFSGroupID, but storing the PTS entry name, not the ID, to account for the disconnect between the POSIX username and the PTS name. [DONE] - bxAFSPTSName
• Linux and Solaris can use PAM stack tricks to try BX.PSU.EDU before dce.psu.edu. On RedHat, realm=FOO should suffice.
  • On RedHat, realm=dce.psu.edu cell=bx.psu.edu seems to work fine when listed alongside another pam_krb5 [VERIFIED]
• For OSX, we might be able to write a plugin to be called via /etc/authorization?
• On Windows (as this is what started this whole thing), hosts would be bound to ACCESS.PSU.EDU, and users would select 'dce.psu.edu' at login. Need to verify that KfW and OpenAFS do the Right Thing and know how to get tokens.
• WebLogin: The dc=psu,dc=edu LDAP hack would need to do the right thing when cosign talks to it. dce.psu.edu would be made the default realm. Maybe we could get away with killing our cosign service entirely? That would be awesomesauce.
• How does system:authuser work with foreign realms? atc135@dce.psu.edu is, by default, a member of system:authuser@dce.psu.edu. Can I change this somehow, or at least nes the two groups?

Other concerns:

• For the users that use OSX, this would have to be an all-at-once switch, or if the user only logs into one machine, have two classes in cfengine for each of the default_realm settings, and convert the users and machines piecemeal.
• Any service that uses GSSAPI would need to be verified to work with the cross-realm
  • ssh
  • IMAP - works with password auth
  • remctl
  • LDAP