Greetings,
We have a cifs share that gets worked on by various people in the company in different countries and business groups. We have access opened up to users with a valid Windows 2003 Server domain authentication. Since we don't know everyone who will have access to this, we don't have unix accounts for them, or entries in the usermap.cfg file. This share is also nfs accessed and has unix security style.
The problem is when we look in the messages files these users seem to show up with their workstation name followed by the $ sign. It's difficult to track who owns the machine and who logged into it. Here is an trimmed example entry:
auth.trace.authenticateUser.loginAccepted:info]: AUTH: Login by dwc46q1$ from xx.xx.xx.xx accepted.
I'd like a better way to figure out who logged in from dwc46q1$ . The cifs.trace_login is on.
Thanks,
Jeff
Greetings,
We have a cifs share that gets worked on by various people in the company in different countries and business groups. We have access opened up to users with a valid Windows 2003 Server domain authentication. Since we don't know everyone who will have access to this, we don't have unix accounts for them, or entries in the usermap.cfg file. This share is also nfs accessed and has unix security style.
The problem is when we look in the messages files these users seem to show up with their workstation name followed by the $ sign. It's difficult to track who owns the machine and who logged into it. Here is an trimmed example entry:
auth.trace.authenticateUser.loginAccepted:info]: AUTH: Login by dwc46q1$ from xx.xx.xx.xx accepted.
I'd like a better way to figure out who logged in from dwc46q1$ . The cifs.trace_login is on.
Thanks,
Jeff
Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611 _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Hi Jeff,
We used to use options cifs.trace_login but as you point out, it omits a lot of information and often (high load?) login events are not logged. (We run a university wide home directory service with 60,000 users, so we get a huge number of logins.)
You might want to do this, which works much better:
options cifs.audit.enable on options cifs.audit.logon_events.enable on options cifs.audit.account_mgmt_events.enable off options cifs.audit.file_access_events.enable off
and play with the cifs.audit.autosave options to control the rotation of the event log files.
These options generate files on the filer named
/etc/log/adtlog.*.evt
The filer accumulates audit events in /etc/log/cifsaudit.alf (of unknown format) and periodically dumps this to an adtlog.*.evt file.
The adtlog.*.evt files are in Windows event log format, which you can view on a Windows box. Sounds like you are a Unix guy like me. A while back I researched the EVT format and wrote a perl module to parse the adtlog.*.evt files.
The module and script are fairly short, so I have attached them. You will need to change this line in dumpevt.pl depending on where you put evt.pl
require("/na/local/evt.pl");
Usage: dumpevt.pl evtfile ...
I have attached the perl files with .txt appended to the names to avoid email filters.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
Steve,
Thanks for the information and the modules. I'll look into everything next week when I get back. I had tried the strings command on the cifsaudit.alf file but it only gave me IP addresses of the clients.
The only audit setting we had differently was the cifs.audit.file_access_events.enable. I've turned it off as you mentioned since it probably won't cause too much trouble. I'll see what the evt files come up with when they are created.
Thanks,
Jeff
On Tue, Nov 22, 2011 at 3:00 PM, Steve Losen scl@virginia.edu wrote:
Greetings,
We have a cifs share that gets worked on by various people in the company in different countries and business groups. We have access opened up to users with a valid Windows 2003 Server domain authentication. Since we don't know everyone who will have access to this, we don't have unix accounts for them, or entries in the usermap.cfg file. This share is also nfs accessed and has unix security style.
The problem is when we look in the messages files these users seem to show up with their workstation name followed by the $ sign. It's difficult to track who owns the machine and who logged into it. Here is an trimmed example entry:
auth.trace.authenticateUser.loginAccepted:info]: AUTH: Login by dwc46q1$ from xx.xx.xx.xx accepted.
I'd like a better way to figure out who logged in from dwc46q1$ . The cifs.trace_login is on.
Thanks,
Jeff
Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611 _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Hi Jeff,
We used to use options cifs.trace_login but as you point out, it omits a lot of information and often (high load?) login events are not logged. (We run a university wide home directory service with 60,000 users, so we get a huge number of logins.)
You might want to do this, which works much better:
options cifs.audit.enable on options cifs.audit.logon_events.enable on options cifs.audit.account_mgmt_events.enable off options cifs.audit.file_access_events.enable off
and play with the cifs.audit.autosave options to control the rotation of the event log files.
These options generate files on the filer named
/etc/log/adtlog.*.evt
The filer accumulates audit events in /etc/log/cifsaudit.alf (of unknown format) and periodically dumps this to an adtlog.*.evt file.
The adtlog.*.evt files are in Windows event log format, which you can view on a Windows box. Sounds like you are a Unix guy like me. A while back I researched the EVT format and wrote a perl module to parse the adtlog.*.evt files.
The module and script are fairly short, so I have attached them. You will need to change this line in dumpevt.pl depending on where you put evt.pl
require("/na/local/evt.pl");
Usage: dumpevt.pl evtfile ...
I have attached the perl files with .txt appended to the names to avoid email filters.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support