Symantec Access Management

  • 1.  Using different ADs for IWA authentication

    Posted Mar 25, 2019 03:18 AM

    I have  a typical use case here.

    Currently users of federated applications are being authenticated by an IWA server which is using the AD lets say AD1.

    The current IWA Authentication scheme (IWA_Auth_Scheme) supports Active Directory/LDAP.

     

    Now i need to implement, is to bring more new users who are on AD2 to use the same IWA_Auth_Scheme to access the same federated applications.

     

    The POC that i need to do is:

    1. Use the same IWA server to authentication the users both from AD1 and AD2.

    2. Do a mapping in CA SSO such that if the user is authenticated through  AD2 map his identity with AD1 (e.g if AD2.EmployeeID = AD1.EmpID return AD1.EpID) and return the EmployeeID from AD1 and pass to the federated application.



  • 2.  Re: Using different ADs for IWA authentication

    Broadcom Employee
    Posted Mar 25, 2019 09:56 AM

    Yes, It is feasible and should work as expected. Let us know if you run into any issues.



  • 3.  Re: Using different ADs for IWA authentication

    Posted Mar 25, 2019 10:02 AM

    Hi Ashok,

     

    need assistance/ reference how to set this up. What changes are needed on the IWA server to authenticate the users from AD1 and Ad2.

     

    What mapping we need to do in Admin Ui ? Can this be achieved through expressions ?



  • 4.  Re: Using different ADs for IWA authentication

    Posted Mar 25, 2019 12:54 PM

    Hi Pallavi,

     

    Am I right to say your AD1 and AD2 are not configured with any kind of forest trust? If not, AFAIK out of the box solution isn't available in current CA SSO for you to achieve your objective.

     

    Unfortunately, Authentication chaining still hasn't mature to the point of able to chain multiple Windows authentication schemes.

     

    But that's not to say we can't get creative. Here's how I think I'll approach your POC with regards to the authentication hurdle. I think you should be able to do directory mapping for authorization without issues so I won't go into that.

     

    I'm assuming you are using Access Gateway instead of IIS web agent. but either one should work.

    1. Setup Access Gateway 1 and add it as host to your AD1 DC. <- I think you already have this. I'll call this "ag-for-ad1"
    2. Setup Access Gateway 2 and add it as host to your AD2 DC. <- I'll call this "ag-for-ad2"
    3. Create "Windows Authentication" scheme for ag-for-ad1. (https://ag-for-ad1.mycompany.com/siteminderagent/ntlm/creds.ntc)
    4. Create "Windows Authentication" scheme for ag-for-ad2. (https://ag-for-ad2.mycompany.com/siteminderagent/ntlm/creds.ntc)
    5. In one of you existing app domains/realm, or create 1 for testing, use "ag-for-ad1" Windows auth scheme. I'll just call this app as https://app1.mycompany.com/wonderfulapp
    6. In that realm, create onAuthReject and onAuthAttempt rules. I'm assuming webagent action GET, POST events are already configured and allowed in policy.
    7. In domain policy, set those 2 rules' response to use webagent-onreject-redirect to redirect to https://ag-for-ad2.mycompany.com/auth/ad2auth-for-app1
    8. Now to make sense of what you did in step 7, Create a domain that has AD2 as its User Directory, I'll call this "AD2 Authentication Domain"
    9. Create a realm within the above domain meant for APP1, I'll call this "AD2 Authentication realm for app1". the resource can be anything that is unique which I've already sort of defined in step 7. so use "/auth/ad2auth-for-app1" <- this is a virtual resource that doesn't need to be hosted in any server. We just need something unique for the rules to be fired upon.
    10. The Authentication scheme to use in this realm is "ag-for-ad2" Windows Auth scheme
    11. create onAuthAccept, onAuthAttempt and onAuthReject rules
    12. create domain policy and add those 3 rules in.
    13. onAuthAccept will respond with a webagent-onaccept-redirect to https://app1.mycompany.com/wonderfulapp
      (note that if your authorization mapping is done properly, this should not bounce)
    14. onAuthAttempt and onAuthReject responses will be to one of your custom error pages. stating 403 forbidden or something more humane.
    15. Pray.

     

    I have not tried any of the above. But based on my past experimenting with events and responses, I think it should work.

     

    If anyone has an easier way of doing this, please share.

     

    regards,

    Zen



  • 5.  Re: Using different ADs for IWA authentication

    Posted Mar 26, 2019 12:05 PM

    Thanks Zen for the wonderful explanation. I will implement the logic and will confirm back.



  • 6.  Re: Using different ADs for IWA authentication

    Posted Mar 26, 2019 12:11 PM

    But i still need some assistance on part 2 of my original question. My question is user from AD2.EmployeeIDAD2 logs into the SSO application now we need to map fetch the Ad1.Employeeid of the same user from AD1 on the basis of lets say matching phone number, and return the Ad1.Employeeid as the assertion attribute to the federated application.

    How can this be possible



  • 7.  Re: Using different ADs for IWA authentication
    Best Answer

    Posted Mar 26, 2019 06:24 PM

    As I understood, identity mapping isn't officially supported in partnership federation. But there's some workarounds suggested in past posts. Take a look at what Hubert shared.

     

    https://communities.ca.com/people/HubertDennis/blog/2018/05/14/ca-sso-identitymap-expression-reserve-word-usage-configuration

     

    Good luck

     

    regards,

    Zen



  • 8.  Re: Using different ADs for IWA authentication

    Posted Mar 27, 2019 06:37 AM

    Thanks Zen i've requested for the fix from CA for using the Identity_Map as per the URL above this functionality is broken and requires fix. Hence hoping for the best.



  • 9.  Re: Using different ADs for IWA authentication

    Posted Apr 01, 2019 01:59 AM

    It worked for me Zen. Thanks



  • 10.  Re: Using different ADs for IWA authentication

    Posted Apr 01, 2019 11:35 AM

    Glad it work out well for you.