Automate Driver Application Password changes

I have an audit finding for my IDM driver's application service accounts needing to periodically change their password. Our organization uses CyberArk for PIDM. I'd like to be able to allow CyberArk to:

1. Automatically change the application's service account password (this is CyberArk to application - not IDM. this is NOT the reason for this post)
2. Update the DirXML-ShimAuthPassword and recycle the driver (this is what I would like to automate - reason for this post).

Is there any way to accomplish this or am I relegated to manually updating the password within the driver properties and restarting the driver?

I'm simply trying to find out if anyone has attempted this or, if there's a supported method other than manual to change the driver's application password? I am not looking to hack the DirXML-ShimAuthPassword, I just need to allow CyberArk to automatically update it.

I am not concerned with Remote Loader password nor Driver Object password.

Thanks!

Joe
  • Sorry. I guess I should have mentioned we are running eDirectory 8.8.8.8 and IDM 4.5.5. I know, they are end of life.

    Thanks!

    Joe
  • jmckinne;2479546 wrote:
    I have an audit finding for my IDM driver's application service accounts needing to periodically change their password. Our organization uses CyberArk for PIDM. I'd like to be able to allow CyberArk to:

    1. Automatically change the application's service account password (this is CyberArk to application - not IDM. this is NOT the reason for this post)
    2. Update the DirXML-ShimAuthPassword and recycle the driver (this is what I would like to automate - reason for this post).

    Is there any way to accomplish this or am I relegated to manually updating the password within the driver properties and restarting the driver?

    I'm simply trying to find out if anyone has attempted this or, if there's a supported method other than manual to change the driver's application password? I am not looking to hack the DirXML-ShimAuthPassword, I just need to allow CyberArk to automatically update it.

    I am not concerned with Remote Loader password nor Driver Object password.

    Thanks!

    Joe


    I don't think it's going to be possible, but I wonder if you could do it from outside the driver. Use a SOAP driver and publish the DirXML-ShimAuthPassword to the target driver. I suspect it's RSA encrypted. Set up a quick test with a DelimText driver to see if you can do it.
  • On 4/18/2018 4:54 PM, jmckinne wrote:
    >
    > I have an audit finding for my IDM driver's application service accounts
    > needing to periodically change their password. Our organization uses
    > CyberArk for PIDM. I'd like to be able to allow CyberArk to:
    >
    > 1. Automatically change the application's service account password (this
    > is CyberArk to application - not IDM. this is NOT the reason for this
    > post)
    > 2. Update the DirXML-ShimAuthPassword and recycle the driver (this is
    > what I would like to automate - reason for this post).
    >
    > Is there any way to accomplish this or am I relegated to manually
    > updating the password within the driver properties and restarting the
    > driver?
    >
    > I'm simply trying to find out if anyone has attempted this or, if
    > there's a supported method other than manual to change the driver's
    > application password? I am not looking to hack the
    > DirXML-ShimAuthPassword, I just need to allow CyberArk to automatically
    > update it.


    dxcmd can do it scriptwise, you can see the options (this is from a
    3.6.1 server!!!!)

    DirXML Command Line Utility
    version 3.6.1
    Copyright (C) 2003-2008 Novell Inc., All Rights Reserved

    Enter user name: idmfolder:~ # dxcmd -?

    Usage: java com.novell.nds.dirxml.util.DxCommand [configuration] [actions]

    If no actions are specified interactive mode is used.

    Configuration:
    -user <user name>
    -host <name or IP address>
    -password <user password>
    -port <port number>
    -cert <X.509 DER certificate filename>
    -dnform <slash|qualified-slash|dot|qualified-dot|ldap> (force dn form)
    -version <n.n[.n[.n]]> (force engine version for
    testing)
    -nossl (use clear socket for LDAP)
    -keystore <keystore path and filename> (for LDAP SSL)
    -storepass <keystore password> (for LDAP SSL)
    -q (quiet mode)
    -v (verbose mode)
    -s (write result to stdout)
    -? (show this message)
    -help (show this message)

    Actions:
    -start <driver dn>
    -stop <driver dn>
    -getstate <driver dn>
    -getstartoption <driver dn>
    -setstartoption <driver dn> <disabled|manual|auto> <resync|noresync>
    -getcachelimit <driver dn>
    -setcachelimit <driver dn> <0 or positive integer>
    -migrateapp <driver dn> <filename>
    -setshimpassword <driver dn> <password>
    -clearshimpassword <driver dn>
    -setremoteloaderpassword <driver dn> <password>
    -clearremoteloaderpassword <driver dn>
    -sendcommand <driver dn> <input filename> <output filename>
    -sendevent <driver dn> <input filename>
    -queueevent <driver dn> <input filename>
    -setlogevents <dn> <integer ...>
    -clearlogevents <dn>
    -setdriverset <driver set dn>
    -cleardriverset
    -getversion
    -initdriverobject <dn>
    -setnamedpassword <driver, driverset or job dn> <name> <password>
    [description]
    -clearnamedpassword <driver, driverset or job dn> <name>
    -clearallnamedpasswords <driver or job dn>
    -getdriverstats <driver dn> <output filename>
    -resetdriverstats <driver dn>
    -startjob <job dn>
    -abortjob <job dn>
    -getjobrunningstate <job dn>
    -getjobenabledstate <job dn>
    -getjobnextruntime <job dn>
    -updatejob <job dn>
    -getcachetransactions <driver dn> <position token> <transaction
    count> <output filename>


    I believe -setshimpassword is the application password. Driver object
    is just an NDS password on the object. I see you can also do remote
    loader passwords as well.

    You can call dxcmd in policy via a Java call to cmd: which lets you
    execute command lines. I am not sure if there is a more direct Java call
    to dxcmd's classes that would do that.

    You can also restart a driver with it. Now I have never tried
    restarting this driver itself, with dxcmd via Java, but it might work.
    Worst case, use a second driver to change and update the other driver.


  • Just to make sure we understand, why would you want this password to
    change periodically? What security folks have known forever, and the
    governments are finally figuring out, is that changing passwords does not
    improve security unless the passwords are compromised. Considering the
    limited nature of these passwords, where no users likely use them, what
    benefit is there in changing the password from time to time, other than to
    cause downtime and possibly expose new passwords to attackers because of a
    need to transfer them from here to there to set them initially?

    It is particularly ironic to me that they would care about something like
    this, basically reinforcing a bad idea that decreases security, while
    (apparently) not caring about outdated, unsupported, lower-security
    software (eDirectory 8.8.x, etc.). Security auditors provide no end of
    laughter.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • I cannot find any argument against what you are saying regarding changing the password. I agree. As long as the account is properly monitored for failed attempts/lockouts or inappropriate use, why change the password and increase the risk? However, if you've ever been through an audit, you will realize, as I have, that you can present your arguments, but ultimately, it will still be a finding and we will have to find a solution. :-)

    Trust me, I will probably get a finding on the EOL software as well, but when it takes 2.5 years to upgrade, what can you do? We just went live on IDM 4.5.5 and eDir 8.8.8.8 in June 2017 and that was after upgrading from 3.5.1 and eDir 8.8.5! We are working on the next upgrade project for 2019. <sigh!> Never ends.

    Thanks,

    Joe
  • geoffc,

    Good call! I hadn't even gotten around to looking at dxcmd. I will test with this and see what I can come up with. I'm wondering if CyberArk could execute a script to run the dxcmd on the Linux console or, if I'd need a driver to do it. I'll work with our CyberArk guys to see what my options are. I'd think a shell script might be easier, but we'd have to work out the eDir creds and make sure those are periodically changed too! I do know we can vault eDirectory creds, however, so not too worried about that.

    Thank you!

    Joe
  • On 4/18/2018 6:34 PM, jmckinne wrote:
    >
    > geoffc,
    >
    > Good call! I hadn't even gotten around to looking at dxcmd. I will
    > test with this and see what I can come up with. I'm wondering if
    > CyberArk could execute a script to run the dxcmd on the Linux console
    > or, if I'd need a driver to do it. I'll work with our CyberArk guys to
    > see what my options are. I'd think a shell script might be easier, but
    > we'd have to work out the eDir creds and make sure those are
    > periodically changed too! I do know we can vault eDirectory creds,
    > however, so not too worried about that.


    In a driver, you can store the creds in a named password.

    Also using the DirXML-Access* permissions you can use an account only
    with permission to restart or change the password (Well that one might
    require more permissions, not sure) to the driver.


  • Hi Joe,
    My experience with CyberArk is pretty negative.
    Maybe it is not the software itself, maybe this is our specific implementation, but I can recommend to collect more information about the CyberArk behavior and don't rush to ruin your IDM environment for satisfying fake audit requirements.

    By the way, for run script with dxcmd, you will need to inject your admin password with every run.
    I can see here much bigger security hole.
  • al b <al_b@no-mx.forums.microfocus.com> wrote:
    >
    > I can recommend to collect more information about

    the CyberArk behavior and don't rush to ruin your IDM environment for
    satisfying fake audit requirements.
    >


    Always worth takling a step back and reevaluating whether the advice is
    correct.

    > By the way, for run script with dxcmd, you will need to inject your

    admin password with every run.
    > I can see here much bigger security hole.


    Depends on how well the hosting process hides/masks the credentials/command
    line.






  • On 04/18/2018 04:34 PM, jmckinne wrote:
    >
    > I cannot find any argument against what you are saying regarding
    > changing the password. I agree. As long as the account is properly
    > monitored for failed attempts/lockouts or inappropriate use, why change
    > the password and increase the risk? However, if you've ever been
    > through an audit, you will realize, as I have, that you can present your
    > arguments, but ultimately, it will still be a finding and we will have
    > to find a solution. :-)


    In my experiencing "finding" means about as much as the business wants it
    to mean, and with logic applied it often means< "The auditors have this
    note in a thousand pages of wasted paper that nobody will ever see, but
    which often makes people feel like they should jump to change things
    because it was found and fixing a finding is easier than thinking." I am
    not attributing this to you in particular, but it just seems to be how
    auditing is in general.

    I was in an accounting class years ago where financial audits were
    described the same way; to get the big auditors to sign their boilerplate
    text about, "We audited them, and all is well." it was basically a big
    negotiating task of what was allowed to continue vs. what had to be redone
    with the financial documents. I understand the reasoning why, and that
    seems to be the best way to do it to avoid crippling rigidity in a
    flexible world, but that implies people can think, reason, and understand,
    without just caving to a "finding".

    It reminds me of vulnerability scanners which often "find" things which
    are invalid, but because the security scanner operator guy (as opposed to
    a real security researcher) "found" something, it must be fixed at all
    costs regardless of the silly nature of the finding. Auditors are paid to
    kill trees because otherwise their prices are obviously unjustified,
    instead of being less-obviously unjustified.

    I'm well beyond being helpful, but I figured I"d share this. Let us know
    if you have any luck injecting reason into others.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.