In LDAP and X.500 the way you do this is typically using DIT Structure Rules and/or Name Forms - see http://tools.ietf.org/html/rfc4512 - 389 does not support them, but if we want to implement this feature in a more LDAP/X.500 friendly way, we could use them.

Replying to [comment:1 rmeggins]:

In LDAP and X.500 the way you do this is typically using DIT Structure Rules and/or Name Forms - see http://tools.ietf.org/html/rfc4512 - 389 does not support them, but if we want to implement this feature in a more LDAP/X.500 friendly way, we could use them.

It doesn't look to me that Rules and/or Name Forms really would solve this ticket, although it would get probably closer and would be nice to have.

I would like to augment the RFE with a few uses cases we want to support:

Creating new objects in a common container by generic users.
In this case what matters is the ability to contrain the RDN value, however a simple rule like newentry.rdn = cn=${binduser.uid} may not be sufficient.

Another important use case restricts the RDN or one of the values also based on attributes in the binduser entry, and in this case a strict equality with the attribute is certainly not sufficient.

A use case we want to support is allowing an ipa host to create principal objects for services on the same host. What this mean in LDAP terms is that a "user" with an attribute of krb5principalName (or better krb5CanonicalName) of host/my.server.name@REALM should only be allowed to create new objects where of the form <service>/my.server.name@REALM

Ie basically we need a regex style rule like:

{{{
newentry.krbPrincipalName = ${binduser.krbPrincipalName}/.+\/(.)@(.)/.+/\1@\2\/
}}}

This would force the newentry's principal name to match the first in some parts (in this case the fqdn part of the principal name and the realm).

HTH.

In the case of OTP, we want to restrict users to a certain format (UUID) when they create tokens. Our ACI is currently:

aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "Users can create self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)

In this ACI, the wildcard in the target is too broad.

thierry bordaz wrote:

The feature wants to control the RDN value of a target created entry. The value can be built from different attributes of the bind entry.
Not an immediate fix.

Talking further with Ludwig (thanks ludwig !), at least following "simple" use case can be
addressed using macro ACI.

A user bound as 'cn=user 1,cn=accounts,SUFFIX'
is only allowed to create entry 'cn=user 1,cn=users,cn=vaults,SUFFIX'
but not entry like 'cn=user 2,cn=users,cn=vaults,SUFFIX'

This can be achieved with the following aci:

{{{
dn: cn=vaults,dc=example,dc=com
aci: (target="ldap:///($dn),cn=users,cn=vaults,dc=example,dc=com")(targetattr=
"*")(version 3.0; acl "Allow add macro dn"; allow (add) userdn = "ldap:///($d
n),cn=accounts,dc=example,dc=com";)

}}}

Replying to [comment:7 tbordaz]:

Talking further with Ludwig (thanks ludwig !), at least following "simple" use case can be
addressed using macro ACI.

A user bound as 'cn=user 1,cn=accounts,SUFFIX'
is only allowed to create entry 'cn=user 1,cn=users,cn=vaults,SUFFIX'
but not entry like 'cn=user 2,cn=users,cn=vaults,SUFFIX'

Ah this is great, and would resolve a couple of our issues.
Does it also allow to do something like:
{{{
target="ldap:///prefix-($dn)-suffix,cn=users, ...
}}}

or is the substitution only valid for whole values ?

X'

Ah this is great, and would resolve a couple of our issues.
Does it also allow to do something like:
{{{
target="ldap:///prefix-($dn)-suffix,cn=users, ...
}}}

or is the substitution only valid for whole values ?

I think the intention was using macros for dn components, but implemtation seem just to do string matching. So the mechanism is:
- have an entrydn to apply the aci
- have a target rule in the macro aci containing ($dn): prefix($dn)suffix
- match the entrydn against the target --> get ($dn)
- replace ($dn) in the bind rule userdn=ldap///xxxx($dn)zzzzz to determine if the aci is valid

For vaults the exact ACI provided in comment 7 did not work because the user and the entry use different RDN attributes (uid=... vs. cn=...), so Thierry and I came up with a slightly different solution using macro ACI as well:

{{{
dn: cn=vaults,dc=example,dc=com
aci: (target="ldap:///cn=,cn=users,cn=vaults,dc=example,dc=com")(targetattr=
"")(version 3.0; acl "Allow add macro dn"; allow (add) userdn = "ldap:///ui
d=($attr.cn),cn=users,cn=accounts,dc=example,dc=com";)
}}}

The use of ($attr.cn) doesn't exactly match the examples provided in the documentation, but it seems to be working just fine:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Advanced_Access_Control_Using_Macro_ACIs.html#Advanced_Access_Control_Using_Macro_ACIs-Macro_ACI_Syntax.

Per ticket triage, set milestone to FUTURE.

Some mails summary:

we need host service (fqdn=ipa.f21,cn=computers,cn=accounts,dc=f21) to be able to add/modify/delete
it's services with DN "krbprincipalname=test/ipa.f21@F21,cn=services,cn=accounts,dc=f21".

This can be satisfy with the aci:

{{{
aci: (target="ldap:///krbprincipalname=test/($dn)@F21,cn=services,cn=accounts,dc=f21")(version 3.0; acl "allow managing of own services"; allow (add, delete, write) userdn = "ldap:///fqdn=($dn),cn=computers,cn=accounts,dc=f21";)
}}}

Now the aci (note '*' at the beginning of RDN target) is failing:

{{{
aci: (target="ldap:///krbprincipalname=*/($dn)@F21,cn=services,cn=accounts,dc=f21")(version 3.0; acl "allow managing of own services"; allow (add, delete, write) userdn = "ldap:///fqdn=($dn),cn=computers,cn=accounts,dc=f21";)
}}}

This is likely a bug in DS and the following ticket is opened https://fedorahosted.org/389/ticket/48141

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/1235

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.