tomscaper Posted November 19, 2008 Posted November 19, 2008 Have tried this over and over and i have no idea where i am going wrong, i have followed the guide but still unable to get laptops to connect. We are using HP 520 WL Access points and there logs show Primary EAP/802.1x Authentication Server Access Requests 3 Access Accepts 0 Access Retransmissions 5 Access Rejects 0 Access Challenges 0 Malformed Access Responses 0 Authentication Bad Authenticators 0 Timeouts 6 What that means i don't know but i have radius set up to the server and the right ports set. Either am about to give in or pay for someone to come in and set this up for us.
plexer Posted November 19, 2008 Posted November 19, 2008 Ok to test it's not your radius server try this Periodik Labs: Elektron RADIUS Server for Wireless Security Ben 1
tomscaper Posted November 19, 2008 Posted November 19, 2008 Thanks will try that i just noticed you had posted that before sorry about that i didnt see it.
tomscaper Posted November 19, 2008 Posted November 19, 2008 Tried the Elektron test and it came up with test failed. 1
DMcCoy Posted November 19, 2008 Posted November 19, 2008 Can you ping the AP from the radius server? 1
DMcCoy Posted November 20, 2008 Posted November 20, 2008 Yeah the radius server can ping the AP Ok, What client OS and service pack? What Authentication method (Certificate or password?) Machine or User for authentication? I did see that you are using a peap password from your IAS config, if you are authenticating the machine then you will need to make some changes on the client. 1
tomscaper Posted November 20, 2008 Posted November 20, 2008 Ok, What client OS and service pack? What Authentication method (Certificate or password?) Machine or User for authentication? I did see that you are using a peap password from your IAS config, if you are authenticating the machine then you will need to make some changes on the client. Client XP Sp2 I followed the pdf guide and i create a certificate and set shared key on access. point and on radius. machine authentication. I dont really fully know much about it all, i just followed the guide.
DMcCoy Posted November 20, 2008 Posted November 20, 2008 Try turning off "Request must contain the Message Authenticator attribute." for the AP in the client settings, I know that this does not work with my procurve switches. You aren't getting as far as authentication by the looks of those timeouts. I assume the AP is using an address that it can see for it's radius server (on it's *default* vlan for example) 1
spc-rocket Posted November 20, 2008 Posted November 20, 2008 Client XP Sp2 I followed the pdf guide and i create a certificate and set shared key on access. point and on radius. machine authentication. I dont really fully know much about it all, i just followed the guide. Hi, For testing make sure the shared secret doesn't contain any special characters and use a normal phrase. Usually alpha-numeric combination is best for shared secret. Do you have a security group with the computer accounts in and is this group allowed access? You may need to have both the users and computers in the groups to authenticate them both. Double-check the certificate as this will cause issue. For testing purposes disable the certificate checking by going to the properties of the wireless network and click on the Authentication Tab and then click the Properties button next to Protected EAP (PEAP). Clear the tick box next to "validate server certificate". Ash. 1
tomscaper Posted November 21, 2008 Posted November 21, 2008 Hi, For testing make sure the shared secret doesn't contain any special characters and use a normal phrase. Usually alpha-numeric combination is best for shared secret. Do you have a security group with the computer accounts in and is this group allowed access? You may need to have both the users and computers in the groups to authenticate them both. Double-check the certificate as this will cause issue. For testing purposes disable the certificate checking by going to the properties of the wireless network and click on the Authentication Tab and then click the Properties button next to Protected EAP (PEAP). Clear the tick box next to "validate server certificate". Ash. Special characters could the & sign cause a problem. Security group is fine and has the computers added. Also added Domain users to make sure. I created the certificate from the tutorial so i dunno if its right or not. but will try that if it works then it must be certificate. Will post let you know how it goes.
tomscaper Posted November 21, 2008 Posted November 21, 2008 Try turning off "Request must contain the Message Authenticator attribute." for the AP in the client settings, I know that this does not work with my procurve switches. You aren't getting as far as authentication by the looks of those timeouts. I assume the AP is using an address that it can see for it's radius server (on it's *default* vlan for example) Yeah all on same vlan, and i tried turning off the message authenticate btu that make no difference Also would it make a difference if i rebooted my radius server. would that do any good.
tomscaper Posted November 24, 2008 Posted November 24, 2008 Well i got it all working now, it was something to do with the type of encryption on the AP and that i had to remove the WEP encryption for the WPA to authenticate. Thanks everyone for the help
broc Posted November 28, 2008 Posted November 28, 2008 Earlier in this thread I described a problem where some wireless systems appear to lose the ability to connect to our domain. I have since discovered that when the problem happens, the failing laptops are reported by the 3Com Wireless Switch Manager as having an invalid session state. The 3Com software can see the MAC address and identify the system by name, but it has associated an IP address of 0.0.0.0 and they just sit there attempting to authenticate. Looking at the certificate on the client, it appears to be valid, although sometimes there can be two copies. Another curious fact is the session start time reported by the 3Com software is Thu Jan 01 01:00:00 GMT 1970, on a working system with an active session this would have the actual date/time the session started. We have established that the RTC on the laptop appears to be correct, and within seconds of the DC clock, so the first thought that the batteries had gone flat and the system had lost its time settings appears to be false. Any ideas where this mysterious date/time is coming from? Any ideas how to get a debug log out of a system that has lost its way? Normal event logs don't show anything beyond being unable to connect to the domain.
SYNACK Posted November 28, 2008 Posted November 28, 2008 Any ideas where this mysterious date/time is coming from? Each switch/ap has its own built in clock, have these been set or setup to grab their time of an NTP server?
broc Posted November 28, 2008 Posted November 28, 2008 Each switch/ap has its own built in clock, have these been set or setup to grab their time of an NTP server? Interesting idea, unfortunately the WAPs (or DMAPs as 3Com call them) are pretty 'dumb' devices with a single profile all managed by a single WX2200 WLAN controller. Also we can see machines that have successfully connected using the same DMAP simultaneously as the ones with problems. The WX2200 is set up to use the DC as a time source.
DMcCoy Posted December 6, 2008 Posted December 6, 2008 IMPORTANT Procurve users who update switches beyond I.10.40, K12.25 etc (June 2008 onwards) may find 802.1x stops working completely. The procurves now drop packets with a MTU that is too big, despite working perfectly with older versions). I know this will affect IAS as mine stopped working. To fix this you can change the Frame MTU size in IAS. On the policy add Frame-MTU in advanced and give it a value of 1400, the procuve should now accept any EAP responses from that matching policy. I've had to update all my policies with the mtu setting and all is working again. The change is listed as a fix so it's easy to miss!
mtdmitchell Posted January 30, 2009 Posted January 30, 2009 IMPORTANT Procurve users who update switches beyond I.10.40, K12.25 etc (June 2008 onwards) may find 802.1x stops working completely. The procurves now drop packets with a MTU that is too big, despite working perfectly with older versions). I know this will affect IAS as mine stopped working. To fix this you can change the Frame MTU size in IAS. On the policy add Frame-MTU in advanced and give it a value of 1400, the procuve should now accept any EAP responses from that matching policy. I've had to update all my policies with the mtu setting and all is working again. The change is listed as a fix so it's easy to miss! Hey McCoy, I started to experience wireless problems this week, our core switch reports the following error message which seems to relate to your fix. Too Many Undersized/Giant Packets on port A15 30-Jan-2009 11:11:52 Description: A device on port A15 is transmitting packets shorter than 64 bytes or longer than 1518 bytes (longer than 1522 bytes if tagged), with valid CRCs. Possible causes: The possible causes include a misconfigured NIC or malfunctioning NIC, NIC driver, or transceiver. Actions: Check the NIC for a misconfiguration. Update the NIC driver software. Replace the malfunctioning NIC or transceiver. Check for a short-circuit in the cable path connected to this port. im getting these messages on ports which have Netgear AP's plugged into our Hp Procurve. can you confirm this?
OverWorked Posted February 20, 2009 Posted February 20, 2009 I've spent two whole days on this, this half term. I finally got it working, but it's just too unreliable. Even with computer-only authentication, users frequently get the domain-is-not-available message (even when the IAS server's system log confirms that the machine has been granted access). Users also frequently get profiles and group policies failing to load. It is rare that a user can log on successfully. I've removed the group policy setting wireless security and changed the AP back to 'open'. Any suggestions?
broc Posted April 30, 2009 Posted April 30, 2009 Take a look at Microsoft KB904943. We have been suffering from a problem for ages where wireless laptops 'randomly' lose the ability see the domain. The wireless infrastructure seems ok, the Wireless LAN controller can see the client. If you plug in a network cable the problem melts away.... until the next time.... KB904943 explains how machine only authentication may fail using PEAP-MS-CHAP-V2 and 802.1X because the computer account password on the domain may expire while the computer is offline and subsequent attempts to authenticate fail. Providing the computer with a network connection allows it to reset its domain password, allowing the wireless authentication. The KB article suggests some work-arounds..... either use both user & computer authentication or use EAP-TLS instead of PEAP-MS-CHAP-V2 I guess a third option would be to prevent the computer password from expiring.... I have switched to using both computer & user authentication for the moment to see if it fixes our problem. Fingers crossed 1
plexer Posted April 30, 2009 Posted April 30, 2009 We solved 99% of our wireless network issues by using a proper supplicant on the clients in our case we went for the Juniper Oddessey client. This thing is so configurable and you can see what is going on unlike with the built in windows supplicant. In fact you can tell the wireless is up and authenticated by the machine when they are booting becuase they'll even install software over the wireless. Ben 2
OverWorked Posted April 30, 2009 Posted April 30, 2009 Thanks broc & plexer. I'll look into it later - perhaps when I get all my APs replaced with something decent like 3com or Cisco. I was trailling RADIUS on an old D-Link AP, so I still wonder if that was part of the problem. At the moment, I have a Cisco and D-Link APs. The only common security method they share is 128-bit WEP, or RADIUS, so I'm using the WEP. WEP isn't great, but it's the best I can do right now.
spc-rocket Posted April 30, 2009 Posted April 30, 2009 We solved 99% of our wireless network issues by using a proper supplicant on the clients in our case we went for the Juniper Oddessey client. This thing is so configurable and you can see what is going on unlike with the built in windows supplicant. In fact you can tell the wireless is up and authenticated by the machine when they are booting becuase they'll even install software over the wireless. Ben The oddessey client is a cost option, not sure about the cost but yes it is more configurable. I think most of the time the windows built-in supplicant is pretty good but its let down by badly written drivers by NIC vendors. The way odessey and other supplicant solve this problem is by installing an intermediate driver which communicates to the lower and upper level in TCP. Ash.
plexer Posted April 30, 2009 Posted April 30, 2009 Approx £35 a client I think we bought a 100 user client to do all the student laptop trolleys. Ben
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now