Download ClearPass_SQL_Lookup_Tech_Note

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Concurrency control wikipedia , lookup

Database wikipedia , lookup

SQL wikipedia , lookup

Open Database Connectivity wikipedia , lookup

Microsoft Jet Database Engine wikipedia , lookup

PL/SQL wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Versant Object Database wikipedia , lookup

Relational model wikipedia , lookup

Clusterpoint wikipedia , lookup

Database model wikipedia , lookup

Transcript
ClearPass SQL Lookup Tech Note
The purpose of this tech note is to show how to configure ClearPass to query an
external database. For the purpose of this example, the internal database will be
used. This will allow you to try it out without having to setup a new database server.
In this example we are going to check to see if a user successfully logged in more
than 8 hours ago but less than 1 week.
Prerequisite: Insight must be enabled on ClearPass Policy Manager.
Step 1 – Getting access to the database
First we need to setup the authentication for an external connection to the database.
In ClearPass Policy Manager, navigate to Administration->Server Manager->Server
Configuration and click on Cluster-Wide Parameters.
On the General tab, change the Database user "appexternal" password. For our
purposes, we will use the password of aruba123.
Step 2 – Looking into the database
For this step, we will need an external application to look into the database.
Download and install the application called pgAdmin3. Open pgAdmin3. Click on the
plug in the top right to add a new server connection.
Enter the information as necessary. You can put anything in the “Name” field. Make
sure you enter the appropriate IP address for ClearPass, change the username to
appexternal, and enter the password you set for appexternal in the previous step.
Click to progress down the following path: cp61->Databases->insightdb->Schemas>public->Tables->auth. Right-click on auth and click on Scripts->SELECT Script.
A new window will open up with the default select script. Click on the Run Script
button.
This will display all the information in this table. This is a lot of information. But if
you scroll across, you will see all the information we need is in this table, e.g. mac,
auth_status, and timestamp. What we need to do is trim this back to get just the
information we need. To remove the extra columns, just remove the header name
from the SELECT statement. Now the SELECT statement should look like this:
SELECT auth_status, mac, "timestamp"
FROM auth;
Now run that SELECT statement. You will see just those three columns displayed.
In order to be able to compare date and time, we need to work with EPOCH time. So
we will use the EXTRACT(EPOCH FROM sometime) function. Below I have built the
function that we will need to use in order to get the result we desire.
SELECT auth_status, mac, "timestamp" FROM auth
WHERE (EXTRACT(EPOCH FROM "timestamp")) < (EXTRACT(EPOCH FROM now())-28800)
AND (EXTRACT(EPOCH FROM "timestamp")) > (EXTRACT(EPOCH FROM now())-604800)
AND auth_status = 'User';
If we run that statement in SQL Editor of PGAdmin3, we should see the data
required. Now we can go back into ClearPass and build our authorization source.
Step 3 – Building the authorization source
In ClearPass Policy Manager, navigate to Configuration->Authentication->Sources
and click on Add Authentication Source.
On the general tab for the new authentication/authorization source, give the source
a name. For the purposes of this tech note, we will give it the following name: my
mac check.
For type, choose Generic SQL DB.
Another thing to note on this tab is the cache timeout. Since we are looking at
successful authentications that happened after the past 8 hours, we will want to
shorten the cache timeout 0. This is because the changeover from a non-successful
query to a successfully one could change from one second to the next. Whenever a
time sensitive query is built, you should put the cache timeout at 0, thereby
disabling the cache for that source.
Click Next.
On the primary tab, enter the IP address of the database you are connecting to. In
this case, we will use localhost since this is a local db connection. Enter the
information as shown in the image below.
The database name is insightdb since that is where the auth table is located that we
are querying.
Click Next.
The Attributes tab is where we will enter our search query. Click Add More Filters.
For the new filter, give it a name and paste in the search query from earlier. We
need to make one more modification to that search query. If we leave the search
query as it is, it will be true for everyone, as long as at least one client matched the
criteria in the search query. Instead we need to narrow down the search for the
specific device that is connecting. In order to do that, we need to use a variable in
our search query. For our purposes the Radius:IETF:Calling-Station-Id matches the
MAC address format we see in our test query in PGAdmin3. Therefore, we add the
following to the end of the SQL search query:
AND mac = '%{Radius:IETF:Calling-Station-Id}';
Any attributes that show up on the Input tab of a device’s connection attempt in
access tracker can be used in a SQL query for Authorization. Some common ones are
Radius:IETF:Calling-Station-Id, Connection:Client-Mac-Address-Hyphen,
Connection:Client-Mac-Address-Colon, and Radius:IETF:User-Name.
Now, our final filter query looks like this:
SELECT mac
FROM auth
WHERE (EXTRACT(EPOCH FROM "timestamp")) < (EXTRACT(EPOCH FROM now())-28800)
AND (EXTRACT(EPOCH FROM "timestamp")) > (EXTRACT(EPOCH FROM now())-604800)
AND auth_status = 'User'
AND mac = '%{Radius:IETF:Calling-Station-Id}';
We also need to add an Attribute in order to reference this search query. Click on
the name field.
The Name must match one of the columns being requested from the database table.
In this case, we are selecting “mac” from the table. Therefore enter mac in the Name
field.
The Alias Name is how we will reference it in the Enforcement Policy or Role
Mapping. For our purposes, we will use the alias of mac-check-db. Since the data of a
mac address contains letters and numbers, the data type is String. Make sure you
click the save icon at the end of the line:
Click Save to save the Attribute. Click Save to save the new
authentication/authorization source.
Step 4 – Using the new source in a service
For our testing purposes, we will add this source to an 802.1x service and use it in
the enforcement policy.
Modify an existing 802.1x service. On the Service tab, under More Options, make
sure that the Authorization check box is checked.
Now click on the Authorization tab. Add the my mac check source as an additional
authorization source.
Click the Enforcement tab. Click Modify to modify the enforcement policy. Click on
the Rules tab of the enforcement policy. Select a rule and click Edit Rule.
Click on “Click to add…” in order to add an additional condition. Add the condition
seen in the image below:
If our SQL query returns anything for the search, then EXISTS will be true.
Click Save to save the Rule. Click Save to save the Enforcement Policy. Click Save to
save the modifications to the Service.
That is it. Do not forget that we could use the exact same condition in a Role
Mapping rule which we used above in the Enforcement Policy Rule.