You can control which users have access to an authentication agent in the trusted realm by adding a duplicate authentication record of the agent in the trusted realm. A duplicate authentication record allows you to restrict user access to members of a group. Only the users you assign to this group are able to access the agent in the trusted realm.
For example, suppose that you are the London administrator for a company that has a trusted relationship between two realms: New York and London. The New York realm has an unrestricted VPN agent called “VPN1.” You want to restrict which London users can access VPN1, so you create a duplicate agent record of this agent record, also called “VPN1,” in the London realm. This agent record contains the same data as the agent record in the New York realm, including IP address. You make VPN1 a restricted agent, and create a user group called“VPN users.” Only London members of VPN users have permission to access VPN1 in New York.
You assign the user “jsmith” to the VPN users group. When jsmith travels to New York and attempts to access VPN1 on the New York realm, the New York realm does not recognize the user jsmith, and forwards the following information to the London realm: user name, agent name, and passcode. The London realm recognizes the user name and agent name, and immediately checks to see if the agent is restricted. Because the agent is restricted, and jsmith is a member of VPN users, the authentication request is approved and the New York realm allows jsmith to authenticate.
If you create a duplicate agent record, it is important to know if the corresponding agent in the trusted realm has trusted user groups. If a trusted user group in the duplicate agent record does not contain the same users as the group on the agent on the trusted realm, users might not be able to authenticate. Note the following:
In the above example, assume that VPN1 in the trusted realm has a trusted user group associated with it. If jsmith is not a member of the trusted user group, he cannot authenticate, even though he is a member of his realm’s corresponding user group.
In the above example, assume that a second London user, “sbrown,” is a member of the trusted user group, but is not a member of his realm’s corresponding user group. Despite being a member of the trusted user group, sbrown cannot authenticate because his realm has not given him access to the agent.
If you use aliases for user groups, users might attempt to log on to an authentication agent in the trusted realm using their aliases. To ensure successful authentications in this case, add a duplicate record of the agent in the trusted realm with associated user groups and aliases to your realm.
For example, suppose that your realm has a restricted VPN agent, “VPN2.” Only members of the VPN2 user group can access VPN2. In that user group, users have aliases, a special user name they use just for VPN2. For example, the user “jdoe” has the alias “jdoeVPN,” which he uses when he logs on to VPN2.
If jdoe attempts to authenticate to the trusted realm’s VPN agent, “VPN1” using his alias, “jdoeVPN,” the trusted realm does not recognize jdoe and sends his user name and agent information back to jdoe’s realm. Jdoe’s realm does not recognize the agent “VPN1” or the user name “jdoeVPN.” Therefore, access is denied and the user cannot authenticate.
If jdoe’s realm has a duplicate agent record, also called “VPN1” and VPN1 has an associated user group where jdoe is a member and has “jdoeVPN” as his alias, the problem is solved. Now when “jdoeVPN” tries to access VPN1 in the trusted realm, the trusted realm forwards the user name and agent information back to jdoe’s realm. Jdoe’s realm recognizes the agent name and the alias. Now jdoe can authenticate successfully.