variable assignment between unsuccessful login and next check

Perhaps it's related to the event you're using? Does that event only trigger once? Is there a more specific one you can use or perhaps an additional one related to authentication failure?

hi,

good point 🙂 I'm trying to set the username/password now with the "AUTH FAILURE" event. I never used the "AUTH FAILURE" event, when I'm using it, I get the following error message in the irule editor:

AUTH_FAILURE event in rule (/Common/portal_ras_access-policy) requires an associated AUTH profile on the virtual server (/Common/abx-ldap.abx-ras.ch).

do you know where I have to do that ?

best regards,

Florian

It seems that this events only can be triggered from "Local traffic authentication profiles" I'm not using this at all. All my authentication logic is in the access profile ... I don't know why can I implement authentication on 2 completely different places ?

A few considerations:

1. First and foremost, the AUTH events do not relate to APM. They are left over from the Advanced Client Authentication (ACA) module. If you have OCSP and CRLDP authentication profiles under LTM in the management GUI, that's where you'd use the AUTH events.

    

2. So I'm assuming you're using a logon page to collect the RSA serial number and token code. Unless you've significantly modified the logon page, the serial number will be automatically stored in the session.logon.last.username variable (or whatever you renamed it to), and the token code will be stored (protected) in the session.logon.last.password variable. As you're only using RSA values to authenticate the user, you probably don't need the variable assignment.

    

3. The LDAP Auth agent will generally look for the session.logon.last.username and session.logon.last.password session variables, and the RSA SecurID agent will look for the session.logon.last.password session variable.

    

4. What you're probably witnessing is that auth is failing INSIDE the auth agent and looping around for a retry. Both auth agents have a "Max Logon Attempts Allowed" option that specifies how many attempts it'll make.

    

5. Question: I'm not sure it's completely clear from your description, but are you entering the real username some where in the logon process? How would it have that value otherwise?

    

6. Last point: I would maybe consider the ramifications of your approach if a user lost their token. The username is the serial number, which will change when the user is issued a new token. This may add some unintentional overhead to your authentication solution.

    

Hi Kevin,

i have to clarify a few things which I thing I haven't cleared out enough:

We're building up a SSL-VPN service for many different customers. They can login there and use the RDP client, full tunnel or whatever ...

The customer decides which user gets an RSA-token, which user can authenticate via Google authenticator, which one gets an OTP per SMS, and so on. The customer can edit this settings in a webinterface which is putting the appropriate values in an LDAP directory.

Because we do not want to push the RSA service anymore (and because not every customer wants RSA) we store the password of the user in the LDAP directory. He can change it there and can do numerous other things like generate a barcode for google auth, or

and thats the deal - define an RSA token - for his account. So the customer has a bunch of RSA tokens at his place and can take one of it and assign it to a client. Without even having access to the RSA console.

We want to do that via setting the username of the RSA user to the RSA Token Serial Number. So we define for every Token we give to the customer an RSA user, which name is the Token Serial Number.

At the authentication process we're asking for 3 things:

The username (stored in the LDAP directory) The password (stored in the LDAP directory) The Tokencode

We're checking which token the user has assigned (-> stored in LDAP) and authenticating against the RSA server with:

username: the serial number of the Token -> stored in LDAP password (or PIN): deactivated in RSA, there is an option for it tokencode: the tokencode the user entered at the login prompt

The first time it wors like a charm, read out the tokencode entered in by the user, store it in the "last.password" session variable. I also read out the RSA token serial number, which is stored in an ldap session variable and store it as session variable "last.username".

The RSA Server is authenticating and voila - it works.

When the user has failed to enter the tokencode correctly and enters username,password and tokencode again, the variables are not modified again. as written in my last post, it seems that all steps between login-form and RSA authentication are skipped.

So what happens now: In the login Form the user types in username, password and tokencode. Because there is no replacement taking place, the user is authenticated with

username: username as entered in login form tokencode: tokencode as entered in login form

and that is wrong.

I hope I was able to clarify a few things now.

best regards,

Florian