WSA LDAP Authentication issue

Unanswered Question
Oct 15th, 2008

For the most part, our S650, v5.6.0-618, works fine, so my issue is most likely on the machine level.

All machines on our domain function properly, with the exception of one. The domain is comprised of w2k and XP machines, with the DC running s2k. Yes, I know I need to upgrade the DC to s2k3.

The machine in question, without fail, requires the user to authenticate, even though we have it set up to do so transparently.

Checking all the IE settings, the s650 is listed (via the domain) as a valid intranet site. None of our other Windows authentication enabled intranet sites ever prompt for his credentials.

Any suggestions on what to change are most appreciated, though I've looked through everything of which I can think in order to track down this issue.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
jowolfer Thu, 10/16/2008 - 15:37


We've found that this can be caused by having a saved password in Internet Explorer.

When users enable "Remember this password", browser continues to use these variables over the credentials used to login into the computer.
This works fine as long as the password on the AD does not change.
Once the password changes on AD, browser attempts to use the saved user credentials and fail. The problem is that this data does not clear itself after failing. Next time around, browser again uses the saved credentials and prompts you to enter them again.

IE does not provide a method to clear out these variables from cache. There are couple of options that we have seen help. However, please note that IronPort has not tested these options as it is a Windows configuration issue.

- Clear everything. This data are stored under
C:\Documents and Settings\USERNAME\Application Data\Microsoft\Credentials
You may want to relocate files under this directory, and see if it makes a difference.

- Use third party tool
There are several tools which decrypt the usernames, and would allow you to delete the appropriate data. Unfortunately, we do not have more information on these tools.

In the other cases we've seen this, IT spent hours attempting to get the client to work correctly, but didn't succeed. The end result was to re-image the client. This did work successfully.

Gawayne_ironport Thu, 10/16/2008 - 15:54

Looks like it's the latter case. We've already cleared the password cache (on top of disallowing it from initially being saved). Thanks, though


This Discussion