Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Mapping Subscriber Domains to Access and Session Options

Domain Mapping Overview

Domain mapping enables you to configure a map that specifies access options and session-specific parameters. The map is based on the domain name of subscriber sessions — the router applies the mapped options and parameters to sessions for subscribers that have the specified domains. For example, you might configure a domain map that is based on the domain name example.com. The options and parameters in that domain map are then applied when subscribers with the specified domain name (for example, bob@example.com, raj@example.com, and juan@example.com) request a AAA service.

Note:

A subscriber’s username is typically made up of two parts — the user’s name followed by the user’s domain name, which are separated by a delimiter character. The domain name is always to the right of the domain delimiter. For example, in the username, juan@example.com, the user’s name, juan is followed by the domain name example.com, and the two are separated by the @ delimiter character.

However, some systems use a username format in which the domain name precedes the user’s name. To avoid confusion with the typical domain name usage, this type of preceding domain name is referred to as a realm name, and the realm name is to the left of the realm delimiter. For example, in the username, top321-example.com/mary, the top321-example.com part is the realm name, mary is the user’s name, and the / character is the delimiter character.

The domain map provides efficiency, and enables you to make changes for a large number of subscribers in one operation. For example, if an address assignment pool becomes exhausted due to the number of subscribers obtaining addresses from the pool, you can create a domain map that specifies that subscribers in a particular domain obtain addresses from a different pool. In another use of the domain map, you might create a new dynamic profile and then configure the domain map to specify which subscribers (by their domain) use that dynamic profile.

Starting in Junos OS Release 21.3R1, you can configure subdomains under a domain map. In a subdomain, you can configure access profiles per VLAN or for a VLAN range. This enhancement gives you the flexibility to differentiate the users in a domain and to provide different services based on the users' profiles.

Note:

Subscriber management is supported in the default logical system only. The documentation for the subscriber management domain mapping feature describes using the aaa-logical-system and target-logical-system statements to configure mapping to a non-default logical system. These statements are for future extensions of subscriber management.

Table 1 describes the access options and parameters you can configure in the domain map.

Table 1: Domain Map Options and Parameters

Option

Description

AAA logical system/routing instance

Logical system/routing instance in which AAA sends authentication and accounting requests for the subscriber sessions.

Subscriber management is supported in the default logical system only.

Access profile

Access profile applied to subscriber sessions.

Address pool

Address pool used to allocate addresses to subscribers.

Domain and realm name rules

Rules for domain and realm name usage, including domain name stripping, supported delimiters, and parse direction (delimiters and the parse direction are configured globally).

Dynamic profile

Dynamic profile applied to subscriber sessions.

PADN parameters

PPPoE route information for subscriber sessions.

Target logical system/routing instance

Logical system/routing instance to which the subscriber interface is attached.

Subscriber management is supported in the default logical system only.

Tunnel profile

Tunnel profile applied to subscriber sessions.

Types of Domain Maps and Their Order of Precedence

Starting in Junos OS Release 16.1, subscriber management uses a specific order when searching for a domain map that matches the subscriber domain name. The following list shows that order:

  • Exact match domain map—The subscriber domain name is an exact match to a configured domain map.

  • Wildcard domain map—The subscriber domain name is a partial match to a wildcard domain map.

  • default domain map—The subscriber domain name is neither an exact match nor a partial wildcard match to a domain map.

Note:

If the subscriber username does not have a domain name, then no search is performed and the subscriber is associated with the none domain map, if configured.

Wildcard Domain Map

Starting in Junos OS Release 16.1, the wildcard domain map feature enables you to specify a domain name that is used by subscribers when there is no exact match to the subscriber’s domain name. For example, if you create a wildcard domain map with the name xyz*.example.com, subscribers with the domain names xyz.example.com, xyz-1234.example.com, xyz-eastern.example.com, and xyz-northern.example.com are all mapped to that wildcard domain if there was no exact match for the subscribers’ domain names. You can insert the asterisk wildcard character anywhere within the domain map to create the desired matching specification. Wildcard domain mapping is also used in cases where subscriber names are derived from the DHCPv4 Agent Remote ID (option 82 suboption 2) or the DHCPv6 Remote-ID (option 37).

Default Domain Map

You can configure a default domain map that the router uses for subscribers whose domain or realm name does not explicitly match any existing domain map, and also is not a partial match to a wildcard domain map. Specify the name default as the domain map domain-map-name.

For example, you might configure the default domain map to provide limited feature support for guest subscribers, such as a specific address pool used for guests or the routing instance that provides AAA services. When the router is unable to provide an exact or wildcard match for the guest subscriber, the router then uses the rules specified in the default domain map configuration to handle the guest subscriber’s request.

Domain Map for Subscriber Usernames With No Domain or Realm Name

In some cases a subscriber username might not include a domain name or realm name—you can configure a specific domain map that the router uses for these subscribers. Specify the name none as the domain map domain-map-name.

Understanding Domain Maps and Logical System/Routing Instance Contexts

You can use a domain map to manage the logical system/routing instance that subscriber management uses for AAA and subscriber contexts. Subscriber management is supported in the default logical system only, so you manage the contexts by configuring the routing instance. The following list describes the two types of contexts:

  • Subscriber context—The logical system/routing instance in which the subscriber interface is placed. For most dynamic subscriber sessions, the initial subscriber session context is the default logical system and default routing instance. One exception is LNS, in which the initial context for a dynamic LNS session (PPP over L2TP) is the same as the peer interface (the LAC facing interface). Therefore, for LNS sessions, if the peer interface uses a non-default routing instance, then the initial context of the subscriber session also uses that non-default routing instance.

  • AAA context—The logical system/routing instance that the subscriber session uses for RADIUS interactions, such as authentication and accounting requests. By default, the AAA context is the same as the initial subscriber context. Therefore, for all subscriber sessions other than dynamic LNS sessions, authentication and authorization is performed in the default logical system/routing instance context, unless the default routing instance is explicitly changed.

You can optionally configure a domain map to use a specific subscriber or AAA context. For example, if a dynamic LNS session is initially created in a non-default routing instance (because the initial subscriber context uses the non-default routing instance), you might use the target-routing-instance statement to configure the domain map to place the subscriber in the default routing instance. Or, for security reasons, you might want to have all RADIUS interactions in a particular context. In this case, you would use the aaa-routing-instance statement to configure the domain map to change the initial AAA context to the new routing instance.

Using domain maps to manage AAA and subscriber contexts is also useful in layer 3 wholesale environments. For example, you might want to place dynamic VLAN interfaces in different non-default routing instances, while maintaining all RADIUS interactions in the default routing-instance. In this example, the initial AAA context is in the default routing instance, but RADIUS authorization places the subscriber VLAN session in a non-default routing instance. You can then include the aaa-routing-instance statement in the domain map, to specify that the AAA context uses the default routing instance for the dynamic VLAN session. The subscriber session is unchanged and remains in the non-default routing instance.

Benefits of Using Domain Maps

  • Domains maps simplify managing subscribers at scale by enabling you to make changes for a large number of subscribers in one operation.

  • Domain maps provide granularity in applying changes to specific groups of subscribers based on your map definitions.

Configuring a Domain Map

To configure a domain map for subscriber management:

  1. Create the domain map. For the map name, specify the domain name that you want the domain map to use. (Use default for the name of the default domain map.)
    • For example, to create a domain map to be mapped to subscribers with the domain name example.com:

    • To create a wildcard domain map to be mapped to subscribers whose domain name is not an exact match, but is a partial match:

      See Configuring a Wildcard Domain Map.

    • To create a default domain map to be mapped to subscribers with non-matching domain names:

    • To create a domain map to be mapped to subscribers without a domain or realm name:

  2. (Optional) Specify the access profile used to apply access rules for the domain map.
  3. (Optional) For dynamic profiles, clarify the provided dynamic configuration for the subscriber session.
  4. (Optional) Specify the address pool used to allocate address for the domain map.
  5. (Optional) Configure the target logical system/routing instance for the subscriber context.
  6. (Optional) Configure the target logical system/routing instance in which AAA requests are sent for the domain map.
  7. (Optional) Configure rules for domain names; for example; delimiters, parsing direction, and domain stripping. Delimiters and parsing direction are configured globally for all domain maps. Domain stripping is enabled in the domain map.
  8. (Optional) Configure rules to remove the domain portion from the username for authentication, accounting, and display purposes.
  9. (Optional) Configure parsing the user portion of the username and strip off the user portion for authentication only.
  10. (Optional) Specify a password to use for all subscriber authentications for a domain map. This option affects only the username/password sent in the access-request to external policy/RADIUS servers.
  11. (Optional) Assign a tunnel profile that provides tunnel definitions for the domain map.
  12. (Optional) Assign a tunnel switch profile to be applied by the domain map.

Configuring a Wildcard Domain Map

Subscriber management supports a wildcard domain map feature that enables you to configure a domain mapping that is based on a partial wildcard match. When there is no exact match between the subscriber domain name and a configured domain map, subscriber management next looks for a partial match between the subscriber domain name and a wildcard domain map.

To create the wildcard domain map, you include the asterisk wildcard character when you configure the domain map name, such as, domain map example*. You can insert the wildcard character anyplace within the domain map, and the wildcard can represent zero or any number of characters. The asterisk is the only supported wildcard character.

For example, the configuration statement domain map example*northern.com creates a wildcard domain map that is a partial match for all domain names beginning with example and ending with northern.com, such as examplenorthern.com, example-northern.com, and example1234northern.com. However if you move the wildcard character in the domain map name to domain map example-northern*.com, this creates a more restrictive match that requires the partial matching domain names to start with example-northern, such as example-northern555.com or example-northern-alpha.com.

Wildcard domain mapping is also useful when subscriber management derives subscriber usernames from the DHCPv4 Agent Remote ID (option 82 suboption 2) or the DHCPv6 Remote-ID (option 37). In these cases, the resultant username is in the format subscriberID|service-plan|accountID|unused; for example, EricSmith|premiumTier1|314159265|0000 (where the | character is the delimiter). In this example, subscriber management parses the username left-to-right, and identifies the subscriber’s domain as premiumTier1|314159265|0000. To create a wildcard domain map that is used for this subscriber, you might configure domain map premiumTier1*.

The following example describes how four subscribers are mapped to different domains.

For this example, there are three domain maps configured; the default domain map, a domain map named example3000.com, and a wildcard domain map named example*. The subscribers are mapped as shown in the following list:

  • eric@example3000.com—There is an exact domain map match, so the subscriber is mapped to domain example3000.com.

  • jack@example1001.com—There is no exact match, but there is a partial match to the wildcard domain, so the subscriber is mapped to the wildcard domain example*.

  • ginger@example-western.com—There is no exact match, but there is a partial match to the wildcard domain, so the subscriber is also mapped to the wildcard domain example*.

  • sunshine@test.com—There is no exact match, nor is there a partial match to the wildcard domain, so the subscriber is mapped to the default domain.

To configure a wildcard domain map:

  1. Specify the domain map name, including the wildcard character.
  2. Specify the optional characteristics for the wildcard domain map.

Specifying an Access Profile in a Domain Map

You use access profiles to specify the access rules and options (for example, the RADIUS authentication server and attributes) that the router applies to subscriber sessions. The domain map feature enables you to apply a specific access profile for subscribers in a particular domain.

Access profiles can be specified or modified in several different ways. If conflicts occur, the router applies the access profiles based on the precedence rules shown in Table 2.

Table 2: Precedence Rules for Applying Access Profiles

Precedence (High to Low)

How the Access Profile Is Applied

1

Specified by the RADIUS Redirect-VRouter-Name attribute (VSA 26-25)

2

Specified in the domain map configuration stanza

3

Indirectly specified in the domain map configuration stanza by the AAA logical system/routing instance mapping

4

Specified in the client configuration stanza

5

Specified in the logical system/routing instance configuration stanza

To include an access profile in a domain map:

  1. Specify the domain map you want to configure.
  2. Specify the access profile you want to include in the domain map.

Specifying an Address Pool in a Domain Map

You can use the domain map feature to specify the address pool that the router uses to allocate address for subscriber sessions. The address pool can include both IPv4 and IPv6 address ranges.

Address pools can be specified or modified in several different ways. If conflicts occur, the router applies the address pool based on the precedence rules shown in Table 3.

Table 3: Precedence Rules for Determining the Address Pool to Use

Precedence (High to Low)

How the Address Pool Reference Is Provided

1

Specified by the RADIUS Framed-Pool attribute (RADIUS attribute 88)

2

Configured in the domain map configuration stanza

3

Specified in the client configuration stanza (by address match rules)

To specify the address pool used for a domain map:

  1. Specify the domain map you want to configure.
  2. Specify the address pool you want to use for the domain map.

Specifying a Dynamic Profile in a Domain Map

A dynamic profile defines the set of characteristics that provide dynamic access and services for subscriber sessions (such as class-of-service, protocols, and interface support). The domain map feature enables you to apply a specific dynamic profile based on subscriber domains.

Dynamic profiles are configured at the [edit dynamic-profiles] hierarchy, and can be specified or modified in several different ways. If conflicts occur, the router applies the dynamic profiles based on the precedence rules shown in Table 4.

Table 4: Precedence Rules for Applying Dynamic Profiles

Precedence (High to Low)

How the Dynamic Profile Is Applied

1

Specified by the RADIUS Virtual-Router attribute (VSA 26-1) or the Redirect-VRouter-Name attribute (VSA 26-25)

2

Specified in the domain map configuration stanza

3

Specified in the client configuration stanza

To include a dynamic profile in a domain map:

  1. Specify the domain map you want to configure.
  2. Specify the dynamic profile you want to include in the domain map.

Specifying an AAA Logical System/Routing Instance in a Domain Map

By default, a domain map uses the subscriber logical system/routing instance as the context in which the authd daemon sends AAA authentication and accounting requests. You can optionally configure the domain map to direct AAA requests to a particular context, based on the subscriber domain name. Specifying a non-default AAA context enables you to manage workflow and traffic load, and to efficiently make changes for a large number of subscribers. For example, after upgrading your RADIUS services, you might configure a domain map to specify that all subscribers in the domain example.com are now authenticated by a RADIUS server in a particular AAA context.

Note:

Changing the AAA context does not change the subscriber context. You use the target-logical-system statement to explicitly configure the logical system/routing instance for subscribers.

To configure the logical system/routing instance context used for AAA requests:

  1. Specify the domain map you want to configure.
  2. Specify the routing instance. If a non-default routing instance is currently configured, you can use the default option to specify that the domain map use the default routing instance. The AAA logical system is automatically set to the default.
Note:

Subscriber management is supported in the default logical system only.

Specifying a Target Logical System/Routing Instance in a Domain Map

By default, the router places a subscriber in the logical system/routing instance context of the interface on which the subscriber negotiations start. You can later change the routing instance of the subscriber’s context through the use of either a domain map or the RADIUS authentication server.

Subscriber management is supported in the default logical system only, however you can configure the domain map to use a non-default routing instance. Also, if a non-default routing instance is already configured, you can configure the domain map to use the default routing instance.

To configure the logical system/routing instance context used for a subscriber’s interface :

  1. Specify the domain map you want to configure.
  2. Specify the target routing instance (the default logical system is used by default). If a non-default routing instance is currently configured, you can use the default option to specify that the domain map use the default routing instance.
Note:

Subscriber management is supported in the default logical system only.

Specifying a Tunnel Profile in a Domain Map

Tunnel profiles specify tunnel definitions (for example, a set of L2TP tunnels and their attributes) that the router applies to subscriber sessions. The domain map feature enables you to apply a specific tunnel profile to subscribers in a particular domain.

Note:

A tunnel profile specified by a RADIUS server in the Tunnel-Group attribute (VSA 26-64) takes precedence over the tunnel profile specified in the domain map.

To include a tunnel profile in a domain map:

  1. Specify the domain map you want to configure.
  2. Specify the tunnel profile you want to include in the domain map.

Specifying a Tunnel Switch Profile in a Domain Map

Tunnel switch profiles determine whether packets in an L2TP subscriber session from a LAC are switched to another session that has a different destination LNS. The tunnel switch profile can also specify how certain L2TP AVPs are handled when the packets are switched to a second tunnel. The domain map feature enables you to apply a specific tunnel switch profile to subscribers in a particular domain.

Note:

A tunnel switch profile specified by a RADIUS server in the Tunnel Switch-Profile VSA (26-91) takes precedence over the tunnel switch profile specified in the domain map. If the Tunnel-Group VSA (26–64) is received in addition to the Tunnel Switch-Profile VSA (26-91), the Tunnel Switch-Profile VSA (26-91) takes precedence over the Tunnel-Group VSA (26-64), ensuring that the subscribers are tunnel switched rather than LAC tunneled.

To include a tunnel switch profile in a domain map:

  1. Specify the domain map you want to configure.
  2. Specify the tunnel switch profile you want to include in the domain map.

Configuring Domain and Realm Name Usage for Domain Maps

You can configure how the router determines the domain names that are used for the domain mapping feature. At the global level, you can specify rules that are used for domain maps. The global rules enable you to specify additional characters that the router can recognize as domain or realm name delimiters and to specify the direction the router uses to parse domain or realm names. The purpose of parsing a domain or realm name is to identify a single, unique name that the router uses as the subscriber’s domain name, regardless of whether the source of the name is in the typical domain name format (joseph@example.com) or in the realm name format (example.com\marilyn). The router uses the resulting domain name for operations such as domain map lookup and processing. At the domain map level, you can also enable domain name stripping. Domain name stripping specifies that the router remove the parsed domain or realm name from the subscriber username prior to performing any additional processing for the domain map.

To configure domain name usage rules for domain maps:

  1. (Optional) For domain or realm names, configure the parsing order, which specifies whether the router searches for the domain name or the realm name first.
  2. (Optional) For domain or realm names, configure the delimiters you want the router to recognize for domain maps.
  3. (Optional) For domain or realm names, configure the parse direction you want the router to use when determining domain names for domain maps.
  4. (Optional) For domain names, configure the router to remove the parsed domain or realm name from usernames in the domain map before using AAA services.

Specifying Domain and Realm Name Delimiters

A delimiter is the character that separates a subscriber username from the domain or realm name. Delimiters are commonly used for domain or realm name parsing or domain name stripping. You can specify a maximum of eight delimiters that the router uses to recognize domain or realm names for a domain map. If you do not configure any delimiters, the router uses the @ character by default for domain names. There is no default delimiter for realm names.

For example, your network might include the subscribers bob@test.com, pete!example.com, and test.net\maria. In this case, you would configure the router to recognize the characters @ and ! as domain name delimiters, and the \ character as a realm name delimiter.

Keep the following guidelines in mind when specifying delimiters:

  • You cannot use the semicolon (;) as a delimiter.

  • If you configure optional domain name delimiters, you must also specify the @ character (the default delimiter) if you want to continue to use it as a delimiter.

  • If you configure optional domain name delimiters and then unconfigure them, the router sets the domain map delimiter back to the default @ character.

To configure domain and realm name delimiters for domain maps:

  1. Specify that you want to configure domain attributes.
  2. Specify the characters you want to use as domain name delimiters. Do not include spaces between the delimiters.
  3. Specify the characters you want to use as realm name delimiters. Do not include spaces between the delimiters.

Specifying the Parsing Order for Domain and Realm Names

The router parses the username domain or realm name in order to identify a single, unique name that the router uses as the subscriber’s domain name, regardless of whether the source of the name is in the typical domain name format (joseph@example.com) or in the realm name format (example.com\marilyn). You can specify the whether the router first searches the subscriber username for a domain name or for a realm name. If the router does not find the specified name (for example, you specify realm-first and there is no realm name in the username), then the router searches for the second type of name (domain name, in this case). If the router does not find either a realm-name or a domain name, then there is no domain that can be used for domain mapping operations.

To configure the domain name parsing direction for domain maps:

  1. Specify that you want to configure domain attributes.
  2. Specify the parsing order you want the router to use, either the domain name first or the realm name first.

Specifying the Parsing Direction for Domain and Realm Names

You can specify the direction in which the router performs the parsing operation it uses to identify subscriber domain or realm names for domain maps. During the parsing operation, the router searches the username until it recognizes a delimiter. It then considers anything to the right of the delimiter as the domain. By default, the router parses from right to left, starting at the right-most character in the username.

The router uses a subscriber’s domain name to perform domain map lookup and processing operations. You can configure how the router identifies a unique domain name when the user’s name is presented in a traditional domain name format or a realm name. In the traditional domain name format, the user’s name is followed by the domain name; for example, joe@example.com. In the realm name format, the user’s name is preceded by the domain name, referred to as the realm name; for example, example.com@joe. The purpose of parsing a domain or realm name is to identify a single name that the router uses as the subscriber’s domain name, regardless if the source of the name is the user’s original domain name or realm name. The router uses the resulting domain name for operations such as domain map lookup and processing. At the domain map level, you can also enable domain name stripping.

The domain parsing direction you use is important when there are nested domain names. For example, for the username user1@test.com@example.com, right-to-left parsing produces a domain name of example.com. For the same username, left-to-right parsing produces a domain name of test.com@example.com.

Note:

This operation is similar to parsing the user portion of a username, but the default direction and the results are different.

To configure the domain name parsing direction for domain maps:

  1. Specify that you want to configure domain attributes.
  2. Specify the parsing direction you want the router to use if the username uses the typical domain name format, in which the domain name follows the user’s name.
  3. Specify the parsing direction you want the router to use if the username uses the realm name format, in which the realm name precedes the user’s name.

Enabling Domain Name Stripping

You can configure the router to strip the domain name from usernames before any AAA services are used. Domain name stripping is done for domain maps. The router uses the delimiters and parsing direction you globally configure to determine the domain name that is removed. For example, if the router uses the default delimiter and parsing direction right-to-left, the username user1@example.com is stripped to be user1.

To configure the router to strip the domain name from usernames in a domain map:

  1. Specify the domain map for the stripping operation.
  2. Enable domain name stripping.

Changing the Username and Password to Simplify Off-Chassis Provisioning

For some use cases, you might want to provision L2TP LAC subscriber usernames and authentication passwords off the router chassis. You can strip off the user portion of the username and override the user password.

You can configure how the router identifies the user portion to be stripped when the username is presented in either the traditional domain name format or the realm name format. In the traditional domain name format, the user’s name is followed by the domain name; for example, joe@example.com. In the realm name format, the user’s name is preceded by the domain name, referred to as the realm name; for example, example.com@joe.

You can specify the direction in which the router performs the parsing operation that it uses to identify the user portion of the username. During the parsing operation, the router searches the username until it recognizes a delimiter. By default, the router parses from left to right, starting at the left-most character in the username. Everything to the left of the delimiter is the user portion. This direction works for the traditional domain name format. With this configuration, the router identifies and strips joe from joe@example.com.

For usernames in the realm name format, you need to change the parsing direction to right-to-left. The router parses from right to left, starting at the right-most character in the username. When the router recognizes the delimiter, it considers anything to the right of the delimiter as the user portion. With this configuration, the router identifies and strips joe from example.com@joe.

Note:

This operation is similar to the domain name/realm name parsing operation, but the default direction and the results are different than domain name/realm name parsing.

Note:

The user portion is stripped only for the username sent to an external server for authentication. The unstripped username is used for accounting operations.

To configure the user portion to be stripped from the username for all usernames associated with a domain map:

Specify the parsing direction you want the router to use:

  • Use left-to-right when the username is in the typical domain name format, in which the domain name follows the user’s name.

  • Use right-to-left when the username is in the realm name format, in which the realm name precedes the user’s name.

You can specify a new password to override the existing password for authenticating any subscriber associated with the domain map. To override the password:

  • Specify the override password for PAP authentication.

  • Specify the override password for CHAP authentication.

Release History Table
Release
Description
16.1
Starting in Junos OS Release 16.1, subscriber management uses a specific order when searching for a domain map that matches the subscriber domain name.
16.1
Starting in Junos OS Release 16.1, the wildcard domain map feature enables you to specify a domain name that is used by subscribers when there is no exact match to the subscriber’s domain name.