Security Failures
I just recently changed the default domain administrator password. I have identified all services, and scheduled tasks that I could that were still using the domain administrator account for authentication and changed it to use a service user account. After monitoring my security logs on our DC, I have identified two servers still attempting to use the domain administrator account unsuccessfully.
Here is one error from our ERP utility server, and here is what I know about this event. Every 10 minutes 10 of these events show up in the logs and the logon type of these 10 events is either 2, 3, 4, 5, 6, or 8. I realize it specifies PID 4704 and I have already identified that as the w3wp.exe process. So somewhere in IIS the administrator user is being used but I have been unable to pinpoint what in IIS is still using the administrator account.
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 529
Date: 10/28/2009
Time: 9:57:51 AM
User: NT AUTHORITY\SYSTEM
Computer: SYTEUTIL
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: administrator
Domain: agra
Logon Type: 3
Logon Process: Advapi
Authentication Package: Negotiate
Workstation Name: SYTEUTIL
Caller User Name: NETWORK SERVICE
Caller Domain: NT AUTHORITY
Caller Logon ID: (0x0,0x3E4)
Caller Process ID: 4704
Transited Services: -
Source Network Address: -
Source Port: -
The other server with errors is our Exchange server. This is an example of one error, and here is what I know about this event. This event repeats ever 5 minutes and unfortunately no PID is identified so I have been unable to track down what process or service is attempting to use the administrator account.
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 529
Date: 10/28/2009
Time: 10:02:10 AM
User: NT AUTHORITY\SYSTEM
Computer: AGRAEXCH
Description:
Logon Failure:
Reason: Unknown user name or bad password
User Name: Administrator
Domain: AGRA
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: AGRAEXCH
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: -
Source Port: -Any help tracking down these two culprits would be greatly appreciated.
Answers
a) is the w3wp.exe running under the administrator? I think it is not, is it?
b) determine the Application Pool that is running in the worker process by using:
cscript iisapp.vbs
c) when you know the Application Pool, go into IIS and find the virtual folders that are using the Application Pool
d) once the application/folder found, find its WEB.CONFIG file store in the root the folder tree exposed as applications/virtual folders
e) in the web.config, there will be an element called Impersonation or Authentication
f) give us its contents
ondrej.- Marked As Answer byZachary Dundore Monday, November 02, 2009 10:02 PM
- cool, look into the article I mentioned and use the Aspnet_setreg.exe tool mentioned:
http://support.microsoft.com/kb/329290
ondrej.- Marked As Answer byZachary Dundore Monday, November 02, 2009 10:02 PM
All Replies
- Does anyone have any ideas or could at least point me in the right direction? I am really lost on this. The only good part about this problem is we can't find any loss of functionality in our system but this just has me stumped.
- Can anyone point me in any direction? It would seem to me the IIS issue should be easy to solve, but I am stumped. Does MS offer any products to help me locate where this user would be configured for use in IIS? I have already searched the metabase.xml file and didn't find the administrator user anywhere in that file. That is the only direction I found on the web.
a) is the w3wp.exe running under the administrator? I think it is not, is it?
b) determine the Application Pool that is running in the worker process by using:
cscript iisapp.vbs
c) when you know the Application Pool, go into IIS and find the virtual folders that are using the Application Pool
d) once the application/folder found, find its WEB.CONFIG file store in the root the folder tree exposed as applications/virtual folders
e) in the web.config, there will be an element called Impersonation or Authentication
f) give us its contents
ondrej.- Marked As Answer byZachary Dundore Monday, November 02, 2009 10:02 PM
... the password will probably be stored in registry and you will have to change it
http://msdn.microsoft.com/en-us/library/72wdk8cc(VS.71).aspx
ondrej.- First off thank you so much for the post and help on this. It is greatly appreciated. Here is what i have found.
a) is the w3wp.exe running under the administrator? I think it is not, is it?
Nope, it's running under network service.
b) determine the Application Pool that is running in the worker process by using:
cscript iisapp.vbs
DefaultAppPool - This is the only app pool on the server
c) when you know the Application Pool, go into IIS and find the virtual folders that are using the Application Pool
all of them. we have 12 but three don't have a web.config file.
d) once the application/folder found, find its WEB.CONFIG file store in the root the folder tree exposed as applications/virtual folders
e) in the web.config, there will be an element called Impersonation or Authentication
f) give us its contents
Most say this:
<authentication mode="Windows"/>
The IEVWeb directory says this:
<identity impersonate="true" userName="registry:HKLM\Software\Wow6432Node\IntegralSoftware\ASPNET_SETREG,userName" password="registry:HKLM\Software\Wow6432Node\IntegralSoftware\ASPNET_SETREG,password" />
When i go to the registry entry i am unable to change the userName and password entries. These are binary value registry entries and i cannot change them nor can i interpret them. - cool, look into the article I mentioned and use the Aspnet_setreg.exe tool mentioned:
http://support.microsoft.com/kb/329290
ondrej.- Marked As Answer byZachary Dundore Monday, November 02, 2009 10:02 PM
- Yeah, i have already looked it over. I am waiting for my programer to come back from vacation next week and we are going to tackle those steps together.
Thanks again for the help. This isn't the first time you have helped me.
