Forum Discussion

Nikolay_Matveev's avatar
Nikolay_Matveev
Icon for Nimbostratus rankNimbostratus
Jan 15, 2016

APM iRule to "replicate" password change between AD and stand-alone servers

Dear Community,

 

I have a quite tricky problem to solve and hope somebody can point me in right direction.

 

I have a single sign-on infrastructure where APM provides SSO across 3 VSs. AAA authentication is done against AD using Kerberos. All pool members for all 3 VSs are Windows boxes but only two pools (for VS1 and VS2) contain servers which are members of the AD domain where I authenticate my clients. The last pool (used by VS3) consists of stand-alone servers with their own user account database (the DB is kept on a backend SQL server). And these servers support only form-based or Basic authentication (unfortunately it's a legacy "black box" application). All clients are external (so their PCs do not belong to the AD domain in question).

 

As long as a username and password match both in AD and on those stand-alone servers everything is fine with SSO. As expected the problem appears when a user tries to change his/her password. It gets changed in AD without any issues but as the stand-alone servers have no means to synchronise their user DB with AD I need some means of maintaining identical passwords across all systems. To me the most logical approach would be to create an iRule that would capture the new password when password change dialogue is invoked by APM. Then, provided AD password change was successful in AD, the iRule would construct a request for the VS3 that would change password for the same username on the stand-alone servers.

 

The task seems doable but the questions are:

 

  1. What's the best way (iRule event/condition) to capture the moment when APM invokes that AAA AD password change form?
  2. How can the new password value can be acquired from that form in the iRule code?
  3. How can a password change request be constructed for a server with form-based or Basic authentication.

Assume that accounts in AD and on the stand-alone boxes have the same user login names and initially passwords are identical.

 

Any advices and clues would be very much appreciated!

 

APM
application delivery
iRules

5 Replies

Sort By
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jan 15, 2016

    Hi Nikolay,

     

    If I where you, then I would turn the DB accounts into shadow accounts.

     

    I would change the passwords of the DB to a value which is unknown to end users, but known by your APM (using datagroups or by using a strong and fixed password for every DB user). Then inject those DB credentials during APM logon into the session and use them whenever the user requests content from the application servers.

     

    AD Account => APM Session => DB Account

     

    By doing this the users would still login to your F5 using your AD credentials and every application. And they could change the AD password as usual and as often they want. But without the need for manual or automatic password replication...

     

    Cheers, Kai

     

  • Nikolay_Matveev's avatar
    Nikolay_Matveev
    Icon for Nimbostratus rankNimbostratus
    Jan 18, 2016

    Hi Kai,

     

    Thanks a lot for your quick response and sorry for the delay with getting back to you!

     

    I was also thinking of shadowing in first place but then something made me think that labour-wise password syncing and password shadowing would be more or less the same. Now, after you suggested this, on the second thought I think you're right - this would be easier as less coding should be required (no need to handle AD password expiration for VS3).

     

    Just to be clear - is this what you meant (see diagram below):

     

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jan 18, 2016

    Hi Nikolay,

     

    Yep this is exactly what I mean. By using fixed passwords for the DB based Forms-based SSO you could get rid of the complex password sync mechanism at all.

     

    And if the password are strong enought and protected from the eyes of your users, then you dont even need them to be unique per-user and also not changed on a regular basis. Change them only on demant, if you believe the password was getting compromized...

     

    Cheers, Kai

     

  • Nikolay_Matveev's avatar
    Nikolay_Matveev
    Icon for Nimbostratus rankNimbostratus
    May 23, 2016

    Hi Kai,

     

    I hope you're still subscribed to this topic as I desperately need your help again!

     

    I have now developed around 80% of this system just to discover that I cannot easily store anything in data groups from within iRules (or maybe my DevCentral/Google search skills are not as good as they could be :)).

     

    To populate the shadow database I intercept the moment of creation of user accounts in that "DB-application", look up that account in AD (sideband) and store (currently just in system log):

     

    1. mapping between AD user name and a corresponding user name in the DB-application
    2. password for the account in the DB-application

    Then when a user logs in, I authenticate him/her in AD, look up corresponding account of the DB-application in the data group and, if a matching value is found, I use this account and its password (taken from the data group) for the form-based authentication. Everything works very well with statically populated data groups and log files.

     

    Hence the question - is there a way to permanently store on BigIP (from within iRules) low-volume HTTP data which I capture from user POST data? Neither space nor performance impact is an issue here - it's expected that the system will have from a few hundreds to a couple of thousands of user accounts, each taking up to 84 symbols (so way below 1MB).

     

    I know that data groups were not designed to be used for this purpose but suspect (and very much hope) that there is some sort of a backdoor/workaround which could help me achieve the goal without going down the route of building an external facility where BigIP could store the same data using a sideband call...

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    May 24, 2016

    Hi Nikolay,

    thaks for writing me an E-Mail, since I've unsubribed from devcentral notifications. Well, I don't have much time at these days, since I'm envolved in the developments of some rather complex Active Directory security concepts. So please send an additional e-mail if you have further questions...

    Regarding your question: You can store/lookup additional runtime information using the 

    [table]
    or 
    [table -subtable]
    command. Store/key the table information based on the given username value, set some appropiate lifetimes and then [table lookup] when the user comes back to you and you need to access those information...

    1Mbyte of data is a no brainer for the [table], but you should still set some lifetimes on those values to have some sort of automatic garbage collection.

    Remainder: The [table] command creates a replicated (across different cluster nodes) memory table. There exist no build in way to schedule exports/imports (backup/restore) for those data. If you need those stuff, then you have to work with additional sideband connections, to export/copy and copy/import those data on/from an external source as required.

    HTH, Kai