locked
Application authentication question RRS feed

  • Question

  • Hello group

    I've setup several applications in IAG 2007 (OWA; SP; internal web etc) for a company portal. I've configured authentication for each application to allow only specific AD security groups to access the apps and to see them when logged in. This seems to work okay: if you're in the various groups, you see what I want you to see based on your access requirements.

    So, this works great for the portal but we also have direct links configured to take users directly to certain applications like: my.portal.com/owa. When I have the AD group security setup for the apps Users hitting the direct link receive an error message saying 'You are not authorized to access this application'. As soon as I remove the AD group from the authentication tab of the application and revert back to all users have access, direct links work again.

    I understand according to
    http://support.microsoft.com/kb/960306  that this is by design. The article offers a resolution where you modify the policy setting but I haven't as yet discovered what policies need to be modified or where I do that.

    So, how can I lock down the portal using the AD groups but still allow the /owa etc direct links to function?

    I'm clearly new to IAG (voluntold to admin/learn it) so I thank you in advance if you can provide some help.

    JPenrose MCSE

     

     

     
    Wednesday, October 14, 2009 4:14 PM

Answers

  • I think what you may not be fully understanding is how IAG distinguishes one web application from another.   This is done by the combination of server/path/port.   If more than one application is on the same server, tehn you either need to have IAG know it by a secondary servername, or you need to distiguish it by path or port.   If 2 applications have the same server/path/port, or they have same server/port and one path is a subset of another, then the order they are listed in teh gui makes a difference.  To help yourself understand what is going, log in into iag and click one of the links that isn;t working as expected, and then look at the session details in teh iag web monitor to see which application the iag thinks was launched..  (you should find that it is the first one in teh application list that matches the server/path/port.

    I'm sure you can find a solution once you understand how the HAT is working and the IAG is distinguishing teh multiple web apps.

    PLease mark this as a an answer to our question if it helps..

    Thanks,
    Mark


    BTW-  If you need more detailed help with the IAG project, let me know (http://mbrsecurity.com), thats what MBR Security's core business is, IAG/UAG consulting engagements  (as well as IAG/UAG appliance sales)
    • Proposed as answer by Mark Resnik Thursday, November 5, 2009 3:34 AM
    • Marked as answer by OpsAdmin Thursday, November 5, 2009 2:04 PM
    Thursday, November 5, 2009 3:34 AM
  • Is this an example of your scenario?
    1. User access portal and do not see /owa because he is not authorized.
    2. But he sees Sharpeoint since he is authorized to do that
    3. User enters Sharepoint application and finds link to /owa
    4. When clicking this link he gets the error

    In that case the request for /owa hits the /owa application and is denied as specified by your authorization rules.
    I would say this is the expected behaviour in your config, or dou you want the users to be able to use backdoor to applications they are not authorized to use?

    • Marked as answer by Erez Benari Wednesday, October 14, 2009 5:17 PM
    Wednesday, October 14, 2009 4:59 PM

All replies

  • Is this an example of your scenario?
    1. User access portal and do not see /owa because he is not authorized.
    2. But he sees Sharpeoint since he is authorized to do that
    3. User enters Sharepoint application and finds link to /owa
    4. When clicking this link he gets the error

    In that case the request for /owa hits the /owa application and is denied as specified by your authorization rules.
    I would say this is the expected behaviour in your config, or dou you want the users to be able to use backdoor to applications they are not authorized to use?

    • Marked as answer by Erez Benari Wednesday, October 14, 2009 5:17 PM
    Wednesday, October 14, 2009 4:59 PM
  • Thanks for the reply Kent,

    1. User logs into portal home page using https://myportal.mydomain.com from the browser then logs in using AD UN/PW
    2. Most users see about 6 links to various applications (owa, sharepoint, file access etc)
    3. User clicks a link and accesses the app to which s/he has security group rights to use
    4. User then logs in to a direct link like: https://myportal.mydomain.com/OWA and gets 'You are not authorized to access this application' error (only when using direct link and only when the authentication tab of the application(s) is locked down to a security group)
    5. I remove the AD group from the app and set it to allow all users
    6. Both portal link and direct link behave as expected

    See, the business wants to control who can access applications from the portal so I've setup security such that if you're not in the group then you don't see the link on the portal home page. Some users (like admins) see all links, others may see just an internal dev server and others, like external guests, will see just a single file share (or whatever is needed). As soon as I configure all users have access for an application (to 'fix' the direct link issue) the external vendor sees links they aren't supposed to and so do users that where restricted by being explicitly denied by way of AD group exclusion.

    Does that make better sense? Surely there's a config somewhere that allows me to use group security without breaking direct URL linking. I'm just not seeing it.

    Thanks again for your help Kent
    -J     
    Wednesday, October 14, 2009 5:21 PM
  • Question remains if user in your step 4 are authorized to use /owa in the portal configuration?

    And when you say "business wants to control who can access applications from the portal" i would guess you actually mean
    "business wants to control who can access applications no matter if they use direct link or portal"
    Wednesday, October 14, 2009 5:53 PM
  • Yes, they're authorized to use owa if they go to the portal; I think this is where I'm going wrong: I can set the permissions on the app so that user can get to owa from the portal page by clicking the link b/c s/he is in the right group but I can't see where to permission the same user to use /owa in a direct link. I have one owa app setup and then I have an entry under advanced trunk configuration-application access portal-manual url replacement like this:

    URL                       To URL                    Type                      Server name                      Use SSL             Port
    /owa                      /owa                       Redirect                 mail.mydomain.com            No                     80

    Yes to your second question: the business wants to control access either with direst link or portal.

    Wednesday, October 14, 2009 6:07 PM
  • This somehow got marked as answered. It is in fact still an issue so if anyone else has a suggestion I'm all ears.

    Thanks,
    J
    Friday, October 30, 2009 5:51 PM
  • I'm guessing you have the same or overlapping server/path/port listed on the web servers tab in this application and another application in the list?  If so, the application properties, including authorization, are applied based on the first application in the list from top to bottom which matches a user request.
    Friday, October 30, 2009 7:04 PM
  • Would it then make a difference if I ordered the applications so the direct linked apps are ordered at the top followed by the open access ones? I have a dozen or so links on the page but only 8 of them need to support a /<whatever> in the URL.

    I gotta be missing something with the authorization bits in this appliance. I simply want to control what different groups of users see (call it the 'portal experience') based on group membership but in the process not break direct linking. I'm beginning to think this isn't possible.

    Thanks for the response Mark.

    Tuesday, November 3, 2009 7:11 PM
  • I think what you may not be fully understanding is how IAG distinguishes one web application from another.   This is done by the combination of server/path/port.   If more than one application is on the same server, tehn you either need to have IAG know it by a secondary servername, or you need to distiguish it by path or port.   If 2 applications have the same server/path/port, or they have same server/port and one path is a subset of another, then the order they are listed in teh gui makes a difference.  To help yourself understand what is going, log in into iag and click one of the links that isn;t working as expected, and then look at the session details in teh iag web monitor to see which application the iag thinks was launched..  (you should find that it is the first one in teh application list that matches the server/path/port.

    I'm sure you can find a solution once you understand how the HAT is working and the IAG is distinguishing teh multiple web apps.

    PLease mark this as a an answer to our question if it helps..

    Thanks,
    Mark


    BTW-  If you need more detailed help with the IAG project, let me know (http://mbrsecurity.com), thats what MBR Security's core business is, IAG/UAG consulting engagements  (as well as IAG/UAG appliance sales)
    • Proposed as answer by Mark Resnik Thursday, November 5, 2009 3:34 AM
    • Marked as answer by OpsAdmin Thursday, November 5, 2009 2:04 PM
    Thursday, November 5, 2009 3:34 AM