Section 1.4.1, Configuring Protected Resource for a SharePoint Server
Section 1.4.2, Configuring a Protected Resource for a SharePoint Server with an ADFS Server
Section 1.4.3, Configuring a Protected Resource for Outlook Web Access
Section 1.4.4, Configuring a Protected Resource for a Novell Teaming 2.0 Server
You can protect a SharePoint server as a domain-based or a path-based multi-homing resource on the Linux Access Gateway Appliance. When you protect a SharePoint server on Linux Access Gateway, you might see issues with rewriting if the published DNS name is not the same as the DNS name of the original server. Also, if you access SharePoint folder by using non-browser clients such as Microsoft Network Place, Nautilus in SUSE Linux Enterprise Server (SLES), or the MAC finder, you might see issues because these WebDAV clients do not support 302 redirection for authentication. You must modify the authentication procedure to prevent redirection on initial authentication or redirection to Identity Server when the user session expires.
For more information on how to configure a protected resource for a SharePoint server, see Novell Cool Solutions.
If your SharePoint server is configured to use an ADFS server and you want to create a protected resource for the SharePoint server, you need to configure the following Access Manager features. The instructions assume that you have a functioning SharePoint server and a functioning Access Manager system:
ADFS requires a different format for a contract URI than the format used in the default contracts. It expects the URI to conform to the format of a URL. You need to create a custom contract.
In the Administration Console, click
> > > > >Click
, then fill in the following fields:Display name: Specifies the name of the authentication contract.
URI: Specifies a value that uniquely identifies the contract from all other contracts. No spaces can exist in the URI field. For SharePoint, specify the following format for the URI:
https://<baseurl>/name/password/uri
Replace <baseurl> with the base URL of your Identity Server. If the DNS name of your Identity Server is idp-50.amlab.net, the URI would have the following format:
https://idp-50.amlab.net:8443/nidp/name/password/uri
Methods and Available Methods: Move a name/password method to the
list. We recommend , but you can use .Do not configure a password expiration servlet. This contract is going to be used with non-redirected login, which prevents all redirection, including redirection to a password expiration service.
For more information on the other options, see Configuring Authentication Contracts
in the Novell Access Manager 3.1 SP2 Identity Server Guide.
Click
.Configure a card for the contract by filling in the following:
Text: Specify the text that is displayed on the card to the user.
Image: Specify the image to be displayed on the card. To use an existing image, select an image from the drop-down list. To add an image to the list, click
.Show Card: Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.
Click
, then .Update the Identity Server and the Access Gateway.
Continue with Creating a Reverse Proxy Service.
In the Administration Console, click
> > >In the
section, click .Fill in the following fields:
Proxy Service Name: Specify a display name for the proxy service that the Administration Console uses for its interfaces.
Multi-Homing Type: Select
as the multi-homing method that the Access Gateway should use to identify this proxy service.Published DNS Name: Specify the DNS name you want the public to use to access the SharePoint server. This DNS name must resolve to the IP address you set up as the listening address.
If the DNS name of the reverse proxy is the same as the DNS name of the SharePoint server, no rewriting configuration is required. If they are different, there is a high probability that the application will respond incorrectly to user requests.
Web Server IP Address: Specify the IP address of the IIS Web server with the SharePoint server.
Host Header: Select the
option.Web Server Host Name: Specify the DNS name of the SharePoint server that the Access Gateway should forward to the Web server.
For more information on creating a reverse proxy, see Section 1.1, Managing Reverse Proxies and Authentication
Click
.Continue with Configuring Multiple Protected Resources.
If your SharePoint server has been configured for multiple domains, you need to create three protected resources to enable single sign-on. The server has two ways to access the home page. You need to create a protected resource for each of these paths, and then a protected resource for the other pages. These protected resources should have a configuration similar to the following:
SharePoint Page |
URL Path |
Contract |
Authentication Procedure |
---|---|---|---|
home page |
default.aspx |
custom |
Normal |
root |
/ |
custom |
Normal |
all others |
/* |
custom |
Non-redirected login |
For single sign-on, all the protected resources need to specify the same contract. When assigning the contract for the /* resource, the contract needs to be configured to use non-redirected login for its authentication procedure. When a user first accesses the SharePoint server, the users are directed either to the home page or the root of the server. From either of these locations, the users can be redirected to the Identity Server for authentication. After the users have authenticated and the SharePoint server requests authentication for access to any of the other pages, these pages need to be configured to use non-redirected login.
In the
, click the name of the Proxy Service you created, then click .To create a protected resource for the home page:
In the homepage, then click .
, click , specify a name such asFor the home page of the SharePoint server, specify the following values:
Authentication Procedure: Select the custom contract you created.
URL Path: Click /* and replace it with default.aspx, then click twice.
To create a protected resource for the root page:
In the root, then click .
, click , specify a name such asFor the root of the SharePoint server, specify the following values:
Authentication Procedure: Select the custom contract you created.
URL Path: Click /* and remove the asterisk, then click twice.
To create a protected resource for all other pages:
In the allothers, then click .
, click , specify a name such asFor all other pages of the SharePoint server, specify the following values:
Authentication Procedure: Select the custom contract you created.
URL Path: Leave the default value.
Click the
icon on the line.Click the name of your custom contract, then fill in the following:
Non-Redirected Login: Select this option.
Realm: Specify a name that your users associate with the SharePoint server. This name is displayed when the user needs to reauthenticate.
For more information about this feature, see Section 1.3.2, Configuring an Authentication Procedure for Non-Redirected Login.
Click
three times.In the
, you should have three protected resources that use the same Authentication Procedure.For information on configuring protected resources, see Section 1.3.1, Setting Up a Protected Resource.
Click
, then update the Access Gateway.(Conditional) If you have limited your users to one session, modify this limitation:
Click
> >Increase the value of the
option.Click
, then update the Identity Server.If you want to protect your Outlook Web Access server with the Access Gateway Appliance, you need to configure the following Access Manager features. The instructions assume that you have a functioning Outlook Web Access server and a functioning Access Manager system:
The following instructions assume that you have a basic setup with at least one reverse proxy and proxy service. If you don’t have this basic setup, see Section 1.1, Managing Reverse Proxies and Authentication and complete a basic setup before continuing.
In the Administration Console, click
> > .In the
section, click .Specify a name for the proxy service, then click
.Click the newly added proxy service. Fill in the fields:
Proxy Service Name: Specify a display name for the proxy service, which the Administration Console uses for its interfaces.
Published DNS Name: Specify the DNS name you want the public to use to access your site. This DNS name must resolve to the IP address you set up as the listening address.
Multi-Homing Type: Select the multi-homing method that the Access Gateway should use to identify this proxy service.
Web Server IP Address: Specify the IP address of the IIS Web server.
Host Header: Select the
option.Web Server Host Name: Specify the DNS name of the Outlook Web Access server that the Access Gateway should forward to the Web server.
Click
.Continue with Configuring an Authentication Procedure.
Click
> > > .Click
, then specify a display name for the resource.(Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting this resource.
Select an authentication contract. If you want to enable non-redirected login, select
as the authentication contract.(Optional) If you want to enable non-redirected login, click the
icon, then click the contract that you have added to specify the following information:Non-Redirected Login: Select the option to enable non-redirected login.
Realm: Specify the security realm configured for the IIS server running the Outlook Web Access server.
To check the security realm configured for the IIS server, open the IIS Administration Console, right-click the Outlook Web Access Server the Access Gateway is protecting, then select
. The tab contains the field.Create protected resource:
In the root, then click .
, click , specify a name such asSpecify the following values:
Authentication Procedure: Select the contract you created.
URL Path: Make sure that /* is selected. If you have configured Outlook Web Access as a path-based service, then click the URL path and add the path name of the service. For example, /owa/*, where owa is the path name.
Click
twice.Create a second protected resource:
In the
, click , specify a unique name, then click .Specify the following values:
Authentication Procedure: Do not select any authentication procedure because the URL path is a public resource.
URL Path: Specify /exchweb/*as the URL path. If you have configured Outlook Web Access as a path-based service, click the URL path and add the path name of the service. For example, /owa/exchweb/*, where owa is the path name.
Click
twice.Click
.In the
, ensure that the protected resource you created is enabled.If you want to enable single sign-on, then configure Identity Injection or Form Fill policy, depending on the Outlook Web Access configuration. For more information, see Configuring Identity Injection.
Continue with Configuring a Rewriter Profile.
In the Administration Console, click
> > > > > .Click
in the .Configure a Word profile:
Specify a name for the profile, select
as the search boundary, then click .Click value.
in the section, then specifyClick
.Select
.Select
Select
.Make sure that
remains selected.(Optional) If you have configured the path-based multi-homing service, do the following:
Add the following content types for the
option in the Word profile:text/x-component
extension/htc
Configure the following options for
:Specify /exchange and as $path/exchange
asSpecify /exchweb and as $path/exchweb
asTo save your changes to browser cache, click
.Use the up-arrow button to move your profile to the top of the
.To apply your changes, click the
link, then click > .You must configure an Identity Injection policy in order to enable single sign-on with the Outlook Web Access server that has basic authentication configured. This Identity Injection policy should be configured to inject an authentication header. For information on creating this policy, see Configuring an Authentication Header Policy
in the Novell Access Manager 3.1 SP2 Policy Guide.
The following sections explain how to configure the Access Gateway with a domain-base multi-homing service. The instructions assume that you have a functioning Novell Teaming 2.0 server on Linux and a functioning Access Manager system (3.1 SP1 IR1 or higher) with a reverse proxy configured for SSL communication between the browsers and the Access Gateway.
The Teaming server needs to be configured to trust the Access Gateway to allow single sign-on with Identity Injection and to provide simultaneous logout. You also need to create an Access Gateway proxy service and configure it.
For information on other possible Access Gateway configurations, see “Teaming 2.0: Integrating with Linux Access Gateway”.
To use Teaming as a protected resource of an Access Gateway and to use Identity Injection for single sign-on, the Teaming server needs a trusted relationship with the Access Gateway. With a trusted relationship, the Teaming server can process the authorization header credentials. The Teaming server accepts only a simple username (such as user1) and password in the authorization header.
This section explains how to set up the trusted relationship and how to enable simultaneous logout, so that when the user logs out of Teaming, the user is also logged out of the Access Gateway.
To configure the trusted relationship:
Log in to the Teaming server.
Stop the Teaming server with the following command:
/etc/init.d/teaming stop
Run the installer-teaming.linux script.
Follow the prompts, then select
.Follow the prompts, then select
.Follow the prompts, selecting the defaults until the Yes.
option appears, then typeIn the
section, include the IP address of the Access Gateway that is used for the connection to the Teaming server.If the Access Gateway is part of a cluster, add the IP address for each cluster member. Wildcards such as 164.99.*.* are allowed.
When you specify IP addresses in this option, Teaming logins are allowed only from the specified addresses. Also, if Authorization header credentials are not present or are incorrect, the user is prompted for login using Basic Authentication.
When prompted for the Logout URL, specify the URL of the published DNS name of the proxy service plus /AGLogout.
For example, if the published DNS name of the proxy service is teaming.doc.provo.novell.com, specify the following URL:
https://teaming.doc.provo.novell.com/AGLogout
When you are prompted to use the Access Gateway for WebDAV connections, type No.
Follow the prompts to complete the reconfiguration process.
Start the Teaming server with the following command:
/etc/init.d/teaming start
Continue with Configuring a Domain-Based Multi-Homing Service for Novell Teaming.
The following instructions describe how to set up a domain-based service to protect the Teaming server. In this example, the published DNS name of the service is teaming.doc.provo.novell.com. Users would access the Teaming server with a URL similar to http://teaming.doc.provo.novell.com/teaming. The /teaming path is the default access path for the Teaming application.
To configure a domain-based service for Teaming, complete the following tasks:
In the Administration Console, click
> > > .In the
, click , then fill in the following fields:Proxy Service Name: Specify a display name for the proxy service that the Administration Console uses for its interfaces.
Multi-Homing Type: Select
.Published DNS Name: Specify the DNS name you want the public to use to access your site. This DNS name must resolve to the IP address you set up as the listening address. For example, teaming.doc.provo.novell.com.
Web Server IP Address: Specify the IP address of the Novell Teaming server.
Host Header: Select the
option.Web Server Host Name: Specify the DNS name of the Teaming server.
Click
.Click the newly added proxy service, then select the
tab.Change the
to 8080.If the Teaming server has port forwarding enabled, you do not need to change from the default port 80.
Click
.Change the value of
option to 1200 seconds.This longer timeout is needed for file uploads.
Click
.Continue with Configuring Protected Resources.
You need to create two protected resources, one for HTML content and one for WebDAV and AJAX content.
Click
> > > .Create a protected resource for HTML content:
In the
, click , specify a name, then click .(Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting this resource.
Specify a value for
For example, select the contract.In the /* path and add the following two paths:
, remove the/teaming/* /ssf/*
Click
.Create a protected resource for WebDAV and AJAX content:
In the
, click , specify a unique name, then click .(Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting this resource.
Click the
icon.In the
, click , specify a name, then click .Fill in the following fields:
Contract: Select the
contract, which is same contract that you selected for the HTML content protected resource.Non-Redirected Login: Select this option.
Realm: Specify a name that you want to use for the Teaming server. This name does not correspond to a Teaming configuration option. It appears when the user is prompted for credentials.
Redirect to Identity Server When No Authentication Header is Provided: Deselect this option.
Click
twice.For the Authentication Procedure, select the procedure you just created.
In the /* path and add the following two paths:
, remove the/ssfs/* /ssf/a/do?* /ssf/rss/*
The /ssfs/* path is for WebDAV content, the /ssf/a/do?* path is for AJAX content, and the /ssf/rss/* path enables non-redirected login for RSS reader connections.
Click
.In the
, ensure that the protected resources you created are enabled.To apply your changes, click
> , then click .Continue with Configuring a Rewriter Profile.
In the Administration Console, click
> > > > > .In the
, click .Specify a name for the profile, select
as the search boundary, then click .In the
section, click , then specify the following type:application/rss+xml
In the
section, click , then specify the following as the variable to search for:value
Click
.Make sure that
remains selected.Click
.In the
, move the Word profile you created to be the first profile in the list, and move the default profile to be the second profile in the list.Click
.To apply your changes, click
> , then click .Continue with Creating a Pin List.
The Access Gateway needs to be configured to bypass the published URL of the proxy service:
In the Administration Console, click
> >Click
in the configuration page.Click teaming.doc.provo.novell.com.
, then specify the published DNS name of the proxy service. For example,Select
as the Pin type.Click
.To save the configuration changes, click
> , then click .Continue with Configuring Single Sign-On.
You must configure an Identity Injection policy to enable single sign-on with the Novell Teaming server. This Identity Injection policy should be configured to inject the authentication credentials into the authorization headers.
In the Administration Console, click
> .Select the policy container, then click
.Specify a name for the policy, select
for the type, then click .(Optional) Specify a description for the injection policy. This is useful if you plan to create multiple policies to be used by multiple resources.
In the
section, click , then select .Fill in the following fields:
User Name: Select
> .Password: Select
> .Click
.To save the policy, click
, then click .For more information on creating such a policy, see Configuring an Authentication Header Policy
in the Novell Access Manager 3.1 SP2 Policy Guide.
Assign this policy to the protected resources:
Click
> > > .Click the name of the teaming proxy service, then click the
tab.For each teaming protected resource, click the
link, select the Identity Injection policy, click , then click .Click
To save the configuration changes, click
> , then click .