Multiple Realm Authentication use cases

Security > Proxy user authentication > Multiple realm authentication > Multiple Realm Authentication use cases

Multiple Realm Authentication use cases

Help | Content Gateway | Version 7.7.3

Use case 1: Domain acquired; explicit proxy

Use case 2: Internal domain added; explicit proxy

Use case 3: Temporary domain added; transparent proxy

See, also: Authentication based on User-Agent

Use case 1: Domain acquired; explicit proxy

This describes a common case in which a second domain is added to an existing, single-domain environment.Content Gateway is an explicit proxy; clients use a PAC file.

An organization—let's call them Quality Corp—uses a software installation of Content Gateway. They have one domain (QCORP), and one domain controller. They use NTLM to authenticate users.

Quality Corp acquires New Corp who has their own domain (NCORP) and domain controller. They use LDAP to authenticate users.

Quality Corp would like to manage the combined employees in a single domain, but isn't ready to make the infrastructure changes. Until they are, they would like to have a separate use policy for New Corp users (i.e., not use the "default" user on the QCORP domain).

The Multiple Realm Authentication feature makes this possible.

To configure the solution, Quality Corp would:

1.	Enable Multiple Realm Authentication.

2.	Add a second, non-default HTTP port (Configure > Protocols > HTTP). This port will be used by all members of NCORP.

3.	Create a PAC file for members of NCORP that causes them to connect to Content Gateway on the new, second port.

4.	Create Multiple Realm Authentication rules, one each for the QCORP and NCORP domains:

a.	Define an NCORP rule for connections on the second port. Specify in the Advanced Settings area that the user to use for policy determination is the static string "NCorpUser".

b.	Define the QCORP rule to handle all other connections.

5.	Add "NCorpUser" to the QCORP domain as a valid user and create policy for that user in TRITON—Web Security.

At this point, everyone connecting to Content Gateway from NCORP is authenticated against the NCORP domain controller and gets the group policy associated with NCorpUser. Note that no individual user-based policy or features, such as quota time, are possible in this scenario. Transactions are logged as NCorpUser. This is all performed with no effect on the authentication, policy, or logging of users on the QCORP domain.

Use case 2: Internal domain added; explicit proxy

This describes a common case in which a second domain is added to an existing, single-domain environment. Content Gateway is an explicit proxy; clients use a PAC file.

An organization—let's call it BigStars—uses a software installation of Content Gateway. They have one domain (BIG), and one domain controller. They use NTLM to authenticate users.

A group in the company converts to Apple computers, which can't be authenticated with NTLM. The IT group installs an LDAP server and creates a new domain—BIGAPL—for the Apple users.

Because this group of users previously existed and was managed on the primary domain (BIG), the IT department expects that both user-based policy and logging still apply.

The Multiple Realm Authentication feature makes this possible.

To configure the solution, BigStars would:

1.	Verify that every user in BIGAPL is also in BIG with the exact same user name.

2.	Enable Multiple Realm Authentication.

3.	Add a second, non-default HTTP port (Configure > Protocols > HTTP). This port will be used by all members of BIGAPL.

4.	Create a PAC file for members of BIGAPL that causes them to connect to Content Gateway on the new, second port.

5.	Create Multiple Realm Authentication rules, one each for the BIGAPL and BIG domains.

a.	Define the BIGAPL rule for connections on the second port.

b.	Define the BIG rule to handle all other connections.

At this point, all members of BIGAPL are authenticated with LDAP, but maintain their individual policy as specified by their existing NTLM identities. Logs and reports also refer to that same user.

Use case 3: Temporary domain added; transparent proxy

This describes a common case in which a second, special-purpose domain is added to an existing, single-domain environment. Content Gateway is a transparent proxy using WCCP v2.

An organization—let's call it Creative Corp—uses a software installation of Content Gateway. They have one domain (CCORP), and one domain controller. They use NTLM to authenticate users.

Creative Corp is about to launch a new product and wants to make a big splash. They decide to have an open house complete with kiosks, demonstrations, and presenters. The kiosks only need the default Internet policy to properly demonstrate the new product. The IT manager wants to keep the kiosk network as walled off from the corporate intranet as possible. In this scenario, logging individual users isn't a requirement.

The Multiple Realm Authentication feature makes this possible.

To configure the solution, Creative Corp would:

1.	Build a new, temporary network complete with its own domain controller. Let's call this domain CTEMP.

2.	Add one or more users to CTEMP. They can either match one-to-one with existing users on the primary domain, or be one or more generic users for use by the presenters.

3.	Redirect Internet traffic on CTEMP to Content Gateway with WCCP v2.

4.	Enable Multiple Realm Authentication.

5.	Create Multiple Realm Authentication rules, one each for the CTEMP and CCORP domains:

a.	Define the CTEMP rule to apply to all connections coming from the IP address range assigned to the CTEMP domain. In the Advanced Settings area, specify that Aliasing and leave the field blank. This has the result of applying the default policy to all users of CTEMP.