Archived from groups: microsoft.public.win2000.security (
More info?)
OK. Glad it worked and thanks for reporting back. FYI and for others the
paste below is from the Windows 2000 Security hardening guide and explains
some of the ramifications of modifying " additional restrictions for
anonymous connections" . Note that there is a hotfix called 328817 for the
can not change password issue. --- Steve
Set Additional Restrictions for Anonymous Connections
Security Objective: Disable ability of anonymous users to enumerate SAM
accounts and shares.
Recommendations:
. Domain and stand-alone servers - set this to "Do not allow
enumeration of SAM accounts and shares." This setting is equivalent to
RestrictAnonymous set to 1 and frequently, the setting is referred to this
way.
. Laptops and workstations - set this to "No access without explicit
anonymous permissions" (RestrictAnonymous = 2).
Note: The "No access without explicit anonymous permissions" option has the
potential to cause connectivity problems in many environments. Hence, we do
not recommend this setting for systems that need to accept inbound
connections generally. However, because of its great security value, we
encourage testing it thoroughly to evaluate whether it can be used in your
particular environment. Currently, several major incompatibilities with this
setting are known:
1.
When set to "No access without explicit anonymous permissions" on
Exchange 2000 servers, clients will be unable to look up addresses in the
Global Address Book. This issue was fixed in Windows 2000 Service Pack 3.
2.
When set to "Do not allow enumeration of SAM accounts and shares" on a
Windows 2000 domain controller, users on Windows XP, NT, and Macintosh
clients will be unable to change their domain password at logon. A fix for
Windows XP can be obtained from PSS by asking for hotfix 328817. No fix is
available for Windows NT and Macintosh clients.
3.
Down-level clients (Windows 9x and earlier) will be unable to
authenticate to the domain if this is set.
4.
Users on trusting NT 4 domains will be unable to list users from the
trusted Windows 2000 domain.
5.
The Browser Service does not function reliably.
6.
Inter-forest communication will not function correctly.
For more information, please see Microsoft Knowledge Base 246261
Note: On a bastion host system, we recommend seriously considering
configuring this to "No access without explicit anonymous permissions
"Mike Robertson" <mikerobertson01@hotmail.com> wrote in message
news:153501c4ad35$2a849360$a301280a@phx.gbl...
> Thanks Steve, You had it bang on. In a recent audit
> finding it was recommended that all anonymous access
> privileges should be tightened. Unfortunately "Additional
> restrictions for anonymous access" was changed to "no
> access without explicit anonymous permission". Once I
> changed that and force a policy refresh the problem was
> fixed.
> Thanks so much for your kind and expeditious assistance.
>>-----Original Message-----
>>Check their user account properties to make sure they
> are not restricted
>>from changing passwords. If you enable auditing of
> account management in the
>>Domain Controller Security Policy, you may find useful
> info in the security
>>log for failed events for account management. If these
> are XP Pro computers
>>having this problem, make sure that the domain
> controllers do NOT have the
>>security option set for "additional restrictions for
> anonymous access" set
>>to no access without explicit anonymous permissions as
> there effective
>>setting. You can look under Local Security
> Policy/security settings/local
>>policies/security options to view the setting and also
> check the registry
>>setting. See the KB link below for that.
>>
>>http://support.microsoft.com/?kbid=246261
>>
>>Depending on your domain makeup make sure that the pdc
> fsmo domain
>>controller is operational and look in the Event Viewer
> of it for any
>>problems. It is also possible that the everyone group
> does not have proper
>>permissions to Active Directory user objects. See the
> link below on how to
>>check that. --- Steve
>>
>>http://support.microsoft.com/default.aspx?scid=kb;EN-
> US;258788
>>
>>Try to think if their has been a configuration change
> around the time this
>>started happening such as importing a security template
> or modifying
>>security policy on domain controllers or domain
> computers as that may be
>>related. --- Steve
>>
>>
>>
>>"Mike Robertson" <mikerobertson01@hotmail.com> wrote in
> message
>>news:1ede01c4ac69$3c490b20$a601280a@phx.gbl...
>>> When a User request a password reset the user receives
>>> a "You do not have access to change your password"
> error.
>>> I've pruned through all my access, security and Group
>>> policies and cannot pinpoint what's overiding the "User
>>> must change password at next logon" policy.
>>> I am using a temporary workaround but it time
> consuming.
>>> When the user send a password reset request I change
> the
>>> password and get the user on the phone. I tell them
> what
>>> the password is reset to and then have them log in then
>>> do a Ctl+Alt+Del and click the change password button
> and
>>> choose a new password. This as I say though is very
> time
>>> consuming. Can you help me resolve this problem
>>
>>
>>.
>>
Facebook
Twitter
Instagram