Highlighted
Visitor.
587 views

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,,,
Labels (1)
0 Likes
7 Replies
Highlighted
Knowledge Partner
Knowledge Partner

Re: V4.6 as non-root install

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.
0 Likes
Highlighted
Visitor.

Re: V4.6 as non-root install

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

Re: V4.6 as non-root install

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.
0 Likes
Highlighted
Visitor.

Re: V4.6 as non-root install

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

Re: V4.6 as non-root install

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.
0 Likes
Highlighted
Visitor.

Re: V4.6 as non-root install

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

Re: V4.6 as non-root install

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