"Drew Govnyak" <no-email-(E-Mail Removed)> wrote in
news:uL$(E-Mail Removed):
> There was nothing wrong with the switch port, we plugged other
> computers there to test and didn't have any problems. This was not a
> hardware failure
>
>
>
> Yes, we are using IAS for PEAP authentication, I analyzed IAS logs but
> didn't see any errors indicating an authentication problem, moreover
> the problematic machine is not listed in the IAS logs the day of the
> problem, but listed several times a day prior to the problem with
> successful authentication.
>
>
>
> I ended up switching the machine to a NON .1x port, disjoining the
> Domain, then rejoining the domain and then switched it back to the
> same .1x port where machine could not authenticate previously. So
> looks like I have the fix for the problem, but don't know what caused
> the issue in the first place.
>
>
>
>
>
> "James McIllece [MS]" <(E-Mail Removed)> wrote in message
> news:Xns9A6483EFFE468jamesmcionlinemicros@207.46.2 48.16...
>> "Drew Govnyak" <no-email-(E-Mail Removed)> wrote in
>> news:(E-Mail Removed):
>>
>>> 802.1X with Port Security was implemented almost 2 years ago on our
>>> wired network. All XP workstations have Zero Wireless configuration
>>> turned on and authentication set to PEAP
>>>
>>> Additionaly, AuthMode = 2 and SupplicantMode = 3 was configured on
>>> all machines under
>>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EAPOL\Parame ters\General\Global
>>>
>>> In the past year .1x stopped working on two workstations for no
>>> apparent reason. What happened was machine stops authenticating and
>>> ends up with an APIPA address. In both cases there were NO security
>>> violation on their switch ports. Clients are plugged in to the
>>> 3560-G series switch. Is there something in the client Event log
>>> that would give me a hint what happened?
>>>
>>>
>>>snip<
>>
>> If the machine has an APIPA address it means it can't contact the
>> DHCP server. With 802.1X, authentication occurs before the switch
>> opens the port
>> that allows the client to broadcast a DHCP Discover message to the
>> DHCP server, so apparently authentication is failing and the port is
>> not opening. (Either that or the physical port is damaged or faulty
>> -- try connecting other computers to the port to see if this is a
>> hardware failure.)
>>
>> If it isn't a faulty port, then authentication is failing and the
>> switch isn't opening the port.
>>
>> Are you using IAS for PEAP authentication? If so, check the IAS
>> events in the event log to find a reason code that explains why
>> authentication fails.
>>
>> If you are not using IAS but are using another RADIUS product, check
>> the RADIUS server logs (see your RADIUS server documentation to learn
>> how).
>>
>> If the switch itself is handling authentication, the switch
>> documentation should tell you how to troubleshoot authentication
>> problems.
>>
>> Another possibility depending on your setup is that the client's DHCP
>> Discover broadcast message can't reach the DHCP server for some other
>> reason -- in other words, authentication is successful, the port is
>> opened by the switch, and the client sends the DHCP Discover message,
>> but it isn't
>> reaching the DHCP server. This can happen if the DHCP server is
>> separated from the client by a router that does not have DHCP
>> forwarding enabled -- so if that's your setup (eg there are one or
>> more routers between the switch and the DHCP server) you can check
>> that too.
>>
>> --
>> James McIllece, Microsoft
>>
>> Please do not send email directly to this alias. This is my online
>> account
>> name for newsgroup participation only.
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>
>
>
Glad you got it fixed. :-)
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.
|
Similar Threads
Linear Mode
