We set roleContextDN to cn=nnmi-access

And it still barfs, but I found stuff in the access log file: (redacted a bit)

[06/Dec/2019:12:49:18.055641820 +0000] conn=2805 fd=110 slot=110 connection from NNMi-Server to IdM-Server

[06/Dec/2019:12:49:18.055983514 +0000] conn=2805 op=0 BIND dn="" method=128 version=3

[06/Dec/2019:12:49:18.056068589 +0000] conn=2805 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0000264910 dn=""

[06/Dec/2019:12:49:18.060407586 +0000] conn=2805 op=1 SRCH base="cn=users,cn=compat,dc=lab,dc=PROJECT,dc=EXAMPLE,dc=ORG" scope=2 filter="(uid=USER)" attrs="distinguishedName"

[06/Dec/2019:12:49:18.060803785 +0000] conn=2805 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0000453635

[06/Dec/2019:12:49:18.061436537 +0000] conn=2806 fd=125 slot=125 connection from NNMi-Server to IdM-Server

[06/Dec/2019:12:49:18.061707766 +0000] conn=2806 op=0 BIND dn="" method=128 version=3

[06/Dec/2019:12:49:18.061784637 +0000] conn=2806 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0000187246 dn=""

[06/Dec/2019:12:49:18.066780892 +0000] conn=2806 op=1 SRCH base="cn=users,cn=compat,dc=lab,dc=PROJECT,dc=EXAMPLE,dc=ORG" scope=2 filter="(uid=USER)" attrs="distinguishedName"

[06/Dec/2019:12:49:18.067161659 +0000] conn=2806 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0000428881

[06/Dec/2019:12:49:18.067812476 +0000] conn=2807 fd=128 slot=128 connection from NNMi-Server to IdM-Server

[06/Dec/2019:12:49:18.068098286 +0000] conn=2807 op=0 BIND dn="" method=128 version=3

[06/Dec/2019:12:49:18.068165707 +0000] conn=2807 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0000161713 dn=""

[06/Dec/2019:12:49:18.071528890 +0000] conn=2807 op=1 SRCH base="cn=nnmi_access" scope=2 filter="(member=uid=USER,cn=users,cn=compat,dc=lab,dc=PROJECT,dc=EXAMPLE,dc=ORG)" attrs="1.1"

[06/Dec/2019:12:49:18.071562192 +0000] conn=2807 op=1 RESULT err=32 tag=101 nentries=0 etime=0.0000074662

[06/Dec/2019:12:49:18.072926385 +0000] conn=2807 op=2 SRCH base="cn=nnmi_access" scope=2 filter="(groupmember=uid=USER,cn=users,cn=compat,dc=lab,dc=PROJECT,dc=EXAMPLE,dc=ORG)" attrs="1.1"

[06/Dec/2019:12:49:18.072953042 +0000] conn=2807 op=2 RESULT err=32 tag=101 nentries=0 etime=0.0000067911

[06/Dec/2019:12:49:18.074036480 +0000] conn=2807 op=3 UNBIND

[06/Dec/2019:12:49:18.074048223 +0000] conn=2807 op=3 fd=128 closed - U1

This is what popped up in the access log this command was run on the NNMi server:

nnmldap.ovpl -diagnose USER

The output from the command is:

=========================================================

= Configuration

=========================================================

Diagnosing LDAP connectivity for user USER

Using LDAP configuration file <path to nms-auth-config.xml>

=========================================================

= Found User Distinguished Name: "uid=USER,cn=users,cn=compat,dc=lab,dc=PROJECT,dc=EXAMPLE,dc=ORG"

=========================================================

!!!!!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!

! No LDAP groups found for this User Distinguished Name.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!

! LDAP Appears to be Misconfigured. See above for more information.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Also, in nms-auth-config.xml,

<users>	Container element to include all user configuration details.
<userSearch>	Container element to include the configuration information for searching users.
<base> </base>	For example: <base> SAMAccountName={0} </base>. <base> uid={0} </base>
<baseContextDN> </baseContextDN>	For Active Directory, specify the portion of the directory service domain that stores user records. For example: For Active Directory CN=user,OU=Users,OU=Accounts,DC=mycompany,DC=com For other LDAP technologies ou=People,o=example.com
</userSearch> </users>

base is set to "uid=(0)"

and baseContextDN is set to "cn=users,cn=compat,dc=lab,dc=PROJECT,dc=EXAMPLE,dc=ORG"

A simple ldapsearch for "uid=USER" returns a boatload of info with many "memberOf" lines including

memberOf: cn=nnmi_access,cn=groups,cn=accounts,dc=lab,dc=PROJECT,dc=EXAMPLE,dc=ORG

Does this shed any light on the dilemma ?

______________________________________________________________________________________________

Daniel E. White
daniel.e.white@nasa.gov

NICS Linux Engineer
NASA Goddard Space Flight Center
8800 Greenbelt Road
Building 14, Room E175
Greenbelt, MD 20771

Office: (301) 286-6919

Mobile: (240) 513-5290

From: Rob Crittenden <rcritten@redhat.com>
Date: Thursday, December 5, 2019 at 14:31
To: Daniel White <daniel.e.white@nasa.gov>, FreeIPA users list <freeipa-users@lists.fedorahosted.org>
Subject: Re: [EXTERNAL] Re: [Freeipa-users] Anyone using FreeIPA/IdM and MicroFocus Network Automation ?

White, Daniel E. (GSFC-770.0)[NICS] wrote:

Thanks, Rob.

I will give it a try.

I made a posix group to use for application access - call it "nnmi_access"

I can ldapsearch using

(&(objectclass=groupofnames)(cn=nnmi_access)) member

and get back the members of the group like this:

member: uid=foobar,cn=users,cn=accounts,dc=…

So then the roleBase is "member". but what should the roleContextDN be ?

Maybe cn-nnmi-access,cn=groups,…,dc=… ?

That's the way I read their docs as well. I guess it won't hurt trying.

rob