12-Apr-1996 14:50:18 -0700,1780;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Fri, 12 Apr 1996 14:50:17 -0700 (PDT) Return-Path: Received: from saul2.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA22090; Fri, 12 Apr 96 14:50:16 -0700 Received: from localhost by saul2.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA03031; Fri, 12 Apr 96 14:50:10 -0700 Date: Fri, 12 Apr 1996 14:50:10 -0700 (PDT) From: Yonah Karp To: Tracy Stenvik , Jim Fox Cc: James W DeRoest Subject: setname on max Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We're sending out a detailed message Monday morning about Setname going away June 10 and about people needing to collapse their login names to one. This means that some (like Dave Wall, as a matter of fact) need to change their name on Max. I think there is a problem with setname on max: $ setname Password: New logon name: YONAHH Change logon name to YONAHH? [YES]: %SETNAME-I-NEWUSENAM, logon name has been changed to YONAHH Error: err=7 msg='unknown host name' %SETNAME-F-LIFAILURE, unable to communicate with the network server $ It works except for the li piece: This is MAX1. Please log in. Username: YONAHH Password: This is MAX1 and AXP/VMS V6.2 Jim: is there a problem with max being reported in Li? (Could it be because hostname is 'max1'?) Tracy: Would you look at the code on Max to help resolve this? Thanks, guys! Yonah 15-Apr-1996 13:58:36 -0700,3261;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Mon, 15 Apr 1996 13:58:36 -0700 (PDT) Return-Path: Received: from mailer6.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA14910; Mon, 15 Apr 96 13:58:35 -0700 Received: from mx2.cac.washington.edu by mailer6.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA27228; Mon, 15 Apr 96 13:58:34 -0700 Received: from saul2.u.washington.edu by mx2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA09818; Mon, 15 Apr 96 13:58:26 -0700 Received: from localhost by saul2.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA22432; Mon, 15 Apr 96 13:58:24 -0700 Date: Mon, 15 Apr 1996 13:58:24 -0700 (PDT) From: Yonah Karp To: James W DeRoest Cc: Oren Sreebny , is-fsco@cac.washington.edu, Sandy Moy Subject: Re: FAQs for namespace questions In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > > > - point them at gpw to see if their accounts are on the same uid. > > > > > > If you mean different userids on the same uid, yes. Do we > > > need to talk about 'uids' with the users? I think the concept > > > of student number/ ssn > > > > > > The question arises because people don't know what accounts are hooked to > > their ssn and which are supplemental - so we need to give them a way of > > checking their account names - for instance my oren accounts are all on my > > ssn, but my orenhelp account is supplemental - the easiest way to explain > > that may be to explain about uids and then give them a way to check. > > > > This looks like a call for the "owner" field. Will need to move a bit > faster on implementing this to handle this type of request. > > Jim Is the real need for a user to see what accounts are related to the account they're currently logged into? If so, a 'myaccount' utility that would query li and spit the answer back in a user-friendly format (e.g. the below table) might be the answer. I could probably put that together fairly quickly. fmail also tells the user of all userids related to that 'account' (account == encrypted SSN or student number). Note that 'account' in the UA world now matches one-to-one with a uid. So fmail currently is a utility that will tell the user (in a less friendly format) the below. Also, I was under the impression that there was still some disagreement about having real people connected to dept'l accounts. The kind of tool Jim is talking about would be nice to have, but would take some time (and agreement). The more pressing issue (I think) is the one of a user like 'yonah' below. ==== sample output of 'myaccount' ==== Host Userid ==== ====== saul yonah mead ykarp max yooonah carson yonah You have 3 userids for the uid 4143. 2-Apr-1996 16:12:36 -0800,3789;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Tue, 2 Apr 1996 16:12:36 -0800 (PST) Return-Path: Received: from mailer6.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA12704; Tue, 2 Apr 96 16:12:35 -0800 Received: from mx1.cac.washington.edu by mailer6.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA15823; Tue, 2 Apr 96 16:12:34 -0800 Received: from red3.cac.washington.edu by mx1.cac.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA07146; Tue, 2 Apr 96 16:12:31 -0800 Received: by red3.cac.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA08053; Tue, 2 Apr 96 16:12:30 -0800 Date: Tue, 2 Apr 1996 16:12:29 -0800 (PST) From: Mike Pingree To: Oren Sreebny , Jim DeRoest Cc: Sandy Moy , Yonah Karp , Mike Pingree , Jean Wells Subject: Re: Student staff and the fac/student split Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Currently there are two data transfers from HEPPS to the LI Database . Both are scheduled to occur nightly, except during the payroll calculation. Neither specifically selects graduate students (TA's or RA's). Selection criteria (using Job Classification Code) could be modified to include them in either process. UNIFORM ACCESS INFORMATION THE FORMAT IS: Id number Name Home Department Employment Type Birth Date (MMDDYY) Academic Group Code Campus Mail Box THE SELECTION CRITERIA IS: Non separated individuals who have an employment type of: Bargaining Unit, Classified Staff, Physician, Administrative Professional, Faculty, Intercollegiate Athletics, Print Plant, Temporary Exempt, Hourly, Courtesy, Retiree, or Stipend - or - Affiliates who have a campus mail box of 357370 (Howard Hughes Medical Institute). Graduates are NOT included except when they hold an additional appointment that meets one of the above employment type criteria. DIRECTORY INFORMATION Currently the feed to LI contains HEPPS individuals who meet the following selection criteria: Must NOT be separated Must be listed in the Staff Directory THE FILE CONTAINS: Person Name Department 1 Name Department 2 Name Working Title 1 Description Working Title 2 Description Office Address 1 Office Address 2 Work Phone Work Phone Extension Alternate Work Phone Alternate Work Phone Description TDD Fax Number E-mail Address 1 E-mail Address 2 Campus Mail Box Job Classification Code is NOT included. The source of the bulk of the data is from the Directory Data. Ed specifically indicated that only people that wished to be included in the directory should be included in this feed. Our software does NOT preclude adding Graduate Students to the directory. ********** > Date: Tue, 2 Apr 1996 07:32:49 -0800 (PST) > From: Oren Sreebny > To: James W DeRoest > Cc: Sandy Moy , > Mike Pingree , > "Yonah D. Karp" > Subject: Re: Student staff and the fac/student split > > Good - as TA's and RA's are supposed to have access to fac/staff resources > (according to Ron), we'll need to figure out exactly how they're defined > in hepps, and then add track that data in li somehow. I'm not even sure > who the best person is to help us get that definition - maybe Mike knows. > > - Oren 4-Apr-1996 09:42:28 -0800,5901;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Thu, 4 Apr 1996 09:42:28 -0800 (PST) Return-Path: Received: from mailer6.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA13460; Thu, 4 Apr 96 09:42:27 -0800 Received: from mx2.cac.washington.edu by mailer6.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA17799; Thu, 4 Apr 96 09:42:26 -0800 Received: from franklin01.u.washington.edu by mx2.cac.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA09692; Thu, 4 Apr 96 09:42:24 -0800 Received: from tao.cac.washington.edu by franklin01.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA13450; Thu, 4 Apr 96 09:42:22 -0800 Date: Thu, 4 Apr 1996 09:43:53 -0800 () From: Jim Fox To: Yonah Karp Cc: Oren Sreebny , James W DeRoest , Sandy Moy , Kathryn Sharpe , Ken Lowe Subject: Re: New namespace/ dce message In-Reply-To: Message-Id: X-Sender: fox@franklin01.u.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I believe the add-supplemental-account program is already equipped to handle the 'owner' field of a supplemental account. (right Yonah?) Possibly we should give up the implicit linkage between account number (ssn or sn) and account type (staff or student). We might implement additional fields in LI to explicitly designate that an account: (is student) (is staff) (is faculty) (is whatever) or any combintation of these. The only distinction between the two types of account numbers would be that we lookup SNs in the student name database and SSNs in the staff database. We cannot just give SSNs to everybody because some students don't have SSNs (I think). We could, however, use SSNs for those students who have them. Jim Fox On Wed, 3 Apr 1996, Yonah Karp wrote: > Regarding the issue of linking ssn's to sn's in li -- this keeps > coming up, and I think it is an excellent idea for the future. > > However, there is a point that is often glossed over when people > refer to this linking, which is the fact that much of the client > (e.g. 'new' and related clients) design is based on referring to > either the student # or ssn as an 'account'. I'm including Jim > F and Ken in this discussion -- it's nontrivial to get this > linkage, and this will impact our plans. > > On Wed, 3 Apr 1996, Oren Sreebny wrote: > > > It (of course) won't end up being that easy - some departments (like > > nursing) have hundreds of listdists, whcih then get cascaded into > > listprocs and used in weird and wondrous ways. We'll probably need to be > > prepared to create *lots* of supplemental accounts in a big hurry. I > > think turning Dave and Tom loose on this is a good idea. > > > > One question is what we'll do for students who are using separate accounts > > for specfific activities - I'd like to say we'll only create separate > > supplemental accounts with a faculty sign for them, but I hope we're all > > prepared for that to be very unpopular, and the timing wrt the tech fee > > could be tricky. > > > > Another issue is the fact that as far as I know we still are not linking > > supplemental accounts to their owners' ssn in li, and it would be nice to > > get that in place before this creates many more supplemental accounts > > which are essentially unmanaged by any of our regular mechanisms. > > > > - Oren > > > > On Wed, 3 Apr 1996, James W DeRoest wrote: > > > > > > > > We're going to need a procedure for handling listdist accounts. > > > Probably should just convert them to listproc lists. We've > > > got 3 servers in the listproc cluster, so should be able to > > > take the load. Maybe David Wall and Tom Remmers could work up > > > a procedure to convert. > > > > > > Jim > > > > > > On Tue, 2 Apr 1996, Sandy Moy wrote: > > > > > > > Here is my try at the announcement. As I understand it, we have > > > > agreement on the direction statement and Kathryn has passed a few minor > > > > correcitons to Oren on paper -- which probably awaits his return to the > > > > office. > > > > > > > > KAthryn, if Jim/Oren/Yonah think this is the correct message, could you > > > > find time to fix it up quite soon so we can get on with the announcement? > > > > --- > > > > > > > > > > > > System message > > > > ============== > > > > > > > > In order to provide a more secure computing environment and to make it > > > > easier for you to use the many computing and networking resources > > > > available to you at the UW, it is necessary for each person using the C&C > > > > computers to have just one login id that does not change. Through this id > > > > you will eventually be able to move from service to service without > > > > logging in each time. > > > > > > > > For this to happen, there are two intial steps that must take place: > > > > 1. You need to collapse all of your accounts to just one name > > > > 2. 'setname' must be removed from the UA systems so that once a login id is > > > > established, it is not changed. > > > > > > > > We are asking those who have more than one account name to please reduce > > > > your account names to one before June 10, at which time, setname will no > > > > longer be available. > > > > > > > > For a detailed explanation of why we are doing this, and our directions > > > > for the future, please go to the URL http://blah > > > > > > > > > > > > > > > > > > > > 4-Apr-1996 10:51:04 -0800,7439;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Thu, 4 Apr 1996 10:51:04 -0800 (PST) Return-Path: Received: from mailer2.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA19740; Thu, 4 Apr 96 10:51:03 -0800 Received: from mx1.cac.washington.edu by mailer2.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA88350; Thu, 4 Apr 96 10:51:02 -0800 Received: from red5.cac.washington.edu by mx1.cac.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA25269; Thu, 4 Apr 96 10:51:02 -0800 Received: by red5.cac.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA22418; Thu, 4 Apr 96 10:51:01 -0800 Date: Thu, 4 Apr 1996 10:50:59 -0800 (PST) From: Sandy Moy To: Oren Sreebny Cc: James W DeRoest , Yonah Karp Subject: Re: New namespace/ dce message In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Right now, supplimental accounts are not set up to do anything when the person who requested them leaves. I checked with Doris and she says that she would not think that we would want that to happen since the office environment changes and we would end up with more problems than we solved if we tied the departmental supplimental accounts to a ssn. When a departmental account has a problem, someone at the dean or at least supervisory level is contacted in order to resolve. This seems to work now. Class accounts get expired according to what the instructor specifies when the account gets set up. I know we would like to automate more things, but at this point, I do not think planning for what we do with supplimentals should hold up the namespace project. On Thu, 4 Apr 1996, Oren Sreebny wrote: > I think there are a lot more questions than answers here - how do we know > who to contact about an account? What happens when the prof teaching a > class with an account retires and a new person all of a sudden shows up > and wants access to that account? What if an account is misused? What if > an account never gets expired and gets used for non-class purposes after a > class is no longer taught? I think this needs very careful thinking > through in our environment where we have no way of depending on any formal > organizational structure to make sense of this - which is why we've been > depending on personal ownership of all accounts. > > - Oren > > On Thu, 4 Apr 1996, Sandy Moy wrote: > > > Oren, there are a lot of supplimental accounts that I do not consider to > > be associated with a soc. security number. I think I have asked about > > this before, so everyone please bare with me... > > > > Since a lot/most supplimental accounts are for an office-sharing > > environment, why must we tie them to a specific person? It will just > > make more work when that person leaves or changes jobs. Can't we have a > > group of ids whose social security numbers are replaced with department > > or unit names or numbers? Even class supplimentals could have the class > > name as its social security number (realizing that these probably have to > > be numbers... ) And, that would leave us with the very few individuals > > who have a supplimental account so that they can pay us some money... > > that is, accounts that are paid for by a grant... I don't know what to do > > with them since they probably need to separate out their work... > > > > So I guess the question for Oren is: can you live with the supplimental > > accounts not being tagged to some real person in li? (I know you need > > someone to call when there is a problem with the account, but I do not > > think that has to be resolved by making some ss hold that number in li?) > > > > And, for Yonah: what technical nightmares am I suggesting? > > > > On Wed, 3 Apr 1996, Oren Sreebny wrote: > > > > > It (of course) won't end up being that easy - some departments (like > > > nursing) have hundreds of listdists, whcih then get cascaded into > > > listprocs and used in weird and wondrous ways. We'll probably need to be > > > prepared to create *lots* of supplemental accounts in a big hurry. I > > > think turning Dave and Tom loose on this is a good idea. > > > > > > One question is what we'll do for students who are using separate accounts > > > for specfific activities - I'd like to say we'll only create separate > > > supplemental accounts with a faculty sign for them, but I hope we're all > > > prepared for that to be very unpopular, and the timing wrt the tech fee > > > could be tricky. > > > > > > Another issue is the fact that as far as I know we still are not linking > > > supplemental accounts to their owners' ssn in li, and it would be nice to > > > get that in place before this creates many more supplemental accounts > > > which are essentially unmanaged by any of our regular mechanisms. > > > > > > - Oren > > > > > > On Wed, 3 Apr 1996, James W DeRoest wrote: > > > > > > > > > > > We're going to need a procedure for handling listdist accounts. > > > > Probably should just convert them to listproc lists. We've > > > > got 3 servers in the listproc cluster, so should be able to > > > > take the load. Maybe David Wall and Tom Remmers could work up > > > > a procedure to convert. > > > > > > > > Jim > > > > > > > > On Tue, 2 Apr 1996, Sandy Moy wrote: > > > > > > > > > Here is my try at the announcement. As I understand it, we have > > > > > agreement on the direction statement and Kathryn has passed a few minor > > > > > correcitons to Oren on paper -- which probably awaits his return to the > > > > > office. > > > > > > > > > > KAthryn, if Jim/Oren/Yonah think this is the correct message, could you > > > > > find time to fix it up quite soon so we can get on with the announcement? > > > > > --- > > > > > > > > > > > > > > > System message > > > > > ============== > > > > > > > > > > In order to provide a more secure computing environment and to make it > > > > > easier for you to use the many computing and networking resources > > > > > available to you at the UW, it is necessary for each person using the C&C > > > > > computers to have just one login id that does not change. Through this id > > > > > you will eventually be able to move from service to service without > > > > > logging in each time. > > > > > > > > > > For this to happen, there are two intial steps that must take place: > > > > > 1. You need to collapse all of your accounts to just one name > > > > > 2. 'setname' must be removed from the UA systems so that once a login id is > > > > > established, it is not changed. > > > > > > > > > > We are asking those who have more than one account name to please reduce > > > > > your account names to one before June 10, at which time, setname will no > > > > > longer be available. > > > > > > > > > > For a detailed explanation of why we are doing this, and our directions > > > > > for the future, please go to the URL http://blah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 12-Apr-1996 14:04:33 -0700,3389;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Fri, 12 Apr 1996 14:04:33 -0700 (PDT) Return-Path: Received: from saul2.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA20210; Fri, 12 Apr 96 14:04:32 -0700 Received: from localhost by saul2.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA11936; Fri, 12 Apr 96 14:04:28 -0700 Date: Fri, 12 Apr 1996 14:04:28 -0700 (PDT) From: Yonah Karp To: Sandy Moy Cc: James W DeRoest , Ken Lowe , David Wall , Oren Sreebny , 'Larry' L Gales Subject: Final (?) system message In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This will be posted Monday a.m. modulo any last-minute minimal changes. I believe that I have incorporated all changes to date. ========== Setname Going Away ------------------ To provide a more secure computing environment and make it easier for you to use computing and networking resources at the UW, each person using the Uniform Access computers may have just one login name, and that login name will not change. If you have only one login name across all of our computers, this will not affect you. (Your login name is the part of the name before the "@" sign in your email address "userid@u.washington.edu".) Eventually, you will be able to use your one login name to move from service to service without having to log in each time. For this more secure and efficient environment to be realized, two initial steps must take place: 1. If you have more than one login name, you need to change to using just one login name for all your accounts. 2. Computing & Communications staff need to remove the 'setname' command from the UA systems so that once a login name is established for a user, it is not changed. If you have more than one login name, please use the 'setname' command to reduce them to one name before June 10. Starting on June 10, setname will no longer be available. At some point between June 10 and Winter Quarter 1997 we will choose one login name for anyone still having multiple login names. If you are using multiple account names in a way that will be defeated when you rename your accounts to a single name--for example, if you are using multiple names to manage email, to run an email distribution list, or for some other dedicated purpose--and you need help finding alternate solutions that meet your needs, please send email to help@cac.washington.edu. For more information about the future directions in computing that require this change, as well as how to change your login name, please look at the article "Toward An Integrated Namespace" on the C&C Technology Directions page on the World Wide Web at: http://www.washington.edu/tech_home/Directions.html 16-Apr-1996 10:27:53 -0700,3646;000000000011 Return-Path: Received: via tmail-4.0(2) for deroest; Tue, 16 Apr 1996 10:27:53 -0700 (PDT) Return-Path: Received: from mailer4.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA17846; Tue, 16 Apr 96 10:27:52 -0700 Received: from mx2.cac.washington.edu by mailer4.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA71644; Tue, 16 Apr 96 10:27:52 -0700 Received: from mailhost2.cac.washington.edu by mx2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA01002; Tue, 16 Apr 96 10:27:46 -0700 Received: from pentangle.cac.washington.edu by mailhost2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA12755; Tue, 16 Apr 96 10:27:45 -0700 Date: Tue, 16 Apr 1996 10:27:43 -0700 (PDT) From: Oren Sreebny To: Sandy Moy , Jim DeRoest , jamieson@cac.washington.edu, Nathan Dors , yonah@cac.washington.edu, dorish@cac.washington.edu, davidw@cac.washington.edu Cc: Ed Lightfoot , Terry Gray Subject: managing incoming mail on a single account Message-Id: X-Sender: oren@redms.cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks - Like I noted yesterday, as we announced the setname turnoff, we've heard from some students who are using multiple accounts to manage multiple incoming mail streams, which they won't be able to do once they are reduced to a single account name. Those who are using it for serious academic purposes can probably get faculty sigoff on supplemental accounts (which brings up the question again about what entity those accounts get associated with), but those who are using it to manage list subscriptions or other multiple incoming streams are left in the lurch. I think as we are encouraging faculty to use lists we need to respond to this need somehow. As I understand it so far (admittedly limited) here's some current options: - we tell people to move their email to saul and use elm filtering or procmail, point them to the documentation and wish them luck. - user+folder addressing - this does not appear to work on the UA machines at the moment, at least from my limited testing. It does work on red, but you have to use somewhat convoluted syntax, specifying the machine name and the mail directory, e.g. oren+mail/folername+red.cac.washington.edu. - could this be made to work on ua machines? - could the syntax be simplified? - An additional drawback is as we look towards giving faculty tools to automatically create email lists for classes from electronic class lists, the email addresses for students won't have a folder name with them. We could get around this by devising a set of conventions for class folder names and adding these into either the class lists or the mail list creation for the class. - elm filter or procmail - these work on galaxy machines currently, but not on homer. These are difficult to explain to novices. - Could these be made to work on homer? - Could we come up with a simple interface that allows people to easily build filter rules for some common circumstances, like case insensitive text matching in To:, From:, and Subject: fields which save messages to a named folder? What am I missing? Is this not worth worrying about? 16-Apr-1996 12:06:50 -0700,4946;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Tue, 16 Apr 1996 12:06:49 -0700 (PDT) Return-Path: Received: from saul2.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA17870; Tue, 16 Apr 96 12:06:48 -0700 Received: from localhost by saul2.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA15908; Tue, 16 Apr 96 12:06:46 -0700 Date: Tue, 16 Apr 1996 12:06:46 -0700 (PDT) From: Yonah Karp To: Doris Holmes Cc: Oren Sreebny , James W DeRoest , Ken Lowe , Jim Fox Subject: Re: again with change account In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Doris, A change account function is feasable, but will not be available today, or probably even this week -- I'd really like to talk to Ken about this, and he is at a DCE conference this week. At least, I'd like to track down the old chacct (and the folks who had problems with it) and figure out a decent solution to this problem. Regarding your questions, the problem is that whatever is done has to check LOTS more than the uid. When uids change in li, they also need to change for the files this person owned (files are owned by uid) -- and not in just one place, but on all the hosts involved. Also, the account in the CDF needs to change, since that is also different (and this is true for EVERY galaxy on which the change takes place). Also we need to worry about all the special cases -- suppose the user has three userids, and they want two to go to a the same userid but then be converted to a dept's account. And then there's the auf, which is different on every cluster. I am not trying to overwhelm you with detail about how this works -- that's really our job, not something that we want to dump on you -- but I am trying to give you an idea of what will be involved in creating something that will work for most, if not all, cases. (And also to show you that I am not just being nasty when I said yesterday "Don't do that!" to your query "Can I write an eMail app that changes all of these accounts in li?" There really is some reasoning behind my answer.) Is there someone I could talk to about why you all stopped using the old 'chacct'? I'd like to see if we could fix that so that it could work both for you and for us. "Working for us" means that we don't have to manually clean up after accounts that have been changed incompletely (which is something that used to happen more frequently and is quite time-consuming). "Working for you" is explained pretty well below. I will have some comments and questions about your second paragraph, but will deal with them separately. The bottom line is that we will have something for you -- but that it will take a little bit. And it's your call whether you want them to be requesting supplementals immediately. My only comment about that is that filter (which is a utility consultants did tell me would be able to resolve some of these issues without more supplemental accounts being created) could solve some of these problems, for certain users. Yonah On Tue, 16 Apr 1996, Doris Holmes wrote: > Yonah, > > With setname going away, it looks like a change account function will be > needed for student->staff changes, as well as the staff->supplemental > changes we're dealing with now. I will attempt to describe how we would > like for a change account function to function. > > logon name unchanged > account changed > uid changed for staff->sup, unchanged? for stud->staff, staff->stud > forwarding same as uid > > What would happen if the change account always reset the uid and > forwarding? I expect it would be a problem for stud->staff accounts. Maybe > there could be two separate functions, or two options within one function? > > I realize we've got eight weeks, but users want to make the change to a > supplemental account asap. If we get a tool to make the change for them, > they'll continue to cruise along without a break in service and we can > tell them we'll take care of it (before we collapse accounts to one > login). However, if we determine that a change account function resetting > the uid isn't feasible, we can begin telling users to request new > supplementals now. > > Let us know what you think. > > Thanks, > > Doris > > ************************ > > Doris J. Holmes, Manager > Computing & Communications Information > University of Washington > Email: dorish@cac.washington.edu > (206)543-5925, FAX: (206)543-3909 24-Apr-1996 12:38:12 -0700,5482;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 24 Apr 1996 12:38:12 -0700 (PDT) Return-Path: Received: from saul2.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA20988; Wed, 24 Apr 96 12:38:12 -0700 Received: from localhost by saul2.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA05951; Wed, 24 Apr 96 12:38:09 -0700 Date: Wed, 24 Apr 1996 12:38:09 -0700 (PDT) From: Yonah Karp To: "Nathan A. Dors" , Robert Jamieson , Oren Sreebny Cc: James W DeRoest Subject: Re: Using user+folder on Homer (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Note that this makes user+folder easier -- user does not have to note specific IMAP server (e.g. mailer2). Can just specify same server as being used by INBOX. Yonah ---------- Forwarded message ---------- Date: Wed, 24 Apr 1996 12:10:36 -0700 (PDT) From: David L Miller To: Michael Seibel Cc: Yonah Karp , email-dev@cac.washington.edu Subject: Re: Using user+folder on Homer Ahhh, you snuck that one by me! Yes, that should simplify the procedure. It should be noted that in either case, this makes the mailer number hard-coded and will break configurations if a user is moved from one mailer to another... |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) University of Washington, Networks & Distributed Computing, JE-20 4545 15th Ave NE, Seattle WA 98105, USA On Wed, 24 Apr 1996, Michael Seibel wrote: > Date: Wed, 24 Apr 1996 11:20:27 -0700 (PDT) > From: Michael Seibel > To: David L Miller > Cc: Yonah Karp , email-dev@cac.washington.edu > Subject: Re: Using user+folder on Homer > In-Reply-To: > Message-ID: > > Dave, I'm confused by comments in #2 and #5. Why's it necessary to note > the Inbox server's hostname? I thought there was a sub-option to the > "Name of server..." prompt to use the same server as Inbox. At least, I > thought it was added explicitly for this situation. Did you find it > broken or is there some other interface problem rendering it inadequate? > > Sorry for the delayed comment; I've still got a couple hundred messages to > go thru... > > -mikes > > On Tue, 16 Apr 1996, David L Miller wrote: > > > > > Here is a procedure for setting up and using > > user+folder@u.washington.edu for alternate INBOXes on homer/mailer: > > > > 1. First, you need to tell Pine that you want to use a list of > > "Incoming Folders." From the Main Menu, press 's' then 'c' to enter > > the Setup/Configuration screen. Scroll down to the feature-list and > > select the "enable-incoming-folders" feature. > > > > 2. Before exitting the Setup/Config screen, look at the value for > > "inbox-path" near the top of the list. You should see something like > > > > > > > > Note the hostname listed between the "{" and "}", mailer2 in the above > > example. You will need this hostname later in this procedure. > > > > 3. Quit and restart Pine to make the new configuration take effect. > > > > 4. Go to the Folder List and you should see something like > > > > -------------------------------------------------------------------------------- > > Incoming Message Folders > > -------------------------------------------------------------------------------- > > > > INBOX > > > > 5. Create an incoming folder. Press 'a' to Add a folder to the > > Incoming Folders list. At the prompt > > > > Name of server to contain added folder : > > > > enter the hostname you noted in step 2 and press RETURN. At the > > prompt > > > > Folder on "mailer2" to add : > > > > enter "test" and press RETURN. At the prompt > > > > Nickname for folder "test" : > > > > enter "Test Incoming Folder" and press RETURN. > > > > 6. Compose and send a test message to > > > > username+test@u.washington.edu > > > > (substitute your user name for "username" above) > > > > 7. In the Folder List, move the cursor to "Test Incoming Folder" and > > press RETURN to open the folder. The message you composed in step 6 > > should appear in the Index in a few minutes. > > > > Additional folders may be created by repeating step 5 above. Any > > message sent to an address like the one listed in step 6 will arrive > > in the corresponding Incoming Folder. If someone specifies an > > incoming folder that does not exist, the message will be delivered to > > your INBOX. > > > > > > > > |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 > > |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) > > University of Washington, Networks & Distributed Computing, JE-20 > > 4545 15th Ave NE, Seattle WA 98105, USA > > > > > > 7-May-1996 14:07:22 -0700,3817;000000000011 Return-Path: Received: via tmail-4.0(2) for deroest; Tue, 7 May 1996 14:07:22 -0700 (PDT) Return-Path: Received: from mailer10.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA20928; Tue, 7 May 96 14:07:21 -0700 Received: from mx2.cac.washington.edu by mailer10.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA28207; Tue, 7 May 96 14:07:21 -0700 Received: from saul2.u.washington.edu by mx2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA00563; Tue, 7 May 96 14:07:17 -0700 Received: from localhost by saul2.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA04367; Tue, 7 May 96 14:07:15 -0700 Date: Tue, 7 May 1996 14:07:14 -0700 (PDT) From: Yonah Karp To: Oren Sreebny Cc: jamieson@cac.washington.edu, ken@cac.washington.edu, Sandy Moy , Kathryn Sharpe , Jim DeRoest , davidw@cac.washington.edu, larryg@cac.washington.edu Subject: Re: Draft email message for multiple name holders In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We could do it this way (making the user find out their own login names) or we could tell the user their login names. The first would be easier, of course (just send them the message below). If we do it this way the text below is fine with me. Thoughts? Yonah On Mon, 6 May 1996, Oren Sreebny wrote: > This is a draft of the email messages we will send to people with multiple > personal login names once a month between now and January. > > ---------------------------------------------------------------------- > According to our records you have multiple login names on different > Uniform Access computers. To provide a more secure computing environment > and make it easier for you to use computing and networking resources at > the UW, Computing & Communications is in the process of requiring all > account holders on Uniform Access computers to consolidate to a single > login name. > > Your login name is the part of the name before the "@" sign in your email > address "userid@u.washington.edu". > > To consolidate your login names, please use the 'setname' command to > reduce them to one name before June 10. Starting on June 10, setname will > no longer be available. At some point between June 10 and Winter Quarter > 1997 we will choose one login name for anyone still having multiple login > names. > > You can review what names you have on different Uniform Access > computers by checking your email forwarding. To do this, choose the 'F - > forwarding' option from the Other Choices menu on Homer, or use the > 'fmail' command from the Unix shell prompt on any Uniform Access computer. > > If you are using multiple account names in a way that will > be defeated when you rename your accounts to a single > name--for example, if you are using multiple names to manage > email, to run an email distribution list, or for some other > dedicated purpose--and you need help finding alternate > solutions that meet your needs, please send email to > help@cac.washington.edu. > > For more information about the future directions in > computing that require this change, as well as how to change > your login name, please look at the article "Toward An > Integrated Namespace" on the C&C Technology Directions page > on the World Wide Web at: > > http://www.washington.edu/tech_home/Directions.html > > > > > > > 22-May-1996 15:45:35 -0700,2771;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 22 May 1996 15:45:35 -0700 (PDT) Return-Path: Received: from saul4.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA12240; Wed, 22 May 96 15:45:33 -0700 Received: from localhost by saul4.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA12951; Wed, 22 May 96 15:45:28 -0700 Date: Wed, 22 May 1996 15:45:28 -0700 (PDT) From: Yonah Karp Reply-To: Yonah Karp To: Sandy Moy , David Wall , Oren Sreebny , Ken Lowe , 'Larry' L Gales , James W DeRoest , Kathryn Sharpe , Jim Fox Subject: 'pickname' In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, I have a sample dialogue of the current pickname. I have a little more work to do to get the functionality in (seems to work right for everyone but Ken Lowe, for some reason), but it's never too early to finalize the text. The structure of the dialogue is similar to 'setname' in that there are beginning and ending sets of warnings (which users can page through with 'more'), with the real meat of the change/ dialogue taking place between the two sets of warnings. I'm going to send this out in three parts, to (hopefully) make the discussion a bit less unwieldy. To answer some of Dave Wall's questions: > Aside from the _warnings_ about fmail, will this have any > functionality regarding email forwarding? What will it/ > won't it do? It will do just what setname does regarding email -- nothing. It warns about that, too. > I think maybe some of the warnings may need to be up > front, rather than at the end. I'd rather know in advance > that if I complete "pickname" all email addressed to one of > my (former)accounts will bounce. Done, by modeling this after the warnings before/ warnings after structure of setname. > Also, I'd say that adding a tiny note about why we don't > change the other clusters from 'here' would prevent some > hard feelings and questions. Good idea. Let me know where you think such a warning should go. (I would guess in the body, somewhere near where we say the user may need to run pickname on other systems.) Yonah 22-May-1996 15:47:30 -0700,2934;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 22 May 1996 15:47:30 -0700 (PDT) Return-Path: Received: from saul4.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA20724; Wed, 22 May 96 15:47:29 -0700 Received: from localhost by saul4.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA13286; Wed, 22 May 96 15:47:26 -0700 Date: Wed, 22 May 1996 15:47:26 -0700 (PDT) From: Yonah Karp Reply-To: Yonah Karp To: Sandra Moy , David Wall , Oren Sreebny , Ken Lowe , 'Larry' L Gales , James W DeRoest , Kathryn Sharpe , Jim Fox Subject: 'pickname' warnings, first set Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You may use the 'pickname' command to change your login name. However: o CHANGING YOUR LOGIN NAME MAY CAUSE PROBLEMS WITH MAIL -- please carefully note the following issues. o ANY ELECTRONIC MAIL SENT TO YOU AT YOUR OLD LOGIN NAME WILL NOT BE DELIVERED. You must tell your friends that you have a new login name. Any mail sent to your old login name on this computer, or to your old username@u address will be returned to the sender. o YOU MIGHT NOT RECEIVE ELECTRONIC MAIL SENT TO YOU AT YOUR *NEW* LOGIN NAME UNLESS YOU RESET YOUR MAIL FORWARDING. After completing the setname process, we recommend that you log off, log on, and then use the 'fmail -forward' command to check your mail forwarding. WARNING: This is what will happen if you use 'pickname' to change your login name: 1. You will not receive email sent to your old login name on this computer. Any mail sent to your old login name will be returned to the sender with the message 'no such user'. Mail will *NOT* be forwarded to your new login name. 2. All computers in this 'galaxy' of clusters will be affected by this setname change. 3. You must change any references to your home directory that use your old login name. Check for such references in your .cshrc and .login files. If you have made any of your files available to your friends, your friends must also change their references to your home directory. 4. Your weber home page will not work properly until you run new-weber to fix the public_html directory link. 5. Some of the commands on the system may not work until you log off and log back on under your new name. 22-May-1996 15:47:57 -0700,2338;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 22 May 1996 15:47:57 -0700 (PDT) Return-Path: Received: from saul4.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA20492; Wed, 22 May 96 15:47:56 -0700 Received: from localhost by saul4.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA13374; Wed, 22 May 96 15:47:54 -0700 Date: Wed, 22 May 1996 15:47:54 -0700 (PDT) From: Yonah Karp Reply-To: Yonah Karp To: Sandy Moy , David Wall , Oren Sreebny , Ken Lowe , 'Larry' L Gales , James W DeRoest , Kathryn Sharpe , Jim Fox Subject: 'pickname' -- body of utility In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Either the user sees ====== [only one userid across UA hosts] You have exactly one login name across the Uniform Access computers. You don't need to run pickname. [and then is exited from pickname.] ====== OR ====== [more than one userid across UA hosts] ---> Warning set #1 (previous email) then NOW THAT YOU HAVE READ THE WARNING ABOVE, are you sure you still want to change your login name ? [y/n]: if 'y' You have more than one login name, from which you need to pick one. You are "yonah" on franklin saul homer You are "zzzzz" on carson daffy.cac mead You are "frootcake" on nineveh becker inpho.hs Which login name would you like to be your one login name across all systems? frootcake ^^^^^^^^^ Okay, I'll make you frootcake on saul... Done. You may need to run "pickname" on other computers to become "frootcake" everywhere. Thanks for your help! ---> Warning set #2 (next email) 23-May-1996 16:55:27 -0700,3356;000000000011 Return-Path: Received: via tmail-4.0(2) for deroest; Thu, 23 May 1996 16:55:27 -0700 (PDT) Return-Path: Received: from mailer3.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA03914; Thu, 23 May 96 16:55:26 -0700 Received: from mx1.cac.washington.edu by mailer3.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA46231; Thu, 23 May 96 16:55:25 -0700 Received: from mailhost1.cac.washington.edu by mx1.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA18607; Thu, 23 May 96 16:55:23 -0700 Received: from pentangle.cac.washington.edu by mailhost1.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA29843; Thu, 23 May 96 16:55:20 -0700 Date: Thu, 23 May 1996 16:55:32 -0700 (PDT) From: Oren Sreebny To: Yonah Karp Cc: Sandy Moy , Robert Jamieson , Ken Lowe , Kathryn Sharpe , Jim DeRoest , David Wall , Larry Gales Subject: Re: Draft email message for multiple name holders In-Reply-To: Message-Id: X-Sender: oren@redms.cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OK - here's a revised draft: ---------------------------------------------------------------------- According to our records you have multiple login names on different Uniform Access computers. To provide a more secure computing environment and make it easier for you to use computing and networking resources at the UW, Computing & Communications is in the process of requiring all account holders on Uniform Access computers to consolidate to a single login name. Your login name is the part of the name before the "@" sign in your email address "userid@u.washington.edu". To consolidate your login names, please use the 'pickname' command to reduce them to one name. At the beginning of January, 1997 we will choose one login name for anyone still having multiple login names. You can review what names you have on different Uniform Access computers by checking your email forwarding. To do this, choose the 'F - forwarding' option from the Other Choices menu on Homer, or use the 'fmail' command from the Unix shell prompt on any Uniform Access computer. If you are using multiple account names in a way that will be defeated when you rename your accounts to a single name--for example, if you are using multiple names to manage email, to run an email distribution list, or for some other dedicated purpose--and you need help finding alternate solutions that meet your needs, please send email to help@cac.washington.edu. For more information about the future directions in computing that require this change, as well as how to change your login name, please look at the article "Toward An Integrated Namespace" on the C&C Technology Directions page on the World Wide Web at: http://www.washington.edu/tech_home/Directions.html 30-May-1996 12:50:54 -0700,1967;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Thu, 30 May 1996 12:50:54 -0700 (PDT) Return-Path: Received: from saul4.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA21094; Thu, 30 May 96 12:50:54 -0700 Received: from localhost by saul4.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA17246; Thu, 30 May 96 11:40:04 -0700 Date: Thu, 30 May 1996 11:40:04 -0700 (PDT) From: Yonah Karp Reply-To: Yonah Karp To: helpinfo@u.washington.edu Cc: Oren Sreebny , James W DeRoest Subject: pickname/ email to people with multiple login names Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Pickname is installed everywhere. Please let me know ASAP if you see bugs. The email telling folks that they have more than one userid is going out now, as I write this. A few caveats: - There are a few folks with ids on 'lists'. These folks need to be converted to listprocs, I believe. - We're sending mail to folks who have more than one login name on UA machines, excluding max and austen. (Also, max and austen are not mentioned in the list of hosts for a given login name.) Caccluster (bank, red, etc.) is mentioned; however, we are not sending email to folks who have one login name on (e.g.) bank and another on UA hosts until we formulate a policy. (We need to formulate a policy; let's do that after whatever response to this current mail dies down.) - The email folks receive will appear to come from help@cac. The pickname warning files are in /usr/local/lib/pickname.warn.1 and /usr/local/lib/pickname.warn.2, for your (and anyone's) edification. Yonah 5-Jun-1996 11:46:23 -0700,5215;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 5 Jun 1996 11:46:23 -0700 (PDT) Return-Path: Received: from mailer13.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA03978; Wed, 5 Jun 96 11:46:22 -0700 Received: from mx2.cac.washington.edu by mailer13.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA01610; Wed, 5 Jun 96 11:46:22 -0700 Received: from osi-west.es.net by mx2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA01409; Wed, 5 Jun 96 11:46:19 -0700 Received: from grep.nersc.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 11:43:41 -0700 Received: from grep.nersc.gov (localhost [127.0.0.1]) by grep.nersc.gov (8.7.3/8.7.3/ESNET-Feb96) with SMTP id LAA06973; Wed, 5 Jun 1996 11:43:40 -0700 (PDT) Message-Id: <199606051843.LAA06973@grep.nersc.gov> X-Mailer: exmh version 1.6.2 7/18/95 To: nisg@es.net, authtf@es.net Subject: SSH Authentication Reply-To: ramus@es.net Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Wed, 05 Jun 1996 11:43:39 -0700 From: Joe Ramus ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" This could be a useful tool as an alternative to Kerberos 5 rlogin or telnet. Note that it includes Ticket Forwarding and AFS token passing. I assume the forwarded Kerberos ticket could also be converted to a DCE context on the remote system. ------------------------------------------------------------------------------ | Joe Ramus ESnet, LBNL, Berkeley, CA (510) 423-8917 ramus@es.net | ------------------------------------------------------------------------------ ------- =_aaaaaaaaaa0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1" ------- =_aaaaaaaaaa1 Return-Path: bb+transarc.afs.psupport.info-afs-errors@transarc.com Received: from osi-west.es.net (osi-west.es.net [198.128.3.61]) by grep.nersc.gov (8.7.3/8.7.3/ESNET-Feb96) with SMTP id LAA06642 for ; Wed, 5 Jun 1996 11:24:59 -0700 (PDT) Received: from transarc.com by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 11:22:40 -0700 Received: by transarc.com (5.54/3.15) id ; Wed, 5 Jun 96 13:08:40 EDT Received: via switchmail; Wed, 5 Jun 1996 13:08:39 -0400 (EDT) Received: from transarc.com via qmail ID ; Wed, 5 Jun 1996 12:51:26 -0400 (EDT) Received: from transarc.com via qmail ID ; Wed, 5 Jun 1996 12:25:16 -0400 (EDT) Received: from po2.transarc.com via qmail ID ; Wed, 5 Jun 1996 12:13:46 -0400 (EDT) Received: from lukyduk.ifs.umich.edu ([141.211.168.44], [141.211.168.44]) by po2.transarc.com (5.54/3.15) id ; Wed, 5 Jun 96 11:36:45 EDT Received: by lukyduk.ifs.umich.edu (8.7.5/2.2) id LAA16976; Wed, 5 Jun 1996 11:33:59 -0400 (EDT) Received: from dugsong@localhost(127.0.0.1) by lukyduk.ifs.umich.edu via smap (V2.0umich) id sma016973; Wed, 5 Jun 96 15:33:44 GMT Date: Wed, 5 Jun 1996 11:33:43 -0400 (EDT) From: Douglas Song X-Sender: dugsong@lukyduk.ifs.umich.edu To: Ken Hornstein Cc: terryh@mailbox.slac.stanford.edu, info-afs@transarc.com Subject: Re: inter-cell token In-Reply-To: <199606050323.XAA18383@ginger.cmf.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1297 On Tue, 4 Jun 1996, Ken Hornstein wrote: > However, I assume Transarc made rsh work this way specifically to prevent > people from trying to do what you're doing :-) Using rsh to pass your AFS > token sends the token in the clear over the network. At our site our > admins tolerate this on our local net, but I'd never want to send my token > in the clear over the Internet. Anyone who is packet sniffing could grab > it and do all sorts of evil things to my files. > > The _real_ solution is to use Kerberos 5 and forwardable tickets, which might > even be doable if the long-awaited beta 6 actually works :-) If you're interested, I've just completed adding support for traditional Kerberos authentication, AFS password authentication, AFS token and Kerberos ticket passing to Tatu Ylonen's SSH (Secure Shell) package (a drop-in replacement for all the Berkeley r-commands). Tokens and tickets are passed only after Kerberos V4 authentication succeeds, and never in the clear. http://www.cs.hut.fi/ssh for more info on SSH, and write me if you want my diffs to try out. --- Douglas Song dugsong@{umich.edu,monkey.org} University of Michigan ITD GPCC Unix Services www: http://www-personal.umich.edu/~dugsong keyid: C2263445 fingerprint: BF F5 20 EA DA 2F C4 F4 7D 68 4A 50 E4 35 D1 17 ------- =_aaaaaaaaaa1-- ------- =_aaaaaaaaaa0-- 5-Jun-1996 12:33:10 -0700,9722;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 5 Jun 1996 12:33:10 -0700 (PDT) Received: from mailer10.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA03870; Wed, 5 Jun 96 12:33:09 -0700 Received: from mx2.cac.washington.edu by mailer10.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA15066; Wed, 5 Jun 96 12:33:08 -0700 Received: from homer02.u.washington.edu by mx2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA02840; Wed, 5 Jun 96 12:33:03 -0700 Received: from localhost by homer02.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA14324; Wed, 5 Jun 96 12:33:02 -0700 Return-Path: X-Received: via tmail-4.0(2) for eliot; Tue, 4 Jun 1996 11:22:40 -0700 (PDT) Return-Path: X-Received: from mx4.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA24858; Tue, 4 Jun 96 11:22:40 -0700 X-Received: from mx1.cac.washington.edu by mx4.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA20963; Tue, 4 Jun 96 11:22:39 -0700 X-Received: from nitro.openhorizon.com by mx1.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA17517; Tue, 4 Jun 96 11:22:26 -0700 X-Received: by openhorizon.com (SMI-8.6/SMI-SVR4) id LAA24622; Tue, 4 Jun 1996 11:22:13 -0700 Date: Tue, 4 Jun 1996 11:22:13 -0700 From: coverstr@openhorizon.com (Chip Overstreet) Message-Id: <199606041822.LAA24622@openhorizon.com> To: eliot@cac.washington.edu Subject: CyberSafe and Open Horizon Partner to Provide Integrated Single Sign-On Resent-Date: Wed, 5 Jun 1996 12:32:59 -0700 (PDT) Resent-From: Eliot Lim Resent-To: jim deroest Resent-Subject: Resent-Message-Id: Open Horizon and CyberSafe today announced a partnership to integrate Open Horizon's Connection with CyberSafe's Challenger. Challenger is a security solution based on Kerberos that provides interoperability with a number of standard security solutions to provide single sign-on (SSO) across heterogeneous operating systems. With the integration of Challenger and Connection, single sign-on is extended to include client/server, Internet and Intranet applications that access databases such as DB2, Informix, Oracle, Sybase and Microsoft’s SQL Server. In addition to operating system SSO, Challenger also offers such features as: * secured network applications such as rlogin, rsh, rcp, and telnet; * password checking; * incremental propagation; * integration with token security cards; and * interoperability with DCE Security and Kerberos Versions 5 and 4. This relationship further extends Open Horizon's commitment to provide customers with plug-and-play security solutions for their distributed applications. The press release below explains the details of the partnership. Regards, Chip Overstreet Vice President Marketing and Business Development If you would like to be removed from this email list, please let us know. *************************************************************************** Open Horizon and CyberSafe Unite Kerberos-Based Security with Relational Databases and Client/Server Applications Partnership delivers operating system, database, and application single sign-on (SSO) via a single, integrated solution Belmont, CA and Issaquah, WA -- June 4, 1996 -- Open Horizon, Inc. and CyberSafe Corporation today announced a partnership that will give organizations a complete security solution through the integration of Open Horizon's Connection with CyberSafe Challenger. This integration extends the benefits of CyberSafe's secure single sign-on (SSO) solution to client/server applications and heterogeneous databases without requiring customers to change existing applications. CyberSafe Challenger secures distributed networks by providing a single point from which to administer access to multiple authentication mechanisms, message integrity, and message privacy across heterogeneous platforms. With Challenger's SSO solution, users can securely access all their network resources with one password. Challenger is based on the Kerberos network security protocol and provides interoperability with a variety of standard security solutions. Open Horizon's Connection helps organizations tie together the disparate components of distributed computing environments and take advantage of the best enterprise services for security, directory, and application management with its Enterprise Brokers. Connection's flexible architecture allows organizations to simply plug in new or existing applications without any modification to take advantage of these services. The integration of Challenger and Open Horizon's Connection Security Broker enables organizations to extend the CyberSafe security infrastructure to support client/server, Internet, and Intranet applications as well as a variety of databases including DB2, Informix, Oracle, Sybase, and SQL Server. Customers can derive the benefits of user authentication, application authentication, data encryption and secure single sign-on with client/server applications that include PeopleSoft, Visual Basic, PowerBuilder, Oracle's Developer/2000 and JavaSoft's Java. "From their desktops, customers have access to a broader range of secured applications -- extending from the desktop to the mainframe," said Dr. Daniel Webb, president of CyberSafe. "Integration with Open Horizon secures access to a wealth of additional applications from within the CyberSafe Challenger security framework, quickly extending the CyberSafe Challenger single sign-on security solution across an entire enterprise." Security has emerged as a key requirement as organizations expand the scope of their client/server projects. The partnership between CyberSafe and Open Horizon provides an integrated security solution that works across the enterprise. "Customers are looking to the vendor community to offer complete solutions, not just pieces of technology," said Nicholas Zaldastani, president and CEO of Open Horizon. "By working closely with CyberSafe, we are able to deliver highly secure solutions to our customers that require little more than 'plugging in' their existing applications." Standards Support Both CyberSafe and Open Horizon support the industry-standard Generic Security Service Application Program Interface (GSS-API). CyberSafe products are interoperable with DCE security and with Kerberos Versions 5 and 4. Open Horizon supports the full range of industry standards for database access, security integration, directory services, and application services. Pricing and Availability The integrated product will enter beta within 30 days. Pricing information may be obtained directly from Open Horizon and CyberSafe. About CyberSafe Corporation CyberSafe Corporation is the leading provider of cross-industry enterprise network security solutions. CyberSafe's internetwork technology gives its customers the freedom to do business in more ways than previously possible, encouraging collaborative business relationships without compromising security. CyberSafe Corporation is a privately held company based in Issaquah, Washington. For more information about CyberSafe, call (206) 391-6000, send e-mail to sales@cybersafe.com, or visit their World Wide Web site at http://www.cybersafe.com. About Open Horizon, Inc. Open Horizon, Inc. is a leading provider of standards-based connectivity software that assists organizations in moving from departmental to enterprise-wide client/server solutions. The company builds and markets Connection, the first product to provide new or existing applications with plug-and-play access into enterprise services such as heterogeneous databases, user authentication, data encryption, directory services and transaction processing monitors, for both two-tier and three-tier client/server architectures. Open Horizon, headquartered in Belmont, Calif., was founded in 1993. For more information about Open Horizon, call (415) 598-1200, send e-mail to info@openhorizon.com, or visit their World Wide Web site at http://www.openhorizon.com. CyberSafe Press Contact: Laurie Anderson, CyberSafe Corporation, (206) 391-6000, laurie.anderson@cybersafe.com Open Horizon Press Contact: Becky Snape, Niehaus Ryan Group PR, (415) 615-7903 or becky@nrg.com Open Horizon Sales and Marketing Contact: Chip Overstreet, Open Horizon, Inc., (415) 598-1242 or chip@openhorizon.com CyberSafe is a registered trademark of CyberSafe Corporation. The CyberSafe logo and CyberSafe Challenger are trademarks of CyberSafe Corporation. Connection, Database Broker, Application Broker, Security Broker, Directory Broker, Management Broker, Connecting the Enterprise, and QuickBrew are trademarks of Open Horizon, Inc. All other brand names and product names are trademarks, registered trademarks, or tradenames of their respective holders. ************************************************************************ Chip Overstreet main: 415/598-1200 Vice President direct: 415/598-1242 Marketing & Business Development fax: 415/593-1669 Open Horizon, Inc. 1301 Shoreway Road, Suite 125 email: chip@openhorizon.com Belmont, CA 94002 www: http://www.openhorizon.com ************************************************************************ 5-Jun-1996 13:44:36 -0700,5837;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 5 Jun 1996 13:44:36 -0700 (PDT) Return-Path: Received: from mailer3.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA14568; Wed, 5 Jun 96 13:44:36 -0700 Received: from mx1.cac.washington.edu by mailer3.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA45604; Wed, 5 Jun 96 13:44:35 -0700 Received: from osi-west.es.net by mx1.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA19320; Wed, 5 Jun 96 13:44:35 -0700 Received: from achilles.ctd.anl.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 13:41:05 -0700 Received: from pembroke.ctd.anl.gov (pembroke.ctd.anl.gov [146.137.64.73]) by achilles.ctd.anl.gov (8.6.11/8.6.11) with ESMTP id PAA04881; Wed, 5 Jun 1996 15:41:04 -0500 Received: (b17783@localhost) by pembroke.ctd.anl.gov (8.6.11/8.6.11) id PAA39982; Wed, 5 Jun 1996 15:41:02 -0500 Date: Wed, 5 Jun 1996 15:41:02 -0500 Message-Id: <199606052041.PAA39982@pembroke.ctd.anl.gov> From: Doug Engert To: ramus@es.net Cc: nisg@es.net, authtf@es.net Subject: SSH Authentication In-Reply-To: <199606051843.LAA06973@grep.nersc.gov> References: <199606051843.LAA06973@grep.nersc.gov> Joe Ramus writes: > ------- =_aaaaaaaaaa0 > Content-Type: text/plain; charset="us-ascii" > > This could be a useful tool as an alternative to Kerberos 5 rlogin or > telnet. Note that it includes Ticket Forwarding and AFS token passing. > I assume the forwarded Kerberos ticket could also be converted to > a DCE context on the remote system. It might be. But note that it is Kerberos V4, not V5. You can not get a DCE context from it. This looks like another of those interesting side diversions which might be usefull in some areas. Doug > > ------------------------------------------------------------------------------ > | Joe Ramus ESnet, LBNL, Berkeley, CA (510) 423-8917 ramus@es.net | > ------------------------------------------------------------------------------ > > > ------- =_aaaaaaaaaa0 > Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1" > > > ------- =_aaaaaaaaaa1 > > Return-Path: bb+transarc.afs.psupport.info-afs-errors@transarc.com > Received: from osi-west.es.net (osi-west.es.net [198.128.3.61]) by grep.nersc.gov (8.7.3/8.7.3/ESNET-Feb96) with SMTP id LAA06642 for ; Wed, 5 Jun 1996 11:24:59 -0700 (PDT) > Received: from transarc.com by osi-west.es.net with ESnet SMTP (PP); > Wed, 5 Jun 1996 11:22:40 -0700 > Received: by transarc.com (5.54/3.15) id ; Wed, 5 Jun 96 13:08:40 EDT > Received: via switchmail; Wed, 5 Jun 1996 13:08:39 -0400 (EDT) > Received: from transarc.com > via qmail ID ; > Wed, 5 Jun 1996 12:51:26 -0400 (EDT) > Received: from transarc.com > via qmail ID ; > Wed, 5 Jun 1996 12:25:16 -0400 (EDT) > Received: from po2.transarc.com > via qmail ID ; > Wed, 5 Jun 1996 12:13:46 -0400 (EDT) > Received: from lukyduk.ifs.umich.edu ([141.211.168.44], [141.211.168.44]) > by po2.transarc.com (5.54/3.15) id ; > Wed, 5 Jun 96 11:36:45 EDT > Received: by lukyduk.ifs.umich.edu (8.7.5/2.2) id LAA16976; > Wed, 5 Jun 1996 11:33:59 -0400 (EDT) > Received: from dugsong@localhost(127.0.0.1) by lukyduk.ifs.umich.edu > via smap (V2.0umich) id sma016973; Wed, 5 Jun 96 15:33:44 GMT > Date: Wed, 5 Jun 1996 11:33:43 -0400 (EDT) > From: Douglas Song > X-Sender: dugsong@lukyduk.ifs.umich.edu > To: Ken Hornstein > Cc: terryh@mailbox.slac.stanford.edu, info-afs@transarc.com > Subject: Re: inter-cell token > In-Reply-To: <199606050323.XAA18383@ginger.cmf.nrl.navy.mil> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Content-Length: 1297 > > On Tue, 4 Jun 1996, Ken Hornstein wrote: > > > However, I assume Transarc made rsh work this way specifically to prevent > > people from trying to do what you're doing :-) Using rsh to pass your AFS > > token sends the token in the clear over the network. At our site our > > admins tolerate this on our local net, but I'd never want to send my token > > in the clear over the Internet. Anyone who is packet sniffing could grab > > it and do all sorts of evil things to my files. > > > > The _real_ solution is to use Kerberos 5 and forwardable tickets, which might > > even be doable if the long-awaited beta 6 actually works :-) > > If you're interested, I've just completed adding support for traditional > Kerberos authentication, AFS password authentication, AFS token and > Kerberos ticket passing to Tatu Ylonen's SSH (Secure Shell) package (a > drop-in replacement for all the Berkeley r-commands). > > Tokens and tickets are passed only after Kerberos V4 authentication > succeeds, and never in the clear. http://www.cs.hut.fi/ssh for more info > on SSH, and write me if you want my diffs to try out. > > --- > Douglas Song dugsong@{umich.edu,monkey.org} > University of Michigan ITD GPCC Unix Services > www: http://www-personal.umich.edu/~dugsong > keyid: C2263445 fingerprint: BF F5 20 EA DA 2F C4 F4 7D 68 4A 50 E4 35 D1 17 > > > ------- =_aaaaaaaaaa1-- > > ------- =_aaaaaaaaaa0-- 7-Jun-1996 06:18:44 -0700,7284;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Fri, 7 Jun 1996 06:18:44 -0700 (PDT) Return-Path: Received: from mailer12.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA23110; Fri, 7 Jun 96 06:18:43 -0700 Received: from mx1.cac.washington.edu by mailer12.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA18070; Fri, 7 Jun 96 06:18:43 -0700 Received: from osi-west.es.net by mx1.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA01739; Fri, 7 Jun 96 06:18:42 -0700 Received: from achilles.ctd.anl.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 06:11:53 -0700 Received: from pembroke.ctd.anl.gov (pembroke.ctd.anl.gov [146.137.64.73]) by achilles.ctd.anl.gov (8.6.11/8.6.11) with ESMTP id IAA23463 for ; Fri, 7 Jun 1996 08:11:53 -0500 Received: (b17783@localhost) by pembroke.ctd.anl.gov (8.6.11/8.6.11) id IAA35172; Fri, 7 Jun 1996 08:11:51 -0500 Date: Fri, 7 Jun 1996 08:11:51 -0500 Message-Id: <199606071311.IAA35172@pembroke.ctd.anl.gov> From: Doug Engert To: authtf@es.net Subject: Kerberos V5 BETA 6 is released In-Reply-To: <9606070117.AA18720@dcl.MIT.EDU> References: <9606070117.AA18720@dcl.MIT.EDU> MIT has released the next version of Kerberos, 5 beta 6. It should have many of our changes in it. Doug Theodore Y. Ts'o writes: > > I am proud to announce the release of Kerberos V5 Beta 6. This > release contains several new features and enhancements over previous > versions. In particular this release provides a much more stable base > for Kerberos V5 application client and server programs: > > * Kerberos V5B6 is much more portable. Notable new platforms include > Windows-16, OSF/1, NetBSD, SGI and HPUX. (Note: the Macintosh port is > not yet fully complete, especially in regards to the user interface > for managing the user's tickets.) > > * In addition, the Beta 6 release is the first release where shared > libraries are supported. This should significantly decrease the > executable size for Kerberos V5 application clients and servers. > > * The Kerberos V5 API has changed some over Beta 5, but the API should > be considered stable at this point. No major changes are planned > before the 1.0 release of Kerberos. > > Beta 7, which is currently targeted for September 1, will have as its > major emphasis a new and stable administration server (donated by > OpenVision), and in general, a full and stable set of programs for the > Kerberos KDC server. Beta 7 will also include support for the > triple-DES and SHA algorithms. > > Beta 7 will represent the final shakedown release before the final > Release 1.0 of Kerberos, which we are targeting for November 1. > > > > Early in the Beta 6 development cycle, it had been our intention to > continue development on the new administration server which had first > made its appearance in Beta 5. However, it became clear that it was > taking too long to finish creating a solid, reliable administration > server. So, when OpenVision offered to donate their administration > server, we gratefully jumped at this opportunity. > > This integration work is ongoing; Barry Jaspan, whose time has been > generously donated by the Internet Software Consortium, is currently > at work integrating the OpenVision administration system into the MIT > Kerberos sources. This work should be complete by the end of the > summer, at which point we will release Beta 7, which will be the last > stability shakedown release before 1.0 comes out. (The release time > between Beta 7 and 1.0 will be extremely short; a month at most.) > > In the meantime, the Beta 6 release contains our current > administration server, with substantial fixes donated to us by Cygnus > Support so that it is minimally functional. If you have not installed > previous versions of Kerberos, the administration system in Beta 6 > allows you to remotely administer the Kerberos server, and allow users > to change their passwords. (Or, if you have an installed base of > Kerberos V4, you will want to use the V4 compatibility server, which > will allow users with Kerberos V4 administration clients and V4 > kpasswd clients to administer your V5 database.) > > However, if you have an previous Beta 4 or Beta 5 Kerberos KDC already > installed, you may want to defer upgrading your KDC software until the > new administration server is available. Kerberos applications linked > against the Beta 6 application library will work just fine against an > older KDC server. > > > - Ted > > > FTP Instructions: FTP to athena-dist.mit.edu, in /pub/kerberos. Get > the file README.KRB5_BETA6. It will contain instructions on how to > obtain the Beta 6 release. > > > > >> << > >> Please report any problems/bugs/comments to 'krb5-bugs@athena.mit.edu' << > >> << > > > > Appreciation Time!!!! There are far too many people to try to thank > them all; many people have contributed to the development of Kerberos > V5. This is only a partial listing.... > > Thanks to John Linn, Scott Foote, and all of the folks at OpenVision > Technologies, Inc., who donated their administration server for use in > the MIT release of Kerberos. > > Thanks to Paul Vixie and the Internet Software Consortium for > supporting the OV administration server integration work. > > Thanks to Mark Eichin, Ken Raeburn, Nancy Gilman, and all of the > folks at Cygnus Support, who provided innumerable bug fixes and > portability enhancements to the Kerberos V5 tree. > > Thanks to Doug Engert from ANL for providing many bug fixes, as well > as testing to ensure DCE interoperability. > > Thanks to Sean Mullan and Bill Sommerfeld from Hewlett Packard for > their many suggestions and bug fixes. > > Thanks to the members of the Kerberos V5 development team at MIT, both > past and present: Jay Berkenbilt, John Carr, Don Davis, Nancy Gilman, > Sam Hartman, Marc Horowitz, Barry Jaspan, John Kohl, Cliff Neuman, > Paul Park, Chris Provenzano, Jon Rochlis, Jeff Schiller, Harry Tsai, > Ted Ts'o, Tom Yu. > > > Note: > > Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, Moira, and > Zephyr are trademarks of the Massachusetts Institute of Technology (MIT). No > commercial use of these trademarks may be made without prior written > permission of MIT. > > FYI, "commercial use" means use of a name in a product or other for-profit > manner. It does NOT prevent a commercial firm from referring to the MIT > trademarks in order to convey information (although in doing so, recognition > of their trademark status should be given). Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (708) 252-5444 PGP Key fingerprint = 20 2B 0C 78 43 8A 9C A6 29 F7 A3 6D 5E 30 A6 7F i