none
NPS as a radius server,the network policys are not enforced sometime RRS feed

  • Question

  • Hi All,

    I have configed a NPS server on a windows server 2012 r2 OS, the radius client is a cisco hardware vpn device.
    there is a custom NPS extension registered for some extra authentication(two step authentication).
    theere are two types of authentication method:

    1. user submit two passwords use "active directory password" + "some extra password" format, like 
    "password1_password2", NPS extension split and check both two passwords and NPS itself authorize the user 
    using netwok policy, both works fine. there're two security events logged into windows event log: 
    the first event (ID6272) shows Network Policy Server granted access to a user.
    the second event (ID6278) shows Network Policy Server granted full access to a user because the host met the defined health policy.
    in both two events, i can see the Authentication Details shows Proxy Policy Name and Network Policy Name.

    2. user submit the first "active directory password" to NPS, NPS extension check the password and return a radius challenge message to the radius client, then user submit the second "some extra password" to NPS, then NPS extension check the second password again.
    the problem is: when the authentication process complete, NPS bypass the authorize(network policy) process and directly grant access to the network.
    there is only one security events logged into windows event log: 
    event (ID6272) shows Network Policy Server granted access to a user.
    in this event, only shows the Proxy Policy Name. Network Policy Name is "-".

    because the NPS extesion only registered fo authentication and it's worked  fine, so i think this is not a develop related question.
    i am not very familiar with NPS, may be i make some wrong configration. 

    THanks for your help。

    =======================================

    below are policies, values that i did not mention are all use default :

    create a new connect request policy:
    add a conditions -- NAS Port Type=virrtual(VPN);

    create a new network policy:
    add a conditions -- Windows Group= contoso\vpn_access_group;
    Authentication Method -- only check unencrypted authentication(PAP,SPAP)
    Ignore user account dial in propery

    =======================================

    we find a problem, 

    when the authentication extension returrn to radius client a access-challenge message AND a ratState attribute, NPS does not un network policies and diectly let user login.

    when the authentication extension returrn to radius client ONLY access-challenge message, NPS can use network policies to authorize the user.




    • Edited by nggg Thursday, November 3, 2016 2:03 PM
    Monday, October 31, 2016 1:29 PM

All replies

  • Hi Nggg,

    >>user submit the first "active directory password" to NPS, NPS extension check the password and return a radius challenge message to the radius client

    User will submit account information to VPN server, VPN server will send radius message to NPS.

    >>the problem is: when the authentication process complete, NPS bypass the authorize(network policy) process and directly grant access to the network.

    Please check if user could connect to VPN server after you disabled network policies.

    If it could, please ensure NPS was not configured RADIUS proxy.

    Best Regards

    John


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 1, 2016 8:05 AM
  • thanks for  the reply, because i cannot touch the vpn hardware environment now, i use the NTradping tool (a software radius server test utility)  to emulate the vpn hardware.

    the result is:

    1. disable all network policies:
    NPS give NTradping a radius access-accept message and record a event id 6272 (granted access to a user).
    in that event,  netwok policy is "-".

    2.disable all network policies, make a Incorrectly configured connect request policy:
    the connect request policy for vpn hardware has a 
    property:NAS Port Type=virrtual(VPN),
    but when i use a software radius client, the NAS port type is not configured,
    NPS give NTradping a radius 
    access-accept message and record a event id 6272 (granted access to a user).
    in that event, NAS port type is "-",  connect request policy is "-", netwok policy is "-".

    3.disable all network policies and all connect rrequest policies:
    NPS give NTradping a radius access-REJECT message and record a event ID6273 (denied access to a user).
    in that event, the reject reason is :  radius request does not match any connection request policy.

    Tuesday, November 1, 2016 2:34 PM
  • test using hardware vpn device, the result is same as software radius client.

    in my understanding, config NPS radius proxy need at least one remote radius server group, my remote radius erver group is empty.

    Wednesday, November 2, 2016 2:07 AM
  • Hi Nggg,

    >>test using hardware vpn device, the result is same as software radius client.

    Did you mean that VPN client could connect to VPN server and it could access internal resources?

    >>Ignoreuseraccountdialinpropery

    Please disable Ignore user account dial-in properties and try again.

    You could catch packet to analyze issue by Microsoft monitor.

    Here is link about monitor download for your reference:

    https://www.microsoft.com/en-sg/download/details.aspx?id=4865

    Best Regards

    John


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, November 2, 2016 7:34 AM
  • yes, vpn client can connect to vpn server and it can access internal resources. 

    i tried both enable or disable Ignore user account dial-in properties,  the result is no different, user can login without a network policy.


    Wednesday, November 2, 2016 8:47 AM
  • i only capture udp 1812 and 1645 port, the zip file contains two files,

    001 is using radius request-challenge-request mode, 002 is using "password1_password2" in one radius request mode.

    https://1drv.ms/u/s!AnEs62TNQM0fgdJIgvcTmVcIxXmS6w

    Wednesday, November 2, 2016 9:22 AM
  • Hi Nggg,

    Have you configured called-station-id on network policy?

    Could you please post the details conditions of network policy for further troubleshooting.

    Best Regards

    John


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 3, 2016 8:31 AM
  • hi,

    i did not config called-station-id. following are captures of all network policy, the language is Chinese.

    Thursday, November 3, 2016 8:59 AM
  • and more pictures:

    Thursday, November 3, 2016 9:01 AM
  • and i also captured the CRP:

    Thursday, November 3, 2016 9:13 AM
  • we find a problem, 

    when the authentication extension returrn to radius client a access-challenge message AND a ratState attribute, NPS does not un network policies and diectly let user login.

    when the authentication extension returrn to radius client ONLY access-challenge message, NPS can use network policies to authorize the user.

    Thursday, November 3, 2016 2:04 PM
  • Hi Nggg,

    I am glad to hear that your issue was successfully resolved.

    If there is anything else we can do for you, please feel free to post in the forum.

    Best Regards

    John


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, November 4, 2016 1:57 AM
  • hi john,

    the problem has not been solved, it's just getting more complicated,  i am not sure this is a NPS configuration problem, or a extension develop problem, or a NPS bug.....

    Friday, November 4, 2016 11:34 AM
  • Hi Nggg,

    Sorry for my mistake.

    And I have tested it on my lab, it works, I suggest that you could check conditions by following description below.

    Here is information about the condition configuration below for your reference:

    Connection request policies configuration:

    Type of network access server: Remote Access Server(VPN-Dial up).

    Conditions: NAS Port Type       VPN.

                     Tunnel Type           PPTP.(according to your requirement)

     

    Network request policies configuration:

    Type of network access server: Remote Access Server(VPN-Dial up).

    Conditions: User Groups.

                     Tunnel Type              PPTP.

                     NAS Port Type           VPN.

    Please reference the picture below for further understanding:

    Best Regards

    John


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    • Edited by John Lii Monday, November 7, 2016 6:55 AM
    Monday, November 7, 2016 6:28 AM
  • hi john,

    Is your test using a NPS extension that doing a radius access-challenge operation?

    I'll test your policy configuration tomorrow.

    Monday, November 7, 2016 2:45 PM
  • Hi Nggg,

    >>Is your test using a NPS extension that doing a radius access-challenge operation?

    Yes, I have created L2TP VPN server, and add it in RADIUS client.

    And then I configured network policies and connection policies for L2TP VPN as I mentioned above.

    I will waiting for your result and provide further troubleshooting for you.

    Best Regards

    John


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 8, 2016 2:02 AM
  • Hi John,

    I configured the network policy as your instruction:

    an did the following test using NTRadping tool to emulate a radius client:

    1.remove the custom NPS extension, test with a user IN the specified group in network policy. the result is access-accept.

    2.remove the custom NPS extension, test with a user NOT IN the specified group in network policy. the result is access-reject.

    3.remove the custom NPS extension, test with a user IN the specified group in network policy, and with a radius attribute "State". the result is no response from NPS. network monitor installed on the NPS server shows the packets reached NPS server, but NPS does not answer them. there is some events logged in to system events: Internal error while processing a request, error code is 80004005.

    then we test the NPS extension, the extension is re-coded to ignore radius "state" attribute.

    4.register the custom NPS extension, test with a user NOT IN the specified group in network policy. the result is access-reject(that is good, NPS reject user login because the request does not match the network policy).

    5.register the custom NPS extension, test with a user NOT IN the specified group in network policy, and with a radius attribute "State". the result is access-accept.

    Same user, same password, same NPS extension, the olny difference is add a radius attribute "State"=what ever something, then the network policy is bypassed.

    Tuesday, November 8, 2016 7:04 AM
  • we make another NPS extension that only do one thing: return access-accept, no matter what password entered by the user.

    according to microsoft document https://msdn.microsoft.com/en-us/library/bb891985(v=vs.85).aspx 

    "If an Authentication Extension DLL returns ACCEPT, the packet skips the NPS authentication and goes directly to NPS authorization."

    the test result is: NPS authorization is also skipped, unauthorized user can login to the system.

    Tuesday, November 8, 2016 8:14 AM
  • Hi Nggg,

    Have you configured request connection policies and Type of network access server as I mentioned above?

    >> Same user, same password, same NPS extension, the olny difference is add a radius attribute "State"=what ever something, then the network policy is bypassed.

    The issue seems to be too complicated to discuss in a forum.  

    I suggest you open a case with Microsoft, more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.

    Here is the link:

    https://support.microsoft.com/en-us/gp/contactus81?Audience=Commercial&wa=wsignin1.0

    Best Regards

    John


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    • Edited by John Lii Tuesday, November 8, 2016 8:24 AM
    Tuesday, November 8, 2016 8:19 AM
  • update:

    i contact a microsoft  employee to open a case, he ask me to pay 5800USD to solve this problem. i think this is a microsoft system bug and that employee cannot start analysis  before i pay.

    Thursday, November 24, 2016 5:38 AM
  • Hi Nggg,

    For pictures that you provided, it add state=01 in additional RADIUS attributes, and the NPS accept the request, I have not found this attributes on NPS server.

    I suggest that you could contact with software provider to get effect support.

    Best Regards

    John


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 24, 2016 6:59 AM
  • hi john,

    i don't understand what you mean about "attributes not found",  are you using the ntradping?

    Wednesday, November 30, 2016 2:12 PM
  • Hi Nggg,

    Ntradping is thirty-party software, and then you could contact with software provider to get effect support.

    State attributes: Allows state information to be maintained between the network access server and the RADIUS server. This attribute is applicable only to CHAP challenges.

    Best Regards

    John


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, December 1, 2016 2:00 AM
  • hi John,

    can you tell me what non-thirty-pary software you use to test the state attribute ?

    and where did you find out the CHAP challenge only attributes? i read the rfc document, it's does not mention any CHAP only state attribute.

    Tuesday, December 6, 2016 8:43 AM
  • Hi Nggg,

    I found extended state attribute on NPS, please reference link below for further understanding:

    Network Policy Settings Properties

    https://technet.microsoft.com/en-us/library/cc772474(v=ws.10).aspx

    You could reference PDF below to understand state:

    http://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfrdat1.pdf

    Since ntradping is third-party software, it could not be reappeared on my lab, you could contact with software provider to get effect support.

    Best Regards

    John


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, December 7, 2016 9:31 AM
  • hi John,

    i want to use a tool that we both accept, to reproduce the problem, so you can analysis it, can you provide me one ? 

    Thursday, December 8, 2016 1:50 PM
  • Hi Did you find a solution to this problem?

    We have the ecsact same problem, regarding Azure MFA in a local NPS server installed on the Domain controller, And the problem only occurs when you have choosen your 2 factor to be SMS or OTP code.
    when you are using App notification or phone call, it works fine with the connection policies.

    And as you have mentioned the problem occurs when the Access-challange MSG is sent and responded by the RADIUS client ( Cisco ASA)
    And when you are using phone app notification, your phone are speaking directly with Microsoft Azure, and therfore the msg flow goes from microsoft to your NPS extension.

    And in that flow there are only 1 set of Radius Access-Request -> Access Accept.msg and within that first communication the RADIUS server are able to determin that the user are member of an AD group and therefore are sending the correct RADIYS attributes allong with the Access-Accept msg. 

    I have 1: connection policy that allows everyone to authenticate with AD credentials.

    2: i have multiple network policies with more conditions.
    And conditions are based on witch AD group member you are, and then are sending RADIUS "filter-ID" attribute with an Access-Accept message to our CISCO VPN solution.

    So i have diagnosed this but i have not yet found a soulution :(


    • Edited by MickiW Friday, January 18, 2019 12:48 PM
    Friday, January 18, 2019 12:32 PM
  • Notice that the Azure MFA messages does not contain any information regarding the network policies the user belongs to.

    And there fore the Access-Accept msg is based on the Connection rewuest policy, that dont have any attributes configured, ( and can not sort on AD grop membership by the way)

    [FIRST message AD Validation - RADIUS Client: I want in here are my Ad credentials]
    SwitchIP                  : [ip]
    Username                  : myusername
    Date-Time                 : 13:13:48 01/18/2019
    RADIUS-Server             : OurRADIUS SERVERNAME
    Packet-Type               : Access-Request
    Switch-Friendly-Name      : ASA-FW
    NAS-Port-Type             : 5
    Tunnel-Client-Endpt       : 2.128.195.99
    NAS-Port                  : 94887936
    NAS-IP-Address            : ASA FirewallIPaddress
    Workstation-MAC           : 2.128.195.99
    Connection-Request-Policy : Use Windows authentication for all users
    Fully-Qualified-User-Name : Domain/container
    Authentication-Type       : PAP
    Called-Station-ID         : IpAddress
    NAS-Manufacturer          : 9
    NPS-Policy-Name           : IT VPN-MFA deployment using Microsoft Azure
    Framed-IP-Netmask         : 4128
    SAM-Account-Name          : MyAD_Username
    Not_Documented            : 1
    Class                     : 311 1 Ipadrress 01/11/2019 13:15:27 429
    Reason-Code               : IAS_SUCCESS
    Switch-IP-Address         : ASA FirewallIPaddress

    [Second message AD Validation - RADIUS Server: first pw is fine, but i need a second password before i let you in]
    SwitchIP                  : ASA FirewallIPaddress
    Username                  : MyAD_Username
    Date-Time                 : 13:13:48 01/18/2019
    RADIUS-Server             : OurRADIUS SERVERNAME
    Packet-Type               : Access-Challenge
    Fully-Qualified-User-Name : Domain/container
    Switch-IP-Address         : ASA FirewallIPaddress
    Filter-ID                 : 4142
    Connection-Request-Policy : Use Windows authentication for all users
    NPS-Policy-Name           : IT VPN-MFA deployment using Microsoft Azure
    NAS-Manufacturer          : 9
    Switch-Friendly-Name      : ASA-FW
    Framed-IP-Netmask         : 4128
    SAM-Account-Name          : MyAD_Username
    Not_Documented            : 1
    Class                     : 311 1 Ipadrress 01/11/2019 13:15:27 429
    Reason-Code               : IAS_SUCCESS
    Reply-Message             : Enter Your Microsoft verification code
    Authentication-Type       : PAP

    [FIRST message Azure MFA -RADIUS Client: okay here are my SMS password ]
    SwitchIP                  : ASA FirewallIPaddress
    Username                  : MyAD_Username
    Date-Time                 : 13:14:01 01/18/2019
    RADIUS-Server             : OurRADIUS SERVERNAME
    Packet-Type               : Access-Request
    Switch-Friendly-Name      : ASA-FW
    NAS-Port-Type             : 5
    Tunnel-Client-Endpt       : VPNClient IPaddress
    NAS-Port                  : 94887936
    NAS-IP-Address            : ASA FirewallIPaddress
    Workstation-MAC           : VPNClient IPaddress
    Connection-Request-Policy : CBS - Use Windows authentication for all users
    Authentication-Type       : Custom
    Framed-IP-Address         : 25
    Called-Station-ID         : IpAddress
    NAS-Manufacturer          : 9
    Framed-IP-Netmask         : 4128
    Not_Documented            : 1
    Class                     : 311 1 Ipadrress 01/11/2019 13:15:27 430
    Reason-Code               : IAS_SUCCESS
    Switch-IP-Address         : ASA FirewallIPaddress

    [Seccond message Azure MFA - RADIUS Server: okay i let you in, ( but only Once)]
    SwitchIP                  : ASA FirewallIPaddress
    Username                  : MyAD_Username
    Date-Time                 : 13:14:01 01/18/2019
    RADIUS-Server             : OurRADIUS SERVERNAME
    Connection-Request-Policy : CBS - Use Windows authentication for all users
    Switch-Friendly-Name      : ASA-FW
    Not_Documented            : 1
    Framed-IP-Netmask         : 4136
    Switch-IP-Address         : ASA FirewallIPaddress
    Packet-Type               : Access-Accept
    Reason-Code               : IAS_SUCCESS
    NAS-Manufacturer          : 9
    Authentication-Type       : Custom
    Class                     : 311 1 Ipadrress 01/11/2019 13:15:27 430
    Framed-IP-Address         : 4155

    • Edited by MickiW Friday, January 18, 2019 12:46 PM
    Friday, January 18, 2019 12:45 PM
  • I got an answer to my support case, and ms confirms that this is an issue.
    ---------------------------------------------------------------------------------------------------

    I apologize for the inconvenience and also, appreciate your time and patience on this issue.

    After thorough investigation and collaboration with the Backend Team, this is known limitation with NPS where in the network policies are not applied for SMS or OTP Flows.

    If you use a challenge method it does not support the NAP policies. These are only evaluated during primary authentication. 

    When using Radius Challenge(for SMS or OTP), the Challenge response skips primary auth and so these policies are not evaluated.

    However, the Product Team are currently working on this but there is no estimated Time of arrival for the fix.


    Friday, January 25, 2019 7:28 AM