× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



MBW0201A:

On Mon, 05 November 2001, MBW0201A@aol.com wrote:

> We usually delete a user profile when an employee leaves. We are saying an 
>employee was fired on October 11 and she says she worked Oct 15 and 16th. User 
>profile is deleted. Other than history log is there anyway to tell when her 
>last sign on or sign off was or when user profile was deleted? Any other ideas 
>on how to track down?


You specified 'other than history log' and mentioned elsewhere that spoolfiles 
(e.g., joblogs) might not be useful -- the history log would be the best 
starting place because you could get quick indications of whether or not any 
signons/signoffs happened or any servers swapped to the user profile plus get 
times of day to help narrow other searches. Eliminating those, various system 
and application journals seem to be the best remaining choices. But I have to 
point out up front that the system will only track what it's been told to track 
and will only keep the info if it's been told to; if it hasn't been configured 
or info's been deleted and proper backups don't exist, all bets are off 
regardless of what's installed.

The first critical system journal is the audit journal QAUDJRN, which is 
mentioned in another post. If it's been configured, locate the related 
receivers for any dates in question, i.e., at least for 10/11 and 10/15-16, and 
make sure they're safe. Restore them if they're saved off-line. (You might need 
an unbroken chain of receivers if the issue becomes serious because it might be 
necessary to demonstrate that the profile was not recreated and deleted again 
later.)

Once you have the appropriate QAUDJRN receivers on-line, there are numerous 
possibilities depending on what configuration options were set during the 
critical times. The previous QAUDJRN post mentioned the 'DO' journal entry type 
so I can skip that. Just be aware that many other entries may supply supporting 
info.

For example, some high-authority user profile had to run the command to delete 
the profile in question. Perhaps the actions of that high-authority profile 
were audited and the actions themselves would be in QAUDJRN. Many other 
possibilities might be found in QAUDJRN as long as the system knew you wanted 
an audit trail. Look over the journal entries in general for ideas.

Another possibility could be the job accounting journal QACGJRN if it was 
created and configured. Also consider the mail server framework journal QZMF -- 
you might find related bits of evidence through the DSPDSTLOG command.

Besides system journals, you might have any number of application journals. Any 
of these might contain entries generated by the user's profile. And any 
journals you have will be your strongest evidence (although searches will be 
more difficult without history log files as a guide) because it's exceeding 
difficult to manipulate journal entries while data files can be changed in 
numerous ways.

If you don't IPL your system often or if you keep joblogs, there could be 
various server joblogs that could provide evidence that a profile was used (not 
what you'd like to find, but it'd at least save you from trying to prove 
otherwise). Servers commonly log messages when a profile attaches from a client 
showing which profile is being served. Search the QEZJOBLOG *outq as a starting 
point, but be aware that joblogs might be in other outqs and that a given 
server might still be active even three weeks later; the joblog might not be 
printed yet.

Overall, if you haven't told your system to keep an audit trail and you don't 
save the journals and log files, you are essentially saying that the audit info 
isn't important to you. Regardless of what products you might have installed, 
you simply won't have the info you're looking for.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com


___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/






As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.