Re: GPO causing client security logs to fill?

LDD15 wrote:
Thanks again for your time. I am going to go at this a piece at a
time. Also let me mention that to my knowledge there never was any
virus. That was suggested buy someonw else but I have found no
evidence. I believe the initial problem was entirely a resulte of the
Time32 sync being off.

Based upon my understanding of what you have been saying. I think
that I should:

No this is not what I suggested to you;


1) Unlink the Default Domain Controller Policy (As it was not
previously linked)

Only unlink it from the Domain. It should remain linked to the Domain
Controllers OU!!!


2) Possibly delete the Default Domoan Controller Policy (As it did not
previously exist under the Domain, it only existed under the GPO
folder)


NO, DO NOT DELETE ANY GROUP POLICY OBJECTS!!!


Does this sound correct?

Please carefully review my previous suggestions. If you are not comfortable
following them, consider engaging someone that is, or contacting Microsoft
CSS to do it for you.



"kj" wrote:

LDD15 wrote:
Ok,


Proably not fair to ask me to jump into that aspect of your previous
issues as it was about recoverying from a virus which appears to
have been successfull.

So you've seen the list.

Several questions/comments.

1) Ok in the previous post there was a comment to the effect of the
settings as applied by the wizard cannot be trusted or that is why
the default domain/default domain controller policies where edited.
Do you disagree with this comment

I've no substantial comment on this one. Hardly anything can be
trusted with a virus in play. Normaly, the wizards are more
trustworthy than an experienced MCSE, certainly more consistant.


2) If so, should I go back and undo the changes and set it the way
you are suggesting or leave it?

I believe, from the information you have provided, that the policy
settings, errant linkage, and incorrect 'enforced' setting are
causing default audit settings to be applied on your client
workstations.


3) You are correct. An actual linking change was not suggested. I
mistated that part. The suggested change was to the password
complexity setting. I added the link because I saw that this was the
location of that specific setting in the actual GPO's, in otherwords
I was trying to follow the same model. My mistake.

Group Policy is a complex and often misunderstood beast. It's not
hard to make a simple yet disastrous mistake.


4) Is there an audit log somewhere so that we can undo the changes
of the last several days. I have taken notes but perhaps it would be
good to verify.

No not really - even if actions hadn't changed the effective audit
policy. You might have entrys that policy had been changed but these
would lack the detail of *what* had been changed. I personally use a
change management log for my clients, as it is the only way I could
remember what I did last month. (OneNote 2007 makes for a great tool
for this purpose.)


5) Based on what you have seen from the list that I posted would
this account for the added items in the security logs?

Not so much the added items, but the audit log settings that are
causing the event logs to become full and not permitting the users
to log on.

The actual events may or may not be, you'd have to post some detailed
examples. Still the event log would eventually fill up with
legitimate events and you'd be right back where you are.



Thanks so much.

"kj" wrote:

LDD15 wrote:
In answer to both of your questions, I am pasting the text from a
previous thread below. In summary we were having a sudden issue
with client logon failures. In this same newsgroup I posted a
thread titled "Client Logon Failure". Below are two sections of
text that result from that thread and from an email which was
external to the thread. I am under the impression that all of
this work was for not as I believe the actual problem was a
result of Time32 issues.

In summary, the following was changed. I modified the account
lockout policies as instructed below. This was done in the Group
Policy Objects. I realize that as a rule you are only supposed to
change the linked GPO's as opposed to the actual GPO's themselves.
However, I did find an article in the MS KB that said that
account/password items should be changed in the actual GPO's.

So basically, the Account lockout threshold, account lockout
duration and the account lockout reset where changed. I believe
this was changed in both the Default Domain Policy and the Default
Domain Controller Policy.

Also, per recommendations a linked GPO was made to the Default
Domain Controller Policy to set the "required password complexity
requirements" to enabled.

If this is not enough info please let me know.

First, Password policy (in SBS) should be set using the wizard and
only is effective when linked on the Domain (Small Business Domain
Password Policy, Small Business Server Lockout Policy). Second
adding another policy link probably changed the GPO precedence.
Also, it is not really a good idea to modify "default (domain or
domain controller) policy settings. It's better to add additional
Group Policy Objects then link accordingly and order precedence.

Unfortunately the recommendations are not Small Business Server
specific rather a generic Windows 2003 / AD. I may be missing it,
but I don't see where any GPO linking change was suggested.

If you have the details of what new GPO links were made, I'd
consider undoing (unlinking) the new links.

Btw, Audit log settings for the client computers are set in the
"Small Business Client Computers" Group Policy Object and I beleive
should be at link precendece order 3 in the domain policy list.
Perhaps post a list what policies you have linked there and what
order they are in.


Thank you both.
_________________________________________________________________________
From: Terence Liu (CS&S) [mailto:v-terliu@xxxxxxxxxxxxx]
Sent: Thursday, June 14, 2007 7:01 AM
To: Don Emerson
Subject: RE: Client Logon Failure (39270465-Client Logon Failure)

Hello Don,

Thank you for kind update.

In your client even log, I find many error message 1053:

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1053
Date: 2007-2-10
Time: 14:06:27
User: NT AUTHORITY\SYSTEM
Computer: MARMAC1

Description:

Windows cannot determine the user or computer name. (An internal
error occurred. ). Group Policy processing aborted.

1. I agree with you. This is mostly a virus related issue. The
other 2 workstations may infected by virus from this problematic
client.

Therefore, how about the step 1#? Do you find any virus from the
client?

Please try to install the antivirus on all client computers and
SBS, update the virus definition to latest and perform full virus
scan on the computers. If you do not have anti-virus application
installed, you may try: http://housecall.trendmicro.com/.

2. When you do clean boot on the client computer, you have to
logon as Administrators member account. I suggest you logon the
problematic client with local administrator and then do the clean
boot to test.

3. You can try to reboot the client and enter to Safe Mode (with
network), then try to logon domain. Is it fine?

Based on my research, the behavior can happen when the virus
activity that guessed the password, or the machine password is not
properly sync between SBS and internal clients. I suggest we try
the following steps to see if we can resolve this issue:

1. Enable complicated password policy.

Note: The Password Policy need to be configured in Default Domain
policy.

We can configure the settings under:

Computer Configuration\Windows Settings\Security Settings\Account
Policies\Password Policy

2. Configure account lockout policy.

Generally, it is a best practices suggestion to set the Threshold
value to 10 or higher. This is high enough to rule out user error
and low enough to deter hackers, especially when the password
complexity policy is enabled.

For medium security requirement, the recommended configurations
are:

Reset account lockout counter after: 30
Account lockout duration: 30
Account Lockout Threshold: 10

For high security requirement, the recommendations are:

Reset account lockout counter after: 30
Account lockout duration: 0
Account Lockout Threshold: 10

For more information, please refer to:

Account Passwords and Policies
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx

3. Check your firewall to ensure that only the necessary ports are
opened.

4. Ensure the above settings have been successfully applied.

1) On the problematic SBS server, please run the following command
to refresh the group policy changes:

GPUPDAGE /FORCE

2) Run SECPOL.MSC and check the above changed password, Account
lockout and auditing policies to see their effective settings, and
ensure that the policies have been applied successfully.

If the policies have been applied successfully, we should have
enhanced the security protection of that server.

5. The issue may occur if the remote SBS server sends broadcast
packets to the network. I suggest you change the "nolmhash" value
to "0" in the following registry key on the SBS server:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA

Reboot the server for this change to take effect and check if the
event
does not appear.

6. If the event still appears, go to
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\lanmanserver\Parameters
and set "enablesecuritysignature" and "requiresecuritysignature"
to "0". Reboot the server and check if everything is OK.

7. There are several running processes on the computer that will
attempt to connect using the machine account.

This behavior can happen when the machine password is not properly
sync.

In order to reset the machine account password of a domain
controller use:

NETDOM RESETPWD /Server:ServerName /UsedD:Administrator
/PasswordD:*

The syntax of this command is:

NETDOM RESETPWD /Server:domain-controller /UserD:user
/PasswordD:[password | *]

NETDOM RESETPWD Resets the machine account password for the domain
controller on which this command is run. Currently there is no
support for resetting the machine password of a remote machine or
a member server. All parameters must be specified.

/Server Name of a specific domain controller that should
have its

machine account password reset.

/UserD User account used to make the connection with the
domain

controller specified by the /Server argument.

/PasswordD Password of the user account specified with
/UserD. A * means

to prompt for the password

After completing the command, reboot the server.

If we can not resolve the issue after we perform the above steps,
please kindly help me collect some information for further
investigation:

Please send the Server Performance report to me.

Hope these steps will give you some help.

Thanks and have a nice day!

Terence Liu

________________________________________________________________________
Hello Customer,

Thank you for posting here.

According to your description, I understand that you notice that
one of the client computer have several logon failures through a
day. If I have misunderstood the problem, please don't hesitate
to let me know.

First, please let me know:

1. Does this problem happen every day?
2. How do you notice the logon failures?

Based on my research, the virus or 3rd-party software may relate
to

--
/kj


.

Relevant Pages

  • Re: GPO causing client security logs to fill?
    ... a virus in play. ... settings to be applied on your client workstations. ... Group Policy is a complex and often misunderstood beast. ... I modified the account ...
    (microsoft.public.windows.server.sbs)
  • Re: GPO causing client security logs to fill?
    ... Unlink the Default Domain Controller Policy (As it was not previously ... settings to be applied on your client workstations. ... I modified the account ... So basically, the Account lockout threshold, account lockout ...
    (microsoft.public.windows.server.sbs)
  • Re: Win2K - Account Lockout Policy
    ... A W2K client should be able to view the local security policy. ... settings for the policy should come down from the domain controller. ... >> that the account get locked out after 1 incorrect attempt, ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Win2K - Account Lockout Policy
    ... A W2K client should be able to view the local security policy. ... settings for the policy should come down from the domain controller. ... >> that the account get locked out after 1 incorrect attempt, ...
    (microsoft.public.win2000.security)
  • Re: Any of you having problem with Exchangeserver 2003 and OUTLOOK 2002?
    ... There must be something between Exchange 2003 and OL 2002 client that I just ... > the (insert latest virus name here) virus, all mail sent to my personal ... > account will be deleted without reading. ...
    (microsoft.public.officeupdate)