Clearing cached credentials for multiple users

[DTracy]

Hi all,
I have a situation where several XP pro workstations have from 10 to 30 user profiles on each. A change in drive mapping on a server requires that I logon to each workstation as each user and disconnect the mapped drives individually. I have tried altering the login script to include the instructions:

net use */delete
net use */persistent:no
and then the usual drive mapping

But this doesn't work, I still have to disconnect manually before the login script will map the new drives. It takes me all day to do nine workstations because I may have to login 200 or more times.

How can I clear the cached credentials of all users on a single workstation in one operation instead of the way I do it now?

Thanks for any suggestions.


Best Regards,
David Tracy

 

[bcastner]

What you are doing should work, although you are missing an important space:

net use * /delete
net use * /persistent:no
and then the usual drive mapping

If the currently mapped drives letters are F:, G: and Z: you could modify the logon script:

net use * /delete
net use F: /delete
net use G: /delete
net use Z: /delete
net use * /persistent:no

 

[TechyMcSe2k]

Is the * supposed to represent a mapped letter drive?
The logon script should be
net use h: /DELETE
net use k: /DELETE
net use h: \\severname\sharename
net use k: \\servername\sharename

I used h: and k: only as examples; change these to your needed drive letters.

This should work in resolving your issue. The /PERSISTANT is not needed in this case. Let me know if I have gone the wrong way in understanding your question.

 

[bcastner]

net use * /delete
This command removes all existing mappings.

Persistent:No is a good choice when a logon script is being used. Persistent:Yes is a good choice when no logon script is being used to rebuild the drive mappings. Without the statement prior to the drive mappings in the logon script, the subsequent mappings would be persistent by default. This can occasion with fast logon optomization an error "Device in use" without a formal setting of persistence to no.

 

[DTracy]

Yes, well ok. I believe the spacing is alright but I will double check that.

I think my question was about the removal of the cached credentials for all users. Is this possible?

Thanks ever-so much.



Best Regards,
David Tracy

 

[tcambridge]

David,

As far as clearing the cached accounts, I'm not sure how to do that. However, you can disable cached account logging in the following location:

HKLM/Software/Microsoft/Windows NT/CurrentVersion/winlogon/cachedlogonscount

The default is set at 10. The max is 50. To disable, set to 0.

As I understand it, the cached account only takes effect when a domain controller is unable to authenticate a logon request. If the DC is unavailable, then the authentication is reverted back to the last successful logon for that user.

BCastner has provided a great solution by deleting and remapping the drives at each logon. This will ensure that the users will have the most current drive mappings each time they log on.

Hopefully this answered your question on cached accounts.

Tim
Certified AND Qualified

 

[bcastner]

By default, the Stored User Names and Passwords feature creates a "key" for any connection that you make in the graphical user interface (GUI) that requires alternate credentials. When you make a connection at a command prompt by using the net use command and by passing alternate credentials, a key is not created. This means the drive mappings made in a logon script do not generate a saved credential.

For the net use command to save the credentials in Credential Manager, you would use the /savecred switch. When you use the /savecred switch, any credentials that you are prompted for when you use the net use command are saved as a key.

Note too, that you only create a saved credential situation when alternate credentials are required to access a resource. If your logon username and passsword are acceptable for the Net Use command, no credentials are saved.

For web passed username and passwords, The actual information is stored in a protected portion of the registry under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Protected Storage System Provider\[SID of the user]\Data. You have to use the Internet Options, Content, AutoComplete applet to clear these.

When you use the command:
net use * \\computer_name\share_name /user:user_name password /savecred

Credential Manager stores the supplied password in the so called "Enterprise Credential Set" of the local machine.
This set of credentials is stored in the file:
\Documents and Settings\%Username%\Application Data\Microsoft\Credentials\%UserSID%\Credentials
and is encrypted using the DPAPI subsystem.

You can manual clear these entries with control userpasswords2, Advanced, Manage Passwords; you can use Group Policy to disable their being saved at all; or I suspose you could delete their filestore as mentioned above.

 

[DTracy]

Thanks to all for the responses and the detailed explaination of the credential cache. I have isolated the problem to the login script not being executed. The net use instructions are typographically and syntactually correct but the workstations do not seem to follow them. This morning I attempted some drive mapping changes on another one of those workstations and even with the drive disconnected from the workstation it would not re-map by the login script. I had to map manually. I checked the DNS numbers, and they seem ok. I obviously don't have a permission/authentication problem because I can manually map the drives. I can see everything that I'm supposed to see in the neighborhood, and can connect accordingly. The user profiles on the PDC are correct, and the login bat files are accessible. No errors anywhere.

Why, do you think, the workstations won't map from the login script?

Thanks again for all the help, it is greatly appreciated.


Best Regards,
David Tracy

 

[tcambridge]

Can you post your script so we can take a look at it? Where in the script does it stop processing?

Tim
Certified AND Qualified

 

[DTracy]

Hi Tim,
Thanks for the interest. This is the contents of one of the login scripts that is used:

net use * /delete
net use * /persistent:no
NET USE F: \\GREENLEENT5\Data
NET USE G: \\GREENLEENT5\Users
NET USE V: \\GREENLEENT7\SheriffApp
Net Time \\greenleent4 /set /y
exit

I've tried deleting the individual drives and then re-map, no change. For whatever reason the workstations seem to ignore these instructions. The users can login ok, and if I change a user password on the PDC, the user must then also enter the changed password in order to login, so cached credentials are being read through to the PDC.

Thanks for any thoughts, or assistance.




Best Regards,
David Tracy

 

[bcastner]

...and if I change a user password on the PDC, the user must then also enter the changed password in order to login, so cached credentials are being read through to the PDC."

I really think you are misunderstanding cached credentials. As you pose the issue, a password change would have led to a mapping failure because of the older cached credentials.

I will repeat what I said earlier, in a Net Use or through the GUI, a device mapping does not occasion the saving of a credential. The only exception is if you use the command line Net Use statement with the optional parameter /Savecred

Where you can run into trouble is if you have multiple servers, or shares with individual authentication demands. It is unclear whether the following is showing 3 servers: GREENLEEN4, GREENLEEN5 and GREENLEAN7. This would pose an issue if there is no Trust relationship, or a replication failure by the PDC.

Moreover, if each share posed seperate credentials, this will not work well for Win2k or XP as clients, as only the last set of credentials are preserved. See this discussion, including the provided links:

http://support.microsoft.com/default.aspx?scid=kb;en-us;283492&Product=winxp

 

[bcastner]

One good way to see what is happening is to add as the first line in your logon:

Echo On

Then place a Pause statement between each Net Use

You can strip this out later.

 

[DTracy]

Hi Mr. Castner,

The servers:

GreenleeNT4 is the PDC and replicates to GreenleeNT3 only.

GreenleeNT5 and GreenleeNT7 are in the farm only, and their IP's are in the DNS.

The reason I said whatever it was about the password was to demonstrate that the workstation is indeed authenticating from the PDC. There are not any trust relationship problems that I am aware of.

I appreciate your time and insight very much, thank you.



Best Regards,
David Tracy

 

[bcastner]

DTracy,

It would be interesting to see if the logon script is executed.

Add at least a line for testing:

cls
net use
pause

 

[DTracy]

Mr Castner,

After reading the information at the link you provided about stored passwords, I believe that I have misrepresented the problem somewhat. The reason I have followed the thought line of cached credentials is because I felt that the workstation was just using cached logon credentials and not reading/executing the login script. Perhaps this is not the reason for the failure to execute the login script at all. And this then would be the real issue. Do I need to start a new thread?



Best Regards,
David Tracy

 

[bcastner]

My opinion is not.

It is clearly not a cached credential issue, but rather one of the logon script either not executing, or failing on the Net Use statements.

Lets continue here. I think it shows a linear troubleshooting sequence.

And my best regards. If I can help you to figure this out I would be more than happy to. You are lucky as I will be attentive this afternoon as a snowstorm settles in over the area. I agree with you that there are different issues between cached credentials, a logon that fails to run, and a map that does not succeeed. But there is a reasonable diagnostic flow going on here I would hate to break at this point for other NT/XP client domain users.

Best wishes,
Bill Castner

 

[DTracy]

Thank you sir,

Well then, I think more information about the LAN is in order. This is a county government LAN and part of an intranet from the Supreme Court of our state. The problem area is in the sheriff's department where I have a few workstations with many profiles. The entire LAN has a mixture of w2k and xp-pro workstations, with the sheriff's department using xp-pro. The PDC (GreenleeNT4) is NT4 as is the BDC (GreenleeNT3). The farm (x.84.x.x) is all W2k. I am in the process of upgrading the NT4 to W2k, but not today. As I indicated there are many departments in the LAN with four subnets (x.82.x.x, x.83.x.x, x.84.x.x, and 159.x.x.x)used and a LayerIII switch as well as a bunch of routers and a couple of satellite uplinks. It sort of looks like a plumbers nightmare, even on paper! All this stuff is required by one agency or another or by some other State department. Also, we are connected to the other counties by wireless and the local sheriff's department(x.84.x.x) is connected to the servers by wireless. Also, the sheriff's substation (x.82.x.x)in the lower end of the county is connected by wireless. So much for that.

The workstations in the local sheriff's office will re-map sometimes if the old mapping has been disconnected(cleared). The workstations in the substation will not re-map anytime. They have to be manually mapped.

It's a half mile to the local sheriff's office and 30 miles one way to the substation. So any changes may take a while for me to test.

Other than the NT4 thing, what do you think I should try?


Best Regards,
David Tracy

 

[bcastner]

Lets focus first on the peculiarities of XP as Domain client.

It does not act the way a Win9x, or even Win2k client does in your mixed setting. This concern, while valid, is unlikely at play, as you have a Layer III switch: " As I indicated there are many departments in the LAN with four subnets (x.82.x.x, x.83.x.x, x.84.x.x, and 159.x.x.x)used and a LayerIII switch as well as a bunch of routers and a couple of satellite uplinks."

If we can resolve two issues, the rest falls into place:

. is the XP client doing the logon script?
. What does the XP client need to know at startup?

See my notes here as a start: faq779-4017
. Disable Fast Logon Optomization (last paragraph of the FAQ);
. Make sure if using DNS and/or WINS that the settings are completely correct under Network Connections, Properties. No other references are permitted other than your internal server(s).
. And while you are unlikely to want to hear this at the moment, XP SP2 has a revamped redirector that is just amazing relative to any earlier version offered for Windows.

 

[DTracy]

Mr. Castner,

Sorry for the delay, a lightning storm yesterday afternoon fried the amplifier of our main wireless link. Then my boss decided to take the 4X4 out of town for the weekend and took all the keys with him. So, here I am, low man on the totem pole.

Anyway, first of the week I plan to start with a basic login script to test execution on the substation XP workstations. I'll resume this thread when I have something new to report.

Again, thank you and all for your interest and kind attention.

Best regards,
David Tracy

 

[bcastner]

Be sure to remove "Echo off" from the script and insert a lot of Pause statements.