Karim Elatov

Browser Configurations for the RSA SecurID Access IWA Connector

Blog Post created by Karim Elatov Employee on Dec 7, 2015

Integrated Windows Authentication

A lot of the times we configure IWA to allow seamless login into the RSA SecurID Access Web Portal. Instructions on how to install and configure IWA are located in Install the Integrated Windows Authentication Connector and the installer itself is located at RSA Via Access IWA Connector Installer. IWA uses kerberos capabilities (SPNEGO) for authentication, therefore browser configuration is necessary to trust the IWA server and ease the login process.

 

Internet Explorer

If you are on a windows machine the first you can do is confirm that kerberos tickets have been assigned to the logged in user. This can be done by using the klist command:

 

C:\>klist

Current LogonId is 0:0x31ae6
Cached Tickets: (2)

#0>     Client: devuser @ ELATOV.NET
        Server: krbtgt/ELATOV.NET @ ELATOV.NET
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 9/24/2015 12:58:21 (local)
        End Time:   9/24/2015 22:58:21 (local)
        Renew Time: 10/1/2015 12:58:21 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1>     Client: devuser @ ELATOV.NET
        Server: LDAP/dc.elatov.net/elatov.net @ ELATOV.NET
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        Start Time: 9/24/2015 12:58:51 (local)
        End Time:   9/24/2015 22:58:21 (local)
        Renew Time: 10/1/2015 12:58:21 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

 

We can see that we have a valid kerberos ticket for the elatov.net domain. As long as my IWA Server's hostname is within that domain (ie. iwa.elatov.net) then we can proceed configuring the browser to trust the elatov.net domain. If look under the Internet Explorer Settings (Tools -> Internet Options -> Security -> Local Intranet -> Custom Level), you will notice that automatic login is allowed for sites that are in the Intranet Zone by default:

ie-auto-log-local-sites.png

Now all that we have to do is add our domain into the Local Intranet Zone in Internet Explorer and we will be all set. This is accomplished by going to Tools -> Internet Options -> Security -> Local intranet -> Sites -> Advanced and add the following for the site: https://*.elatov.net/ :

 

ie-sec-site-added.png

After that if you visit your portal and you if have configured it as per the instructions laid out in Enable Automatic Integrated Windows Authentication you will be automatically logged in the portal with Internet Explorer.

 

Mozilla/Firefox

 

A similar mechanism exists for Firefox. From Mozilla's Integrated Authentication page:

 

Mozilla currently supports a whitelist of sites that are permitted to engage in SPNEGO authentication with the browser. This list is intended to be configured by an IT department prior to distributing Mozilla to end-users.

The preferences are:

pref("network.negotiate-auth.trusted-uris", site-list); 
pref("network.negotiate-auth.delegation-uris", site-list);
pref("network.automatic-ntlm-auth.trusted-uris", site-list);

where, site-list is a comma-separated list of URL prefixes or domains of the form:

site-list = "mydomain.com, https://myotherdomain.com"

network.negotiate-auth.trusted-uris lists the sites that are permitted to engage in SPNEGO authentication with the browser, and
network.negotiate-auth.delegation-uris lists the sites for which the browser may delegate user authorization to the server.
network.automatic-ntlm-auth.trusted-uris lists the trusted sites to use NTLM authentification.

To modify these settings we start firefox in the address we can enter about:config and modify just the top two options to include our domain (elatov.net):

 

firefox-auth-neg.png

Chrome/Chromium

Chrome for windows is actually pretty easy, from Chromium's HTTP authentication page:

 

In Windows only, if the AuthServerWhitelist setting is not specified, the permitted list consists of those servers in the Local Machine or Local Intranet security zone (for example, when the host in the URL includes a "." character it is outside the Local Intranet security zone), which is the behavior present in IE. Treating servers that bypass proxies as being in the intranet zone is not currently supported.

So if we configure the Local Intranet Security Zone appropriately in Internet Explorer then Chrome will use those settings as well.

 

Mac OS X

As long as the Mac OS X system is joined to the domain (I will talk more about that below) and has a valid kerberos ticket then you can launch chrome with the following command:

 

$ open -a 'Google Chrome' --args --auth-server-whitelist="*.elatov.net" --auth-negotiate-delegate-whitelist="*.elatov.net"

 

Or you can set the following setting permanently:

 

$ defaults write com.google.Chrome AuthServerWhitelist "*.elatov.net"
$ defaults write com.google.Chrome AuthNegotiateDelegateWhitelist "*.elatov.net"

 

Linux

As long as the Linux Machine is able to get a kerberos ticket (I will talk more about that later), then you can launch from with the following parameters:

 

$ google-chrome-stable --auth-server-whitelist="*.elatov.net" --auth-negotiate-delegate-whitelist="*.elatov.net"

 

If you want to make it permanent, create a file with the following settings:

 

$ cat /etc/opt/chrome/policies/managed/policies.json
{
    "AuthServerWhitelist": "*.elatov.net",
    "AuthNegotiateDelegateWhitelist": "*.elatov.net"
}

 

And then just launch Google Chrome as you would normally do. You can also confirm the policy settings by going to chrome://policy in the address bar of the Chrome Browser:

 

gc-pol-set.png

Safari and Mac OS X

 

Safari by default supports IWA, from Best Practices for Integrating OS X with Active Directory :

 

Apple and Microsoft both support Kerberos to provide a secure single sign-on environment. When integrated into an Active Directory environment, OS X uses Kerberos exclusively for all authentication activities. The use of Microsoft’s NT LAN Manager (NTLM) suite of protocols, including both NTLMv1 and NTLMv2, can be prohibited on the network as needed, without effecting Mac computers or services provided by OS X Server within the Active Directory environment.


When a user logs in to a Mac using an Active Directory account, the Active Directory domain controller automatically issues a Kerberos Ticket Granting Ticket (TGT). When the user attempts to use any service on the domain that supports Kerberos authentication, the TGT generates a ticket for that service without requiring the user to authenticate again.


You can use the Kerberos administration tools on a Mac to view currently issued tickets both from the command line, where klist displays the current

tickets, or by using the graphical Ticket Viewer utility located at /System/Library/CoreServices/Ticket Viewer.app.

 

As long as klist shows something similar to this, Safari will work by default:

 

$klist
Ticket cache: KCM:01C347AC-5C1C-46E4-B9BC-6260049FCB2B
Default principal: devuser@elatov.net

Valid starting                 Expires                        Service principal
09/24/2015 12:27:37  09/24/2015 22:27:37  krbtgt/ELATOV.NET@ELATOV.NET
09/24/2015 12:29:37  09/24/2015 22:27:37  HTTP/iwa.elatov.net@ELATOV.NET

 

Authenticating with Kerberos with Linux

 

I was testing this out with an Ubuntu Machine and it worked out for me. In order to get a kerberos ticket you first have to install the kerberos tools:

 

$ sudo apt-get install krb5-user

 

Then we need to create the Realm/Domain information, I ended up creating this simple file (Capitalization is important):

 

$ cat /etc/krb5.conf
[libdefaults]
  default_realm = elatov.net
  krb4_config = /etc/krb.conf
  krb4_realms = /etc/krb.realms
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true


[realms]
  ELATOV.NET = {
  kdc = dc.elatov.net
  admin_server = dc.elatov.net
  }
[domain_realm]
  .elatov.net = ELATOV.NET
  elatov.net = ELATOV.NET


[login]
  krb4_convert = true
  krb4_get_tickets = false

 

Then authenticate your self to get a ticket:

 

$ kinit devuser@ELATOV.NET
Password for devuser@ELATOV.NET: 

 

If that's successful, you will see your ticket:

 

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: devuser@ELATOV.NET

Valid starting       Expires              Service principal
09/24/2015 16:03:58  09/25/2015 02:03:58  krbtgt/ELATOV.NET@ELATOV.NET
  renew until 09/25/2015 16:03:53

 

Then after configuring Firefox (or Google Chrome) as per the above instructions, I visited the portal and was automatically logged in. Checking the kerberos tickets I saw a new one:

 

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: devuser@ELATOV.NET

Valid starting       Expires              Service principal
09/24/2015 16:03:58  09/25/2015 02:03:58  krbtgt/ELATOV.NET@ELATOV.NET
  renew until 09/25/2015 16:03:53
09/24/2015 16:08:43  09/25/2015 02:03:58  HTTP/iwa.elatov.net@ELATOV.NET
  renew until 09/25/2015 16:03:53

 

That should be it!

Outcomes