Check Auditing from Domain Controller

[playsafe]

Hello All,

I have a AD domain controller running 2003 server, and one Windows 2003 storage server as member server.

Unfortunately, i did not set logon auditing at member server. Now I want to check who logged on to this server between specific time interval. Is there any other way to check it. Logon Auditing is enabled set on domain controller though, can it help in some way that authentication is performed by Domain controller and it may show somewhere that a user requested to login to member server and came for authentication.

Thanks for going through above text.

[Noise]

The only way I know id to check the security log on the domain controller using event viewer. Do a search for the users logon name.

[MrJinje]

I have a AD domain controller running 2003 server, and one Windows 2003 storage server as member server.

Unfortunately, i did not set logon auditing at member server. Now I want to check who logged on to this server between specific time interval. Is there any other way to check it. Logon Auditing is enabled set on domain controller though, can it help in some way that authentication is performed by Domain controller and it may show somewhere that a user requested to login to member server and came for authentication.

It's possible, unless they had cached credentials on the member server and did not need to contact DC for login. Meaning if it was a server admin who had already logged into the machine before, the DC might not get contacted for subsequent logins.

If you cannot find any information via the event viewer, you could always go old-school, search for ntuser.dat files and see which ones have timestamps matching your time frame.

Here are some greater details on the event ID #'s and how to decipher them.

http://technet.microsoft.com/en-us/library...28WS.10%29.aspx

Edited January 9, 2010 by MrJinje

[playsafe]

I have found below log on my domain controller,

1/9/2010,7:57:29 AM,Security,Success Audit,Logon/Logoff ,540,TMN\USERNAME,DC,"Successful Network Logon:

User Name: USERNAME

Domain: TMN

Logon ID: (0x0,0xE55832A)

Logon Type: 3

Logon Process: Kerberos

Authentication Package: Kerberos

Workstation Name:

Logon GUID: {3362e1d8-b952-9b84-8911-df846e16c05e}

Caller User Name: -

Caller Domain: -

Caller Logon ID: -

Caller Process ID: -

Transited Services: -

Source Network Address: 172.18.10.xxx

Source Port: 0

From Information above and related articles on internet, i conclude that either of following,

i) User logged into this server Or

i) User accessed some share on this server

though its authentication event triggered on domain controller where I have found this log. Correct me if I am wrong.

[MrJinje]

Logon Event #540 - A user successfully logged on to a network.

Logon Type #3 - Network - A user or computer logged on to this computer from the network.

Sounds like someone accessed a file share from the network. This would happen if someone were to map a network drive, or if they browsed the network neighborhood to the file share. This is normal if the employee in question is supposed to be using that network file share.

Before we go any further, maybe we need to define what type of logon you are looking for. Are you looking for someone who actually logged into the machine (interactively/w desktop + start menu and all all that) and wasn't supposed too. Or are you looking for someone who accessed the machines file-shares remotely ?

These two types of logins are completely different and maybe we could narrow down and get you the correct advice.

[cluberti]

It's also worth noting that going spelunking for historical data like this when there was no auditing or data gathering policy really configured on the DCs and workstations beforehand is generally an exercise in futility. If this is the case, you'd be better rectifying the situation by enabling the amount of logging and auditing your domain can handle and that someone (or some group) is comfortable monitoring and hoping to catch the next occurrence.

[playsafe]

@MrJinje

I am looking for remote desktop (yes interactively) into a member server (Win 2003). The below logs are from my domain controller which has auditing enabled. The user in question has part of I.T team and has appropriate rights to logon to this server officially. I just wanted to check against an event that happened on member server.

@cluberti

The auditing is not enabled on member server but it is enabled on domain controller, my point was if authentication request goes to domain controller it may hold some related logs. And I found those from domain controller but just want to confirm if it was access to a share or interactive remote desktop as both could initiate the authentication process.

[cluberti]

@cluberti

The auditing is not enabled on member server but it is enabled on domain controller, my point was if authentication request goes to domain controller it may hold some related logs. And I found those from domain controller but just want to confirm if it was access to a share or interactive remote desktop as both could initiate the authentication process.

Understood - but it is always better to have logon and/or logoff auditing enabled in that case on the DC and the member servers going forward, and it's also a good idea to archive those logs regularly if they'll be needed for any type of forensics. Given the log entry above, it would indicate more a share access than a logon request.

[MrJinje]

@MrJinje

I am looking for remote desktop (yes interactively) into a member server (Win 2003). The below logs are from my domain controller which has auditing enabled. The user in question has part of I.T team and has appropriate rights to logon to this server officially. I just wanted to check against an event that happened on member server.

Perfect, we just need to filter for a logon of "type 10" Remote Interactive. But like I mentioned, if the user had already accessed the member server previously and it had "cached" his/her credentials, it is very likely it would not contact the DC. In those cases it would be a logon type 11, stored only in the member servers event log (if tracking was enabled - which we know it's not). If there are no type 10's on the DC, then there are none, it was only a slim chance to begin with.

Logon Type - 10 - RemoteInteractive

A user logged on to this computer remotely using Terminal Services or Remote Desktop.

Logon Type - 11 - CachedInteractive

A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.

Cluberti is right about one thing, enable auditing on the member servers and you will have less problems next time around. Alternatively you could configure the security policy to never cache credentials.

From secpol.msc various cache settings can be controlled from the "Security Options" page here.

security settings/local policies/security options

EDIT: Check this out.

http://www.brianmadden.com/forums/t/21300.aspx

http://www.2x.com/securerdp/

It will secure RDP access to your server and also provides a logging facility with the following information:

Time, Client Computer Name, Client IP Address, Client Computer MAC Address, WinStationName, User Name, Session ID, Accepted/Rejected, Reason for rejecting (if rejected)

in CSV log format which you can easily review in Excel.

Edited January 14, 2010 by MrJinje

[playsafe]

I have now enable auditing on this member server as well, it was just that this server got missed and I have to check for an incident on server. Thanks a lot for your replies and guidance.