Security

We've got a PSK SSID tied to Clearpass via an [Allow All MAC Auth] service, that's using the Endpoints Repository, an external SQL database, Static Hosts List, and AD as authorization sources.  I'm able to leverage info from all of these sources to assign roles based on context, but I'd like to clean up the AD piece a little bit.

I started by trying to create the filter query to select computer objects where <some AD attribute> matches <some Clearpass variable> but no matter what I tried it wouldn't return any matches.  For example, the default Machine filter:  (&(sAMAccountName=%{Host:Name}$)(objectClass=computer)).  I think %{Host:Name} is only populated when the client does machine authentication, so I tried some others like %{Authorization:[Endpoints Repository]:Hostname}, since clients being in the endpoints repository is a prerequisite before they can hit this enforcement policy.  The idea was that in the enforcement policy I could have a simple rule like "Authorization:ADsource <filtername> EXISTS".  No luck there either.

Now I've just got the AD source query set to (objectClass=computer) (which returns all computers from AD and fills the authorization attributes section with a lot of ugly data in access tracker), and the enforcement policy rule is "Authorization:ADSource:<filtername> EQUALS_IGNORE_CASE %{Authorization:[Endpoints Repository]:Hostname}".  This gives me the desired end result, but the pile of computer names in access tracker/auth attributes is going to bug me.

So - is there a way I can use a variable in the filter query for AD to only pull results that match, for example, %{Authorization:[Endpoints Repository]:Hostname}?

You should not modify the machine filters. Those are only used with Machine Authentication. 

Use this for your authentication filter:

(&(cn=%Authorization:[Endpoints Repository]:Hostname})(objectClass=computer))

Also just keep in mind that hostname is easily spoofed.

Thanks Tim,

So the filter name actually has some impact on the operation of it?  I created a new AD source just for this purpose to avoid borking anything with our other AD auth services, fortunately.  I'll give this a shot, thanks!

-Josh.

That doesn't seem to be working, it doesn't return a match when I authenticate, but when I put my hostname in the attributes tab of the filter window it returns a match from AD.

Filter name: Authentication

Filter Query: (&(objectClass=computer)(cn=%{Authorization:[Endpoints Repository]:Hostname}))

Name: cn  Alias name: machineName  Data type: String  Enabled as: attribute.

Yep, and it displays the correct value next to Authorization:[Endpoints Repository]:Hostname under authorization attributes in access tracker, but nothing from the AD source.  It's behaving like it doesn't yet know what the endpoints variable is when it queries AD (I do have the endpoints repository first in the list, and AD last, in case it mattered).

Make sure you have both Endpoint Repository and AD source as additional authorization sources.

Hi Tim,

Endpoint Repository is listed under authentication sources, and all 4 sources are listed under additional authorization sources.

-Josh

I worked with TAC on this and after testing in their lab they confirmed that it doesn't work.  They offered a workaround where we set a custom attribute via our 802.1x SSID, and then leverage that in the query filter (which does seem to work) but that's not live data and isn't going to be sufficient for our needs.  I've concluded that having all of the AD computers listed under the authorization attributes section in access tracker is worth it if it means this works, and it does.

I've finally got a working solution on this that doesn't pollute access tracker with a giant list of computers.

Authentication Source:

Active Directory: domain.com

AD filter:

(&(cn=%{Authorization:[Endpoints Repository]:Hostname})(objectClass=computer))

I'm grabbing cn as machineName and userAccountControl as objectStatus, both enabled as attributes.

As a role mapping rule - doesn't work, no attribute is returned:

(Authorization:domain.com:objectStatus NOT_EQUALS 4130)
 AND  (Authorization:domain.com:machineName EXISTS ) -> TargetRole

As an enforcement condition - this works!  Attributes from AD source are returned.

(Authorization:domain.com:machineName EXISTS )
 AND  (Authorization:domain.com:objectStatus NOT_EQUALS 4130) -> TargetProfile

I can't come up with a reason why this wouldn't work in the role mapping config, but I'd love to hear it if there's any known reason for this.

@joshcurrier

Could you prehaps share some screenshots of how you constructed the AD Authentication source and filters? I'm working with a customer to achieve basically the same result whereby they would like to take the machinename from the endpoints database and search AD for that machine name. If found, apply a custom enforcement profile.

My enforcement profile is configured as the following:

	(Tips:Role  EQUALS  [Employee]) 
 AND  (Authorization:Active Directory - Test:machineName  EXISTS   ) 
 AND  (Authorization:Active Directory - Test:objectStatus  NOT_EQUALS  4130)	Aruba Role SecureAuthenticated AD

The attached screenshot should detail the AD filer I'm using.

This however doesn't appear to be working.. And ideas here?

I agree that using the hostname name learned from DHCP is bad. I'm using the certificate provided for authentication.

My filter look like this:

(&(dNSHostName=%{Certificate:Subject-AltName-DNS})(objectClass=computer))

I can't spot any difference between that and our configuration that should prevent it from working, sorry.  Tim's right though, hostname isn't a safe source to use for identity.  In our case I'm relying more on the SCCM MAC data and the hostname is just an extra data point to compare.  I've begun working on changing this configuration so both the MAC and hostname are validated against SCCM data and only the computer object state will be checked against AD.

Thanks guys!

Currently CPPM is in a form of "monitoring only" mode. The real exercise here is to use CPPM to ferret our deficiencies in an alternative SQL authentication source, to be used at a later time.

User error. Actually, this works great!

We initially didn't have many clients that were matching our specific criteria. Ha