Users cant access network drives after password change 1

[niallo32]

I have a Windows 2000 Terminal Server SP4.

Users are forced through Group Policy to change their passwords every 30 days.

When they do this, they can log on to the Terminal Server after changing the password, however,they cant access any network drives, including their Home folder

I then have to manually reset their password. The account does not appear as 'locked' in the Active Directory

When they open Outlook, they are also prompted to enter login details plus Domain.

When I reset the password, and they log on again, they can access all drives, Outlook opens fine etc.

There are no password restrictions in Group Policy - length/Uppercase characters etc...

Any ideas??

Thanks

 

[ncotton]

Very strange. Sounds like one for mark or Porkie.

Neil J Cotton
njc Information Systems
Systems Consultant

 

[Davetoo]

They can't connect to network drives through TS or from their workstation directly? How are they changing their password? at logon or via CTRL-ALT-DEL?

I advise my users that unless they change their password as they logon to their system, they should always log off and log back on with the new password. Ran into some bugs where if you changed it via CTRL-ALT-DEL the users would slowly be locked out of network resources.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

 

[niallo32]

When they are logged into their TS session, they are unable to connect to their network drives.

They change their password, not through CTRL-ALT-DEL, but when Windows tells them that their password will expire in X days - 'Do you wish to change it now'

Any ideas??

Thanks

 

[ncotton]

And the resources all stay inaccessable, even after reboots and re-logons, untill you reset their profile?

Neil J Cotton
njc Information Systems
Systems Consultant

 

[niallo32]

Exactly. No error appears in the Event Viewer though

 

[markdmac]

First just want to verify these users are logging into the domain right and not accidentally locally?

If they are logging into the domain this sounds like you may have an AD replication problem.

How many DCs do you have? Have you checked the event logs for problems replicating AD?

What I am thinking is happening here is the users are authenticating and changeing their passwords on one DC and that change is not making it to another DC. So when the users try to reach the resources, their credentials don't match.

Some stuff to look at right away.

1. Run DCDiag and NetDiag from each DC and the TS box and compare the results from each. Look for problems with FSMO roles and DNS.
2. Check the event logs for AD Replication problems.
3. Try deleting the Kerberos tickets on all servers using Kerbtray resource kit utility. The tickets will be automatically recreated.


I hope you find this post helpful.

Regards,

Mark

 

[niallo32]

Thanks for the detailed reply:

1. They are logging onto the Domain and not locally
2. I have two DC's. For the two users in question, there is an entry in the 'Security Log' - Event ID 627 - For the date in question
------
Change Password Attempt:
Target Account Name: Username
Target Domain: Domainname
Target Account ID: Domainname\Username
Caller User Name: Username
Caller Domain: Domainname
Caller Logon ID: (0x0,0x9DFC10)
Privileges: -

-------

There is also a recurring error in DNS Log:

The DNS server was unable to load a resource record (RR) from the directory at x.x.x.x.in-addr.arpa. in zone x.in-addr.arpa. Use the DNS console to recreate this RR or check that the Active Directory is functioning properly and reload the zone. The event data contains the error.

-------


The errors are on the 'secondary' DC as opposed to the other DC

-------

I've installed DCDIAG on the TS in question but get an error when I cd to C:\program files\Resource Kit and try and call it from the command line -> 'The Procedure entry point DsIsMangledDnW could not be located in the dynamic link library NTDSAPI.dll'

I've got Kerbtray running in the taskbar on the TS, but can only see a ticket for the Admin, even though there are several users logged in.

Thank

 

[markdmac]

What about NetDiag?

Focus on your existing and known errors.

Give some more details on your environment:
Do you have Exchange?
What is the history of your network?
Were you a 2000 domain with Exchange 2000 and upgraded to Windows 2003 and Exchange 2003?
Are the support tools you installed for the same OS version as the TS box?

My initial research indicates you probably have a problem with your Sysvol structure. It may be necessary to remove the second DC and bring it back in as a possible fix.

Check to see that each server does know of the two DCs by running NETMON /Query DC.

I hope you find this post helpful.

Regards,

Mark

 

[niallo32]

1. Netdiag passes everything except the following:

Kerberos test - Failed
[FATAL] kerberos does not have a ticket for TSname

LDAP test - failed - warning, failed to query SPN Registration on Domain Controller
'DCName1.Domainname'
'DCName2.Domainname'

2. I have Exchange 2000 SP3, installed on a Domain Controller

3. History of Network - hasnt been upgraded from NT, setup as is

4. Upgrades from 2000 -> 2003 - No

5. Support tools versions - Yes, correct versions

6. Netmon - It can establish a connection with DC1 (Exchange Server) for DC2, the NETMON status is 'Time Wait'

 

[markdmac]

niallo32, sorry I posted netmon above but menat to post NETDOM.

from each server (dc1, dc2 and ts)

run
netdom /query dc

Each server should give you the same result.

Which DC holds your FSMO roles?

On each DC run
netdom /query FSMO

Each server should give you the same result. If they don't then you are in for a fun ride. In the end I suspect you are going to need to follow the steps in my FAQ faq96-4733. But before we get to that let's iron out all the facts first.


I hope you find this post helpful.

Regards,

Mark

 

[niallo32]

Can you confirm the syntax of the NETDOM command - it's not working and I've tried a few variations..

Thanks

 

[markdmac]

You can get netdom help using netdom /?.

I must really need more sleep.

NETDOM QUERY DC

I hope you find this post helpful.

Regards,

Mark

 

[niallo32]

That worked now thanks.

NETDOM QUERY DCName from TS with the problem:

Querying domain information on computer \\DC2 ...
Computer \\DC2 is a domain controller of Domainname.
Searching PDC for domain Domainname ...
Found PDC \\DC1
Connecting to \\DC1 ...
Verifying secure channel on \\DC2...

Secure channel established successfully with \\DC1.Domainname for domain
Domainname.

NETDOM QUERY FSMO

The RPC Server is unavaliable

-----

NETDOM QUERY TSName from DC1 with Exchange:
Passed as above but with names in different places as expected

NETDOM QUERY FSMO

The RPC Server is unavaliable

-----------

NETDOM QUERY TSName from DC2

Same as above

----

can you tell from that what the problem may be??

Thanks

 

[markdmac]

You would not be executing this:
NETDOM QUERY TSName from DC2

From each server you should exactly type:
netdom query dc
And then post the results. You can infact dump the results to text liek this and post the contents of the file from each server

netdom query dc >dcquery.txt

Do the same for
netdom query fsmo >fsmoquery.txt

From what you posted above none of your servers are advertising they hold FSMO roles which is really bad. I again think you will need to follow my FAQ on seizing the FSMO roles, but still want to determine if Either of your DCs is undammaged so we know which one to pick to stay.




I hope you find this post helpful.

Regards,

Mark

 

[niallo32]

When I try 'netdom query dc > dsquery.txt from any of the TS or DC's. I get 'RPC SERVER not available' error

Both RPC services are started. I restart them, but it makes no difference.

Same error happens with 'netdom query fsmo >fsmoquery.txt'

Any ideas??

 

[niallo32]

Also, one of the affected users was locked out of the drives this morning, and she did not change her password over the weekend.

The error message was 'Drive letter is not accessible - the specified network password is not correct'

 

[markdmac]

OK, you are exibiting all of the simptoms that made me write my FAQ.

My only suggestion to you is to seize all FSMO roles on one DC, then DCPROMO the other DC out of the domain. After that you will need to remove the references to the removed server from Active Directory's metabase and THEN you can bring that server back in as a DC.

You will find details on how to do the above in my FAQ FAQ96-4733.

I hope you find this post helpful.

Regards,

Mark

 

[niallo32]

A few problems though:

1. How do I know which is the bad dc?
2. There is no NTFRS Service - or at least its not appearing in the DC service list
3. How do I delete the Kerberos certs?

Thanks

 

[markdmac]

The problem is that the servers are out of sync. You could keep either, however you indicated that you have manually been changing the passowrds on one server, this is the server you should be keeping.

You can delete the kerberos tickets with the resource kit utility Kerbtray.

Regarding no NTFRS service, sounds like the servers just have no idea the other exists.

One last thing before you undertake the steps int he FAQ, make sure you don't have any firewall software blocking the RPC communications.

I hope you find this post helpful.

Regards,

Mark