This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.
Logon Script not working .. specific failure circumstances
GPO for user logon/logoff calls VB script that logs Logon/Logoff events, 4624/4634 respectively, to a database.
Works perfectly for users logging on and off the network on their PCs/laptops.
Users going out to a Remote Desktop session have their logoff recorded but not their logon ... the Security Log, in the Event Viewer, records both, as expected, for wherever the user logs on ...
Works perfectly for users logging on and off the network on their PCs/laptops.
Users going out to a Remote Desktop session have their logoff recorded but not their logon ... the Security Log, in the Event Viewer, records both, as expected, for wherever the user logs on ...
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Hi.
It would possibly matter what server OS you use.
Also make sure that no logon script is running by adding a simple one like this one-liner batch:
It would possibly matter what server OS you use.
Also make sure that no logon script is running by adding a simple one like this one-liner batch:
md %appdata%\test\%date%
I paired the script down to just creating a test folder ... the %date% has syntactically incorrect punctuation that causes an error on a pure test environment (my own workstation) ... but still not creating the test folder ...
There was another instruction (call it TASK#2), separate from the VB script that was and is running just fine ... ripped out TASK#2 and placed it in a separate GPO ... still works just fine ...
Again, the VB script is just not "stuffing" the SQL database with the logon event ... but it's fine with "stuffing" the logoff event ... here's a copy of the script to help visualize what we're attempting:
==========================
' -- ADODB Locktypes --
Const adLockReadOnly = 1 ' Default. Read-only records
Const adLockPessimistic = 2 ' Pessimistic locking, record by record. The provider lock records immediately after editing
Const adLockOptimistic = 3 ' Optimistic locking, record by record. The provider lock records only when calling update
Const adLockBatchOptimistic = 4 ' Optimistic batch updates. Required for batch update mode
' Attach to the database
Set objDBConn = CreateObject("ADODB.Connec
objDBConn.open "Provider=SQLOLEDB.1;Integ
Set objNetwork = CreateObject("WScript.Netw
Set objRS = CreateObject("ADODB.Record
If WScript.Arguments.Count = 1 Then
objRS.Open "EventLog", objDBConn, adOpenKeyset, adLockOptimistic
objRS.AddNew
objRS("EventHost") = UCase(objNetwork.ComputerN
objRS("EventUser") = LCase(objNetwork.UserName)
objRS("EventType") = LCase(WScript.Arguments(0)
objRS.Update
objRS.Close
End If
==========================
There was another instruction (call it TASK#2), separate from the VB script that was and is running just fine ... ripped out TASK#2 and placed it in a separate GPO ... still works just fine ...
Again, the VB script is just not "stuffing" the SQL database with the logon event ... but it's fine with "stuffing" the logoff event ... here's a copy of the script to help visualize what we're attempting:
==========================
' -- ADODB Locktypes --
Const adLockReadOnly = 1 ' Default. Read-only records
Const adLockPessimistic = 2 ' Pessimistic locking, record by record. The provider lock records immediately after editing
Const adLockOptimistic = 3 ' Optimistic locking, record by record. The provider lock records only when calling update
Const adLockBatchOptimistic = 4 ' Optimistic batch updates. Required for batch update mode
' Attach to the database
Set objDBConn = CreateObject("ADODB.Connec
objDBConn.open "Provider=SQLOLEDB.1;Integ
Set objNetwork = CreateObject("WScript.Netw
Set objRS = CreateObject("ADODB.Record
If WScript.Arguments.Count = 1 Then
objRS.Open "EventLog", objDBConn, adOpenKeyset, adLockOptimistic
objRS.AddNew
objRS("EventHost") = UCase(objNetwork.ComputerN
objRS("EventUser") = LCase(objNetwork.UserName)
objRS("EventType") = LCase(WScript.Arguments(0)
objRS.Update
objRS.Close
End If
==========================
Yep, I forgot the quotes
md "%appdata%\test\%date%"
Your script code does not matter. Please add the requested info: what server OS is that?
md "%appdata%\test\%date%"
Your script code does not matter. Please add the requested info: what server OS is that?
Logged on to RDS with Domain Admin rights. Ran RSOP.MSC and the Logon script is present ... along with your test ... the VB script ran and logged my Logon (event 4624) both in the Security Log of the Event Viewer and stuffed the info in the SQL database ... as expected ... but your test folder did not get created ... logging off also was logged in the Security Log and stuffed into the SQL database.
Logged on as standard domain user and nothing happened. Logged off and the event appeared in the Security Log and the VB script was able to stuff the event into the SQL database ...
Nothing seems to be able to change these actions ... beginning to redefine "insanity" ... only with different circumstances yielding the same result!!!
Logged on as standard domain user and nothing happened. Logged off and the event appeared in the Security Log and the VB script was able to stuff the event into the SQL database ...
Nothing seems to be able to change these actions ... beginning to redefine "insanity" ... only with different circumstances yielding the same result!!!
Ok.
I'd like to reproduce that, let's see when I find the time for that. I'll simply take my batch command and see if that folder gets created.
I'd like to reproduce that, let's see when I find the time for that. I'll simply take my batch command and see if that folder gets created.
The issue turned out to be a permissions setting on the actual database. Attempted running the script from DOS and finally was able to generate a visible error dialog that was being missed during the GPO Logon ... contacted our SQL guru and he adjusted the permissions on that database for Domain Users ... VOILA!
Premium Content
You need an Expert Office subscription to comment.Start Free Trial