Difference between revisions of "BXadmin:Dce.psu.edu migration"

From CCGB
Jump to: navigation, search
Line 2: Line 2:
  
 
Some thoughts:
 
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
+
* 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. There is now a krb.conf file on all the fileservers and dbservers to make dce.psu.edu an additional 'local' realm. This makes abc123@dce.psu.edu appear as abc123 to the filesystem. '''[DONE]'''
 
* 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'''
 
* 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.
+
Things to do/check:
−
* Any service that uses GSSAPI would need to be verified to work with the cross-realm
+
* services
−
** ssh
+
** ssh + GSSAPI:
−
** IMAP - works with password auth, krb5_kuserok is returning false because username != princpalname
+
*** Linux: works on RHEL5, should work on RHEL6
−
** remctl
+
*** OSX - works on 10.6 with the additonal krb5.conf rules below
−
** LDAP
+
** ssh + password:
 +
*** Linux - works on Linux with second pam_krb5.conf entry. '''[GOOD]'''
 +
*** OSX - Works on OSX 10.6.x if krb5AuthAuthority is set correctly for dce.psu.edu '''[GOOD]'''
 +
** IMAP - works with password auth, krb5_kuserok is returning false because username != princpalname, even with krb5.conf rules ''[PARTIAL]''
 +
** remctl - works fine, principal name looks correct '''[GOOD]'''
 +
** LDAP - GSSAPI binds work, will need additonal rules or ACLs to work with @dce.psu.edu principal names
 +
** graphical login:
 +
*** linux - fine with pam modifications '''[GOOD]'''
 +
*** windows - need to check Windows OpenAFS client to see if Integrated Login works as expected when bound to ACCESS.PSU.EDU
 +
*** osx - need to test
 +
* WebLogin:
 +
** Change cosign cgi rules to make dce.psu.edu logins set REMOTE_USER=abc123 and REMOTE_REALM=dce.psu.edu, and leave FPS the way it is for now.
 +
** The dc=psu,dc=edu backend will return an entry if uid=abc123 exists under dc=bx,dc=psu,dc=edu, but return nothing if abc5123 does not have an entry. Need to test for the existance first and still return a fake search result? Or do we create thin accounts?
 +
** Need to verify that cosign can get kerberos credentials for dce.psu.edu logins so the web apps that do GSSAPI will continue to work.
 +
* ldap2pts:
 +
** Almost works with the new bxAFSPTSName attribute.
 +
** User synchronization works
 +
** Group sync needs some more work, maybe an hour or two, to verify logical correctness and to clean up verbose/debug messages

Revision as of 23:11, 28 September 2011

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. There is now a krb.conf file on all the fileservers and dbservers to make dce.psu.edu an additional 'local' realm. This makes abc123@dce.psu.edu appear as abc123 to the filesystem. [DONE]
  • 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


Things to do/check:

  • services
    • ssh + GSSAPI:
      • Linux: works on RHEL5, should work on RHEL6
      • OSX - works on 10.6 with the additonal krb5.conf rules below
    • ssh + password:
      • Linux - works on Linux with second pam_krb5.conf entry. [GOOD]
      • OSX - Works on OSX 10.6.x if krb5AuthAuthority is set correctly for dce.psu.edu [GOOD]
    • IMAP - works with password auth, krb5_kuserok is returning false because username != princpalname, even with krb5.conf rules [PARTIAL]
    • remctl - works fine, principal name looks correct [GOOD]
    • LDAP - GSSAPI binds work, will need additonal rules or ACLs to work with @dce.psu.edu principal names
    • graphical login:
      • linux - fine with pam modifications [GOOD]
      • windows - need to check Windows OpenAFS client to see if Integrated Login works as expected when bound to ACCESS.PSU.EDU
      • osx - need to test
  • WebLogin:
    • Change cosign cgi rules to make dce.psu.edu logins set REMOTE_USER=abc123 and REMOTE_REALM=dce.psu.edu, and leave FPS the way it is for now.
    • The dc=psu,dc=edu backend will return an entry if uid=abc123 exists under dc=bx,dc=psu,dc=edu, but return nothing if abc5123 does not have an entry. Need to test for the existance first and still return a fake search result? Or do we create thin accounts?
    • Need to verify that cosign can get kerberos credentials for dce.psu.edu logins so the web apps that do GSSAPI will continue to work.
  • ldap2pts:
    • Almost works with the new bxAFSPTSName attribute.
    • User synchronization works
    • Group sync needs some more work, maybe an hour or two, to verify logical correctness and to clean up verbose/debug messages
Retrieved from "http://wiki.bx.psu.edu/index.php?title=BXadmin:Dce.psu.edu_migration&oldid=1517"