V4.6 as non-root install

Hi. We are looking to start migrating our system from eDirectory v8.8sp6/8 to v9.1. We are building new systems most likely and are considering doing a non-root install so we can hand off to non-admin types. We have done non-root in the past for eDirectory so are familiar with that mostly. However looking at a non-root install for idm, it seems you have to manually assign a dirxml password policy package to each driver. Or something line that. We are still using the old idm v3.6x polices with our system. We have not converted to packages all tbis time. So how much trouble is a non-root install going to be for us?? Thanks,,,
  • mtsjej;2484649 wrote:
    Hi. We are looking to start migrating our system from eDirectory v8.8sp6/8 to v9.1. We are building new systems most likely and are considering doing a non-root install so we can hand off to non-admin types. We have done non-root in the past for eDirectory so are familiar with that mostly. However looking at a non-root install for idm, it seems you have to manually assign a dirxml password policy package to each driver. Or something line that. We are still using the old idm v3.6x polices with our system. We have not converted to packages all tbis time. So how much trouble is a non-root install going to be for us?? Thanks,,,


    Which flavour of non-root are you looking at? Root install binaries and running instance(s) as non-root? Or non-root tarball install and run as non-root?

    I don't see any need to assign password policies to drivers just because you're running as non-root. Got a link to that in the documentation?

    Policies still work fine, with or without packages. You should, of course, upgrade to packages, but if you don't it all still works just like it always has.
  • dgersic;2484725 wrote:
    Which flavour of non-root are you looking at? Root install binaries and running instance(s) as non-root? Or non-root tarball install and run as non-root?

    I don't see any need to assign password policies to drivers just because you're running as non-root. Got a link to that in the documentation?

    Policies still work fine, with or without packages. You should, of course, upgrade to packages, but if you don't it all still works just like it always has.


    We are looking at the non-root tarball option. Which we have some eDirectory servers already like that. Just want to do the engine now.

    Here is the document. On page 149

    https://www.netiq.com/documentation/identity-manager-46/pdfdoc/setup/setup.pdf

    Completing a Non-root Installation
    When you install the Identity Manager engine and plug-ins as a non-root user, the process performs all intended installation activities. This section guides you through the manual process required to complete the installation.
    “Assigning the Password Policy Object to Driver Sets” on page 149
    “Creating the Default Notification Collection Object in the Identity Vault” on page 151 “Adding Support for Graphics in Email Notifications” on page 152
  • mtsjej;2484739 wrote:
    We are looking at the non-root tarball option. Which we have some eDirectory servers already like that. Just want to do the engine now.

    Here is the document. On page 149

    https://www.netiq.com/documentation/identity-manager-46/pdfdoc/setup/setup.pdf

    Completing a Non-root Installation
    When you install the Identity Manager engine and plug-ins as a non-root user, the process performs all intended installation activities. This section guides you through the manual process required to complete the installation.
    “Assigning the Password Policy Object to Driver Sets” on page 149
    “Creating the Default Notification Collection Object in the Identity Vault” on page 151 “Adding Support for Graphics in Email Notifications” on page 152


    Oh, that. Yeah, you can go ahead and just do that. It's a password policy, nothing to do with drivers or packages.

    There have been some comments in the eDir forum about getting a non-root tarball install running with systemd at startup. Might see that thread too.
  • dgersic;2484760 wrote:
    Oh, that. Yeah, you can go ahead and just do that. It's a password policy, nothing to do with drivers or packages.

    There have been some comments in the eDir forum about getting a non-root tarball install running with systemd at startup. Might see that thread too.


    Not sure how to assign that policy, the docs talk about applying th package in designer. We are still using the legacy v3.61 polices😀

    As for systemd, yes always fun times.
  • mtsjej;2484789 wrote:
    Not sure how to assign that policy, the docs talk about applying th package in designer. We are still using the legacy v3.61 polices😀

    As for systemd, yes always fun times.


    Somebody needs to update that documentation page. It's ... wrong. They're talking about NMAS password policies. Create in Security container, assign to driver set, and etc.. Then they switch over to talking about a Designer package...?

    You might comment on the page, that'll generate an SR for somebody on the documentation team to go look at it.
  • dgersic;2484818 wrote:
    Somebody needs to update that documentation page. It's ... wrong. They're talking about NMAS password policies. Create in Security container, assign to driver set, and etc.. Then they switch over to talking about a Designer package...?

    You might comment on the page, that'll generate an SR for somebody on the documentation team to go look at it.


    Hi. Yeah I was pretty sure they were wrong. Thanks,,,
  • David touched on it a bit, but if you are still planning I think this
    needs to be called out:

    Two types of eDirectory installs: root (RPM-based) and non-root (tarball).
    Two types of eDirectory instances: root (ndsd running as root) and
    non-root (ndsd running as some other user).

    There is no technical reason you cannot run non-root instances in a root
    install, and in general I think this is the bets way to go. The non-root
    install is probably fine, but it's not supported by some other components
    (IDM did not support it initally, but then they added that), and even with
    the non-root install you need root privileges for some thing like
    upgrading NICI).

    The main driver for non-root anything is usually security and abiding by
    the "Least Privilege" principle. In other words, for your admins, give
    them access to what they need (eDirectory) but not the whole system.
    Similarly, while ndsd is running, give it access to what it needs (to read
    its own libraries and configuration data, to write its own DIB data, etc.)
    and nothing else (no writing of its own binaries, no writing of system
    stuff, etc. The only way to accomplish that last part fully, like every
    other Linux application in the world, is to have the running process NOT
    be able to modify itself; either a root instance, or a non-root instance
    with a non-root install, does not work since either case allows the
    running instance to modify itself completely, and that's not particularly
    safe.

    As a result, for security reasons, a root install with non-root
    instance(s) is the best option.

    Disclaimer: While I think this has been supported, and should be
    supported, and has even been tested in some cases officially (per some
    documentation), it is not explicitly called out in the documentation as an
    option. As a result, there were some claims it was not fully supported.
    I think that will change sooner than later, but it is not my call. It
    definitely works well, but support != function sometimes.

    --
    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.