locked
User authentication issue with AD and Radius in UAG RRS feed

  • Question

  • Hi,

    I have one UAG setup that is having an issue. I have configured the portal trunk with both Active Directory authentication and Radius authentication. This Radius server is strong authentication server. In this Radius, user first authenticates with AD account / password and then he is challenged for one-time password (either SMS OTP or token depending on user configuration). On UAG side, this Radius repository uses Active Directory for group authentication.

    Both authentication methods are working fine. However, we found an problem in this. The workflow goes like this

    1. User authenticates towards Active Directory
    2. User access the portal after successfull authentication
    3. User logs off the portal and goes immediately back to login page
    4. User types in AD account / password and selects RADIUS repository
    5. User is able to login as RADIUS user without he has been challenged for one-time password (so he just gets more applications visible than he should).

    I believe this has something to do with UAG, since the step 4 authentication request is never arriving to RADIUS server - UAG does not ask Radius to authenticate the user.

    Also the user that is NOT listed in Radius as allowed to authenticate, is able to authenticate as Radius user on the way I just described.

    I am aware of disabling authentication credentials caching. I have changed the CredentialsCacheTime from 300 to 0 on UAG server, so it should not cache any credentials though.

    Anybody else having same issues or tips / tricks?

    BR, TommiK

    Sunday, June 6, 2010 7:42 PM

Answers

  • Hi Tommi,

    You mention that this happens when the user immediately goes back to the login page. If he goes back not immediately (for example, after 30-40 seconds) or if he closes and re-opens his browser, does this change the results?

    Also, if this is the same user that goes back in, then other than this being "weird", there's no actual security exposure, as the user won't get to applications he is not supposed to get. Is that right, or did I misunderstand your description?

     


    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Tuesday, June 29, 2010 6:46 PM
    Tuesday, June 29, 2010 6:46 PM

All replies

  • Hi Tommi,

    You mention that this happens when the user immediately goes back to the login page. If he goes back not immediately (for example, after 30-40 seconds) or if he closes and re-opens his browser, does this change the results?

    Also, if this is the same user that goes back in, then other than this being "weird", there's no actual security exposure, as the user won't get to applications he is not supposed to get. Is that right, or did I misunderstand your description?

     


    Ben Ari
    Microsoft CSS IAG Support
    Sammamish, WA
    • Marked as answer by Erez Benari Tuesday, June 29, 2010 6:46 PM
    Tuesday, June 29, 2010 6:46 PM
  • Hi,

    the issue was the when the user first logs on with AD account, then logs out to the portal. Then the user will browse again to logon page. Now he selects STRONG AUTHENTICATION repository instead of AD repository. He can access the UAG portal with AD credentials without entering any STRONG AUTHENTICATION credentials. The authentication request will not even go to the strong authentication server.

    The thing is that the user gets all the applications and services in use, although they should be available on the strong authentication servers, not for AD accounts. So I would say that this is a security issue, since the user can access further more resource only with AD accoun if they are aware of this.

    This will be solved changing the CacheCredentialTime register parameter to 0. I did this once already, but the value was changed back to 300, which the default value.

    The sequence for changing this value was to

    1. Change value
    2. Activate configuration
    3. Reboot the server

    By doing this, the registry value was staying in changed value and this issue was solved.

    BR, TommiK

    Wednesday, June 30, 2010 9:17 AM
  • Using that registry key is the correct answer (workaround) and has been discussed here in the past specifically for RSA SecurID.

    Cheers

    JJ 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, June 30, 2010 9:40 AM