Re: Domain users unable to change password

OK. Let me know if netdiag shows any problems. You could always paste any
results here in a reply. --- Steve


"Hank Arnold" <rasilon@xxxxxxx> wrote in message
news:%231ZQCH7pFHA.156@xxxxxxxxxxxxxxxxxxxxxxx
> In-Line Comments....
>
> --
> Regards,
> Hank Arnold
>
> "Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxx> wrote in message
> news:e7MRkOxpFHA.3516@xxxxxxxxxxxxxxxxxxxxxxx
>> Hmm.
>>
>> As far as No access without explicit anonymous permissions try setting it
>> to none - rely on default permissions instead of undefined though at this
>> point I doubt it is the problem but to will not hurt to try. When they
>> logon via RDP what are they logging onto - a domain server or domain
>> controller?
>
> The clients are logging into a TS server running Citrix MetaFrame Xpa.
> Member server, not a DC.
>
>> Try to give a user the user right for logon locally to a domain
>> controller temporally and then let them logon and try to change their
>> password while logged onto the domain controller [preferably pdc fsmo] to
>> see if that works or just have an admin try to change their password
>> assuming the problem affects all domain users. The reason being is you
>> are bypassing the network to access a domain controller and trying a
>> different operating system.
>
> Not sure what this will do... They can change the password if they log
> onto a server directly. It's when they try to change their password
> locally on the workstation after doing a local logon...
>
>> Be sure to run netdiag on both domain controllers and a domain client
>> computer to see if any problems are found. It sounds like a networking
>> problem of some sort since a the problem is avoided when using RDP which
>> uses port 3389 TCP for traffic for the session instead of the normal
>> ports and protocols. Make sure that from a domain client computer that
>> you can ping your domain controllers by name and IP address and vice
>> versa and verify that you can access the sysvol share of your domain
>> controllers from your domain clients as in \\domaincontroller\sysvol. In
>> the past SMB signing was a problem with XP computers in a W2K domain but
>> I thought for sure that was fixed in SP2. If you want to try messing
>> with that then check the Local Security Policy of your domain controllers
>> to make sure that the options for digitally sign server/client
>> communications (always) is set to disabled. Then on one XP Pro computer
>> use Local Security Policy and set all the options for digitally sign
>> communications to be disabled and reboot the XP computer. If later you
>> find that SMB signing was not the issue restore digitally sign
>> communications settings to what you had them at.
>
> I'll try these sugestions....
>
>>
>> Beyond that a network trace may be helpful. You can use netmon on domain
>> controllers to capture traffic but a lot of lines will be recorded. To be
>> effective you will need to enable netmon just before a user tries to
>> change their password and then stopping it as soon as they change fails
>> and then look in the log for traffic from and to the domain client where
>> sometimes helpful information is in the body of the packet capture. You
>> also might want to try such "after hours" when network traffic is at a
>> minimum or see if you can configure a capture filter for netmon. XP Pro
>> does not have a built in packet snuffer but it may be worthwhile to
>> install Ethereal on one to also try to capture the packet exchange.
>> Starting with the domain client would also show what domain controller it
>> is trying to contact though you could also use the tool Tdimon from
>> SysInternals to see network activity in real time which would show the IP
>> address of a domain controller when trying to do a password change
>> assuming dns was working correctly. --- Steve
>>
>>
>> "Hank Arnold" <rasilon@xxxxxxx> wrote in message
>> news:ery5c%23upFHA.3960@xxxxxxxxxxxxxxxxxxxxxxx
>>> As I indicated, if the user logs onto the domain using an ICA or RDP
>>> client, they can change the password with no problem. If, however, they
>>> do a domain logon from the XP logon screen and try to change the
>>> password, they are not allowed. I am able to change the user's password
>>> from the Active Directory U&C plug-in on the DC.
>>>
>>> I verified that the Domain GPO allows "Everyone" to change password. Our
>>> domain is a windows 2000 domain.
>>>
>>> I did notice that the Security Policy Setting for "Additional
>>> restrictions for anonymous connections" is set for "Do not allow
>>> enumeration of SAM accounts and shares", not "No access without explicit
>>> anonymous permissions". Could this affect it? I'm going to try changing
>>> it to "Undefined" and see if that has any impact...
>>>
>>> Good suggestion about the Event Logs.....
>>>
>>> --
>>> Regards,
>>> Hank Arnold
>>>
>>> "Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxx> wrote in message
>>> news:u%23WuoampFHA.3244@xxxxxxxxxxxxxxxxxxxxxxx
>>>> Check their user accounts in AD Users and Computer to make sure that
>>>> they are not configured to not allow user to change password in account
>>>> properties. Also see if a user can change their password AFTER logging
>>>> onto the domain which may be relevant per KB 258788 that I have listed
>>>> further down.
>>>>
>>>> I can't think of a Group Policy setting offhand but if you have a
>>>> Windows 2003 domain controller try running the Resultant Set of Policy
>>>> mmc snapin in logging mode for a user/computer that is having this
>>>> problem to see the settings configured for the user and the GP applying
>>>> them. You can also use the mmc snapin for RSOP on the XP Pro computer
>>>> but I prefer to do it on a domain controller. If you are not using
>>>> Group Policy Management Console yet that is something you should
>>>> consider to help manage and troubleshoot GP.
>>>>
>>>> There were some issues in the past with not being able to change
>>>> passwords with XP Pro but I though that they were worked out in SP2.
>>>> One was that Windows 2000 domain controllers having the security option
>>>> for additional restrictions for anonymous connections configured to
>>>> be - no access without explicit anonymous permissions. That security
>>>> option could have been configured on a domain controller in either
>>>> Local Security Policy or Domain Controller Security Policy. The other
>>>> issues in the links below may also be of interest.
>>>>
>>>> http://support.microsoft.com/default.aspx?scid=kb;en-us;258788
>>>> http://support.microsoft.com/default.aspx?scid=kb;EN-US;273004
>>>>
>>>> Since you are having domain wide problem I would run the support tools
>>>> netdiag, dcdiag, and gpotool on a domain controller or two [at least
>>>> pdc fsmo] and netdiag on one of the problem domain computers. Those
>>>> tools will check for a variety of problems including dns, kerberos, dc
>>>> list, network connectivity, replication, and secure channel/computer
>>>> account integrity. Also look in the logs using Event Viewer of the
>>>> domain controllers and a problem domain computer to see if anything
>>>> pertinent is found. --- Steve
>>>>
>>>> "Hank Arnold" <rasilon@xxxxxxx> wrote in message
>>>> news:%23bigb9ipFHA.272@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> I'm still having this problem.....
>>>>>
>>>>> We are setting up our workstations, so that they do a domain logon
>>>>> instead of a local logon. Everything is working just fine except for
>>>>> one thing: when the domain GPO expires the password and prompts them
>>>>> to change it, they can't.
>>>>>
>>>>> When prompted, they click on "OK" and the expected window pops up with
>>>>> their old password in "*****" and fields for the new password to be
>>>>> entered and confirmed. The problem is that once they enter it, the
>>>>> system comes back and says that they are not allowed to change it.
>>>>> Needless to say, an admin has to do it for them.....
>>>>>
>>>>> If, however, they log onto the TS server directly, either with a
>>>>> Citrix ICA client or RDP, they are able to accomplish the change. This
>>>>> leads me to believe that it's a GPO setting or such on the local
>>>>> workstation, not a domain GPO issue....
>>>>>
>>>>> The workstations in question are running Windows XP (98% w/SP2).....
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Hank Arnold
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: Please help refresh my memory on AD DC
    ... Also when I promoted this Server 2008 box it did somthing that was not normal. ... DC would the only logon be a Domain logon or would the option to logon ... to Logon locally I would use the admin account of the Server 2003 machine. ... If you promote a server to Domain controller, there is no renaming of the ...
    (microsoft.public.windows.server.active_directory)
  • Re: Windows 2003 member server with Windows 2000 Domain Controller
    ... If anyone is having a Windows 2003 member server with a Windows 2000 ... Windows cannot obtain the domain controller name for your computer ... There are currently no logon servers available to service the logon ...
    (microsoft.public.win2000.security)
  • Re: Windows 2003 member server with Windows 2000 Domain Controller
    ... > Windows 2003 server, both registered the same event as mentioned below. ... > Event Source: NETLOGON ... > There are currently no logon servers available to service the logon ... > If this computer is a domain controller for the specified domain, ...
    (microsoft.public.win2000.security)
  • Re: netlogon and Gbit ethernet issue
    ... By the time a user can log on, net logon connectivity ... When you get the message about no domain controller found can you ping the ... DNS server at that time? ... "This computer was not able to set up a secure session with a domain ...
    (microsoft.public.windows.server.networking)
  • Re: Domain users unable to change password
    ... RDP what are they logging onto - a domain server or domain controller? ... Try to give a user the user right for logon locally to a domain controller ... Be sure to run netdiag on both domain controllers and a domain client ... Then on one XP Pro computer use Local Security Policy and set all the ...
    (microsoft.public.windows.group_policy)