I'm new to Aruba and enterprise wireless in general, so please bear with me. We have a network set up where the user authenticates onto the wireless when he/she logs into Windows. This generally works fine, and the logs on our IAS system recognize the usernames and grant access.
Here's an example of our successful associations:
User DOMAIN\username was granted access. Fully-Qualified-User-Name = domain.com/AD_Group/username NAS-IP-Address = 172.24.1.4 NAS-Identifier = <not present> Client-Friendly-Name = Aruba-3400 Client-IP-Address = 172.24.1.4 NAS-Port-Type = 19 NAS-Port = 0 Policy-Name = Aruba wireless Authentication-Type = MS-CHAPv2 EAP-Type = <undetermined>
The problem lies in that when we lose connectivity briefly (when roaming doesn't quite work right, or we walk to far from a signal, or put the computer to sleep and wake it up) the client OS begins requesting additional information to connect - username and password for the user. When a user enters the requested information, it refuses to re-authenticate. The log on the IAS server that is generated is this:
User DOMAIN\username was denied access. Fully-Qualified-User-Name = DOMAIN\username NAS-IP-Address = 172.24.1.4 NAS-Identifier = <not present> Called-Station-Identifier = 000B86616664 Calling-Station-Identifier = 0024D6AD2830 Client-Friendly-Name = Aruba-3400 Client-IP-Address = 172.24.1.4 NAS-Port-Type = 19 NAS-Port = 0 Policy-Name = <undetermined> Authentication-Type = MS-CHAPv2 EAP-Type = <undetermined> Reason-Code = 16 Reason = There was an authentication failure because of an unknown user name or a bad password.
The primary difference between these two log entries is the fully qualified user name. It seems that when the user's AD folder is included in the FQUN, access is granted. If the user's AD folder is not included in the authentication process, it claims it can't find the user. Has anyone seen anything like this? Is it more a Microsoft problem that should be addressed through their channels?
Our client wireless config seems straightforward to me, and I don't note anything that could affect the syntax of the username:
It's currently set for: WPA2-Enterprise/AES, using PEAP, not validating server certificates, using EAP-MSCHAPv2 which is set to automatically use the Windows username and password (and domain), and Fast Reconnect is enabled. We are set specifically for user authentication. Hope that info helps.
On the Aruba side, our dot1x profile has termination enabled, EAP type is eap-peap, and the Inner EAP-type is eap_mschapv2. No certs are configured.
Any help is greatly appreciated. Thanks! :-)
I was able to get a little light shed on the situation through a Microsoft forum, and through some further Googling. Here's what I've found:
"By default, the access point sends reauthentication requests to the authentication server with the service-type attribute set to authenticate-only. However, some Microsoft IAS servers do not support the authenticate-only service-type attribute. Changing the service-type attribute to login-only ensures that Microsoft IAS servers recognize reauthentication requests from the access point. Use the dot11 aaa authentication attributes service-type login-only global configuration command to set the service-type attribute in reauthentication requests to login-only."
Now, that's Cisco specific, so does anyone know of the comparable mechanism to ensure login-only type packets are sent with Aruba?
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.