locked
NPS allows Macintosh Authentication even if not in Windows Group. RRS feed

  • Question

  • We are in the process of implementing PEAP with AD authentication in our environment.  We are running Server 2008 NPS and Cisco WLC's at our locations.  We recently discovered that the MacBook can authenticate with a username and password that are not in our wireless group.  The Windows PC's, on the domain or not can not authenticate if they are not in the groups.  If they are in the groups they are fine.  What would be causing the Mac's to bypass the groups for authentication through NPS?

    Monday, November 2, 2009 1:58 PM

Answers

  • Have you had a chance to check your Cisco WLC configurations? Are they set up to use 802.1x and not fall back to anything else or act independently of the RADIUS server's response?

    I'm not familar with the configuration options of the Cisco WLC's directly but if that Event Log entry you posted is for the MACBook in question, it looks like it was denied access becuase it didn't match the conditions of your 1 Network Policy (and therefore no Network Policies). Since NPS will send a RADIUS Access-Reject response as a result, I would expect the RADIUS Client/NAS DO_WLC to honor that auth decision. This is why I say to check the configuration of your WLC.
    • Marked as answer by Mervyn Zhang Thursday, November 5, 2009 11:13 AM
    Wednesday, November 4, 2009 6:57 PM

All replies

  • Could you share with us more details on your NPS policy configuration? Also, check the Event log to determine what policies your various clients are matching. For both CRP and NP polices, NPS will start with the policy lowest in the processing order and proceed up the order until a match is found for every authentication request. For the MacBooks, I suspect you have a policy configured with PEAP-MSCHAPv2 which doesn't have the Windows Group condition.

    Your NPS policy configuration and the Event Log are definitely where I would start investigating.
    Monday, November 2, 2009 7:27 PM
  • I am using PEAP-MSChap to authenticate with AD for our wireless policy.  I have NAS Port Type of "Wireless - IEEE 802.11, Windows Group "TestGroup", Ignore Dial-in Properties, Access Persion - "Grant Access", Protocol Method - "PEAP", Moethod - "MS-Chapv1 or MS-Chapv2", NAP Enforcement - " Allow full network access", Update noncompliant clients - "True", Framed-Protocol "PPP", Service Type "Framed", Encryption Policy "Enabled", Encryption - 128bit.


    I removed all other policys and reduced my conditions down to 1 group.  My windows PC's fail to connect if I remove the test user from the group, My Iphone also fails, but the MACBook will still connect.  MACBook is set to WPA2 Enterprise.  NPS logs show the user just Authenticating, It doesn't show the hostname for the MAC's is the only thing I see differant.  We are passing a issuer certificate to the PC and MAC's.
    Monday, November 2, 2009 10:53 PM
  • This is something strange, in the log file I see:

    "NPS2","IAS",11/02/2009,08:30:04,1,"bradstudent@Domain.local","Domain1\bradstudent","00-23-EB-E5-35-E0:TESTSSID","00-1E-52-70-71-14",,,"DO_WLC","x.x.x.x",1,0,"x.x.x.x","DO_WLC",,,19,,,2,5,,0,"311 1 ::1 10/31/2009 08:28:35 195",,,,,,,,,,,,,,,,,,13,6,,,,"110",,,,,,,,,,,"Secure Wireless Connections",1,,,,
    "NPS2","IAS",11/02/2009,08:30:04,3,,"LCSD1\bradstudent",,,,,,,,0,"x.x.x.x","WLC",,,,,,,5,,48,"311 1 ::1 10/31/2009 08:28:35 195",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,"Secure Wireless Connections",1,,,,

    In the logs I see this around the same time:

    Network Policy Server denied access to a user.

    Contact the Network Policy Server administrator for more information.

    User:

    Security ID: S-1-5-21-4106182359-272257547-3847021724-37153

    Account Name: bradstudent@domain.local

    Account Domain: LCSD1

    Fully Qualified Account Name: Domain\bradstudent

    Client Machine:

    Security ID: NULL SID

    Account Name: -

    Fully Qualified Account Name: -

    OS-Version: -

    Called Station Identifier: 00-23-EB-E5-35-E0:Lex1Staff

    Calling Station Identifier: 00-1F-3C-92-C2-A9

    NAS:

    NAS IPv4 Address: x.x.x.x

    NAS IPv6 Address: -

    NAS Identifier: DO_WLC

    NAS Port-Type: Wireless - IEEE 802.11

    NAS Port: 1

    RADIUS Client:

    Client Friendly Name: WLC

    Client IP Address: x.x.x.x

    Authentication Details:

    Proxy Policy Name: Secure Wireless Connections

    Network Policy Name: -

    Authentication Provider: Windows

    Authentication Server: NPS2.lcsd1.local

    Authentication Type: EAP

    EAP Type: -

    Account Session Identifier: -

    Reason Code: 48

    Reason: The connection attempt did not match any network policy.


    I still get an IP address and it shows connection - I can also get to the Internet.

    Monday, November 2, 2009 11:05 PM
  • Looks like NPS is rejecting the request. Is your wireless AP set up to act on the response of the RADIUS server?
    Tuesday, November 3, 2009 5:06 PM
  • Have you had a chance to check your Cisco WLC configurations? Are they set up to use 802.1x and not fall back to anything else or act independently of the RADIUS server's response?

    I'm not familar with the configuration options of the Cisco WLC's directly but if that Event Log entry you posted is for the MACBook in question, it looks like it was denied access becuase it didn't match the conditions of your 1 Network Policy (and therefore no Network Policies). Since NPS will send a RADIUS Access-Reject response as a result, I would expect the RADIUS Client/NAS DO_WLC to honor that auth decision. This is why I say to check the configuration of your WLC.
    • Marked as answer by Mervyn Zhang Thursday, November 5, 2009 11:13 AM
    Wednesday, November 4, 2009 6:57 PM
  • Finally got back to testing this issue.  It looks like what happens is if I authenticate once with the MAC's and then remove the user from the group, even shutting down the wireless card it will pick up an IP address and get to the Internet even though NPS is denies the user.  Once the MAC is fully rebooted the user is denied and will not get an IP address.  Thanks for the assistance.
    Friday, November 6, 2009 12:46 AM