|
Being that many users do not know that they should not be signing on as other people, one option would be to present a screen to users every so often. State that payroll wants the correct spelling of their name and what department that they are working in. You could also specify that the name that they fill is not their USER ID. This tends to weed out some of the culprits. Nothing is full proof though. At a company that I worked at once, I turned on password expiration in hopes of keeping people from using each other's passwords. I thought I had it all worked out until one day while I was in the sales department I heard someone yell, "It's time for me to change my password. Who has the book?". I asked the person what book they were looking for. She said that whenever an employee changes their password, their supervisor makes them write their name and new password in a book for employee reference. They keep by the printer so everyone can access it. Eric Kempter -----Original Message----- From: Jim Langston [SMTP:jlangston@conexfreight.com] Sent: Tuesday, September 21, 1999 8:17 AM To: MIDRANGE-L@midrange.com Subject: Re: Fw: Rewarding challenge AS/400... One of my biggest headaches is that we have 3 remote sites on our WAN. Atlanta, San Diego and Atlanta (and I'm in Los Angeles). I can fairly easily confirm who works here, but it is harder out there. I know when I started creating user profiles I would put descriptions in the text field explaining what their position was and where they were located I.E. LA Counter Supervisor (Counter) so that I could determine at least where to find someone. The older profiles, on the other hand, give no indication of who they are or where they work. I.E. System User (Anna) The name in parenthesis is the name of the group profile they are under. I guess I'll just have to start from #1 and confirm everyone, and then fill out the comments. One of my many, many, many projects I need to do. Regards, Jim Langston "Kahn, David [JNJFR]" wrote: > Jim, > > I think the only thing you can do is to audit your user profiles on an > on-going basis. Set yourself a timescale to get through them all, then > parcel them up into so many per week or per month. When you get to the end > start again at the beginning and repeat indefinitely. It's a PITA for you > and irritating for your users but in the light of... > > >I then took a list of our users to our head accounting person/person > >in charge and asked them who still worked here. She didn't know. > > ... I don't see any realistic alternative. You might be able to verify > against active security badges or something like that, but that's just > another system with its own set of holes. > > John Earl's recent posting "AS/400 on alt.hacker" graphically illustrates > the weakness inherent in assuming active account = good account. It might > also be a good idea to check for multiple concurrent sessions by user > profile. This can also give you an indication that profiles are being > shared. > > Dave Kahn > Johnson & Johnson International (Ethicon) France > Phone : +33 1 55 00 3180 > Email : dkahn1@jnjfr.jnj.com (work) > dkahn@cix.co.uk (home) > > -----Message d'origine----- > De: Jim Langston [mailto:jlangston@conexfreight.com] > Date: 20 September 1999 20:06 > A: MIDRANGE-L@midrange.com > Objet: Re: Fw: Rewarding challenge AS/400... > > Well, usually no one tells me they left. And if I find out later, I delete > them, > > or I find out when I analyze user passwords, and see the last date they > changed > their password was over 30 days ago. > > But if someone is using some else's account... > > There was a case, for instance. Someone had left before I had came here, > analyzing passwords was fine. The, this person came back. And then I see > the message in QSYSMSG that their password was disabled. > > Looking at the display station it was disabled from I quickly figured out > what had happened. There was a user who did not have the authority to > do something years ago, call them UserA, so this other user, UserB, let > them use their account. UserB then left the company. No one was around > to delete UserB's account, and UserA continued to use it. UserB comes > back to the company, and changes their password (how they figured out > what their current password was, I don't know, as they must change it > every 30 days). UserA then tries to log in to UserB's account, and disables > it since the password was changed. > > UserA was talken to (talked to?) and told this was a definite no no, never > do > it again, UserB was talken to and told never to give anyone their password, > a message was broadcast that everyone is to use their log in and no one > else's, > if they needed authority have their manager contact me or they weren't > supposed > to be doing it in the first place. > > I then took a list of our users to our head accounting person/person in > charge > and > asked them who still worked here. She didn't know. > > So what to do? > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.