Security

Hi All,

 

I had thought this might be simple, but now I'm not sure.

 

I have a scenario where there is a captive portal service with mac-caching. The initial web-logins are authenticated against AD, and an endpoint entry gets created (which contains the AD username used in the first place).

 

As an extension to this, I'm now trying to add something to the mac-auth service, which will go back to AD and check that the user's account (which originally was used on the endpoint) simply "exists" and isn't disabled.

 

I assumed this might be achieved by way of an authorization configuration or similar, but I can't get it to work, and my efforts would be nonsense if I posted them here.

 

For a number of complicated reasons, I can't use the service templates. The service has been setup bit-by-bit.

 

Any suggestions would be great.

Don't quite understand this part :

"As an extension to this, I'm now trying to add something to the mac-auth service, which will go back to AD and check that the user's account (which originally was used on the endpoint) simply "exists" and isn't disabled"

 

You should be able to use the Guest Mac authentication template to make this work.

 

You will need to adjust the authentication/Authorization source to use AD in the Service "Guest with Mac caching" of course these are the default names but you could change it later, The only change you need to make to the Guest Mac authentication service is the amount of time you want to allow the user before it gets redirected again.

 

In your Web login you need to select requires username/password and authentication should be set to radius .

 

 

This would probably require a custom SQL query that compares the username in the endpoint database to the account status for that username in Active Directory.

Thanks for the responses. Like I say, we can't use the templates in this customer case.

 

I actually worked out the answer shortly after posting. I've basically achieved what we wanted, by adding an enforcement rule that checks into the AD authorization source, for an LDAP attribute of "userAccountControl". This value seems to be returned as 512 if the account is enabled, so we just check that is the case in the mac-auth service rules. If it's not, we reject (results in logon role).

 

Good point regarding the AD auth source cache timer. We've tuned that a bit.

 

Thanks.

 

Looking to achieve the same things, you wouldn't by chance remember what you configred in the enforcement or if the 512 value is the same for all microsoft AD?

I know this is a bit of an old post but wonder if there is any update on this.

 

I am unsure how “The.racking.monkey”  set the enforcement  rule to check the AD.  I have set this up and it fails and the reason this fails is when it does MAC Auth it is not authenticating with the username but authenticating with the MAC address.

 

Cappalli made the point that you would require a custom SQL query that compares the username in the endpoint database to the account status for that username in Active Directory.

 

Would anyone have done some work around this and be willing to share the information?

Duplicate your AD auth source. Create a new filter like below and then remove all of the other filters.

 

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

 

If your policy, reference the userAccountControl attribute. A list of the values is here: http://jackstromberg.com/2013/01/useraccountcontrol-attributeflag-values/

Thank you :-)

I know this is a bit of an old post but wonder if you could provide any further info

 

I am unsure how “The.racking.monkey” set the enforcement rule to check the AD. I have set this up and it fails and the reason this fails is when it does MAC Auth it is not authenticating with the username but authenticating with the MAC address.

 

As you said you would require a custom SQL query that compares the username in the endpoint database to the account status for that username in Active Directory. Would have any further information around this?

 

Thanks