diff options
Diffstat (limited to 'appl/dceutils/README.original')
| -rw-r--r-- | appl/dceutils/README.original | 335 |
1 files changed, 0 insertions, 335 deletions
diff --git a/appl/dceutils/README.original b/appl/dceutils/README.original deleted file mode 100644 index 088702307a38..000000000000 --- a/appl/dceutils/README.original +++ /dev/null @@ -1,335 +0,0 @@ -KERBEROS and DCE INTEROPERABILITY ROUTINES - -WHAT'S NEW - -When k5dcecon was examining the ticket caches looking to -update one with a newer TGT, it might update the wrong -one for the correct user. This problem was reported by PNNL, -and is now fixed. - -Any Kerberized application can now use a forwarded TGT to establish a -DCE context, or can use a previously established DCE context. This is -both a functional improvement and a performance improvement. - -BACKGROUND - -The MIT Kerberos 5 Release 1.x and DCE 1.1 can interoperate in a -number of ways. This is possible because: - - o DCE used Kerberos 5 internally. Based on the MIT code as of beta 4 - or so, with additional changes. - - o The DCE security server can act as a K5 KDC, as defined in RFC 1510 - and responds on port 88. - - o On the clients, DCE and Kerberos use the same format for the ticket - cache, and then can share it. The KRB5CCNAME environment variable points - at the cache. - - o On the clients, DCE and Kerberos use the same format for the srvtab - file. DCE refers to is a /krb5/v5srvtab and Kerberos as - /etc/krb5.keytab. They can be symlinked. - - o MIT has added many options to the krb5.conf configuration file - which allows newer features of Release 1.0 to be turned off to match - the earlier version of Kerberos upon which DCE is based. - - o DCE will accept a externally obtained Kerberos TGT in place of a - password when establishing a DCE context. - -There are some areas where they differ, including the following: - - o Administration of the database and the keytab files is done by the - DCE routines, rather the the Kerberos kadmin. - - o User password changes must be done using the DCE commands. Kpasswd - does not work. (But there are mods to Kerberos to use the v5passwd - with DCE. - - o DCE goes beyond authentication only, and provides authorization via - the PAC, and the dce-ptgt tickets stored in the cache. Thus a - Kerberos KDC can not act as a DCE security server. - - o A DCE cell and Kerberos realm can cross-realm authenticate, but - there can be no intermediate realms. (There are other problems - in this area as well. But directly connected realms/cells do work.) - - o You can't link a module with the DCE library and the Kerberos - library. They have conflicting routines, static data and structures. - -One of the main features of DCE is the Distributed File System -DFS. Access to DFS requires authentication and authorization, and when -one uses a Kerberized network utility such as telnet, a forwarded -Kerberos ticket can be used to establish the DCE context to allow -access to DFS. - - -NEW TO THIS RELEASE - -This release introduces sharing of a DCE context, and PAG, and allows -any Kerberized application to establish or share the context. This is -made possible by using an undocumented feature of DCE which is on at -least the Transarc and IBM releases of DCE 1.1. - -I am in the process of trying to get this contributed to the general -DCE 1.2.2 release as a patch, so it could be included in other vendors -products. HP has expressed interest in doing this, as well as the -OpenGroup if the modification is contributed. You can help by -requesting Transarc and/or IBM to submit this modification to the -OpenGroup and ask your vendor to adopt this modification. - -The feature is a modification to the setpag() system call which will -allow an authorized process to set the PAG to a specific value, and -thus allow unrelated processes to share the same PAG. - -This then allows the Kerberized daemons such as kshd, to exec a DCE -module which established the DCE context. Kshd then sets the -KRB5CCNAME environment variable and then issues the setpag() to use -this context. This solves the linking problem. This is done via the -k5dfspag.c routine. - -The k5dfspag.c code is compiled with the lib/krb5/os routines and -included in the libkrb5. A daemon calls krb5_dfs_pag after the -krb5_kuserok has determined that the Kerberos principal and local -userid pair are acceptable. This should be done early so as to give -the daemon access to the home directory which may be located on DFS. -If the .k5login file is used by krb5_kuserok it will need to be -accessed by the daemon and will need special ACL handling. - -The krb5_dfs_pag routine will exec the k5dcecon module to do all the -real work. Upon return, if a PAG is obtained, krb5_dfs_pag with set -the PAG for the current process to the returned PAG value. It will -also set the KRB5CCNAME environment as well. Under DCE the PAG value -is the nnnnnnn part of the name of the cache: -FILE:/opt/dcelocal/var/security/creds/dcecred_nnnnnnnn. - -The k5dcecon routine will attempt to use TGT which may have been -forwarded, to convert it to a DCE context. If there is no TGT, an -attempt will be made to join an existing PAG for the local userid, and -Kerberos principal. If there are existing PAGs, and a forwarded TGT, -k5dcecon will check the lifetime of the forwarded TGT, and if it is -less than the lifetime of the PAG, it will just join the PAG. If it -is greater, it will refresh the PAG using the forwarded TGT. -This approach has the advantage of not requiring many new tickets from -having to be obtained, and allows one to refresh a DCE context, or use -an already established context. - -If the system also has AFS, the AFS krb5_afs_pag should be called -after the krb5_dfs_pag, since cache pointed at via the KRB5CCNAME may -have changed, such as if a DFS PAG has been joined. The AFS code does -not have the capability to join an existing AFS PAG, but can use the -same cache which might already had a -afsx/<afs.cell.name>@<k5.realm.name> service ticket. - - -WHAT'S IN THIS RELEASE - -The k5prelogin, k5dcelogin, k5afslogin (with ak5log) were designed to -be slipped in between telnetd or klogind and login.krb5. They would -use a forwarded Kerberos ticket to establish a DCE context. They are -the older programs which are included here. They work on all DCE -platforms, and don't take advantage of the undocumented setpag -feature. (A version of k5dcelogin is being included with DCE 1.2.2) - -K5dcecon is the new program which can be used to create, update or -join a DCE context. k5dcecon returns KRB5CCNAME string which contains -the PAG. - -k5dfspag.c is to be built in the MIT Kerberos 5 release 1.0 patchlevel -1 and added to the libkrb5. It will exec k5dcecon and upon return set -the KRB5CCNAME and PAG. Mods to Kerberized klogind, rshd, telnetd, -ftpd are available to use the k5dfspag. - -Testpag.c is a test programs to see if the PAG can be set. - -The cpwkey.c routine can be used to change a key in the DCE registry, -by adding the key directly, or by setting the salt/pepper and password -or by providing the key and the pepper. This could be useful when -coping keys from a K4 or AFS database to DCE. It can also be used when -setting a DCE to K5 cross-cell key. This program is a test program -For mass inserts, it should be rewritten to read from stdin. - -K5dcelogin can also be called directly, much like dce_login. -I use the following commands in effect do the same thing as dce_login -and get a forwardable ticket, DCE context and an AFS token: - - #!/bin/csh - # simulate a dce_login using krb5 kinit and k5dcelogin - # - setenv KRB5CCNAME FILE:/tmp/krb5cc_p$$ - /krb5/bin/kinit -f - exec /krb5/sbin/k5dcelogin /krb5/sbin/k5afslogin /bin/csh - #exec /krb5/sbin/k5dcelogin /bin/csh - -This could be useful in a mixed cell where "AS_REQ" messages are -handled by a K5 KDC, but DCE RPCs are handled by the DCE security -server. - -TESTING THE SETPAG - -The krb5_dfs_pag routine relies on an undocumented feature which is -in the AIX and Transarc Solaris ports of DCE and has been recently -added to the SGI version. To test if this feature is present -on some other DFS implementation use the testpag routine. - -The testpag routine attempts to set a PAG value to one you supply. It -uses the afs_syscall with the afs_setpag, and passes the supplied -PAG value as the next parameter. On an unmodifed system, this -will be ignored, and a new will be set. You should also check that -if run as a user, you cannot join a PAG owned by another user. -When run as root, any PAG should be usable. - -On a machine with DFS running, do a dce_login to get a DCE context and -PAG. ECHO the KRB5CCNAME and look at the nnnnnnnn at the end. It -should look like an 8 char hex value, which may be 41ffxxxx on some -systems. - -Su to root and unsetenv KRB5CCNAME. Do a testpag -n nnnnnnnn where -nnnnnnnn is the PAG obtained for the above name. - -It should look like this example on an AIX 4.1.4 system: - - pembroke# ./testpag -n 63dc9997 - calling k5dcepag newpag=63dc9997 - PAG returned = 63dc9997 - -You will be running under a new shell with the PAG and KRB5CCNAME set. -If the PAG returned is the same as the newpag, then it worked. You can -further verify this by doing a DCE klist, cd to DFS and a DCE klist -again. The klist should show some tickets for DFS servers. - -If the PAG returned is not the same, and repeated attempts show a -returned PAG decremented by 1 from the previous returned PAG, then -this system does not have the modification For example: - - # ./testpag -n 41fffff9 - calling k5dcepag newpag=41fffff9 - PAG returned = 41fffff8 - # ./testpag -n 41fffff9 - calling k5dcepag newpag=41fffff9 - PAG returned = 41fffff7 - -In this case the syscall is ignoring the newpag parameter. - -Running it with -n 0 should get the next PAG value with or without -this modification. - -If the DFS kernel extensions are not installed, you would get -something like this: - - caliban.ctd.anl.gov% ./testpag -n 012345678 - calling k5dcepag newpag=012345678 - Setpag failed with a system error - PAG returned = ffffffff - Not a good pag value - -If you DFS implementation does not have this modification, you could -attempt to install it yourself. But this requires source and requires -modifications to the kernel extensions. At the end of this note is an -untested sample using the DCE 1.2.2 source code. You can also contact -your system vendor and ask for this modification. - -UNICOS has a similar function setppag(newpag) which can be used to set -the PAG of the parent. Contact me if you are interested. - -HOW TO INSTALL - -Examine the k5dfspag.c file to make sure the DFS syscalls are correct -for your platform. See the /opt/dcelocal/share/include/dcedfs/syscall.h -on Solaris for example. - -You should build the testpag routine and make sure it works before -adding all the other mods. If it fails you can still use the klogind -and telnetd with the k5prelogin and k5dcelogin code. - -If you intend to install with a prefix other than /krb5, change: -DPAGAIX and K5DCECON in k5dfspag.c; the three references in -k5prelogin.c; and the DESTDIR in the Makefile. - -Get k5101.cdiff.xxxxxx.tar file and install the mods for ANL_DFS_PAG -and ANL_DCE to the MIT Kerberos 5 source. These mods turn on some DCE -related changes and the calls to krb5_dfs_pag. - -Symlink or copy the k5dfspag.c to the src/lib/krb5/os directory. - -Add the -DANL_DFS_PAG and -DANL_DCE flags to the configuration. - -Configure and Build the Kerberos v5. - -Modify the k5dce Makefile for your system. - -Build the k5dcecon and related programs. - -Install both the MIT Kerberos v5 and the k5dcecon and dpagaix if AIX. - -The makefile can also build k5dcelogin and k5prelogin. The install -can install k5dcelogin, k5prelogin and update the links for login.krb5 --> k5prelogin and moving login.krb5 to login.k5. If you will be using -the k5dcecon/k5dfspag with the Kerberos mods, you don't need -k5prelogin, or the links changed, and may not need k5dcelogin. - -Note that Transarc has obfuscated the entries to the lib, and -the 1.0.3a is different from the 1.1. You may need to build two -versions of the k5dcelogin and/or k5dcecon one for each. - -AIX ONLY - -The dpagaix routine is needed for AIX because of the way they do the -syscalls. - -The following fix.aix.libdce.mk is not needed if dce 2.1.0.21 -has been installed. This PTF exposed the needed entrypoints. - -The fix.aix.libdce.mk is a Makefile for AIX 4.x to add the required -external entry points to the libdce.a. These are needed by k5dcecon -and k5dcelogin. A bug report was submitted to IBM on this, and it was -rejected. But since DCE 1.2.2 will have a k5dcelogin, this should not -be needed with 1.2.2 - -Copy /usr/lib/libdce.a to /usr/libdce.a.orig before starting. Copy the -makefile to its own directory. It will create a new libdce.a which you -need to copy back to /usr/lib/libdce.a You will need to reboot the -machine. See the /usr/lpp/dce/examples/inst/README.AIX for a similar -procedure. IBM was not responsive in a request to have these added. - -UNTESTED KERNEL EXTENSION FOR SETPAG - -*** src/file/osi/,osi_pag.c Wed Oct 2 13:03:05 1996 ---- src/file/osi/osi_pag.c Mon Jul 28 13:53:13 1997 -*************** -*** 293,298 **** ---- 293,302 ---- - int code; - - osi_MakePreemptionRight(); -+ /* allow sharing of a PAG by non child processes DEE- 6/6/97 */ -+ if (unused && osi_GetUID(osi_getucred()) == 0) { -+ newpag = unused; -+ } else { - osi_mutex_enter(&osi_pagLock); - now = osi_Time(); - soonest = osi_firstPagTime + -*************** -*** 309,314 **** ---- 313,319 ---- - } - osi_mutex_exit(&osi_pagLock); - newpag = osi_genpag(); -+ } - osi_pcred_lock(p); - credp = crcopy(osi_getucred()); - code = osi_SetPagInCred(credp, newpag); - -Created 07/08/96 -Modified 09/30/96 -Modified 11/19/96 -Modified 12/19/96 -Modified 06/20/97 -Modified 07/28/97 -Modified 02/18/98 - - Douglas E. Engert <DEEngert@anl.gov> - Argonne National Laboratory - 9700 South Cass Avenue - Argonne, Illinois 60439 - (630) 252-5444 |