locked
RADIUS authentication at portal trunk fails RRS feed

  • Question

  • Hi all,

    i want to authenticate all users who try to access the UAG portal via a radius server, in addition to AD authentication. They have to enter their pin + OTP generated by a token.

    AD authentication works fine, but RADIUS authentication fails. Configuration is done according to the following TechNet article: http://technet.microsoft.com/en-us/library/dd857368.aspx

    Communication to the RADIUS server works fine, but the request is rejected. So we captured the communication using wireshark and detected the following: The RADIUS request contains the parameter "NAS-IP-address" and the value is set to 127.0.0.1. To my opinion this value must contain the internal IP-address of the UAG in order to perform a valid request. On the RADIUS server the UAG was configured as client, containing the shared secret and the internal IP of the UAG.

    There is a TMG within our infrastructure, too. We also captured the RADIUS communication coming from the TMG and the request contains the NAS-IP-address set to the internal IP of the TMG and everything is fine.

    What could be the reason that UAG sets the NAS-IP to 127.0.0.1? How do I change it?

    We are using DirectAccess with NAP on the same UAG. For NAP the UAG integrated NPS is used. Could there be a problem between the UAG-NPS and our seperate RADIUS server?

    Thanks for every good hint.

    Sebastian

    Thursday, May 3, 2012 8:28 AM

Answers

  • looks like this could be your answer:

    Hi qlloyd78,

    You can modify the NAS-IP attribute UAG is sending, using the method describe inKB960302 (the KB is for IAG, so the directory names may be little different), however, in this scenario, the Radius client is the UAG itself, and not the real client (as the UAG is the machine that authenticate to the Radius). It possible you can set the NAS-IP to the actual client IP usingGetSessionParam (g_cookie, "SourceIP") but not sure if this will work, as this IP address does not belong to the UAG and not sure it can spoof it when contacting the Radius server...

    HTH,

    Ophir.

    • Marked as answer by skrueck Tuesday, July 24, 2012 7:44 AM
    Monday, July 23, 2012 3:09 PM

All replies

  • We are using DirectAccess with NAP on the same UAG. For NAP the UAG integrated NPS is used. Could there be a problem between the UAG-NPS and our seperate RADIUS server?

    It sounds like it...

    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Friday, May 11, 2012 12:07 AM
  • So what to do? Any hints or suggestions?

    Sorry, but "It sounds like it" is not very helpfull.

    Is there any possibility to change the value of the NAS-IP?

    Thanks!

    Monday, May 14, 2012 1:02 PM
  • Seeing as though you had no other replies, I wanted to provide an educated guess it was caused by the UAG integrated NPS option.

    Unfortunately, I have not encountered your specific problem as I have always used off-box NPS servers...

    Hopefully someone else will chip in...have a free bump on me ;) 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Monday, May 14, 2012 1:18 PM
  • Since we're in JJ free-bump territory :-)

    There is a TMG within our infrastructure, too. We also captured the RADIUS communication coming from the TMG and the request contains the NAS-IP-address set to the internal IP of the TMG and everything is fine.

    The remote TMG server in this case is being seen as "Off-box" and the RADIUS client is generating the request using a remote IP address. 

    What could be the reason that UAG sets the NAS-IP to 127.0.0.1? How do I change it?

    Probably because the UAG extracts the request from TMG, that is translated as the built-in object called localhost (because the RADIUS instance is on the same server).

    Is the OTP solution intrinsic to UAG, and runs as an extension Sebastian, and/or is this the only NAP-integrated platform you have? i.e. can you not run it on an another server. Alternatively, can you not configure the RADIUS client with NPS using 127.0.0.1 as the source?

    Regards,

    Mylo

    Monday, May 14, 2012 9:53 PM
  • Hi all,

    thanks for your replies.

    @Mylo:

    Is the OTP solution intrinsic to UAG, and runs as an extension Sebastian, and/or is this the only NAP-integrated platform you have? i.e. can you not run it on an another server.

    Here some more explanation: We are only using NAP in combination with DirectAccess yet. Therefore we had no NPS within our infrastructure bevore. That's why we used UAG's functionality to use its "build-in" NPS for the NAP feature and only for the NAP feature. For user authentication with OTP we are using the RADIUS server within our infrastructure which is not a Microsoft NPS. In addition to DirectAccess we now want to set up a trunk portal to publish some applications. In order to access this portal users should authenticate against AD and via OTP verified by our seperate RADIUS server. This fails as described in my first post.

    Alternatively, can you not configure the RADIUS client with NPS using 127.0.0.1 as the source?

    Configure the RADIUS client with 127.0.0.1 as the source might be working, but this is not the way it is suppost to be, isn't it?

    Probably because the UAG extracts the request from TMG, that is translated as the built-in object called localhost (because the RADIUS instance is on the same server).

    But I thought, that UAG generates the RADIUS request and not TMG, because user try to access the UAG portal and not an application through TMG reverse proxy or is there something wrong in my understanding?

    Regards,

    Sebastian

    Wednesday, May 16, 2012 7:30 AM
  • Hi Sebastian,

    Thanks for the explanation. Leaving the UAG RADIUS client as 127.0.0.1 on NPS and UAG pointing to NPS, have you tried configuring NPS as a RADIUS proxy to forward the authentication servers to the remote RADIUS server which is providing the OTP function?

    Regards,

    Mylo

    Wednesday, May 16, 2012 6:02 PM
  • Hi Mylo,

    you recommend to configure the UAG trunk authentication to send RADIUS requests to the DirectAccess NPS on the same server and the NPS should forward it to our "external" RADIUS server, right?

    1) Is the UAG able to send RADIUS requests to itself?

    2) What about the reqeusts coming from DirectAccess clients for NAP? Are they forwared too (this would cause an authentication fail for them) or is it possible to seperate between both request-types?

    3) To my opinion this would not change the NAS-IP, wouldn't it?

    Thanks for the help again!

    Regards,

    Sebastian

    Friday, May 18, 2012 10:54 AM
  • Hi Sebastian,

    Sorry about the delayed reply, "Hemelvaart" Technet blues :-) Yes, that is what I was suggesting...

    Configuration set and written in UAG writes an access rule in TMG that sets the the From rule in the access rule to Local Host.. Local Host is a built-in object within TMG so I would imagine that's why the NAS-IP is set to 127.0.0.1

    Your point about DirectAccess clients is an interesting one and I'll need to setup a separate UAG server to test this on.. this might take a while .. bear with me :-)

    Regards,

    Mylo

    Tuesday, May 22, 2012 6:39 PM
  • Hi Mylo,

    don't worry about the delay. I've been out of office for two days, so I would not have been able to read your post anyway.

    The first thing that comes to my mind when reading your answer: May it be possible to change the "From" to the internal IP address of the UAG, so that the NAS-IP is set correctly? But then I'm afraid that this will "destroy" the access rule and UAG is not able to send any kind of RADIUS request anymore, right?

    Thanks for testing. I' looking forward for your results. I'm also curious whether you could reconstruct my problem.

    I also have to apologize in advance: Next two week are packed with other projects. So perhaps my answers are delayed or I'm not able to test.

    Regards,

    Sebastian

    Wednesday, May 23, 2012 12:37 PM
  • Hi Mylo (or everyone else),

    any new information or solutions for the problem?

    Regards,

    Sebastian

    Monday, July 23, 2012 10:06 AM
  • Communication to the RADIUS server works fine, but the request is rejected. So we captured the communication using wireshark and detected the following: The RADIUS request contains the parameter "NAS-IP-address" and the value is set to 127.0.0.1. To my opinion this value must contain the internal IP-address of the UAG in order to perform a valid request. On the RADIUS server the UAG was configured as client, containing the shared secret and the internal IP of the UAG.

    Hi Sebastian,

    I don't have a solution for you, but I wanted to let you know what I have found out about NAS-IP-ADDRESS (4) RADIUS attribute.

    This attribute is not needed during normal RADIUS challenge\response with 2nd factor authentication. It is an additional field that can be populated with the connecting client's IP address. Yes the UAG strips this value out and sets it to 127.0.0.1 which is highly annoying when you are troubleshooting or when you are trying, like I am, to use risk based authentication, but I have normal challenge\response 2nd factor authentication working without any issues.

    If the NAS-IP-ADDRESS field was needed, no one would be able to integrate 2nd factor RADIUS with the UAG. I think it's a red herring as far as your 2nd factor authentication issue is concerned.

    The source IP address will always be included in the IP header of the RADIUS packet, so regardless of what is in the NAS-IP-ADDRESS field, there will be a record of the IP address of the server making the RADIUS request, in your case this is the UAG, so you shouldn't be having any issues as long as the right IP address (internal interface of your UAG) is configured correctly on the RADIUS server and your routes are configured correctly on your UAG, so all internal traffic to the RADIUS server is going out through the right interface.

    Gareth

    Monday, July 23, 2012 10:29 AM
  • Hi Gareth,

    thanks for your replay.

    Our old RADIUS-server seems to be the problem. There is no possibility to configure different attributes and I could not find a way to disable the evaluation of the NAS-IP-ADDRESS attribute. Unless there is no way to change the NAS-Attribute within the UAG, we are not able to get this working, to my opinion.

    I keep you informed about further developments, but I'm still open for new hints ;-)

    Sebastian

    Monday, July 23, 2012 11:55 AM
  • looks like this could be your answer:

    Hi qlloyd78,

    You can modify the NAS-IP attribute UAG is sending, using the method describe inKB960302 (the KB is for IAG, so the directory names may be little different), however, in this scenario, the Radius client is the UAG itself, and not the real client (as the UAG is the machine that authenticate to the Radius). It possible you can set the NAS-IP to the actual client IP usingGetSessionParam (g_cookie, "SourceIP") but not sure if this will work, as this IP address does not belong to the UAG and not sure it can spoof it when contacting the Radius server...

    HTH,

    Ophir.

    • Marked as answer by skrueck Tuesday, July 24, 2012 7:44 AM
    Monday, July 23, 2012 3:09 PM
  • Hi glloyd78,

    yes, it worked great. I changed the value to the internal IP address of my UAG and RADIUS authentication works fine!

    Many thanks!

    Sebastian

    Tuesday, July 24, 2012 7:44 AM
  • Good stuff, I got the UAG to pass the client IP address as well by setting:

     param_ip.Value = g_source_ip

    and client source IP addresses are being passed through to the IdentityGuard RADIUS Server now.

    Tuesday, July 24, 2012 7:48 AM