Filter
Top Products
Configuring Rights
the new identification information. The user will now match one of the Identity Profiles near the
top of the table. For example:
• Suppose the client initially matches row 5, (Identity Profile “Any” and Connection Profile
“Accounting”) and his logon information is sent to an external authentication service such as
an LDAP server. That service returns the group affiliation “Accounting” as part of the
successful authentication. As a result the client matches the Identity Profile “Accounting” as
well as Connection Profile “Accounting,” and gets rights based on the “Accounting” Access
Policy as specified in row 1.
• Suppose a client initially matches row 5 and gets successfully authenticated, but the group
information returned is
not
“Accounting.” In this case, the client does not match row 1 because
it does not match Identity Profile “Accounting.” However, because it has been authenticated,
it matches Identity Profile “Authenticated,” and by default matches Connection Profile “Any.”
Therefore it gets rights based on row 3.
• A client that initially matches on row 6, and is successfully authenticated, also gets new rights
based on row 3. Since its Connection Profile is not “Accounting”, it does not match row 1 (most
likely it also does not match the Identity Profile “Accounting”).
• If the user elects to logon as a Guest, she is automatically associated with the “Guest” Identity
Profile, matches on row 2 of the table, and receives rights based on the “Guest” Access Policy.
Guest users are not considered authenticated by the system, and therefore do not match the
“Authenticated” Identity Profile.
Note: In this example it is important that the row containing the —Accounting“ Identity Profile and
the —Accounting“ Connection Profile be placed before the row containing the —Authenticated“
Identity Profile and —Any“ Connection Profile. If these two rows were reversed, all authenticated
clients would match the —Authenticated“ Identity Profile and —Any“ Connection Profile in the first
row–including those who might also match the —Accounting“ Identity Profile and the
—Accounting“ Connection Profile in the second row. Because the table search stops at the first
match, no authenticated clients would ever get as far as the second row to receive access
rights from the —Accounting“ Access Policy.
The second example describes how access rights are assigned to clients that are identified only by MAC
address, where presenting a user name and password is not appropriate. Network devices such as Access
Points fall into this category.
Step 1. A client connects to the 700wl Series system, identified by its MAC address. As in the first
example, this initiates a search of the Rights Assignment Table. However, in this case assume that
this “client” is actually an Access Point, and that the MAC addresses of all Access Points connected
to the various Access Controllers have been added to the built-in database and assigned to the
“Access Points” Identity Profile.
Step 2. In this case the MAC address is known to the system. As in the first example, the client does not
match the Identity Profiles in the first three rows, but it does match the Access Points Identity
Profile in row 4. This results in the client getting access rights based on the Network Equipment
Access Policy. These rights do not send the client through an authentication process, and the
client now has the rights it needs.
Like Guests, clients identified only by MAC address are not considered authenticated, and
therefore do not match the “Authenticated” Identity Profile. If a MAC address user has been
added to the built-in database, but has not been assigned to an Identity Profile, that client will
continue to match the “Any” Identity Profile.
4-8 HP ProCurve Secure Access 700wl Series Management and Configuration Guide