jmckinne Absent Member.
Absent Member.
765 views

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
Labels (1)
0 Likes
11 Replies
jmckinne Absent Member.
Absent Member.

Re: Automate Driver Application Password changes

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Automate Driver Application Password changes

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.
0 Likes
jmckinne Absent Member.
Absent Member.

Re: Automate Driver Application Password changes

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Automate Driver Application Password changes

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Automate Driver Application Password changes

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Automate Driver Application Password changes

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.


0 Likes
Highlighted
jmckinne Absent Member.
Absent Member.

Re: Automate Driver Application Password changes

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Automate Driver Application Password changes

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.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Automate Driver Application Password changes

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Automate Driver Application Password changes

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.






Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Automate Driver Application Password changes

On 2018-04-18 23:44, Geoffrey Carman wrote:
> 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 sould be able to do it via an LDAP extended operation:
https://www.novell.com/documentation/developer/dirxml/dirxmlbk/ref/javadocs/com/novell/nds/dirxml/ldap/SetAppPasswordRequest.html

--
Norbert
--
Norbert
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.