System account logon failures

October 2, 2012, 11:27 pm

≫ Next: PKI Migration from Domain A to Domain B

≪ Previous: Planing to upgrade CA from sha1 to sha256

Hi,

We are experiencing numerous logon failures by a system account on a newly installed 2008R2 Server running Symantec's CCS 11 application.
The account seems to be invoked by a lsass.exe process. Please find logs below. We would love to find a way to stop these logon failures.

Thanks a mill.

Guy

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          2012/10/03 08:12:04 AM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      Server
Description:
An account failed to log on.

Subject:
   Security ID:       SYSTEM
   Account Name:       SERVER$
   Account Domain:       DOMAIN
   Logon ID:       0x3e7

Logon Type:           3

Account For Which Logon Failed:
   Security ID:       NULL SID
   Account Name:
   Account Domain:

Failure Information:
   Failure Reason:       Unknown user name or bad password.
   Status:           0xc000006d
   Sub Status:       0xc0000064

Process Information:
   Caller Process ID:   0x208
   Caller Process Name:   C:\Windows\System32\lsass.exe

Network Information:
   Workstation Name:   SERVER
   Source Network Address:   -
   Source Port:       -

Detailed Authentication Information:
   Logon Process:       Schannel
   Authentication Package:   Kerberos
   Transited Services:   -
   Package Name (NTLM only):   -
   Key Length:       0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
   - Transited services indicate which intermediate services have participated in this logon request.
   - Package name indicates which sub-protocol was used among the NTLM protocols.
   - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4625</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2012-10-03T06:12:04.377951200Z" />
    <EventRecordID>601000</EventRecordID>
    <Correlation />
    <Execution ProcessID="520" ThreadID="8972" />
    <Channel>Security</Channel>
    <Computer>SERVER</Computer>
    <Security />
</System>
<EventData>
    <Data Name="SubjectUserSid">S-1-5-18</Data>
    <Data Name="SubjectUserName">SERVER$</Data>
    <Data Name="SubjectDomainName">DOMAIN</Data>
    <Data Name="SubjectLogonId">0x3e7</Data>
    <Data Name="TargetUserSid">S-1-0-0</Data>
    <Data Name="TargetUserName">
    </Data>
    <Data Name="TargetDomainName">
    </Data>
    <Data Name="Status">0xc000006d</Data>
    <Data Name="FailureReason">%%2313</Data>
    <Data Name="SubStatus">0xc0000064</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">Schannel</Data>
    <Data Name="AuthenticationPackageName">Kerberos</Data>
    <Data Name="WorkstationName">SERVER</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">-</Data>
    <Data Name="KeyLength">0</Data>
    <Data Name="ProcessId">0x208</Data>
    <Data Name="ProcessName">C:\Windows\System32\lsass.exe</Data>
    <Data Name="IpAddress">-</Data>
    <Data Name="IpPort">-</Data>
</EventData>
</Event>

↧

PKI Migration from Domain A to Domain B

September 19, 2018, 3:40 am

≫ Next: admin audit logs

≪ Previous: System account logon failures

Hi People, is there any documentation on Migration of a mature PKI solution to another domain.
What I mean by another domain is, the company I work for has been taken over and instead of being called DomainA.com we are now DomainB.com

Regards

Richard

↧

admin audit logs

September 19, 2018, 3:58 am

≫ Next: CEP not working on Server running CEP (WS_E_ENDPOINT_FAULT_RECEIVED)

≪ Previous: PKI Migration from Domain A to Domain B

Dear Team,

I want to enable admin audit logs on Active directory and Exchange servers and to know how to read and trace logs if any user made any changes and run command so it can be capture.

↧

CEP not working on Server running CEP (WS_E_ENDPOINT_FAULT_RECEIVED)

September 19, 2018, 6:27 am

≫ Next: Certificate Enrollment - Error

≪ Previous: admin audit logs

Hi Everyone,

I try to hunt down the following issue i get with a deployment of mine.

My deployment looks like the following:

Issuing CA running on Server 1

IIS for CRL, CEP, CES and NDES running on Server 2

Servers are all running 2016

Cert enrollment from a client machine is working as expected through CEP (receiving policy, and CES URLs and successfully requests certificates).

My problem is on the Server 2 itself. As it must request certificates through CEP what points to himself (A Record for cep.domain.com)

Some more details:

AppPools Running with identity ces$ (group managed service account) with Managed Pipeling Mode set to Integrated and the account having the following set:
servicePrincipalName:
HTTP/cep.domain.com + HTTP/cep

HTTP/ces.domain.com + HTTP/ces

msDS-AllowedToDelegateTo:
HOST/Server1.domain.com

RPCSS/Server1.domain.com

But Kerberos delegation should not be the problem because i can see in the IIS Logs:

2018-09-19 12:47:03 10.0.200.17 POST /ADPolicyProvider_CEP_Kerberos/service.svc/CEP - 443 DOMAIN\SERVER2$ 10.0.200.17 MS-WebServices/1.0 - 500 0 0 4990

if i fire up a CMD running under the SYSTEM Account, i can see that SERVER2 received a correct TGT by running the following command:

certutil -ping -kerberos -config <CEPURL> CEP

followed by a klist

i also receive a "command completed successfully" with a public cert if i try to ping the CES interface like this

certutil -ping -kerberos -config <CESURL> CES

with fiddler i was able to trace the internal server error a little bit deeper:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header><a:Action s:mustUnderstand="1">http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher/fault</a:Action><a:RelatesTo>urn:uuid:48639d1e-97e0-4aaf-805a-bcf04f8a1959</a:RelatesTo><ActivityId CorrelationId="abe52901-1ebf-4330-aa0b-b8f51b272628" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">00000000-0000-0000-0000-000000000000</ActivityId></s:Header><s:Body><s:Fault><s:Code><s:Value>s:Receiver</s:Value><s:Subcode><s:Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</s:Value></s:Subcode></s:Code><s:Reason><s:Text xml:lang="de-CH">GetAccessRights</s:Text></s:Reason><s:Detail><ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><HelpLink i:nil="true"/><InnerException i:nil="true"/><Message>GetAccessRights</Message><StackTrace>   at Microsoft.CertificateServices.Policy.Providers.EnrollmentPoliciesMgr._GetResponse(Int32[] filteredPolicies, WindowsIdentity caller, Boolean bKeyBasedRenewal, CertificateEnrollmentPolicy[]&amp; enrollmentPolicies, CA[]&amp; enrollmentCAs, OID[]&amp; enrollmentOIDs)&#xD;
   at Microsoft.CertificateServices.Policy.Providers.EnrollmentPoliciesMgr.GetPolicies(RequestFilter requestFilter, WindowsIdentity caller, Boolean bKeyBasedRenewal, CertificateEnrollmentPolicy[]&amp; enrollmentPolicies, CA[]&amp; enrollmentCAs, OID[]&amp; enrollmentOIDs)&#xD;
   at Microsoft.CertificateServices.Policy.Providers.ADPolicyProvider.GetPolicy(WindowsIdentity caller, Boolean bKeyBasedRenewal, DateTime clientLastUpdate, RequestFilter requestFilter, Response&amp; response, CA[]&amp; CAsOut, OID[]&amp; OIDs)&#xD;
   at Microsoft.CertificateServices.Policy.PolicyService.GetPolicies(GetPoliciesRequest request)&#xD;
   at SyncInvokeGetPolicies(Object , Object[] , Object[] )&#xD;
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]&amp; outputs)&#xD;
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc&amp; rpc)&#xD;
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&amp; rpc)&#xD;
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc&amp; rpc)&#xD;
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)</StackTrace><Type>System.Runtime.InteropServices.COMException</Type></ExceptionDetail></s:Detail></s:Fault></s:Body></s:Envelope>

any one a idea?

Please remember to mark the replies as answers if they helped.

↧

Certificate Enrollment - Error

September 19, 2018, 7:24 am

≫ Next: How to verify credential roaming is working for user certificates?

≪ Previous: CEP not working on Server running CEP (WS_E_ENDPOINT_FAULT_RECEIVED)

I am getting the following error when I have the setting for delegation "Trust this computer for delegation to specified services only" and have it set to "Use Kerberos Only" with having "Host" and "rpcss" for the CA. I have full open ports for the TCP 135 and the higher random ports also open, and the connection from Web Enrollment server to the DC we have ports 440 and 636 opened. I am using the DefaultAppPool for my CertSrv applications in IIS and I am using "ApplicationPoolIdentity" as Identity for that pool.

Request Mode:: newreq - New Request
Dis: (never set)
Disposition message:: (none)
Result:: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
COM Error Info:: CCertRequest::Submit: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
LastStatus:: The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
Suggested Cause:: This error can occur if the Certification Authority Service has not been started

But when I change setting for delegation "Trust this computer for delegation to specified services only" and have it set to "Use any authentication protocol" with having "Host" and "rpcss" for the same CA I get this error when just trying to access the certrqma.asp site.

500 - Internal server error.

There is a problem with the resource you are looking for, and it cannot be displayed.

</fieldset>

↧

How to verify credential roaming is working for user certificates?

September 19, 2018, 3:36 pm

≫ Next: Limit Certificates Visible In Web Enrollment Page?

≪ Previous: Certificate Enrollment - Error

I applied a GPO for credential roaming and I know the GPO is successfully applied to the computer because other settings in the policy are working.

How do I verify credential roaming of user certificates is working?

↧

Limit Certificates Visible In Web Enrollment Page?

September 19, 2018, 3:59 pm

≫ Next: X.509 SSL Self-Signed Certificate

≪ Previous: How to verify credential roaming is working for user certificates?

We want only certificates that require CA Certificate Manager approval to be available in the web enrollment page. Users who need to request user certificates from devices not joined to our domain will use this.

We want users to be able to auto-enroll without manager approval from domain joined computers. However, when we make a certificate template available for auto-enrollment, the certificate becomes visible in the web enrollment page.

How can we fix this?

↧

X.509 SSL Self-Signed Certificate

September 20, 2018, 4:41 am

≫ Next: Event 7040 -- System keeps changed startup mode on SQL Server Services

≪ Previous: Limit Certificates Visible In Web Enrollment Page?

Hi,

We run a nessus scan on our domain and getting alerts regrading SSL certificate which is assign to PC.

https://www.tenable.com/plugins/nessus/57582
http://www.nessus.org/plugins/index.php?view=single&id=51192
http://www.nessus.org/plugins/index.php?view=single&id=35291

Is they any way i can tell then system that this is our trusted certificate. This is only being used internally.

↧

Event 7040 -- System keeps changed startup mode on SQL Server Services

September 20, 2018, 8:23 am

≫ Next: Certificate Services - CES/CEP Returning Invalid Function when trying to Enroll via CES, But Can Enroll DIrectrly to the CA

≪ Previous: X.509 SSL Self-Signed Certificate

We have a Windows 2016 server that is used to host a SQL Server database instance. Services "SQL Server (MSSQLSERVER)" "SQLSERVERAGENT" keep getting reverted from startup mode automatic to manual start. Event viewer states that SYSTEM is doing this, but it is worth noting that we have a Managed Service Account used for the login for these services. Any ideas on what might be causing this? I am stumped!

↧

Certificate Services - CES/CEP Returning Invalid Function when trying to Enroll via CES, But Can Enroll DIrectrly to the CA

September 20, 2018, 4:04 pm

≫ Next: AD CS Cluster problem

≪ Previous: Event 7040 -- System keeps changed startup mode on SQL Server Services

When using ADCS CES/CEP Proxy to ENroll for a Computer Certificate, I am given the certificate template that is available, but when it goes to actually enroll I get the following error in certenroll.log in the windows directory:

Nothing is sent to the CA...it all seems to stop at the enrollment proxy....possibly a permissions issue? This is all running on Server 2016, CAs are running 2016 Core.

========================================================================

402.478.948: Begin: 9/20/2018 6:41 PM 29.748s

402.483.0: MMC.EXE

402.491.0: GMT - 4.00

2005.228.0: certca.dll: 10.0.14393.2248 retail

2005.228.0: certcli.dll: 10.0.14393.2248 retail

2005.228.0: certenroll.dll: 10.0.14393.2248 retail

3000.838.0:<2018/9/20, 18:41:31>: 0x0 (WIN32: 0)

3000.839.0:<2018/9/20, 18:41:31>: 0x80094004 (-2146877436 CERTSRV_E_PROPERTY_EMPTY)

2032.4369.0:<2018/9/20, 18:41:31>: 0x80094004 (-2146877436 CERTSRV_E_PROPERTY_EMPTY): Fetch Id

3000.838.0:<2018/9/20, 18:41:31>: 0x0 (WIN32: 0)

3000.839.0:<2018/9/20, 18:41:31>: 0x80094004 (-2146877436 CERTSRV_E_PROPERTY_EMPTY)

3000.875.0:<2018/9/20, 18:41:31>: 0x80094004 (-2146877436 CERTSRV_E_PROPERTY_EMPTY): PsPolicyID

437.633.0:<2018/9/20, 18:41:31>: 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND): LDAPFlags

2720.294.0:<2018/9/20, 18:41:36>: 0x800704c7 (WIN32: 1223 ERROR_CANCELLED)

2007.238.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): XTS-AES

2007.238.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): SHA224

2007.238.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): curve25519

2047.644.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): curve25519

2047.781.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): Microsoft Software Key Storage Provider

2047.859.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): curve25519

2007.238.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP256t1

2047.644.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP256t1

2047.781.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): Microsoft Software Key Storage Provider

2047.859.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP256t1

2007.238.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP384t1

2047.644.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP384t1

2047.781.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): Microsoft Software Key Storage Provider

2047.859.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP384t1

2007.238.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP512t1

2047.644.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP512t1

2047.781.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): Microsoft Software Key Storage Provider

2047.859.0:<2018/9/20, 18:41:37>: 0x80091002 (-2146889726 CRYPT_E_UNKNOWN_ALGO): numsP512t1

452.856.0:<2018/9/20, 18:41:37>: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED): ECCCurveName

452.149.0:<2018/9/20, 18:41:37>: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED): ECCCurveName

2047.551.0:<2018/9/20, 18:41:37>: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED)

2047.781.0:<2018/9/20, 18:41:37>: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED): Microsoft Software Key Storage Provider

2047.859.0:<2018/9/20, 18:41:37>: 0x80090029 (-2146893783 NTE_NOT_SUPPORTED): curve25519