August 13, 2008 at 8:18 am
Hi,
Someone auditing security on one of my SQL Servers has expressed concern with windows event 552 appearing when certain jobs are run:
Event Type:Success Audit
Event Source:Security
Event Category:Logon/Logoff
Event ID:552
Date:8/13/2008
Time:10:06:49 AM
User:DOMAIN\Service Account
Computer:COMPUTERNAME
Description:
Logon attempt using explicit credentials:
Logged on user:
User Name:SERVICE ACCOUNT
Domain:DOMAIN
Logon ID:(HEX VALUE
Logon GUID:{GUID}
User whose credentials were used:
Target User Name:MY Domain Credentials
Target Domain:DOMAIN
Target Logon GUID: -BLANK
Target Server Name:localhost
Target Server Info:localhost
Caller Process ID:1320
Source Network Address:-
Source Port:-
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I created a simple job that runs a select statement to test, and this event is generated. I'm being told that this is evidence that my credentials are being cached somewhere (which is a security violation). My domain account is indeed the owner of the job.
Can someone please educate me abouth whether this is indeed a scenario in which credentials are somehow being cached or what is going on here?
Thanks,
Warren
August 13, 2008 at 9:28 am
I would not think credentials are cache but that sql server checks active directory for credentials each time the job is run. A simple test (although not practical in a production environment) for this would be to remove access to the domain controller from your SQL server and try to execute the job. I suspect the job will not run due to invalid securty, thus proving that credentials are not cached.
August 13, 2008 at 10:26 am
Agree completely.
SQL does not (as far as I am aware) cache AD details. What it does cached is the AD SID's which are kept to compare the SID held by AD to the SID in SQL. In this way security models for SQL or databases can be made quite simple by effectively using AD groups.
SOOOO guess in a way credentials are being cached, but not passwords, just user login names and SID's which are required for AD comparison and authentication.
Try another test, setup a job in SQL but set the owner as a user which does not have permission to accomplish the task specified in the job and you will see a different response.
Sorry if this is a bit waffly 🙂
Good luck 😉
Adam Zacks-------------------------------------------Be Nice, Or Leave
August 13, 2008 at 10:57 am
SQL Server hands off any Windows authentication to the SSPI. Unless there is a GPO to prevent cached credentials or it's set explicitly in the local security policy, the OS will do so automatically.
K. Brian Kelley
@kbriankelley
August 15, 2008 at 7:22 am
Can you point me in the direction of any resources (preferably from MS) that explain exactly how this works?
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply