Security

So multi-building, multi-campus environment here.

 

I have had a web/MAC auth service up and running for our guest/legacy device network. It states the following:

 

OPENSSID-ROLE

1. (Endpoint:Username EXISTS ) [MAC Caching]

2. (Authentication:Source EQUALS [FACSTAFF AD]) [Facstaff]

3. (Authentication:Source EQUALS [MISC USERS MSSQL]) [SQL]

4. (Authentication:Source EQUALS [STUDENT AD]) [Student]

5. (Authentication:Source EQUALS [Guest User Repository]) [Guest]

 

ENFPOLICY

1. (Authorization:[Endpoints Repository]:Unique-Device-Count GREATER_THAN 3) [Deny Access Profile]

2. (Tips:Role EQUALS [Facstaff])  AND  (Connection:NAD-IP-Address BELONGS_TO_GROUP CAMPUS1) [CAMPUS1 Guest Role], MACAUTHSTUFF

3. (Tips:Role EQUALS [Student])  AND  (Connection:NAD-IP-Address BELONGS_TO_GROUP CAMPUS1) [CAMPUS1 Guest Role], MACAUTHSTUFF

4. (Tips:Role EQUALS [Guest])  AND  (Connection:NAD-IP-Address BELONGS_TO_GROUP CAMPUS1) [CAMPUS1 Guest Role], MACAUTHSTUFF

5. (Tips:Role EQUALS [Facstaff])  AND  (Connection:NAD-IP-Address BELONGS_TO_GROUP CAMPUS2) [CAMPUS2 Guest Role], MACAUTHSTUFF

6. (Tips:Role EQUALS [Student])  AND  (Connection:NAD-IP-Address BELONGS_TO_GROUP CAMPUS2) [CAMPUS2 Guest Role], MACAUTHSTUFF

7. (Tips:Role EQUALS [Guest])  AND  (Connection:NAD-IP-Address BELONGS_TO_GROUP CAMPUS2) [CAMPUS2 Guest Role], MACAUTHSTUFF

8. (Tips:Role EQUALS [SQL])  AND  (Connection:NAD-IP-Address BELONGS_TO_GROUP CAMPUS2) [CAMPUS2 SQL Role], MACAUTHSTUFF

 

My issue is the following. The SQL auth source contains a subset of users that rent spaces from us for six or so months at a time. I want to be able to web/MAC auth (we require re-logins every 8 hours) them like I do everyone else, but I only want them to be able to do their initial login from two buildings in particular (where they rent space). I copied my original service, moved the copy above the original, and put a Radius:Aruba Aruba-AP-Group EQUALS BUILDING-AP-GROUP in the service.

 

I haven't enabled the service yet, but my first thought is that users from all auth sources go into BUILDING-AP-GROUP. If they hit my newly created service, they'll just fail auth I think and never roll down to the next (original) service where they would normally work.

 

Thoughts?

Are there any other users in that SQL source other than those unique ones?

Nope. Every 4-6 months they're going to forward us class rosters (smaller colleges hosting distance learning in our shell spaces) and we'll add/remove from the SQL DB as necessary. It's completely seperate from our facstaff/students and traditional guest users.

you should be able to use a rule that checks the auth source and ap-group and move it to rule #2.

For the enforcement policy there isn't a CONNECTION -> AP-GROUP, but there is a CONNECTION -> AP-NAME. I'm guessing a BEGINS_WITH would probably work in this situation? Or did you mean something else entirely? :)

You would need to do a role map to use the radius Aruba ap-group data. Then reference that TIPS role in your enforcement along with the auth source.

1.	(Authentication:Source  EQUALS  [AD])	[Facstaff]
2.	(Authentication:Source  EQUALS  [EAD])	[Student]
3.	(Authentication:Source  EQUALS  [Guest User Repository])	[Guest]
4.	(Authentication:Source  EQUALS  [MSSQL])   AND  (Radius:Aruba:Aruba-AP-Group  EQUALS  C1-B14)	[SQL]

 

I added the AP-Group RADIUS flag in my role mapping as suggested, however, when testing in a different building (C1-B10, etc) using my MSSQL creds ClearPass passed me through as a guest user.

 

Policies Used -
Service:	[AccessSSID]
Authentication Method:	PAP
Authentication Source:	Sql:IP-HERE
Authorization Source:	[Endpoints Repository], [MSSQL]
Roles:	[Guest], [User Authenticated]
Enforcement Profiles:	[Guest Role]
Service Monitor Mode:	Disabled
Online Status:	Online

 

I guess my understanding of role mappings isn't quite there yet. Since I have the AND operator in the role mapping I thought that if it didn't meet both reqs the auth would just fail. Is that not correct?

The role is likely being cached. I'm re-thinking this a bit.

You might be better off duplicating your service and checking for the AP-group in your service rule. Then remove the authentication source in the old (regular) service.

 

Make sure the new service (with AP-group) is above the old service.

 

 

As I have two seperate AP-Groups that the MSSQL users need to be able to auth from, would I have to build two seperate services?

 

My original worry with building out a new service was that if an AD/EAD user hits this service by way of connecting to the AP-Group specified by the service that they would get rejected as they don't fall into the MSSQL auth source. I figured they wouldn't make it down to the next AccessSSID service.

 

I need to get a lab setup!

For the multiple AP-groups, use the belongs-to operator:

 

 

Is there anything unique about the usernames in the database that we can key on? Like a guest- prefix? How about something that isn't in a normal username (for example a period -  tcappalli vs tim.cappalli)?

 

 

 

 

Not looking like it, unfortunately. The DB is a mix of our library patrons, city library patrons, and then external schools. The data is aggregated and inserted into the MSSQL DB in such a way that the username portion of the table matches what each organization traditionally uses for a username. One is 12 digits, the other is 9 alphanumeric, and the last is mostly email addresses that follow the particular schools format (some are first initial last name, some are first name dot last name, etc).

 

Was hoping that keeping them contained to a single DB would be enough. What were you thinking? I might be able to split them up into seperate tables if necessary.

 

End game is having people in this DB be able to initiate auth against two specific AP-Groups and then MAC-auth for up to 4 hours at which point they'll need to punch their credentials in.

If you want only for them to authenticate on certain ap-a but have access all over campus after that then..you should use different services for the different ap groups. Unless you customize insight you will notice that every authentication will start the mins since auth over.

Since you have more than one group of users I would create another authentication source to same database in Clearpass hopefully you can use a more specific query to get only the users you want.


If you want the users just to do the very first login in a certain ap group then just modify ur enforcement profile to say endpoint:username not exist and ap-group equals rented spaces and authentication source equals SQL then deny / drop request. Once there is a username attribute then rule will no longer be hit.
(Only need one group of services for this)