Obi Sso

Configuring authentication and SSO with Active Directory and Windows Native Authentication in Oracle Business Intelligence Enterprise
Edition
An Oracle White Paper December 2010
No table of contents entries found.
Configuring authentication and SSO with Active Directory and Windows Native Authentication in Oracle Business Intelligence Enterprise Edition Page 2
Configuring authentication and SSO with Active Directory and Windows Native Authentication in Oracle Business Intelligence Enterprise Edition
INTRODUCTION
This paper examines how to configure Oracle Business Intelligence Enterprise Edition (Oracle BI EE) 11.1.1.3.0 to use Windows Server Active Directory (AD) as an LDAP Authentication source and how to use Windows Native Authentication (WNA) in an SSO environment. The aim is to describe the configuration and setup required so that users may log on to their Windows PCs and access Oracle BI EE via a standard web browser with no further authentication required on their part Windows Native Authentication and Oracle Weblogic will be doing the hard work to authenticate users to Oracle BI EE using their standard network logins without further troubling authorised users of the system. There are several steps to be performed in Active Directory itself, in the Weblogic Server hosting Oracle BI EE, in the Oracle BI EE web app and finally on the client machine(s) from which you wish users to access Oracle BI EE using Windows Native Authentication SSO. The steps in this document have been tested with Oracle BI EE version 11.1.1.3.0 and Active Directory 2008 (Windows Server 2008).
SCENARIO
In order to illustrate the configuration settings that must be set we will use a worked example of a fictional company XYZ corp. attempting to set up WNA SSO for BI for their internal users. In this scenario, we have the following elements at play: 1. Active Directory Domain: XYZ Corp have an AD domain, xyzcorp.com which authenticates all their internal users when users log into the corporate network on their Windows machines, this is the domain they log into. The AD domain controller is: addc.xyzcorp.com, controlling AD domain (and Kerberos realm) xyzcorp.com Oracle BI EE Weblogic Domain: XYZ Corp have a Weblogic domain, bifoundation_domain (the default for Oracle BI EE installs) installed on a server in a separate network domain bieesvr1.xyz2.com The SysAdmin trying to set all this up is Jo Smith (login jsmith) Jos client machine is xyz47.xyzcorp.com
2. 3. 4.
STAGE 1: USING ACTIVE DIRECTORY AS A USER STORE
Before we can think about having clients authenticate using Single Sign On from machines in the AD domain, first we must configure Oracle BI EE to recognise the AD domain as a valid user store to authenticate Oracle BI EE users against. This is a
standalone operation in its own right once we have completed this section, XYZ Corp users will be able to log in to Oracle BI EE using the same credentials as they use to log in to the Windows domain. NB this also requires Group information to be stored in Active Directory i.e. once authenticated in this way, the system will expect users to be organised in AD groups. So users must be assigned to groups in Active Directory, rather than assigning Group/Role information in INIT blocks, as was the case in Oracle BI EE 10g. AD groups can then be assigned to Application Roles in Enterprise Manager to provide access to functions of the system.
What we need to know
To complete this stage, we need the following pieces of information: Active Directory Server name/port: we need the name of the AD server and the port on which its listening for LDAP requests (defaults to 389). So in our example scenario this is addc.xyzcorp.com:389 Base DN: the base LDAP path from which all searches start for users and groups. In our example scenario, this is:
CN=Users,DC=xyzcorp,DC=com
for the Users Base DN and

CN=Builtin,DC=xyzcorp,DC=com
for the Groups Base DN. GUID attribute: attribute in LDAP used to represent the GUID of users and groups (defaults to objectguid for Active Directory) DN/Password for LDAP Principal: the LDAP DN for the user we will connect to Active Directory as when retrieving information about LDAP users. In our example scenario, this is: CN=jsmith,CN=Users,DC=xyzcorp,DC=com Well also need the password for the user, obviously. NB the user need not be an administrative account, but it does need to have sufficient privileges to be able to make arbitrary queries on the LDAP tree.
Configuring Active Directory Authenticator in Weblogic
Log on to the Weblogic Admin console at http://bieesvr1.xyz2.com:7001/console On the left hand side of the screen is a Domain Structure menu. Select Security Realms then on the main page, click on the link for the domain security realm (default myrealm), then the Providers tab in the main screen, followed by the Authentication subtab.
Click the Lock and Edit button in the top left of the WLS Admin console so we can create a new authentication provider, then click the New button at the bottom of the table of current Authentication Providers in the main screen.
In the Create New Authenticator screen, type in a suitable name (ADAuthenticator in the example below) and select the type as ActiveDirectoryAuthenticator, then click OK.
Youll now be taken back to table of authentication providers, with your new provider at the bottom and the
DefaultAuthenticator at the top. Click on the link to DefaultAuthenticator to edit its properties. In the Common Authentication Provider Settings screen, change the Control Flag drop-down from REQUIRED to SUFFICIENT and click on the Save button. For further information on the implications of these settings, consult the Weblogic Server documentation on Configuring Authentication Providers at http://download.oracle.com/docs/cd/E14571_01/web.1111/e13707/atn.htm#i1204568 which contains a detailed explanation of these settings Go back to the table of authentication providers and click on the link to your new provider (ADAuthenticator in the example) to edit its properties. In the Common Authentication Provider Settings screen, change the Control Flag drop-down from OPTIONAL to SUFFICIENT and click on the Save button.
Next select the Provider Specific tab to bring up the options which apply specifically to connecting to an Active Directory LDAP authentication store. This is where we need specific information about the AD store were trying to connect to. Host Port Principal Credential/Confirm credential User Base DN User Attribute Name Name of the AD server addc.xyzcorp.com Port the AD server is listening for LDAP requests on the LDAP DN for the user we will connect to Active Directory as when retrieving information about LDAP users password of the principal specified in the stage above LDAP query used to find users in AD Attribute used to specify user name in AD defaults to cn. Do not change unless you know your AD is configured to use a different attribute for user name. If you do change it, see the section on Changing user/group name attributes below 389 CN=jsmith,CN=Users,DC=xyzcorp, DC=com welcome1 CN=Users,DC=xyzcorp,DC=com cn
User Object class Group base DN GUID attribute LDAP query to find groups in AD NB only groups defined under this path will be visible to Weblogic The attribute used to define object GUIDs in AD
user CN=Builtin,DC=xyzcorp,DC=com objectguid
Reordering Providers
Return to the main Authentication Provider screen (Security Realms->myrealm->Providers->Authentication). Click the Reorder button, then select the tickbox next to your ActiveDirectoryAuthenticator (ADAuthenticator in our example), then use the shuttle control to put the ActiveDirectoryAuthenticator at the top of the list.
Changing User/Group Name Attributes
If your AD server uses a different attribute for User Name you will need to change the User Name attribute from the default cn. If you do change this attribute, you will also need to change the settings for AllUsersFilter and UserFromNameFilter as shown in the table below (using the example of the user name being stored in an attribute called AnOtherUserAttribute)
Attribute Name
UserNameAttribute AllUsersFilter UserFromNameFilter
Default Setting
cn (&(cn=*)(objectclass=person)) (&(cn=%u)(objectclass=person))
Required New Setting

AnOtherUserAttribute
(&(AnOtherUserAttribute =*)(objectclass=person)) (&(AnOtherUserAttribute =%u)(objectclass=person))
For UserName Attribute only, you also need to add two properties to the Identity Store configuration (user.login.attr and and username.attr) to tell it about the attribute youre expecting to get user name from (it defaults to using uid if none is specified). These settings are reached via the Security Provider Configuration screen, which is accessed via Enterprise Manager. Select Weblogic Domain -> bifoundation_domain->(right click) Security -> Security Provider Configuration.
This brings up the main Security Provider Configuration screen, find the Identity Store Provider section in the middle of the screen and select the Configure button to bring up the Identity Store Configuration screen. Click on the green + icon to add the new properties to the Identity Store and as stated above, two new properties need to be added, user.login.attr and
username.attr, both set to the value of the alternate user name attribute Likewise, if you have a different Group Name Attribute from the default cn, you also need to change the AllGroupsFilter and GroupFromNameFilter, as shown in the table below (using the example of the user name being stored in an attribute called AnOtherGroupAttr)
Attribute Name
StaticGroupNameAttribute/ DynamicGroupNameAttribute AllGroupsFilter
Default Setting
cn (&(cn=*)(|(objectclass=gro upofUniqueNames)(objectcla ss=orcldynamicgroup))) (|(&(cn=%g)(objectclass=gr oupofUniqueNames))(&(cn=%g )(objectclass=orcldynamicg roup)))
Required Changes
AnOtherGroupAttr
(&(AnOtherGroupAttr=*)(|(object class=groupofUniqueNames)(obje ctclass=orcldynamicgroup))) (|(&(AnOtherGroupAttr=%g)(objec tclass=groupofUniqueNames))(&( uid=%g)(objectclass=orcldynami cgroup)))
GroupFromNameFilter
Once youve made all the changes you need to the Provider Specific form, click the Save button
Resetting the system user
On install, Oracle BI EE creates an internal account in the Weblogic LDAP store, BISystemUser, which is used for serviceto-service authentication. The credentials of this account are stored in the Credential Store under the system.user key. Before you proceed any further you need to point this system.user key to a set of credentials available in Active Directory.
You can if you wish use the credentials of an existing user, however we would recommend creating a user account explicitly for this purpose this is not an ordinary user account but rather a set of credentials used to authenticate services within the system to each other. Whether you decided to use an existing account or create a new one, the process for changing the system.user is the same. In Enterprise Manager, select Weblogic Domain -> bifoundation_domain->(right click) Security -> Credentials, this brings up the Credential Store configuration screen. Select the oracle.bi.system map, expand it and select the system.user key. Reset the username and password to your chosen account credentials the example below shows resetting to a new bisystemuser
account created in Active Directory to replace the BISystemUser account in the default WLS LDAP referenced by the Default Authenticator. Next you need to ensure your new system user account is part of the BISystem Application Role. In Enterprise Manager, select Weblogic Domain -> bifoundation_domain->(right click) Security ->Application Roles. This brings up the Application Roles configuration screen. In the drop-down box labelled Application Stripe to Search, select obi and press the green play button next to the Role Name text box. This will bring up a list of application roles, one of which should be BISystem.
Select BISystem, and click the Edit button to edit the application role. In the Edit Application Role screen, scroll down to the Users section and click on the button marked Add User. An Add User dialog will appear. Either type your system user username into the User Name box or for a full list of
users, leave it blank. Again, click the green Play button next to the text box and a list of users will appear in the Available Users selection box. Select the name of your system user account and use the shuttle control to move it into the list of Selected Users. Click OK to dismiss the Add User dialog. Back in the main Edit Application Role Screen, click the OK button in the top right of the screen to apply the changes to the BI System Application Role.
The final stage of configuring the new system user is to ensure they are part of the Weblogic Global Admin role. Log into Weblogic Admin console
Select Security Realms from the left-hand menu, click on the link to your security realm in the main screen (e.g. myrealm), then select Roles and Policies from the tabs along the top
In the list of roles, click on the plus sign to expand Global Roles, then Roles, then click on the link marked View Role Conditions for the Admin Role. Ensure the conditions specified will match your user, either directly, or by virtue of a group they belong to (e.g. condition may be User = bisystemuser or Group=Administrators If you have made any changes, click the Save button. Changes should be applied immediately
Once you have changed the system user credentials in this way, you will need to restart the BI Server and BI Presentation Server before these changes will take effect. The easiest way to do this is via Enterprise Manager select Business Intelligence and Restart All Components.
Mapping Active Directory Groups to Application Roles
Access to functions within Oracle BI is controlled via Application Roles. For a detailed discussion of the purpose and function of the Application Roles, please see the product documentation, for now it will suffice to say that in order for your Active Directory domain users to be able to use the system, they (or rather the groups they are in) need to be mapped to Application Roles. The process for doing this is as for assigning the system user to the BISystemRole, described above, with the exception that we map groups to the role, not just an individual user.
Testing your changes
Once youve restarted Weblogic, check that you can still log into the Weblogic Administrative Console as the Weblogic admin user you specified during install. Next check you can log in to Oracle BI using the credentials of one of the Active Directory users.
TROUBLESHOOTING ACTIVE DIRECTORY AUTHENTICATION
One of the most common causes of issues in Active Directory configuration is simply not having the correct settings. Its useful when trying to diagnose AD LDAP issues to have an LDAP browser to hand. Using an LDAP browser you can test the Base DNs youre using and the credentials used to connect to the LDAP store, then drill into how your AD/LDAP store is organised to, for example, view the attributes your AD store is using, check name hierarchies (useful for diagnosing Base DN issues) etc.
There are several good LDAP browsers freely available which will help you diagnose using your Active Directory as an LDAP store in WLS, such as Apache Directory Studio (shown above) - http://directory.apache.org/studio/downloads.html or the more lightweight JXplorer - http://jxplorer.org/ .
STAGE 2: WINDOWS NATIVE AUTHENTICATION SINGLE SIGN-ON WITH KERBEROS
In simple terms, this feature enables Microsoft clients (typically browsers), authenticated in a Windows domain, using Kerberos (referred to by Microsoft as Integrated Windows Authentication), to be transparently authenticated in a Weblogic domain, based on the same credentials, and without the need to type in their password again. Once users have authenticated to the Windows domain, they are also transparently authenticacted to the Weblogic domain. Three different areas need to be configured for this to happen:
The Client machine

Needs to be configured to send a Kerberos ticket when available
The WLS server

Needs to be configured to access Kerberos, accept Kerberos tickets, and to locate Kerberos credentials information
The KDC (AD domain controller)

A principal needs to be added to represent the WLS server, and some additional configuration to allow the principal to be related to the HTTP service on the WLS server.
The KDC Configuration
A Windows Active Directory domain controller can serve as the Kerberos Key Distribution Center (KDC) server for Kerberos-based client and host systems. In our example scenario, there is a Windows domain xyzcorp.com, run by a domain controller, addc.yzcorp.com. Any user that logs into that domain is authenticated against the AD server running in addc.yzcorp.com, and so is also recognized by the Kerberos service as a valid principal. A realm is the Kerberos equivalent of a Windows domain, i.e. an administrative domain. Kerberos realm names are usually written in uppercase and usually consist of the DNS domain name (so for our example XYZCORP.COM is the realm name)
Configure your domain to use Kerberos
The first step is to locate your domain controller, and ensure that it is enabled to act as a KDC and that the Kerberos and
AD services are running.
Enabling DES Encryption on Windows Server 2008 R2
Windows 7 and Windows Server 2008 R2 by default have DES encryption disabled, so you will need to explicitly enable it following the instructions in this Microsoft support note: http://support.microsoft.com/kb/977321
You should follow the instructions in this section on the Domain Controller: Enable the following Group Policies to apply the DES encryption type to all computers that are running Windows 7 or Windows Server 2008 R2: 1. In the Group Policy Management Console (GPMC), locate the following location:
Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options 2. 3. 4. Click to select the Network security: Configure encryption types allowed for Kerberos option. Click to select Define these policy settings and all the six check boxes for the encryption types. Click OK. Close the GPMC.
Create an account for the WLS server Your Weblogic server does not need to belong to the network domain the AD domain controller administers (xyzcorp.com, in our example) but it does need to be able to identify itself to the KDC. For your Weblogic server to use Kerberos, you must first establish a Kerberos principal, which is based on a standard AD account. This principal will represent your WLS server in the Kerberos realm. So first, you need to create a user account in Active Directory for your Weblogic server instance (NB you create a user not a machine even though this principal will represent the Weblogic Server). While you are free to name the user anything you like, we recommend naming the user by the short name of your Weblogic server host in order to differentiate this account from regular user accounts and also to enable you to more easily distinguish between multiple Kerberos principal accounts representing different Weblogic servers. So in our example scenario, the WLS server instance is running on bieesvr1.xyz2.com so we will create a user named bieesvr1.
On the Active Directory Domain Controller, from the Start Menu, run Programs->Administrative Tools->Active Directory Users and Computers tool. Right click on the Users node and select New->User. (Do not select Machine) Type the same user name in the Full Name field and in the Logon Name field. (i.e. this is where we would type in bieesvr1), then click Next Enter a password (and of course, memorize it), verify that none of the password options are checked and click Next. Click Finish.
Next you must ensure your new user complies with the Kerberos protocol: the encryption type for this account must be DES, and the account must require Kerberos pre-authentication. Go back to the Active Directory Users and Computers tool, and locate your newly created user in the Users tree in the left hand pane. Right-click on the user node, and select Properties. Click on the Account tab. Check the box: Use DES encryption types for this account. Ensure Do not require Kerberos pre-authentication is not checked (i.e. we DO require Kerberos pre-authentication) Click OK. Historically, it has been reported that setting the encryption type may corrupt the password. It is recommended at this point to reset the password of this user, by right clicking on the user, selecting Reset Password and re-entering the same password specified earlier.
Define a Service Principal Name for the service
An SPN (Service Principal Name) is a unique name that identifies an instance of a service and is associated with the logon account under which the service instance runs. It provides a mapping between the AD user account and the service instance and allows for the multipart name format used in Kerberos principal names (e.g. HTTP/hostname.dns.com). The SPN is used in the process of mutual authentication between the client and the server hosting a particular service. The client finds a computer account based on the SPN of the service to which it is trying to connect. So, in our example scenario, we need to link the service that will be invoked by our clients to the account we just defined for our Weblogic server. The service invoked by the browser clients is HTTP/bieesvr1.xyz2.com, which needs to be linked to the
bieesvr1 AD account we just created. After the SPN is created, for a server to use Kerberos, the user must setup a keytab (key table) on the host running the server (see next section). NB this step is not required if your Weblogic server is running on Linux/Unix as the creation of the keytab file using the ktpass utility on the AD domain controller (see below) will also create the SPN. Explicitly using setspn is only required if your Weblogic server is on a Windows machine. setspn is the command line tool that allows us to do this, it is part of the Windows Resource Kit; if you do not already have it installed on your AD controller, you should install it now from the Windows Support Tools CD or download it from the Microsoft website. On the AD server, run the setspn command using the following syntax:
setspn A HTTP/[fully qualified name of Weblogic server] [AD account we wish to link to the service]
and
setspn A HTTP/[short hostname of Weblogic server] [AD account we wish to link to the service]
so in our example scenario, that would be

setspn A HTTP/bieesvr1.xyz2.com bieesvr1 setspn A HTTP/bieesvr1 bieesvr1
You can check what SPNs are associated with your user account, using the command setspn L <account-name>, e.g. setspn -L bieesvr1 will return
Registered ServicePrincipalNames for CN=bieesvr1,CN=Users,DC=xyzcorp,DC=com: HTTP/bieesvr1.xyz2.com HTTP/bieesvr1 It is important to check this as Windows does not handle duplicate or misassigned SPNs well. If the same service is linked to a different account in the AD server, the client will not send a Kerberos ticket to the server. Weblogic Server Configuration
The server hosting the Weblogic server may or may not run on a Windows platform, and may or may not belong to the same internet domain as the KDC and the client browser machine. The important configuration requirements are: The server has to be represented in the Kerberos realm via the principal we defined in the previous section The server needs to be able to access the KDC. The Weblogic server process needs to have access to the credentials of its account in Kerberos. The Weblogic server must be configured to recognize a SPNEGO token in a request.
Configure Weblogic server to find the KDC server
On Windows machines, create a file named krb5.ini, in the C:\Windows directory; on Unix machines, the file is called krb5.conf instead of krb5.ini, and the default location is in /etc/krb5/. It may not be possible in all environments to create
the file at this location, in which case on Linux machines you can point to an alternate location with the environment variable KRB5_CONFIG and for Java command lines the parameter -Djava.security.krb5.conf=<path>/krb5.conf. This file contains the Kerberos configuration information necessary for the Weblogic server to locate and communicate with the Kerberos server and must have these contents: [libdefaults]
default_realm = <Your Kerberos realm remember all caps> default_tkt_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc ticket_lifetime = 600 [realms] <Your Kerberos realm remember all caps> = { kdc = <IP address of the KDC/AD server> admin_server = <host name of the KDC/AD server> default_domain = <Windows domain name in caps> } [domain_realm] .<DNS domain name suffix, starting with .> = <Your Kerberos realm remember all caps> [appdefaults] autologin = true forward = true forwardable = true encrypt = true
So, in our sample scenario, this would look like

[libdefaults] default_realm = XYZCORP.COM default_tkt_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc ticket_lifetime = 600 [realms] XYZCORP.COM = { kdc = 10.221.61.122 admin_server = addc.xyzcorp.com default_domain = XYZCORP.COM } [domain_realm] .xyzcorp.com = XYZCORP.COM [appdefaults] autologin = true forward = true forwardable = true encrypt = true
Create a keytab for your Weblogic server
The next step is to create a keytab file for use on the Weblogic server. For Windows machines this is accomplished with the keytab utility on the Weblogic server, for Unix machines the equivalent is ktpass on the AD domain controller. Ktab is part of the JDK, and you should use the JDK that comes with your Oracle BI EE install. The keytab file produced must be generated or placed in the Weblogic domain directory
Windows
The syntax for ktab on Windows is

ktab.exe k keytab-file-name a account-name@REALM.NAME
(NB realm name must be specified in capitals). So in our example (assuming we have Oracle BI installed at C:\OBI, and a Weblogic domain named bifoundation_domain, which is the default):
C:\OBI\jdk160\bin\ktab.exe C:\OBI\user_projects\domains\bifoundation_domain\bieesvr1.keytab a bieesvr1@XYZCORP.COM k
The ktab utility will prompt you for the password to the account, you should provide the password to the AD account you created for your service principal in the preceding section.
Unix/Linux
NB Unlike in the Windows example where ktab is run on the Weblogic server, for Unix/Linux machines you should run the ktpass command on the AD domain controller as it will both create the keytab and the SPN simultaneously. The syntax for ktpass is slightly different than that used for ktab:
ktpass princ HTTP/<wls-server-name>@<REALM-NAME> -mapuser <account-name> pass password crypto all -ptype KRB5_NT_PRINCIPAL out <keytab-file-name>
(NB again, realm name must be specified in capitals). So in our example scenario we would use
ktpass.exe princ HTTP/bieesvr1.xyz2.com@XYZCORP.COM mapuser bieesvr1 pass password -crypto all -ptype KRB5_NT_PRINCIPAL out C:\bieesvr1.keytab
NB unlike in the Windows example above you should provide the password on the command line. The keytab file must then be copied to the Weblogic server domain directory i.e. in our example scenario:
/opt/obi/user_projects/domains/bifoundation_domain/bieesvr1.keytab
Verify your Kerberos configuration
It is crucial at this specific point to verify that Kerberos is set up properly and that your principal and keytab are valid. If they are not, then there is no point in going further in the process. kinit is a utility provided with the JDK on Windows and as part of the kerberos (or kerberos-tools) package on Linux that can be used to validate your Kerberos configuration. NB at this stage, we are just validating that the server itself can communicate properly with the KDC, i.e. this is machine-level test, not a test of Weblogic config. If your principal was created properly, you should be able to request a TGT (ticket Granting Ticket) from Kerberos using that principal. If the keytab file was generated properly, then you should be able to use this file instead of the password of your account. kinit tests both simultaneously. The syntax is
kinit k t <keytab-file> <account-name>
NB in Unix/Linux, the principal name will be fully qualified in the form HTTP/<wls-server> and the syntax differs slightly in that the V switch should be added or else it will complete silently So, in our example scenario for Windows the synatx is:
C:\OBI\jdk160\bin\kinit k t C:\OBI\user_projects\domains\bifoundation_domain\bieesvr1.keytab bieesvr1
By default, on the Windows platform a cache file named <USER_HOME>\krb5cc_<USER_NAME> will be generated and the output should be something similar to:
New ticket is stored in cache file C:\Documents and Settings\jsmith\krb5cc_jsmith
And for Linux the example syntax would be

kinit V k t /opt/obi/user_projects/domains/bifoundation_domain/bieesvr1.keytab HTTP/bieesvr1.xyz2.com
If you got to this step without any error, then you have successfully configured the KDC. Otherwise, please consult the section on troubleshooting Kerberos configuration.
Configure Weblogic Login Module
JAAS allows dynamic configuration of login modules, so we need to create a JAAS configuration file that specifies the Kerberos login modules. Create a file named krb5Login.conf in the Weblogic domain directory (i.e. in our example scenario this would be at C:\OBI\user_projects\domains\bifoundation_domain\krb5Login.conf) with the following contents:
com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal=<Service principal account>@<Kerberos realm> keyTab=<Name of the keytab file we created, relative to Weblogic domain directory> useKeyTab=true storeKey=true debug=true; };
So, in our example scenario, this would become:

com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal=bieesvr1@XYZCORP.COM keyTab=bieesvr1.keytab useKeyTab=true storeKey=true debug=true; };
Note that we specify just the name of the keytab file as both the keytab file and the krb5Login.conf file are in the Weblogic domain directory. Also note the quotation marks around the principal name these are required.
Next, we need to specify the file location as a startup option in the WLS java command line:
-Djava.security.auth.login.config=krb5Login.conf
and specify the two following additional java options:

-Djavax.security.auth.useSubjectCredsOnly=false -DWeblogic.security.enableNegotiate=true
These settings can be specified in the Weblogic domain environment script which can be found in the bin subdirectory under the Weblogic domain dir. So, in our example scenario, we would edit the file
C:\OBI\user_projects\domains\bifoundation_domain\bin\setDomainEnv.cmd
Find the line that reads:

set JAVA_PROPERTIES=%JAVA_PROPERTIES% %EXTRA_JAVA_PROPERTIES%
and before it, insert this line:

set EXTRA_JAVA_PROPERTIES=-Djava.security.auth.login.config=krb5Login.conf
-Djavax.security.auth.useSubjectCredsOnly=false -DWeblogic.security.enableNegotiate=true Dsun.security.krb5.debug=true %EXTRA_JAVA_PROPERTIES%
N.B. you will, of course, need to restart the Weblogic Admin Server and any/all Managed Servers for these settings to take effect. If your Weblogic server is on Linux and you were not able to place the krb5.conf file in the default location (usually /etc/krb5 in Oracle Unbreakable Linux, but check details if you are using an alternate distribution), you also need to specify the parameter -Djava.security.krb5.conf=<path>/krb5.conf before the %EXTRA_JAVA_PROPERTIES%.
Configure the Single Pass Negotiate Identity Assertion provider
In order to enable Weblogic to extract a SPNEGO/Kerberos ticket from incoming requests, you need to enable the NegotiateIdentityAsserter provider, which will use the login config and keytab file we set up in the previous section to communicate with the Kerberos server. Log in to Weblogic Admin Console Select Security Realms->myrealm, then Providers->Authentication Providers In the Change Centre at the top left, click Lock and Edit, then on the Authentication Providers screen, click New In the New Authentication Provider screen, type in a name for your Asserter and select NegotiateIdentityAsserter from the dropdown box, then click OK
In the Change Centre at the top left, click Activate Changes to save your changes. The changes will not be applied (and so your new Asserter will not be activated) until you restart the Weblogic Admin Server and all Managed Servers Return to the main Authentication Provider screen (Security Realms->myrealm->Providers->Authentication) Click the Reorder button, then select the tickbox next to your NegotiateIdentityAsserter (SPNEGOAsserter in our example), then use the shuttle control to put the NegotiateIdentityAsserter second in the list behind the ActiveDirectoryAuthenticator we configured earlier.
TROUBLESHOOTING KERBEROS/WEBLOGIC SERVER CONFIGURATION
There are a series of config settings on both the KDC and Weblogic Server which all have to be correct in order for the overall WNA/SSO authentication to work, and it is the most likely area to go wrong. Hence in this section, we will attempt to give an overview of some of the tools and techniques you can use to pinpoint likely problem areas.
kinit
kinit is a tool provided with the JDK on Windows or in the kerberos utilities on Linux used to obtain and cache Kerberos ticket-granting tickets and is used to validate that the system on which Weblogic Server is installed can communicate with the KDC. This validates the system-wide krb5.ini file (e.g. C:\Windows\krb5.ini) and the keytab file you have created. The syntax is:
kinit k t <keytab-file> <account-name>
So, in our example scenario:

C:\OBI\jdk160\bin\kinit k t C:\OBI\user_projects\domains\bifoundation_domain\bieesvr1.keytab bieesvr1
By default, on the Windows platform a cache file named <USER_HOME>\krb5cc_<USER_NAME> will be generated and the output should be something similar to:
New ticket is stored in cache file C:\Documents and Settings\jsmith\krb5cc_jsmith
(On Unix platforms a cache file named/tmp/krb5cc_<uid> will be generated. <uid> is the user identification number of the user logged into the system.) On Windows, you can also run kinit with a debug option, and get extensive Kerberos debugging information, by running the Kinit class with debug options (the kinit binary is simply a wrapper to invoke the class). In our example scenario, this would look like:
C:\OBI\jdk160\bin\java.exe -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Kinit
This will generate a much more verbose output, with Kerberos debugging information so that if you do not get the expected New ticket is stored in message, you should run the Kinit debug class shown above for information as to what failed and why.
klist
klist is also supplied with the JDK on Windows or in the kerberos utilities on Linux and is a very useful tool for displaying (and if necessary purging) tickets already granted and cached in communicating with the KDC. It can be useful for purging old tickets (e.g. if you have changed your keytab or config settings and want to make sure youre not still using old cached tickets) and ensuring that the tickets you have been getting are related to the correct service name. It is equally useful on both the Weblogic server and on the client machine from which youre trying to authenticate using SSO. The syntax is:
<path to JDK>/bin/klist (e.g. C:\OBI\jdk160\bin\klist.exe)
to just list the current login tickets, or with the purge option to delete them e.g.:
C:\OBI\jdk160\bin\klist.exe purge
Sample output from klist run without the purge flag (i.e. in simple list mode) on a client machine might look like this:
Current LogonId is 0:0x71c30 Cached Tickets: (3) #0> Client: bjones @ XYZCORP.COM Server: krbtgt/XYZCORP.COM @ XYZCORP.COM KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent Start Time: 12/6/2010 4:27:22 (local) End Time: 12/6/2010 14:27:22 (local) Renew Time: 12/13/2010 4:27:22 (local) Session Key Type: RSADSI RC4-HMAC(NT)
#1>
Client: bjones @ XYZCORP.COM Server: HTTP/bieesvr1 @ XYZCORP.COM KerbTicket Encryption Type: Kerberos DES-CBC-MD5 Ticket Flags 0x40a00000 -> forwardable renewable pre_authent Start Time: 12/6/2010 4:36:55 (local) End Time: 12/6/2010 14:27:22 (local) Renew Time: 12/13/2010 4:27:22 (local) Session Key Type: Kerberos DES-CBC-MD5 Client: bjones @ XYZCORP.COM Server: LDAP/addc.xyzcorp.com/xyzcorp.com @ XYZCORP.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate Start Time: 12/6/2010 4:27:23 (local) End Time: 12/6/2010 14:27:22 (local) Renew Time: 12/13/2010 4:27:22 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96
#2>
Like kinit, klist can also be run as a Java class on Windows, to enable verbose debug output:
C:\OBI\jdk160\bin\java.exe -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Klist
It can also be used to list the entries in a keytab file e.g.

klist -k bieesvr1.keytab Keytab name: FILE: /opt/obi/user_projects/domains/bifoundation_domain/bieesvr1.keytab KVNO Principal ---- -------------------------------------------------------------------------3 HTTP/bieesvr1 @ XYZCORP.COM 3 HTTP/bieesvr1 @ XYZCORP.COM
Kinit errors:
Cannot contact any KDC for requested realm while getting initial credentials
Your computer successfully sent out a request, but the KDC never responded. The network is probably down between your host and the KDC, or you are behind a firewall. Double-check the KDC settings in the krb5.ini (krb5.conf) file.
javax.security.auth.login.LoginException: KrbException:: Pre-authentication information was invalid (24) - Preauthentication failed
The principal exists in Kerberos but the password is wrong. This is a password problem. Double-check the validity of your keytab, or of the password that you have entered. If you are confident about your password, refreshing the password for the user in the AD server may solve the problem. (By right clicking on the user in AD user manager, selecting Reset Password and re-entering the same password specified earlier). Another reason for that problem to happen is if another principal with the same short name exists in the AD server (i.e. different DNs but same CN). This is likely to happen if the host that runs WLS already belongs to the network domain, then it will have an account in the Computers section, and a password there too. In that case, you will run into SPN issues as well. The best way out of this is to create a new user account, with a different CN, and map the HTTP SPN to the new account, (and remove the SPN from any other account).
Exception: krb_error 0 Cannot retrieve key from keytab for principal xxx No error
The keytab file you have provided was not created for that principal, or there is no such file (this will be easy to check). If the file does exist, either the principal does not exist in the AD server or this keytab is not for the specified principal. In order to verify this, run the command without a keytab: kinit xxx (where xxx is the name of your principal). It will prompt you for a password; enter the password you believe to be correct for the principal. If the answer is :Exception: krb_error 6 Client not found in Kerberos database (6), then the principal does not exist at all. If the answer is: Exception: krb_error 24 Pre-authentication information was invalid (24), then the principal exists but the password is incorrect. If the answer is : New ticket is stored in cache file Then the password you know is correct, and probably the keytab file you have provided in the previous command is invalid, or belongs to a different principal.
javax.security.auth.login.LoginException: KrbException: KDC has no support for encryption type (14)
Your KDC does not support the encryption type requested. Typically, the encryption type is specified in the krb5.ini (or krb5.conf in Unix) Kerberos configuration file. Please choose an encryption type that is supported by the KDC you are using. The common encryption types are : DES_CBC_MD5 and DES_CBC_CRC. The default encryption type entries, default_tkt_enctypes and default_tgs_enctypes are optional. However, if the Kerberos client receives an encryption type error, set the default encryption type to either DES-CBC-MD5 or DES-CBC-CRC on both sides of the dialog. If your Active Directory Domain Controller is on Windows Server 2008, DES encryption is disabled by default, so you will need to explicitly enable it as noted in the section Enabling DES Encryption on Windows Server 2008 R2 above.
SPN issues
If your Weblogic server log shows the following:

<Apr 26, 2005 1:29:12 PM PDT> <Debug> <SecurityDebug> <000000> <Found NTLM token when expecting SPNEGO> It means that the Weblogic server was ready to extract a SPNEGO token but could not find one in the request sent by the browser. There are two likely explanations:
The browser is not set up correctly to send a SPNEGO token please see the next section on browser configuration. Something is wrong in your SPN definition. Either no SPN was defined for this service, or you have duplicate SPNs, which means that the SPN resolved in more than one principal associated with it. You can verify this by typing:
LDIFDE -d DC=yourdomain ,DC=com -f c:\export.txt
This will export the list of AD objects to the file export.txt. Then look for your service (HTTP/<WLS-host>) in the values of the attribute ServicePrincipalName. If it shows more than once or not at all, you need to rectify the problem. Please see the suggestions from Microsoft support: http://technet.microsoft.com/en-us/library/cc772897(WS.10).aspx
Weblogic Login Module errors
Once we have established that the system itself can login to/communicate with the KDC, there may still be errors in the krb5Login.conf file that we placed in the Weblogic domain directory. The most common manifestation of this is an error message in the Weblogic server logs:
Exception: Weblogic.security.providers.utils.NegotiateTokenException: GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)
This is a catch-all exception that covers anything that might have gone wrong during the process of the WLS server loading the JAAS configuration from the krb5Login.conf file to reading the keytab and successfully decoding the SPNEGO ticket. So there can be many reasons why you would get this exception. Usually there will be reason nested somewhere in the stack trace, such as:
Caused by: javax.security.auth.login.LoginException: No LoginModules configured for com.sun.security.jgss.accept
The cause can give a little more information regarding when in the process something went wrong. In the example above, the LoginModuleConfiguration was not successful, so you need to look for problems in krb5Login.conf. Common reasons for this error include: The krb5Login.conf file could not be found or opened Double check the way you have specified it to WLS, double check existence and permissions. Some wrong syntax inside the krb5Login.conf This type of problem will not be reported in detail, but as a consequence, the JAAS login configuration will not be loaded, and the exception will be thrown. Go over each and every word of the krb5Login.conf file, and compare it to the one specified in this document.
Other causes can be an invalid or inexistent keytab file, mismatch in encryption types, but most of these would have been discovered at the kinit phase. So, the most probable cause for this exception is around the krb5Login.conf file.
STAGE 3: CONFIGURE BI FOR SSO Configure BI Analytics App to request SPNEGO Authentication
Finally on the Weblogic server, we need to change the deployment descriptors for the BI analytics application to apply a security constraint so that it will request the SPNEGO/Kerberos authentication information. Locate the analytics.ear in your Oracle BI Home directory. This will be <Oracle BI Install Dir>/Oracle_BI1 (or whatever you chose to name your Oracle BI Home on install)/bifoundation/analytics.ear. So in our example scenario, this would be located at:
C:\OBI\Oracle_BI1\bifoundation\jee\analytics.ear
Make a backup copy of the ear file so that you have a restore point to refer back to (and revert to) if needed Unpack the analytics.ear file to a temporary location, using the Java jar tool. Use the command line options xvf to extract the contents to the current working directory (e.g. C:\OBI\jdk160\bin\jar xvf C:\OBI\Oracle_BI1\bifoundation\jee\analytics.ear), so you will probably want to create a temporary directory to hold the unpacked contents and change into that directory before running the command. The ear contains a META-INF directory and two war files, analytics.war and analytics-ws.war In the META-INF directory, there is a MANIFEST.MF file, add the following line to the end of the file:
Weblogic-Application-Version: 11.1.1
Unpack the analytics.war file to a second temporary location, it contains a default.jsp file and five top-level directories, one of which is called WEB-INF. Create a new deployment descriptor file in WEB-INF called weblogic.xml. It should contain the following:
<?xml version="1.0" encoding="windows-1252"?> <weblogic-web-app xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app"> <context-root>analytics</context-root> <security-role-assignment> <role-name>SSORole</role-name> <principal-name>BIUsers</principal-name> <principal-name>BIAdmins</principal-name> </security-role-assignment> </weblogic-web-app>
The name of the role is not important, so long as it is consistent in this file and in sections we will add in the web.xml file in the next step. The principal name element(s) should refer to the Active Directory groups (not Application Roles) you wish to allow access to the application. NB all BI users will need to be members of at least one of the these groups. Also, in the WEB-INF directory, you will find an existing file called web.xml. Edit web.xml and look for a section like this:
<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>
Replace this section with the following:

<security-constraint> <web-resource-collection> <web-resource-name>BI Analytics</web-resource-name>
<url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>SSORole</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <role-name>SSORole</role-name> </security-role>
The name of the role is not important, so long as it is consistent in this file and in the Weblogic.xml file. Once you have edited both files, repackage the analytics.war file, again using the jar tool, and, in turn, repackage that back into the analytics.ear file.
Next we need to redeploy the analytics.ear file to Weblogic so that the new security constraint will come into effect. Log into Weblogic Admin Console and click on Deployments In the Change Centre at the top left, click Lock and Edit Find the analytics app and click the tickbox next to it, then click on the Update button
In the Update Application Assistant screen, make sure the deployment path is the same as the ear file you just updated, if not change the path
Click Next, then Finish In the Change Centre at the top left, click Activate Changes to save your changes. If you have not already done so, restart the Weblogic Admin Server and all Managed Servers
Configure BI for SSO
Finally, we must tell the core BI Application to accept SSO-authenticated clients from Weblogic. Log in to Oracle Enterprise Manager (e.g. http://bieesvr1:7001./em/) In the menu on the left hand side select Farm-> Business Intelligence -> coreapplication Then on the main screen, select the Security tab Click Lock and Edit Configuration in the Change Centre section at the top of the screen Tick the Enable SSO tickbox and select Windows Native Authentication in the dropdown
Click Apply at the top right of the Security screen Click Activate Changes in the Change Centre
STAGE 4: CONFIGURING CLIENT MACHINES
The final stage is to configure the browser on the client machine(s) you will use to access your Oracle BI EE system via SSO. N.B. users must be logged into the AD domain on the client machine they should then be able to simply access the system via their browser with no further authentication required
Configure the client for single sign on
Internet Explorer
Go to Tools --> Internet Options Select the "Security" tab Click on "Local Intranet" Icon. This will enable the "Sites" button. Click "Sites" button. This will show a "Local Intranet" Popup. Make sure the option "Include all local (intranet) sites not listed in other zones" option selected. (Windows XP Only). Click on "Advanced" Button. In the new popup window add the URL for the machine hosting Weblogic. Click OK to save your settings. In the "Security" tab, Click "Custom Level" button. In the "Security Settings" dialog, under "User Authentication" section, make sure "Automatic logon only in Intranet zone" option is selected. Click OK to save your settings. Go to "Connections" tab ---> LAN Settings. If you have a proxy server enabled, click on "Advanced" button. Make sure you add the URL for the machine hosting Weblogic in the "Exceptions" box. In the "Internet Options ---> Advanced" tab, make sure "Enable Integrated Windows Authentication (requires restart)" option is checked. Click "OK". (If this option is not selected previously, you need to close all browser instances for the setting to take effect).
Firefox
To configure a Firefox browser to use Windows Integrated Authentication, complete the following steps: Start Firefox. Enter about:config in the Location Bar. Enter the filter string network.negotiate. Set the preferences as shown below
Preference Name
network.negotiate-auth.allow-proxies network.negotiate-auth.delegation-uris
Status
default user set
Type
boolean string
Value
true http://,https://
Preference Name
network.negotiate-auth.gsslib network.negotiate-auth.trusted-uris network.negotiate-auth.using-native-gsslib
Status
default user set default
Type
string string boolean
Value <blank>
http://,https:// true
Additional settings for SSL with IE8/Windows 7
If your BI web application is protected by SSL and your client is using either Internet Explorer 8 or Windows 7, you may be affected by a compatibility issue between the Microsoft Extended Protection for Authentication Security Update and the Java Virtual Machine shipped with Oracle BI 11.1.1.3.0. If you find that you can access the SSL-protected app from IE7 but not from clients using IE 8 or Windows 7, you can either roll back those client to IE7 or else follow the instructions in this technote from Microsoft:
http://support.microsoft.com/?scid=kb%3Ben-us%3B968389&x=10&y=18 Specifically, the setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection
must be present and set to a decimal value of 3 on clients using Windows 7/Internet Explorer 8 that are affected by this issue.
Troubleshooting the client and 401 errors
Unfortunately, after the stage of testing your server can communicate with the KDC, theres no point testing you can do until you get to the stage of actually pointing a client at the BI web app and seeing what happens. If it works, youll be authenticated and logged in to the application without having to sign in. If it doesnt your likely to see an error message saying Error 401: Unauthorized. This means exactly what it says youre not authorised to access the web application. The question is why if the SSO setup was all working, you should have just gone straight in. Essentially, if you experience this error, but you have validated your keytab is good and the server can communicate with the KDC using kinit, then the issue lies in one of the steps in between. The following are probable causes (N.B. specific troubleshooting steps are covered in their respective sections): 1.
The Weblogic Kerberos config file is incorrect so that although kinit verifies your machine can authenticate with the AD server, Weblogic cannot. Recheck the settings in krb5login.conf, and setDomainEnv.cmd (see section above entitled Configure Weblogic Login Module) Your client is not correctly configured - have you added the Weblogic server URL (e.g. http://: bieesvr1.xyz2.com:9704/analytics/) to the Intranet zone and set the Automatic logon in Intranet zone setting? (see the section above entitled Configure the client for single sign-on) You're not logged into the AD domain on the client - you need to login to Windows on the client machine as an account in your AD domain (e.g. XYZCORP\jsmith) Your user account is not a member of the group(s) you specified in the principal element(s) in weblogic.xml. N.B. these groups must exist in the AD domain (see section above entitled Configure BI Analytics App to request SPNEGO Authentication)
2.
3. 4.
REFERENCES
[1] Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1) http://download.oracle.com/docs/cd/E14571_01/bi.1111/e10543/toc.htm [2] Configuring Single Sign-On with Microsoft Clients http://download.oracle.com/docs/cd/E12839_01/web.1111/e13707/sso.htm [3] Java GSS-API Troubleshooting Guide http://download.oracle.com/javase/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html [4] Microsoft support note on enabling DES encryption on Windows 2008 and Windows 7 http://support.microsoft.com/kb/977321 [5] Microsoft TechNet setspn overview http://technet.microsoft.com/en-us/library/cc773257(WS.10).aspx [6] Securing Oracle Weblogic Server http://download.oracle.com/docs/cd/E14571_01/web.1111/e13707/toc.htm
Configuring authentication and SSO with Active Directory and Windows Native Authentication in Oracle Business Intelligence Enterprise Edition November 2010 Author: Paul Davis Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Copyright 2010, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Obi Sso

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Obi Sso

Загружено:

Авторское право:

Доступные форматы

Configuring authentication and SSO with Active Directory and Windows Native Authentication in Oracle Business Intelligence Enterprise

No table of contents entries found.

STAGE 1: USING ACTIVE DIRECTORY AS A USER STORE

for the Users Base DN and

user CN=Builtin,DC=xyzcorp,DC=com objectguid

Required New Setting

(&(AnOtherGroupAttr=*)(|(object class=groupofUniqueNames)(obje ctclass=orcldynamicgroup))) (|(&(AnOtherGroupAttr=%g)(objec tclass=groupofUniqueNames))(&( uid=%g)(objectclass=orcldynami cgroup)))

TROUBLESHOOTING ACTIVE DIRECTORY AUTHENTICATION

STAGE 2: WINDOWS NATIVE AUTHENTICATION SINGLE SIGN-ON WITH KERBEROS

The Client machine

The WLS server

The KDC (AD domain controller)

The KDC Configuration

Define a Service Principal Name for the service

so in our example scenario, that would be

Configure Weblogic server to find the KDC server

So, in our sample scenario, this would look like

Create a keytab for your Weblogic server

The syntax for ktab on Windows is

Verify your Kerberos configuration

And for Linux the example syntax would be

So, in our example scenario, this would become:

and specify the two following additional java options:

Find the line that reads:

and before it, insert this line:

-Djavax.security.auth.useSubjectCredsOnly=false -DWeblogic.security.enableNegotiate=true Dsun.security.krb5.debug=true %EXTRA_JAVA_PROPERTIES%

TROUBLESHOOTING KERBEROS/WEBLOGIC SERVER CONFIGURATION

So, in our example scenario:

It can also be used to list the entries in a keytab file e.g.

If your Weblogic server log shows the following:

<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>

Replace this section with the following:

Configure BI for SSO

STAGE 4: CONFIGURING CLIENT MACHINES

Additional settings for SSL with IE8/Windows 7

Вам также может понравиться