MSM710 Active Directory 802.1X authentication issue?

[SteveB2177]

Having some users who are unable to authenticate to a VSC using Remote Authentication to Active Directory.

I have tested this to some degree, and have confirmed they have the LDAP attribute set on their user account (Tested it, the absence of which would get an "Invalid User" rejection, not the "Login incorrect" we are seeing). I had one user try connecting on my laptop (which definitely conects when logged on to window as myself) and he met with the same failure he sees on his laptop. It locks out his account in AD Users and Computers, so it is talking to AD, and is recognizing his user ID... somehow it is just not passing along his password correctly?

It was/is set to automatically pass the user credentials you were logged onto your windows session with, which should rule out any issues of typing it incorrectly. The pasword worked to log onto the laptop with his domain account, but is failing to properly authenticate his wireless connection.

Puzzled, and not finding anything on point after googling this forum (and the internet at large) fairly extensively.

Hopeful someone has an idea of what to try next...

Thanks in advance!

[Fred!]

Out of curiosity, you did tried a "simple" password with no spaces, no special characters, etc? Like a very standard, plain and simple, let's say 6 character password (just for a test)?

[SteveB2177]

The password of the one person I am focusing on (based on him being similar privelege level, and an adjacent desk) that does not work is about 8 characters long, no spaces or special characters, just numbers and letters.

One I know works (aka mine) has more characters and includes special characters.

But there is also another that does currently work (same priveleges, also an adjacent desk) whose password is similarly just letters and numbers...

No rhyme or reason we can see as yet...

Thanks Fred! Willing to try more if someone can point us in a direction...

[Fred!]

OK, sorry for the obvious question, but we must start somewhere, right? :)

Then maybe what I can see is that this might be related to the group(s) this particular user is associated to. There must be an exact match between the groups returned by the AD server and the ones defined in the active directory profiles. So let's say in AD your own user profile has a group named 'IT-Staff' there must be an 'IT-Staff' profile inside the MSM710. For the people where this does not work, maybe they are in a group that is not currently defined in the MSM710. If there is no match, the system will refuse the user authentication.

If you don't know which group is returned or if you think this is not the problem, one way to debug what's going on is to enable the active directory debugs in the MSM710. In Service Controller >> Tools > System tools you have an item called 'Extra AD/RADIUS debug' run that tool, clear your syslog, try again and look at the logs (you can eventually post them back here if they don't make much sense). In there you should be able to see exactly what's happening with your problematic user, versus the ones that work.

[SteveB2177]

I had ran across that tip for extra logging on another thread and tried it Friday, actually... Here is what we are getting in the log for him...

-Timestamp- debug radiusd A:Login incorrect: [DOMAIN\\username] (from client localhost port 70 cli -mac address-)

He is in the same AD OU as I (and the other person who works) and we are in all the same groups...

I tried removing the attribute it looks for (Remote Access Permission on Dial Up tab) and then we got the error "Invalid User" unstead of "Login Incorrect" in the log file... and it does lock his account, so it apparently recognizes him correctly as a domain user, and sees he has the right to connect, it just doesn't pass his credentials correctly somehow is how it appears to me/us.

Thanks Fred! Really appreciate the help... Pretty sure you were the one who I had previously see make that additional debugging suggestion, actually...

[Fred!]

Yes, I might have :) I like to repeat myself :)

Can you attach the full system log to this discussion thread? I trust that you have checked, x2 checked and x3 checked, but maybe we have missed something. And you are also saying that you don't have any particular log on the AD server when the user gets refused, right? Which would really mean that the phenomenon is happening at the controller level.

And while we are at it, what SW version are you running on the controller?

[SteveB2177]

We have 7 DC's... On the two located here at HQ, nothing... I am (slowly) working through the remote servers at the 5 other locations, but nothing as yet... I'll try to get through them today and post what I can of the log files as well...

Thanks!

Steve

[SteveB2177]

But I would think it is generating a failure on the AD side somewhere, since it is locking his account in AD users and computers...

Perhaps it is not under his username in the server logs, but I am looking at any failure generated in the time frame of one specific example from the MSM710 controller's logs, so if it is there I should find it... but having so many servers makes it a bit time consuming.

Thanks!

[SteveB2177]

I found no failure errors in the Security event logs on any of our DCs that would correlate to the failures in authentication we are seeing.

Software version: 5.3.5.0-01-7943

I am attaching a slightly sanitized version of the unfiltered log...

Thanks so much for your assistance!

[Fred!]

OK, so I've looked at the detailed log. Unfortunately in this log what I could see is that the user account was locked on the first attempt. So I could not really use the log unfortunately. What would be good is to see the user trying for a couple of times and then get locked, maybe that would help, but again I understand that it might be painful in your setup to get to that information.

What I would suggest is to try to lower your AD security policy for that particular user. There is a lot of challenges between the client and the server, and some back and forth, and maybe the sringent policy to lock an account after (how many retries? 3?) might be a little harsh.

As a test I would try to augment that limit to let's say 10 or just to remove it temporarily to see if it makes any good on your users...

[SteveB2177]

I set it to more failures before lockout, and much quicker reset for that user, so we honestly can't say whether it ever locked him out or not.

I also had the other user log in successfully a bit later, so I copied and pasted both of those saved logs into one file. Username1 is the user who fails, Username2 is the user who succeeds. Both are in the same OU, groups, and etc.

(Names changed to protect the innocent)

Thanks so much for your help!

[Fred!]

Ah! Nobody's innocent :)

OK, here is where the problem is. I have recreated a shorter version of the log file with just the portion where the problem occurs (see attached file).

If you look for the same kind of MS-CHAP challenge for Username1 and Username2, one ends with a failure (0xc000006d) the other ends with an OK state.

Now, this error is a microsoft error code returned by the server during the challenge. I found a couple of interesting articles on the web, that may sound related to your problem.

As I'm not as intimate as you are on the version of the microsoft server you are using, I have pasted the google search URL on "microsoft 0xc000006d". There seem to be some information with regard to this error that might help you. Let me know if you see something interesting in there...

http://www.google.ca/search?hl=en&source=hp&q=microsoft+0xc000006d&meta=&aq=f&aqi=&aql=&oq=&gs_rfai=

[Mike Hydra]

Steve, Seems like the configuration is being setup correctly.
I'm sort of puzzled in the information you're providing.
I've done this setup a dozen times on various school without any errors.

Would it be possible to have a look at the web-interface of the controller to check some settings and reading the log file while you do a login?

Best regards,

Mike Hydra
2 Fast 4 Wireless

[SteveB2177]

Mike, thanks for the google search suggestion. The fact that the user was able to authenticate for logon (on my laptop, and for the first time) but unable to authenticate to AD via wireless controller is the oddest thing... makes it seem unlikely to be related to the 'computer account in the domain' concern and some of the other things I saw...

In other news I tweaked the groups listed in the AD authentication on the controller and now he is able to authenticate and connect if he manually enters the password at a prompt, but still fails if he sets it to automatically use his logged on credentials. How's that for weird? It is possible that is where the breakdown was occurring before, although I thought he'd tried manually entering the password with failure before as well.

Happy to try anything, Mike, just let me know what you'd like me to look at...

Thanks!

Steve