locked
W2K IAS Intermittent User Authentication over Wireless RRS feed

  • Question

  • Hello,

    I'm a bit new to IAS and such, so please bear with me.

    We have set up an Aruba wireless system that talks back to our Windows 2000 based IAS server. We use user authentication on our WPA2 SSIDs, and normally it works just fine - there's no issue.

    Occasionally, however, we get denied users in the logs. These users will be able to log in one minute and access the wireless, but if they lose signal or roam, or put the system to sleep we can not guarantee they will be able to get back on without rebooting. We get a message in the taskbar saying 'Additional Information Is Needed to Connect To <SSID>'.

    Looking at the logs, I see a discrepancy between access grants and denials:

    User EXAMPLE\smithj was granted access.
     Fully-Qualified-User-Name = example.com/users/SmithJ
     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>

    And denied:

    User EXAMPLE\smithj was denied access.
     Fully-Qualified-User-Name = EXAMPLE\smithj
     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.

    It looks to me like some sort of corruption is occurring somewhere in the data path that's preventing the fully qualified user name from being presented to the IAS server properly? So far, it seems like this issue can happen with any user, it's intermittent, and can happen on multiple client machines. Multiple users at once may or may not be affected - what I mean is, a single denial could occur grouped within several grants. Or we might have several denials grouped together as well.

    If I can provide any further information, please let me know.

    Thanks!

    Adam

    • Moved by Aiden_Cao Monday, August 6, 2012 8:48 AM (From:Network Infrastructure Servers)
    Friday, August 3, 2012 6:03 PM

All replies

  • Hi,

    Thanks for your post.

    Is this issue only occur when user re-authentication with ISA server? From your description, I assume that the user will fail authentication when they temporarily disconnect from wireless network. However, I am not familiar with Aruba network device. For some Cisco device, the access point sends re-authentication requests to the IAS server with the services-type attribute set to authenticate-only. However, with Windows 2000 IAS server does not support the authenticate-only service-type attribute. We need to changing service-type attribute to login-only ensures that IAS server recognize re-authentication requests from the access point. This is a solution with Cisco Access point with Windows 2000 ISA server. In your scenario, it can also cause by the ISA server not recognize the re-authentication requests. For best practice, I would like to recommend that you contact Aruba device support team for further support. Your understanding is highly appreciated.

    Best Regards,

    Aiden


    Aiden Cao

    TechNet Community Support

    • Proposed as answer by Aiden_Cao Friday, August 10, 2012 1:27 AM
    • Marked as answer by Aiden_Cao Monday, August 13, 2012 12:59 AM
    • Unmarked as answer by adamsih300u Tuesday, August 21, 2012 7:52 PM
    Monday, August 6, 2012 9:41 AM
  • We have done some further testing:

    This issue only seems to occur when the 'Use Windows logon name and password (and domain if any)' is enabled. So, if we have this set, we can log in to the computer and domain and associate with the wireless without issue. Then when a temporary disconnection occurs, we are unable to re-associate for the duration of the login session. This could happen when roaming, though it does not always, or when the system is put to sleep and woken up. When we get the 'Additional information is needed to connect to SSID' popup, the domain\username is pre-populated based on the login, and the password field is empty. Entering the correct password does not result in successful re-connection.

    If we do NOT set the 'Use Windows logon name...' in the client's wireless profile, and instead enter the domain\username and password manually at the login screen (in the additional fields provided for 802.1x as we have single sign-on set), all re-associations with the wireless work seamlessly during the login session when roaming or sleeping/waking.

    Our Windows 2000 domain controllers are registering a 'bad password' event code if the authentication begins to fail in the first situation, and eventually a user may be locked out based on our policies. It would seem that the packets are being read by our Windows 2000 IAS server, but that the password being sent by the client is different in some way than if we enter it manually when the 'Use Windows logon...' option is not set.

    Tuesday, August 21, 2012 7:52 PM