chip@eniac.seas.upenn.edu (Charles H. Buchholtz) (06/26/91)
In article <1991Jun26.120235.27892@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >A requester, whether student or faculty from another >department, is advised to request access in writing to the dept chair. We have a slightly looser policy on our machine, which also works well. If the request is from a student, faculty or staff member of the department, then I verify their status (faculty is trivial, staff I check with the office manager, and students get checked with the grad or undergrad assistant). If the request is from anyone else, I tell them that the request needs to come from a faculty member of my department. Any faculty member can create an account for anybody. I keep a record of why the account was created and who the sponsor was. Twice a year I go through the accounts and eliminate those students, faculty and staff who are no longer here. I them mail a list to every sponsor listing the accounts that have sponsored and asking which should be deleted. Of course, I give three week warnings, grace periods, etc. Actually, in most cases I don't delete accounts, I make a note that the account is in grace period and delete it in the next cycle. This avoids a lot of "I need another week to move my files" hassles. -- Charles H. Buchholtz Systems Programmer chip@seas.upenn.edu School of Engineering and Applied Science University of Pennsylvania
sblair@upurbmw.dell.com (Steve Blair) (06/26/91)
An approach that I've used in several companies works around a concept of paper trails. Especially important if you're an Internet site, as things can & do happen. Consider this: A user is caught by the watchful eyes of the sysadmin group attempting to connect to machine/companies/etc., that that user should *not* be connecting to. A sysadmin from one of the other sites calls *YOU* on the phone, and tells you: "Someone is attempting to connect to our site from yours, and they've not got a reason/account/friend here". You're now stuck with a dilema, is this internal employee a breakin artist, or just "exploring". If the case is the latter, then a discussion with his *manager(NOT HIM/HER)* should then ensue, with the manager of that employee about their behaviour is totally not "net.acceptable", and that it'd better end immediately. If you continue to watch the employee, such as the case with the first example, there exists a clause in most companies that can cause theivery as a situation that can be a cause for dismissal. Many folks will ask for accounts on machines that they need. Also there's another "class" that >perceives< that they need an account. Best option is to allow management to decide, it covers your tail!!! A simple form that has things like proposed login name, *reason for access need, etc*, signed by their manager, will leave you a paper trail that's a *MUST* in the case of the dismissal. I know that the way the labor laws are going that most companies' lawyers will *NOT* recommend a dismissal, if some type of paperwork is not there. Because, if that employee who gets dismissed goes to a sleazoid lawyer, for a wrongfull dismissal lawsuit, it's 100% CYA with the paperwork. I've had this at a company(NOT DELL) where I used to work, and it took me a few hours to determine that this employee was *not* just playing around. I will not discuss how I determined that, other than to say, that with the help of several "impartial" observers working through the evening, we were able to get enough information to the next morning turn it over to the respevtive managers & H/R. It's possible that we would have terminated that employee, had he not resigned first thing the next morning. **********************IMPORTANT************************************* When considering the "circle of trust" that we as sysadmins have to deal with, always have *some paperwork* trail. Without it, your company could/would potentially be in for major hassles in court !!!!!! CYA CYA CYA CYA, and then some more, you can't in 90% ++ cases, go wrong!!! -- Steve Blair DELL UNIX DIVISION sblair@upurbmw.dell.com ================================================================ *Notice: "/earth is 98% full, please delete anyone you can...." -anonymous @dell.com
wjb@cogsci.cog.jhu.edu (06/27/91)
In article <22300@uudell.dell.com> sblair@upurbmw.dell.com (Steve Blair) writes: > >A user is caught by the watchful eyes of the sysadmin group attempting >to connect to machine/companies/etc., that that user should *not* >be connecting to. A sysadmin from one of the other sites calls *YOU* >on the phone, and tells you: > >"Someone is attempting to connect to our site from yours, and they've >not got a reason/account/friend here". >... >I've had this at a company(NOT DELL) where I used to work, and it >took me a few hours to determine that this employee was *not* >just playing around. Your idea of a paper trail sounds like a good one and it sounds like you dealt with your situation (gathered your own evidence) in a reasonable manner. Written policy is also helpful. I do have problems with this statement though: >"Someone is attempting to connect to our site from yours, and they've >not got a reason/account/friend here". I couldn't possibly accept that statement without question. The administrator hopefully would know that my user didn't have an account on their machines, might by talking to EVERYONE at their site discover that my user didn't have any friends there, but unless telepathic couldn't possibly know if my user had a reason (good or not). An administrator does not become a deity upon reaching that status (I should know), nor are all users scum. Again, it seems like you had a real situation and handled it judiciously. For discussions on a different example, take a look in "comp.admin.policy" where disagreement on whether the actions of the user were "wrong" not to mention the appropriateness of the administrator's response. My point here: be sure you know the difference between "facts" and "assumptions" and with which you are dealing. Bill Bogstad