Back to your phpLogCon instancecan anyone help?
my Active Directory service account keeps locking-out. the policy for my domain is 3 bad attempts to log in and is locked-out.
I've checked the event log but except event id 677 failure code 18 (0x12) I've found nothing! This says that the service ticket failed due to lokout.
but no unsuccesfull logon i've discovered and no account management either.
I suspect another domain admin is playing with me but I'm not sure.
I'm new to ADS but pretty good in NT Server
Is you were and admin how would ou lock an account (may be a service with my account started, and the password could be wrong)
I've changed my password several times but it seems that when I am logged on for hours my account locks severeal times, but not regularly...
Pleaseeee.... HELP
ADS user account locking out
Moderator: alorbach
3 posts • Page 1 of 1
by Guest » Wed Jul 14, 2004 6:39 pm
I HOPE THIS HELPS, YOU DIDN'T MENTION ANYTHING ABOUT IF YOU ARE RUNNING EXCHANGE SERVER, BUT I WILL INCLUDE SOME INFO ON THAT ALSO..... FEEL FREE TO WRITE BACK AT ANYTIME......
I am sending you a few articles, maybe one will help or apply to your situation.... THE ARTICLES I SENT MAY SEEM LONG, BUT IT WILL HELP YOU WITH A BETTER UNDERSTANDING ON NETWORKS.... I BEEN DOING THIS FOR OVER 15 YEARS, AND YOU KNOW WHAT?? THERE IS ALWAYS SOMETHING NEW TO LEARN.......I AM STILL LEARNING, AND IT NEVER STOPS, BUT I LOVE IT..... ALSO, YOU MAY KNOW THIS ALREADY, BUT I WILL MENTION IT.... IF YOU GET STUCK ON A SITUATION, OR NEED HELP WITH EVENT ID NUMBERS, OR ANYTHING YOU WANT TO KNOW......
JUST GO TO "GOOGLE.COM" AND TYPE IN WHATEVER YOU WANT TO KNOW.... YOU CAN EVEN TYPE IN HOW TO HACK IN ANOTHER SERVER, AND IT WILL SHOW YOU PAGES OF STUFF..... I CAN ALSO SEND YOU TO A HACKER SITE WHERE THEY HAVE ALL THE UTILITIES YOU NEED TO CATCH HACKERS, MONITOR YOU NETWORKS, HELL,,, EVEN WILL TELL YOU HOW TO BE YOUR OWN HACKER, AND WILL GUIDE YOU WITH STEPS AND COMMANDS, BESIDES SOFTWARE..... TALK TO YOU SOON, HOPE THIS HELPS.....
STEVE NETWORKS@NETSCAPE.NET or .COM (New Account)
This article was previously published under Q281431
SYMPTOMS
When you use the Active Directory Connector (ADC) with Microsoft Exchange Server 5.5, a logon failure is reported every time the ADC is run. You can find the failure in the security event log if auditing for "audit account logon events" is enabled for "logon failure."
The security event log shows the following event:
Event Type: Failure
Event Source: Security
Event Category: Account Logon
Event ID: 677
Date: 1/4/2001
Time: 1:01:30 PM
User: NT AUTHORITY\SYSTEM
Computer: ServerName
Description:
Service Ticket Request Failed:
User Name: Administrator
User Domain: DOMAIN.COM
Service Name: LDAP/ExchangeSrvName.domain.com
Ticket Options: 0x40810010
Failure Code: 7
Client Address: 127.0.0.1
STATUS
This event can be safely ignored because this version of Exchange Server is not Kerberos-aware and does not register a Service Principal Name (SPN) with the Active Directory.
MORE INFORMATION
The error is generated when the ADC attempts the contact the Lightweight Directory Access Protocol (LDAP) service on a member server running Exchange Server 5.5. The server running the ADC attempts to authenticate against Exchange service by requesting a Kerberos ticket for LDAP/myexhangesrv.mydomain.com.
The Microsoft Windows 2000 Kerberos Key Distribution Center (KDC) attempts to resolve the Service Principal Name (SPN) to a Windows 2000 server. Exchange Server 5.5 is not Kerberos-aware and does not register an SPN with the Active Directory. Because an SPN that matches does not exist, the KDC returns an error that is logged as the 677 event. The server that is running the ADC falls back to NTLM and is able to connect to the LDAP service on the Exchange Server computer.
Although it is possible to manually add an SPN for the LDAP server by using SETSPN from the Resource Kit, this will cause the ADC to fail.
Manually adding an SPN will cause the 677 events to stop. However, the ADC will no longer be able to authenticate to the LDAP service on the Exchange Server computer. Because the SPN can be resolved to a server, the KDC will return a Kerberos ticket for the target server (the server with the LDAP SPN registered). The server that is running the ADC will attempt to use a Kerberos ticket to authenticate to the Exchange service. Because Exchange 5.5 is not Kerberos-aware, it is not able to validate the user. This occurs even if Exchange Server 5.5 is installed on a Windows 2000 member server.
ANOTHER ARTICLE:
The Security Event ID 677 (Failure Audit) is generated by the Kerberos Service Ticket Service. Kerberos is used by Windows 2000 Active Directory for authentication and is supposed to replace the old Windows NT security architecture. Typically there are 2 types of 677 events: with Failure code 7 and with Failure code 32 (see the table below for a more detailed list of potential failure codes). Let's analyze the two most common codes, 7 and 32!
Failure code 7
Any Kerberos-compliant software will try first to use Kerberos in order to obtain access to various servers or applications and usually if such access fails they will try an NT-compliant access (using NT authentication). So typically, a Kerberos-compliant application willing to access let's say SERVER1 will interrogate the Kerberos Distribution Center server for the Service Principal Name (SPN) of SERVER1. Kerberos-compliant application will register their SPN with a KDC but applications like MS SQL 7.0 won't. As a consequence, the KDC is not able to resolve the SPN for the MS SQL 7.0 server and a 677 event with Failure Code 7 is generated.
Example:
Service Ticket Request Failed: User Name: sql_service User Domain: CORPORATE.NET Service Name: MSSQLSvc/SERVER1.CORPORATE.NET:1433 Ticket Options: 0x40810010 Failure Code: 7 Client Address: 127.0.0.1
This event may be generated by various services that are trying to authenticate through a Kerberos Service Ticket. Between the services reporting such errors are: IIS, SQL, DNS, Exchange 5.5, etc... When instead of a user name, a COMPUTERNAME$ is listed, that means that it is the System account that failed to obtain a Kerberos service ticket. Microsoft Knowledgebase has an article documenting the occurrence of event 677 when ADC (Active Directory Connector) is trying to connect to an Exchange 5.5 server. See Q281431 - XADM: Logon Failure Event ID 677 with Exchange Server 5.5 and Active Directory Connector
A combined environment, Windows 2000, Windows NT / 98 with Active Directory running on mixed mode may cause the occurrence of such events as NT/Win98 machines are trying to connect to a Win2000 machine and fail because NT and Windows 9x are not Kerberos-aware.
Another source of 677 messages are improper DNS configurations. Typically, they would occur when the NetBIOS name of the server is different from the DNS host name. For example, we see these events on domain controllers with the source machine of the event being 127.0.0.1, the LOCALHOST which probably is not recognized as a valid SPN. We suspect that this might be the case when these event occur in a "native" Windows 2000 Active Directory environment (supposedly 100% Kerberos compatible).
By disabling NetBIOS over TCP/IP on the Windows 2000 Domain Controller performing the role of the PDC, some of these events may be eliminated and this action should not affect Windows 2000 AD environments running in "native" mode.
Failure code 32
The problem in this case is in the Kerberos ticket expiration. It appears that Windows 2000 just keeps renewing tickets until it fails because of expiration and then gets a new one. If this is correct, then the 677 failure code 32 errors are "normal" events that one cannot prevent without disabling the auditing for Failure Audits.
* * *
The failure codes reported by these events come directly from the Kerberos RFC 1510. These codes may help with the identification of what caused the error.
Code
Description
0
No error
1
Client's entry in database has expired
2
Server's entry in database has expired
3
Requested protocol version number not supported
4
Client's key encrypted in old master key
5
Server's key encrypted in old master key
6
Client not found in Kerberos database
7
Server not found in Kerberos database
8
Multiple principal entries in database
9
The client or server has a null key
10
Ticket not eligible for postdating
11
Requested start time is later than end time
12
KDC policy rejects request
13
KDC cannot accommodate requested option
14
KDC has no support for encryption type
15
KDC has no support for checksum type
16
KDC has no support for padata type
17
KDC has no support for transited type
18
Clients credentials have been revoked
19
Credentials for server have been revoked
20
TGT has been revoked
21
Client not yet valid - try again later
22
Server not yet valid - try again later
23
Password has expired - change password to reset
24
Pre-authentication information was invalid
25
Additional pre-authentication required
31
Integrity check on decrypted field failed
32
Ticket expired
33
Ticket not yet valid
34
Request is a replay
35
The ticket isn't for us
36
Ticket and authenticator don't match
37
Clock skew too great
38
Incorrect net address
39
Protocol version mismatch
40
Invalid msg type
41
Message stream modified
42
Message out of order
44
Specified version of key is not available
45
Service key not available
46
Mutual authentication failed
47
Incorrect message direction
48
Alternative authentication method required
49
Incorrect sequence number in message
50
Inappropriate type of checksum in message
60
Generic error (description in e-text)
61
Field is too long for this implementation
Additional information, links, postings:
RFC 1510 - The Kerberos Network Authentication Service (V5)
MSDN - Kerberos in Win2K
Technet - Kerberos Explained
A posting from Microsoft (May 17, 2001) :
"The following event ID can occur under two situations if your Windows 2000 Dynamic Domain Name Server (DDNS) server is configured to accept only secure updates and a non-secure update is received:
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 677
[...]
CAUSE
=====
The two situations which cause this behavior are:
1. A DDNS client attempts an update to the zone without negotiating a secure connection.
2. Another DDNS server attempts a zone transfer without negotiating a secure connection.
When a Windows 2000 DNS server is configured for Active Directory Integration there are three options for Allowing Dynamic Updates:
1. Yes
2. No
3. Only secure updates
By setting a zone to only allow secure updates, you cannot receive them from any non-secure client.
RESOLUTION
==========
To resolve this issue:
1. Start the DNS snap-in.
2. Double click the "Forward Lookup Zones" and the "Reverse Lookup Zones" if they are configured.
3. Right click the zone you would like to configure and choose properties.
4. Choose the general tab.
5. In the Allow dynamic update drop down list select Yes.
6. Choose ok.
STATUS
======
This behavior is by design
MORE INFORMATION
================
The DNS server for Windows 2000 will send and accept dynamic updates if it is configured to do so. It can also send and accept secure updates. Secure updates are currently only supported between Windows 2000 clients and Windows 2000 servers.
Additionally, if while running DCPROMO you allowed the wizard to set up the DNS zones for the Active Directory, they default to "Only Secure Updates". These will need to be changed before exchanging dynamic updates with supported third party DDNS servers.
This behavior is due to the type of authentication used by Windows 2000 to allow secure updates. There are several different IETF drafts available for this authentication but a standard has not yet been defined. As a result, there are currently no third party DDNS servers which support the same method of authentication for secure updates."
I am sending you a few articles, maybe one will help or apply to your situation.... THE ARTICLES I SENT MAY SEEM LONG, BUT IT WILL HELP YOU WITH A BETTER UNDERSTANDING ON NETWORKS.... I BEEN DOING THIS FOR OVER 15 YEARS, AND YOU KNOW WHAT?? THERE IS ALWAYS SOMETHING NEW TO LEARN.......I AM STILL LEARNING, AND IT NEVER STOPS, BUT I LOVE IT..... ALSO, YOU MAY KNOW THIS ALREADY, BUT I WILL MENTION IT.... IF YOU GET STUCK ON A SITUATION, OR NEED HELP WITH EVENT ID NUMBERS, OR ANYTHING YOU WANT TO KNOW......
JUST GO TO "GOOGLE.COM" AND TYPE IN WHATEVER YOU WANT TO KNOW.... YOU CAN EVEN TYPE IN HOW TO HACK IN ANOTHER SERVER, AND IT WILL SHOW YOU PAGES OF STUFF..... I CAN ALSO SEND YOU TO A HACKER SITE WHERE THEY HAVE ALL THE UTILITIES YOU NEED TO CATCH HACKERS, MONITOR YOU NETWORKS, HELL,,, EVEN WILL TELL YOU HOW TO BE YOUR OWN HACKER, AND WILL GUIDE YOU WITH STEPS AND COMMANDS, BESIDES SOFTWARE..... TALK TO YOU SOON, HOPE THIS HELPS.....
STEVE NETWORKS@NETSCAPE.NET or .COM (New Account)
This article was previously published under Q281431
SYMPTOMS
When you use the Active Directory Connector (ADC) with Microsoft Exchange Server 5.5, a logon failure is reported every time the ADC is run. You can find the failure in the security event log if auditing for "audit account logon events" is enabled for "logon failure."
The security event log shows the following event:
Event Type: Failure
Event Source: Security
Event Category: Account Logon
Event ID: 677
Date: 1/4/2001
Time: 1:01:30 PM
User: NT AUTHORITY\SYSTEM
Computer: ServerName
Description:
Service Ticket Request Failed:
User Name: Administrator
User Domain: DOMAIN.COM
Service Name: LDAP/ExchangeSrvName.domain.com
Ticket Options: 0x40810010
Failure Code: 7
Client Address: 127.0.0.1
STATUS
This event can be safely ignored because this version of Exchange Server is not Kerberos-aware and does not register a Service Principal Name (SPN) with the Active Directory.
MORE INFORMATION
The error is generated when the ADC attempts the contact the Lightweight Directory Access Protocol (LDAP) service on a member server running Exchange Server 5.5. The server running the ADC attempts to authenticate against Exchange service by requesting a Kerberos ticket for LDAP/myexhangesrv.mydomain.com.
The Microsoft Windows 2000 Kerberos Key Distribution Center (KDC) attempts to resolve the Service Principal Name (SPN) to a Windows 2000 server. Exchange Server 5.5 is not Kerberos-aware and does not register an SPN with the Active Directory. Because an SPN that matches does not exist, the KDC returns an error that is logged as the 677 event. The server that is running the ADC falls back to NTLM and is able to connect to the LDAP service on the Exchange Server computer.
Although it is possible to manually add an SPN for the LDAP server by using SETSPN from the Resource Kit, this will cause the ADC to fail.
Manually adding an SPN will cause the 677 events to stop. However, the ADC will no longer be able to authenticate to the LDAP service on the Exchange Server computer. Because the SPN can be resolved to a server, the KDC will return a Kerberos ticket for the target server (the server with the LDAP SPN registered). The server that is running the ADC will attempt to use a Kerberos ticket to authenticate to the Exchange service. Because Exchange 5.5 is not Kerberos-aware, it is not able to validate the user. This occurs even if Exchange Server 5.5 is installed on a Windows 2000 member server.
ANOTHER ARTICLE:
The Security Event ID 677 (Failure Audit) is generated by the Kerberos Service Ticket Service. Kerberos is used by Windows 2000 Active Directory for authentication and is supposed to replace the old Windows NT security architecture. Typically there are 2 types of 677 events: with Failure code 7 and with Failure code 32 (see the table below for a more detailed list of potential failure codes). Let's analyze the two most common codes, 7 and 32!
Failure code 7
Any Kerberos-compliant software will try first to use Kerberos in order to obtain access to various servers or applications and usually if such access fails they will try an NT-compliant access (using NT authentication). So typically, a Kerberos-compliant application willing to access let's say SERVER1 will interrogate the Kerberos Distribution Center server for the Service Principal Name (SPN) of SERVER1. Kerberos-compliant application will register their SPN with a KDC but applications like MS SQL 7.0 won't. As a consequence, the KDC is not able to resolve the SPN for the MS SQL 7.0 server and a 677 event with Failure Code 7 is generated.
Example:
Service Ticket Request Failed: User Name: sql_service User Domain: CORPORATE.NET Service Name: MSSQLSvc/SERVER1.CORPORATE.NET:1433 Ticket Options: 0x40810010 Failure Code: 7 Client Address: 127.0.0.1
This event may be generated by various services that are trying to authenticate through a Kerberos Service Ticket. Between the services reporting such errors are: IIS, SQL, DNS, Exchange 5.5, etc... When instead of a user name, a COMPUTERNAME$ is listed, that means that it is the System account that failed to obtain a Kerberos service ticket. Microsoft Knowledgebase has an article documenting the occurrence of event 677 when ADC (Active Directory Connector) is trying to connect to an Exchange 5.5 server. See Q281431 - XADM: Logon Failure Event ID 677 with Exchange Server 5.5 and Active Directory Connector
A combined environment, Windows 2000, Windows NT / 98 with Active Directory running on mixed mode may cause the occurrence of such events as NT/Win98 machines are trying to connect to a Win2000 machine and fail because NT and Windows 9x are not Kerberos-aware.
Another source of 677 messages are improper DNS configurations. Typically, they would occur when the NetBIOS name of the server is different from the DNS host name. For example, we see these events on domain controllers with the source machine of the event being 127.0.0.1, the LOCALHOST which probably is not recognized as a valid SPN. We suspect that this might be the case when these event occur in a "native" Windows 2000 Active Directory environment (supposedly 100% Kerberos compatible).
By disabling NetBIOS over TCP/IP on the Windows 2000 Domain Controller performing the role of the PDC, some of these events may be eliminated and this action should not affect Windows 2000 AD environments running in "native" mode.
Failure code 32
The problem in this case is in the Kerberos ticket expiration. It appears that Windows 2000 just keeps renewing tickets until it fails because of expiration and then gets a new one. If this is correct, then the 677 failure code 32 errors are "normal" events that one cannot prevent without disabling the auditing for Failure Audits.
* * *
The failure codes reported by these events come directly from the Kerberos RFC 1510. These codes may help with the identification of what caused the error.
Code
Description
0
No error
1
Client's entry in database has expired
2
Server's entry in database has expired
3
Requested protocol version number not supported
4
Client's key encrypted in old master key
5
Server's key encrypted in old master key
6
Client not found in Kerberos database
7
Server not found in Kerberos database
8
Multiple principal entries in database
9
The client or server has a null key
10
Ticket not eligible for postdating
11
Requested start time is later than end time
12
KDC policy rejects request
13
KDC cannot accommodate requested option
14
KDC has no support for encryption type
15
KDC has no support for checksum type
16
KDC has no support for padata type
17
KDC has no support for transited type
18
Clients credentials have been revoked
19
Credentials for server have been revoked
20
TGT has been revoked
21
Client not yet valid - try again later
22
Server not yet valid - try again later
23
Password has expired - change password to reset
24
Pre-authentication information was invalid
25
Additional pre-authentication required
31
Integrity check on decrypted field failed
32
Ticket expired
33
Ticket not yet valid
34
Request is a replay
35
The ticket isn't for us
36
Ticket and authenticator don't match
37
Clock skew too great
38
Incorrect net address
39
Protocol version mismatch
40
Invalid msg type
41
Message stream modified
42
Message out of order
44
Specified version of key is not available
45
Service key not available
46
Mutual authentication failed
47
Incorrect message direction
48
Alternative authentication method required
49
Incorrect sequence number in message
50
Inappropriate type of checksum in message
60
Generic error (description in e-text)
61
Field is too long for this implementation
Additional information, links, postings:
RFC 1510 - The Kerberos Network Authentication Service (V5)
MSDN - Kerberos in Win2K
Technet - Kerberos Explained
A posting from Microsoft (May 17, 2001) :
"The following event ID can occur under two situations if your Windows 2000 Dynamic Domain Name Server (DDNS) server is configured to accept only secure updates and a non-secure update is received:
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 677
[...]
CAUSE
=====
The two situations which cause this behavior are:
1. A DDNS client attempts an update to the zone without negotiating a secure connection.
2. Another DDNS server attempts a zone transfer without negotiating a secure connection.
When a Windows 2000 DNS server is configured for Active Directory Integration there are three options for Allowing Dynamic Updates:
1. Yes
2. No
3. Only secure updates
By setting a zone to only allow secure updates, you cannot receive them from any non-secure client.
RESOLUTION
==========
To resolve this issue:
1. Start the DNS snap-in.
2. Double click the "Forward Lookup Zones" and the "Reverse Lookup Zones" if they are configured.
3. Right click the zone you would like to configure and choose properties.
4. Choose the general tab.
5. In the Allow dynamic update drop down list select Yes.
6. Choose ok.
STATUS
======
This behavior is by design
MORE INFORMATION
================
The DNS server for Windows 2000 will send and accept dynamic updates if it is configured to do so. It can also send and accept secure updates. Secure updates are currently only supported between Windows 2000 clients and Windows 2000 servers.
Additionally, if while running DCPROMO you allowed the wizard to set up the DNS zones for the Active Directory, they default to "Only Secure Updates". These will need to be changed before exchanging dynamic updates with supported third party DDNS servers.
This behavior is due to the type of authentication used by Windows 2000 to allow secure updates. There are several different IETF drafts available for this authentication but a standard has not yet been defined. As a result, there are currently no third party DDNS servers which support the same method of authentication for secure updates."
- Guest
by viccaz » Thu Jul 15, 2004 8:29 am
Thanks for the articles, guest!
but i don't think this is the problem, because i get 644 (few) though but from my machine (obivously Ms guys are stupid). Of course if my account is locked out during my Workstation Lock, then it seems obivous that when I try to log in back, DC gets a 644. But who's blocking my account.
Another thing ... I get many ANONYMOUS logons on my machine from N/A machine.
I don't have admin shares and only accounts controlled by me are admins.
CORRECT ME if i am wrong:
If someone (another admin) shoud write a .bat with net use and my user, to connect to a different computer (not mine) form his (where I can get no access), then on that computer will account bad password will show up in the event viewer not on DC or mine or not even on his. This is due to the fact that that computer asks the DC for corectness on received (bad) password.
But from 500 comps - mine - 3 DC which one.
At least I would have on DC a bad (internal)...something request form that computer.???
but i don't think this is the problem, because i get 644 (few) though but from my machine (obivously Ms guys are stupid). Of course if my account is locked out during my Workstation Lock, then it seems obivous that when I try to log in back, DC gets a 644. But who's blocking my account.
Another thing ... I get many ANONYMOUS logons on my machine from N/A machine.
I don't have admin shares and only accounts controlled by me are admins.
CORRECT ME if i am wrong:
If someone (another admin) shoud write a .bat with net use and my user, to connect to a different computer (not mine) form his (where I can get no access), then on that computer will account bad password will show up in the event viewer not on DC or mine or not even on his. This is due to the fact that that computer asks the DC for corectness on received (bad) password.
But from 500 comps - mine - 3 DC which one.
At least I would have on DC a bad (internal)...something request form that computer.???
- viccaz
- New
- Posts: 2
- Joined: Mon Jul 12, 2004 3:00 pm
Google Ads
3 posts • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 0 guests
