389-ds-base

#51112 RootDN Access Contorl plugin blocks UNIX socket connections
Closed: wontfix by spichugi. Opened by yrro.

Closed: wontfix
Reopen Issue

Issue Description

I'm looking for a way to use the RootDN Access Control plugin, but still allow simple authentication via UNIX sockets. A number of external mamanagement tools (e.g., ipa-replica-manage list-ruv) are unable to use SASL EXTERNAL authentication to bypass the plugin.

(Aside: On the one hand, it seems like an inconsistency that simple authentication is blocked but SASL EXTERNAL authentication is still permitted. On the other hand, I guess if SASL EXTERNAL authentication were blocked as well then management tools like dsconf would stop working! Perhaps that could be mentioned in the plugin documentation.)

Package Version and Platform

1.4.3.8-1.fc32 on Fedora 32

Steps to reproduce

Before enabling the plugin, simple authentication works:

# ldapwhoami -H ldapi://... -W -D 'cn=Directory Manager'
Enter LDAP Password:
dn: cn=directory manager

After enabling the plugin, which has been configured only to allow connections from localhost:

# dsconf ldapi://... plugin root-dn show
dn: cn=RootDN Access Control,cn=plugins,cn=config
cn: RootDN Access Control
[...]
rootdn-allow-ip:: Ojox
rootdn-allow-ip: 127.0.0.1
# dsconf ldapi://... plugin root-dn enable
Enabled plugin 'RootDN Access Control'
# systemctl restart dirsrv@...
# ldapwhoami -H ldapi://... -W -D 'cn=Directory Manager'
Enter LDAP Password:
ldap_bind: Server is unwilling to perform (53)
        additional info: RootDN access control violation
# ldapwhoami -Y EXTERNAL -H ldapi://...
SASL/EXTERNAL authentication started
SASL username: gidNumer=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=Directory Manager

I guess that's the thing, the rootdn access control is really doin what you asked, which is only to allow from 127.0.0.1, and that's different to ldapi.

So I wonder what would be the right way to express "ldapi" is an "allowed ip"?

But as you say also, ldapi isn't an ip, so maybe yes, it should not consider it, because this can be controlled seperately through the ldapi-autobind config item.

@mreynolds thoughts? I think I would err to rootdn only working on TCP/IP because we control ldapi through a seperate stack. That makes the most sense to me.

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

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

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