389-ds-base

#50294 ManagedEntriedPlugin RDN incorrect according to documentation
Closed: wontfix by spichugi. Opened by jlanclos.

Closed: wontfix
Reopen Issue

Issue Description

According to documentation https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/deployment_guide/managed-entries
Configuring a template with mepRDNAttr: cn
and mepMappedAttr: cn: $uid Posix Group
should result with the rdn being cn=$uid Posix Group,ou=groups,.....
See 5.4.2 of documentation link.
However, mep.c code always uses the 1st part of the dn from the origin instead of using the mepMappedAttr value for mepRDNAttr.
This prevents the ability to create multiple managed entries of the same type for an origin entry.
We require the ability to create per-service HBAC rules for each host and would like to do so with MEP.

Package Version and Platform

All 389-ds-base versions with mep plugin

Steps to reproduce

  1. MEP configuration:
dn: cn=Host sshd HBAC Template,cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX
objectClass: mepTemplateEntry
objectClass: top
cn: Host sshd HBAC Template
mepStaticAttr: objectclass: ipaassociation
mepStaticAttr: objectclass: ipahbacrule
mepStaticAttr: objectclass: extensibleObject
mepStaticAttr: accessRuleType: allow
mepStaticAttr: ipaenabledflag: TRUE
mepStaticAttr: ipauniqueid: autogenerate
mepStaticAttr: memberservice: cn=sshd,cn=hbacservices,cn=hbac,$SUFFIX
mepMappedAttr: memberhost: $dn
mepMappedAttr: cn: ${serverhostname}_sshd
mepRDNAttr: cn
dn: cn=Host sshd HBAC Definition,cn=Definitions,cn=Managed Entries,cn=etc,$SUFFIX
objectClass: extensibleObject
objectClass: top
cn: Host sshd HBAC Definition
originscope: cn=computers,cn=accounts,$SUFFIX
originfilter: objectclass=ipahost
managedbase: cn=hbac,$SUFFIX
managedtemplate: cn=Host sshd HBAC Template,cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX

  1. Add ipa host:
    ipa host-add testhost123.$SUFFIX

  2. View mep created hbac rule:

ipa hbacrule-show testhost123_sshd --raw --all | sed 's/dc=.*/\$SUFFIX/g'
  dn: cn=testhost123.example.com,cn=hbac,$SUFFIX
  cn: testhost123_sshd
  cn: testhost123.example.com
  ipaenabledflag: TRUE
  memberhost: fqdn=testhost123.example.com,cn=computers,cn=accounts,$SUFFIX
  memberservice: cn=sshd,cn=hbacservices,cn=hbac,$SUFFIX
  accessRuleType: allow
  ipaUniqueID: 8a87f5da-49bb-11e9-9a14-525400b8c8c9
  mepManagedBy: fqdn=testhost123.example.com,cn=computers,cn=accounts,$SUFFIX
  objectClass: ipaassociation
  objectClass: ipahbacrule
  objectClass: extensibleObject
  objectClass: mepManagedEntry
  objectClass: top

Actual results

  dn: cn=testhost123.example.com,cn=hbac,$SUFFIX
  cn: testhost123_sshd
  cn: testhost123.example.com
  ipaenabledflag: TRUE
  memberhost: fqdn=testhost123.example.com,cn=computers,cn=accounts,$SUFFIX
  memberservice: cn=sshd,cn=hbacservices,cn=hbac,$SUFFIX
  accessRuleType: allow
  ipaUniqueID: 8a87f5da-49bb-11e9-9a14-525400b8c8c9
  mepManagedBy: fqdn=testhost123.example.com,cn=computers,cn=accounts,$SUFFIX
  objectClass: ipaassociation
  objectClass: ipahbacrule
  objectClass: extensibleObject
  objectClass: mepManagedEntry
  objectClass: top

RDN is incorrect. MEP plugin used the 1st part of the origin dn which was (fqdn=testhost123.$SUFFIX) instead of using the mepMappedAttr value for cn which should have been testhost123_sshd according to the template.

Expected results

According to template configuration, rdn should be created with the mepRDNAttr which was cn. The cn attr was defined as mepMappedAttr: cn: $serverhostname_sshd
dn should have been cn=testhost123_sshd,cn=hbac,$SUFFIX

  dn: cn=testhost123_sshd,cn=hbac,$SUFFIX
  cn: testhost123_sshd
  ipaenabledflag: TRUE
  memberhost: fqdn=testhost123.example.com,cn=computers,cn=accounts,$SUFFIX
  memberservice: cn=sshd,cn=hbacservices,cn=hbac,$SUFFIX
  accessRuleType: allow
  ipaUniqueID: 8a87f5da-49bb-11e9-9a14-525400b8c8c9
  mepManagedBy: fqdn=testhost123.example.com,cn=computers,cn=accounts,$SUFFIX
  objectClass: ipaassociation
  objectClass: ipahbacrule
  objectClass: extensibleObject
  objectClass: mepManagedEntry
  objectClass: top

The following patch to map.c fixes this behavior and will fall back to using the 1st part of the origin dn if rdn_val is null for some reason. 

--- a/ldap/servers/plugins/mep/mep.c
+++ b/ldap/servers/plugins/mep/mep.c
@@ -1329,13 +1329,15 @@ mep_create_managed_entry(struct configEntry *config, Slapi_Entry *origin)
         /* If an origin entry was supplied, the RDN value will be
          * the mapped value.  If no origin entry was supplied, the
          * value will be the mapping rule from the template. */
-        if (origin) {
+
+        // Obtain rdn_val from managed_entry 1st
+        rdn_val = slapi_entry_attr_get_charptr(managed_entry, rdn_type);
+        //Fall back to using 1st part of origin rdn if rdn_val is null.
+        if (origin && rdn_val == NULL) {
             const char *origin_dn = slapi_entry_get_dn(origin);
             rdn_vals = slapi_ldap_explode_dn(origin_dn, 1);
             rdn_val = rdn_vals[0];
-        } else {
-            rdn_val = slapi_entry_attr_get_charptr(managed_entry, rdn_type);
-        }
+        } 
         /* Create the DN using the mapped RDN value
          * and the base specified in the config. */

With the above changes, mep operates as described as expected from documentation.

ipa host-add testhost1234.$SUFFIX --force
....
ipa hbacrule-show --all --raw testhost1234_sshd | sed 's/dc=.*/$SUFFIX/g' 
  dn: cn=testhost1234_sshd,cn=hbac,$SUFFIX
  cn: testhost1234_sshd
  ipaenabledflag: TRUE
  memberhost: fqdn=testhost1234.example.com,cn=computers,cn=accounts,$SUFFIX
  memberservice: cn=sshd,cn=hbacservices,cn=hbac,$SUFFIX
  accessRuleType: allow
  ipaUniqueID: eec25dda-49be-11e9-9356-525400b8c8c9
  mepManagedBy: fqdn=testhost1234.example.com,cn=computers,cn=accounts,$SUFFIX
  objectClass: ipaassociation
  objectClass: ipahbacrule
  objectClass: extensibleObject
  objectClass: mepManagedEntry
  objectClass: top

What do you think @mreynolds ?

Metadata Update from @firstyear:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

Metadata Update from @mreynolds:
- Issue priority set to: normal
- Issue set to the milestone: 1.4.3

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3353

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
High
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.