Security

Mac Caching is deployed and working. When we disable a user in AD and user has already authenticated via captive portal and then mac cached user continues to have the ability to mac cache (and access resources). The following Ldap query is being used in the WebLoginExists attribute within our current Authorization method. (&(sAMAccountName=%{Endpoint:Username})(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

If you clear the cache for the endpoint, does it work?


Thanks,
Tim

We can clear cache at the attribute in the  authentication source.  We did this and the AD account is disabled yet devices still auth in CPPM via mac caching.

Your Mac caching enforcement must also include ad authorization.

AD auth is in place. Tested LDAP query against enabled and disabled accounts prior to ma caching using WebLoginExists attribute. What may be happening is that once mac caching is complete there is no check back into AD to see if an account has become disabled. Mac caching changes user name from AD to mac hw address in the endpoint db. There is an attribute that references the ad name assoc. with the mac hw account in the endpoint db entry for the device. We have Mac caching enabled for 48 hours.

 

If there was a check in place for a  disabled account after mac caching   mac caching should fail and the user would return to captive portal for authentication.  Upon captive portal authentication attempt user woud not be able to access resources.

I ran into that same issue a couple of months ago.

Unfortunately I couldn't find a way that during the MAC AUTH we can check whether the user account was disabled or expired.

This is setup was for contractors with an AD account , we decided that they had to login everyday (only cache the mac for the day) through the captive portal .

I may be misreading the problem here but couldn't the AD authentication source be changed slightly so the value of "userAccountControl:1.2.840.113556.1.4.803:" is written to an attribute which can then be queried as part of MAC authentication.

 

Essentially you would leave your LDAP filter as the standard:

 

(&(sAMAccountName=%{Endpoint:Username})(objectClass=user))

 

and add an attribute called AccountEnabled which matches the field "userAccountControl:1.2.840.113556.1.4.803:". On the MAC authentication service you just write an enforcement profile which checks whether the Authorisation attribute AccountEnabled is not equal to 2.

 

Apologies if this is wrong, maybe you could post screenshots of the service so we could take another look.

 

Very nice!! Dave
That's exactly what I was missing:

(&(sAMAccountName=%{Endpoint:Username})(objectClass=user))

I added the username to endpoint and included the useraccountcontrol but didnt add the endpoint username check

Team-

 

I am going to try to work on this in our near prod environment this afternoon and I will post results.

 

Kirk

Team-

First. Thank you.

We revisited our auth source and added an attribute to an exisiting filter called Webdn  called userAccountControl. We then removed the following from the ldap query (!(userAccountControl:1.2.840.113556.1.4.803:=2))  leaving only this (&(sAMAccountName=%{Endpoint:Username})(objectClass=user). 

 

We then revisited out enforcement policy for mac caching and added a condition

Authorization:AD Domain userAccountControl=514

Enforcement profile: Radius(Deny Access Profile)

We authenticated via Captive portal.  We then Authenticated via MAc Caching.  We disabled in AD.

Test did not work. We were still able to authenticate via Mac Caching.  We cleared cache for the authentiction source and re tested.  Success.  We were denied access and returned to the captive portal.uccess 

Thanks to the team of Airheads  helping me out. One more question?

What is the interval for clearing cache on auth sources?  Is it automated and can it be changed?

Thank you again....

You can change the automated timeout in the authentication source.

 

Team-

 

I lept before I looked.  Thank you for the reply.  I searched the community and found the solution.  I have also verified in my test bed.  Ours is set to 1800  seconds or 30 mins.

 

Thank you

 

Kirk