TACACS password authentication - Handling Password Expiry

Hi Hamish,

 

 

I wonder if you could get any kind of status from the TACACS server from an iRule using AUTH::response_data:

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/AUTH__response_data.html

 

 

Can the DC'ers take this as a nudge to finish documenting the AUTH::response_data wiki page for the non-LDAP options the command might support?

 

 

Thanks,

 

Aaron

I investigated AUTH::Response_data first... I don't get anything from it... I've implemented the check as

 

 

Needs 9.4.0 or later...

 

when AUTH_RESULT {

 

set debugFlag [findclass "debug" $::formsPref " "]

 

 

array set AFauth_reponse_data [AUTH::response_data]

 

 

if { $debugFlag > 0 } {

 

log $::loghost local0. "Authentication Result"

 

log $::loghost local0. "START auth response data"

 

foreach {key value} [array names AFauth_response_data] {

 

log $::loghost local0. "ARData ($AFkey) ($AFvalue)"

 

}

 

log $::loghost local0. "END auth response data"

 

}

 

}

 

 

 

however the array is just empty...

 

 

ec 8 10:04:40 tmm tmm[5941]: Rule auth-by-form-94.01a : Authenticating xxxx

 

Dec 8 10:04:40 tmm tmm[5941]: Rule auth-by-form-94.01a : Authentication Result

 

Dec 8 10:04:40 tmm tmm[5941]: Rule auth-by-form-94.01a : START auth response data

 

Dec 8 10:04:40 tmm tmm[5941]: Rule auth-by-form-94.01a : END auth response data

 

Dec 8 10:04:40 tmm tmm[5941]: Rule auth-by-form-94.01a : Authentication success orig_uri is /

 

 

I logged a support call... F5 support tell me that devcentral is pretty much the only place to go. Unless I want to try iRules on demand... Which I presume is a chargable service (Not sure there, I never used it)...

 

 

Hi Hamish,

 

 

Yes, the iRules on demand is chargeable, but I don't think you're asking for consulting help. You're trying to find out details on iRule functionality and commands.

 

 

Can you ask them to provide the possible values for the AUTH::response_data for TACACS? While they have the subcase up to ENE or Product Development, you might also ask them if there is any functionality for handling password expiry or resets. If there isn't any existing functionality, they should offer to open a Request For Enhancement CR for you.

 

 

In general, F5 Support should be able to help with iRules in the following cases:

 

 

- documentation and expected functionality for iRule commands and/or events

 

- testing potential bugs in an existing iRule

 

 

Aaron

Yeah, we're trying to get some decent answers out of them. We don't get to talk direct to F5 support anymore, so it may just be that the path of communication is slightly garbling the info passing back & forth. It's possible that they don't realise exactly what we're asking.

 

 

I'm also going to test on 10.0.1 from my lab machines and see if that's any different (All the testing so far has been from 9.4.8) .

 

 

H

I opened a case with F5 Support requesting more complete details on the possible AUTH::response_data values for all client auth types not currently listed on the wiki page. The case number is C606593. I'll let you know what I find from that. If you get any answers on your case, please let me know.

 

 

Thanks,

 

Aaron

http://devcentral.f5.com/wiki/default.aspx/iRules/AUTH__response_data.html

By the way, part of the info I received from Support from C606593 was:

 

 

The error codes for AUTH::status correspond to the PAM API. There isn't a separate status code for [OCSP] revoked, so we didn't alter the AUTH::status command.

 

 

The error codes returned by AUTH::response_data for the error cases you're inquiring about largely come from OpenSSL directly. We don't have any information over why they decided to choose certain classes of error strings over others.

 

 

For RADIUS, on a successful response, AUTH::response data will contain the attributes returned by the server with a form of radius:attr: .

 

 

Similarly, for TACACS, the attributes will be with a form of tacplus:attr: .

 

 

For Kerberos, they will be with a form of krbdelegate:attr: .

 

 

For CRLDP, no attributes are returned.

 

 

In all of these cases, no results are returned if there is an error. Note that in the future, the general plan is for the APM functionality to supercede this iRule authentication, authorization, and error handling functionality.

 

 

Aaron