Windows Native Authentication

At this point WNA should be completely configured. All that remains to be done is configure the users browser settings and test the WNA feature.

Login to windows using a user account that has been synchronized from the AD server to the OID server. Although the passwords have not been synchronized with OID we will still be able to login to our SSO apps because we have already setup OID for "External Authentication".

Note: Prior to configuring WNA, the SSO server was using the "uid" attribute value in OID for the user authentication login name. After WNA is configured the SSO server will now use the "orclsamaccountname" attribute as the user authentication login name.

Since non AD users such as "orcladmin" and "portal" do not have a value set for the "orclsamaccountname" attribute you will not be able to login as these users.

To fix this login problem for non AD user authentication you will need to assign a value for these users in the "orclsamaccountname" attribute.

For instance, enter the value "orcladmin" in the "orclsamaccountname" attribute for the "orcladmin" user account, enter the value "portal" in the "orclsamaccountname" attribute for the "portal" user account and so on for all user that are NOT authenticating against Active Directory.

Do not attempt to alter the "orclsamaccountname" attribute values for any users authenticating against the Active Directory Windows domain. These values should already be correct and have a certain format that is different from non AD users. Your ActiveImport attribute mapping settings should have already set the "orclsamaccountname" attribute value for all AD users properly.

Configuring the Windows Domain Users IE Browser

After loging into the Windows domain, open the Internet Explorer browser.

From the "Tools" menu in the browser, select "Internet Options".

Select the "Security" tab.

Highlight the "Local Intranet" icon.

Click on the "Sites" button.

On the next form that comes up click the "Advanced" button.

In the field that read "Add this Web site to the zone" enter the URL for the machine that is running the SSO server. Do not enter the SSO login page or port number.

Example:

http://aspen.us.oracle.com

Click the "Add" button.

Click the "OK" button.

Back at the "Internet Options" tab, click on the "Customer Level" button.

The "User Authentication Logon" should be set for "Automatic logon only in Intranet zone".

Now we need to navigate in the IE browser to a web application URL that is controlled by the SSO server. The easiest way to do this is to go to the SSO server login page.

Example:

http://aspen.us.oracle.com:7777/pls/orasso

At the login page you will see a link in the upper left hand corner that reads "Login". Click on this link.

Watch a viewlet to see how its done.

Your Kerberos credentials will be transparently passed through the IE browser to the SSO server and you will be logged into the SSO server. The user will not see a page that asks for their credentials because login has been achieved transparently to the user.

This is evident when you click on the "Login" link, and the link name changes to "Logout".

Fallback Authentication

Only browsers that are Internet Explorer 5.0 or greater support SPNEGO-Kerberos authentication. OracleAS Single Sign-On provides fallback authentication support for unsupported browsers such as Mozilla and Netscape Communicator. Depending upon the type of browser and how it is configured, the user is presented with the single sign-on login form or the HTTP basic authentication dialog box. In either case, he or she must provide a user name and password. The user name consists of the Kerberos realm name and the user ID. It must be entered this way:

domain_name$user_id

For example: ACME.COM$jdoe Note that the user name and password are case sensitive. Note, too, that password policies for Microsoft Active Directory do not apply. Fallback authentication is performed against Microsoft Active Directory, using an external authentication plugin for Oracle Internet Directory.