Sporadic "A device attached to the system is not functioning" Erro

[Kevin Burnett]

Hey All,

We use LDAP to authenticate users on our web site. Recently we underwent an
upgrade of our domain controllers. After the upgrade any user with the "User
Must Change Password at Next Login" flag set to on could not log in. Prior
to this upgrade this is what we were doing:

Present user's credentials to LDAP server.
If LDAP server authenticated then log user in.
If not authenticated turn on the "Password Never Expires" flag.
Resend user's credentials.
If authenticated send user to a "change password" screen.
If not authenticated tell user their credentials were not correct.

I discovered that after the upgrade that setting the "Password Never
Expires" flag on would not "trump" the "User Must Change Password at Next
Login" flag so the LDAP server would never authenticate the credentials. To
work around this I started unchecking the "User Must Change Password at Next
Login" flag when I set the "Password Never Expires" flag. That solved the
problem but now we are encountering another problem.

Very sporadically when I call the "CommitChanges" method of the
DirectoryEntry object it throws the error "A device attached to the system is
not functioning". There is no pattern to this as a user may get this message
and then try to login again and succeed. It seemed like some sort of a
"timing" issue to me initially so I added some code to put the CommitChanges
in a loop for five more tries if it failed. I am still getting plagued by
the error...

Does anyone have any idea what I could be doing that would cause this?

Thanks for any help you could offer.

--
Kevin Burnett
Lead Software Analyst

[Joe Kaplan]

I've seen that error before and I've seen other people report it but I don't
know what causes it. I'm almost positive the actual error is being
misreported and there is a different underlying error that makes more sense
but I'm not sure how to get that in your case.

I have to say I like your hack to figure out the various "non credential"
failure states. That's pretty creative. I sure wish LDAP auth made that part
easier. It is a common complaint. Many companies I interact with would never
give you an account with permissions to make those types of changes for an
authentication application but if you got them, it should work.

One thing you might consider is to sniff the LDAP traffic with a packet
sniffer and see if you can see what happened on the wire when this failure
occurred. There might be a better LDAP error embedded in the response
message or something else useful.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Kevin Burnett" <kevnw...@noemail.noemail> wrote in message
news:AFB88369-990D-41A4...@microsoft.com...

[Jialiang Ge [MSFT]]

Hello

ADSI in general is very picky about attribute values. I once saw the error
"A device attached to the system is not functioning" from CommitChanges
just because of an additional space at the end of user account name. Please
debug your website and check the attribute values when you see the error.

Additionally, is it convenient for you to share the offending code here?

Regards,
Jialiang Ge
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

[Kevin Burnett]

Jialiang,

Thanks for your reply. I would be happy to post the code though there is a
lot of it. Is putting it in the body of the message acceptable or is there a
better way?

I would like to make another observation about this problem. The initial
problem as pointed out in my post was after the upgrade of the domain
controllers we could no longer get the LDAP server to authenticate the
credentials even after programmatically setting the "Password Never Expires"
flag on. What's weird is that the original code still works in another
environment we have that is running on Windows Server 2008. Our production
environment is running on Windows Server 2003. I could never duplicate the
problem on my development machine (Windows 7) but can recreate it every time
on a different development box running Windows Server 2003. The only thing I
see in common here besides the OS is the version of IIS that is running on
each of the boxes. I just can't see how that would have any effect though.
If I could solve the original problem of why the "User Must Reset Password at
Next Login" flag must be set ON in order for the code to work on a Windows
Server 2003 box I would be most elated!

Thanks again for everyone's help!

Kevin Burnett
Lead Software Analyst

""Jialiang Ge [MSFT]"" wrote:

> .
>

[Kevin Burnett]

Joe,

Thanks for your reply. I can't say I can take credit for the process. It's
been so long since we came up with that solution I can't remember how we did
it thought hi-jacking it from the web would probably be a good first guess.
:0)

I will look into using a sniffer to inspect the response from the LDAP
server. It's been sometime since I have had to do something like that but I
think we can get that taken care of.

--
Kevin Burnett
Lead Software Analyst

"Joe Kaplan" wrote:

> .
>

[Jialiang Ge [MSFT]]

Hello

I further discussed the issue with some escalation engineers in Microsoft.
They have seen intermittent issues involving how the ADSI Dlls work with
WLDAP32. One possible work around is to close all of the connections from
this application to the LDAP server and rebuild them. If this workaround
does not work for you, please the escalation engineers suggest that you
open a support incident in Microsoft CSS department with your free
incidents in MSDN subscription. They will help to dig into the cause.