Symantec Access Management

 View Only
  • 1.  IWA in Siteminder

    Posted Jun 30, 2018 03:14 AM

    Hello All,


    I would like to understand IWA in detail i.e. how ceredentials are passed to the IIS server and how it validates and how and what all sessions are generated? How policy server validated the IIS authenticated user etc.


    Can you please guide me to documentation or share your thoughts on the above?


    Thank You

    Ankur Taneja

  • 2.  Re: IWA in Siteminder

  • 3.  Re: IWA in Siteminder

    Posted Jun 30, 2018 06:32 AM

    Hi Ankur,


    For Integrated Windows Authentication, it is IIS that does the authentication, not SiteMinder. SiteMinder Web Agent does not do any authentication for IWA, Siteminder Web Agent trusts the credentials accepted by the IIS and send it to Policy Server for Siteminder authentication and authorization.


    When a user accesses a resource on any type of web server protected by the SiteMinder NTLM or Windows Authentication scheme,


    SiteMinder Policy Server returns a credential collector redirect URL to the web agent that must use the FQDN of an IIS web server,with a URI of /siteminderagent/ntlm/creds.ntc.


    The web agent then performs the redirect to the IIS Web server, which must be configured for NTLM/Windows authentication when the/siteminderagent/ntlm virtual directory is accessed.


    The MS IIS web server then sends the IE browser a request for the user's credentials (user name and password )


    The MS IE browser communicates with the MS Windows OS to get the current user's desktop login credentials, encrypts them and sends them back to the MS IIS web server.


    The IIS web server decrypts the creds, then uses them to login to the Active Directory  and declares the user authenticated if the login is successful.


    Once IIS has authenticated the user, control finally passes to the SiteMinder Web Agent which extracts user's ID and passes it to the policy server for "Authentication".


    The policy server doesn't really do full authentication. It disambiguates the user in a user store and then just declares the user authenticated, having trusted IIS to actually verify credentials.


    The Web agent then sets an SMSESSION cookie, and sets SM_USER to domain\loginID, then redirects back to the user's original target.


    Refer : 


    How NTLM/Windows Authentication works? - CA Knowledge 


    How to Troubleshoot Integrated Windows Authenticat - CA Knowledge 



    Leo Joseph.

  • 4.  Re: IWA in Siteminder

    Posted Jul 02, 2018 01:10 AM

    Hello Leo,


    Thank you for the detail. 


    In the link above it says "The IIS web server decrypts the creds, then uses them to login to the MS NT Domain Controller (Active Directory nowadays) and declares the user authenticated if the login is successful." 


    I would like to understand how IIS Web Server connects to the Active Directory for validation of credentials? 


    Thank You

    Ankur Taneja

  • 5.  Re: IWA in Siteminder

    Posted Jul 02, 2018 01:48 AM

    Hi Ankur,


    That is internal call happens between web-server and AD  - I would request you to check with Microsoft on this.


    Leo Joseph.

  • 6.  Re: IWA in Siteminder

    Posted Jul 02, 2018 02:11 AM

    Hello Leo,


    Thanks, will try to figure out. But was wondering how IIS Server will know which AD to validate credentials against and how it would have access to that AD? Maybe this IIS server should be in same Domain as the end user machine?


    Thank You

    Ankur Taneja

  • 7.  Re: IWA in Siteminder

    Posted Jul 02, 2018 02:24 AM

    Hi Ankur,


    Windows authentication is best suited for an intranet environment for the following reasons:

    • Client computers and Web servers are in the same domain    

    Windows Authentication | Microsoft Docs 



    Leo Joseph.

  • 8.  Re: IWA in Siteminder

    Broadcom Employee
    Posted Jul 02, 2018 05:11 PM

    If you've only got one domain, then IIS server and client PC should be in the same domain.

    In a multi-domain forest, IIS Server should be in the same forest as the client PC.


    I've never configured it for multiple forests. But assuming forest trust is set up correctly, it should work. But see Microsoft publications for details.