08-30-2014 12:17 PM
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:
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]
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.
08-30-2014 12:23 PM
08-30-2014 12:28 PM
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.
08-30-2014 12:37 PM
08-30-2014 12:47 PM
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? :)
08-30-2014 01:12 PM
09-02-2014 12:00 PM
|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)
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 -
[Endpoints Repository], [MSSQL]
[Guest], [User Authenticated]
|Service Monitor Mode:|
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?
09-02-2014 12:05 PM - edited 09-02-2014 12:07 PM
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.
09-02-2014 01:38 PM
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!
09-02-2014 01:45 PM
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)?