ACI limiting read to groups a user is member of
by Grant Byers
Hi,
In an effort to tighten search and read permissions on our internal
directory server, we've limited accounts to read certain attributes of
"self". They have search on the entire tree, but otherwise no read
perms. This is all well and good for clients that utilize the memberOf
attribute of self, but not so good for applications that utilize
memberUid, or insist on searching for groupOfUniqueNames or
groupOfNames then enumerating them programmatically to determine which
groups the user belongs to after binding as the user.
So. I've been reading docs and haven't been able to find anything, but I
was wanting to do something like this;
dn: ou=groups,dc=example,dc=com
aci: (targetattr = "*")
(targetfilter = "(&(objectClass=groupOfUniqueNames)(uniqueMember={{rdn
of self}})")
(version 3.0; acl "Allow authenticated users to read own group
membership"; allow (read,compare,search)
(userdn="ldap:///all");)
where the target filter limits results to only those that match
uniqueMember={{rdn of self}}
Is this possible?
Thanks,
Grant
4 years, 1 month
SizeLimit Exceeded although Limit should be much higher
by Julian Kippels
Hi,
I am having a small problem with a slightly larger lookup. The
SizeLimit and LookthroughLimit are both set to 300000, but when I do a
larger search, I still get:
> # search result
> search: 2
> result: 4 Size limit exceeded
>
> # numResponses: 50001
> # numEntries: 50000
Where else could I look for limits, that could be applicable here? I am
using 389-ds version 1.2.2. The search in question is in a base that
has around 55000 Entries and the filter is something like
(modifytimestamp>$oldtimestamp). The modifytimestamp-attribute is
indexed for presence and equality.
Thanks
Julian
4 years, 1 month
Announcing 389 Directory Server 1.4.3.3
by Mark Reynolds
389 Directory Server 1.4.3.3
The 389 Directory Server team is proud to announce 389-ds-base version
1.4.3.3
Fedora packages are available on Fedora 32 adn Rawhide.
https://koji.fedoraproject.org/koji/taskinfo?taskID=41485060
<https://koji.fedoraproject.org/koji/taskinfo?taskID=41485060> - Rawhide
(Fedora 33)
https://koji.fedoraproject.org/koji/taskinfo?taskID=41484528
<https://koji.fedoraproject.org/koji/taskinfo?taskID=41484528> - Fedora 32
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2131928cb1
<https://bodhi.fedoraproject.org/updates/FEDORA-2020-2131928cb1> - Bodhi
The new packages and versions are:
* 389-ds-base-1.4.3.3-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.3.3.tar.bz2>
Highlights in 1.4.3.3
* Bug fixes
Installation and Upgrade
See Download <https://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
steps required.
There are no upgrade steps besides installing the new rpms
See Install_Guide
<https://www.port389.org/docs/389ds/howto/howto-install-389.html> for
more information about the initial installation and setup
See Source <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
New UI Progress (Cockpit plugin)
The new UI is fully functional. There are still parts that need to be
converted to ReactJS, but every feature is available.
Configuration Tab
Functional
Written in ReactJS
Server Tab Yes Yes
Security Tab Yes Yes
Database Tab Yes Yes
Replication Tab Yes Yes
Schema Tab Yes Yes
Plugin Tab Yes Yes
Monitor Tab Yes Yes
Navigation Tab Yes No
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.4.3.3
* Issue 50855 - remove unused file from UI
* Issue 50855 - UI: Port Server Tab to React
* Issue 49845 - README does not contain complete information on building
* Issue 50686 - Port fractional replication test cases from TET to
python3 part 1
* Issue 49623 - cont cenotaph errors on modrdn operations
* Issue 50882 - Fix healthcheck errors for instances that do not have
TLS enabled
* Issue 50886 - Typo in the replication debug message
* Issue 50873 - Fix healthcheck and virtual attr check
* Issue 50873 - Fix issues with healthcheck tool
* Issue 50028 - Add a new CI test case
* Issue 49946 - Add a new CI test case
* Issue 50117 - Add a new CI test case
* Issue 50787 - fix implementation of attr unique
* Issue 50859 - support running only with ldaps socket
* Issue 50823 - dsctl doesn’t work with ‘slapd-‘ in the instance name
* Issue 49624 - cont - DB Deadlock on modrdn appears to corrupt
database and entry cache
* Issue 50867 - Fix minor buildsys issues
* Issue 50737 - Allow building with rust online without vendoring
* Issue 50831 - add cargo.lock to allow offline builds
* Issue 50694 - import PEM certs on startup
* Issue 50857 - Memory leak in ACI using IP subject
* Issue 49761 - Fix CI test suite issues
* Issue 50853 - Fix NULL pointer deref in config setting
* Issue 50850 - Fix dsctl healthcheck for python36
* Issue 49990 - Need to enforce a hard maximum limit for file descriptors
* Issue 48707 - ldapssotoken for authentication
--
389 Directory Server Development Team
4 years, 1 month
Announcing 389 Directory Server 1.4.1.15
by Mark Reynolds
389 Directory Server 1.4.1.15
The 389 Directory Server team is proud to announce 389-ds-base version
1.4.1.15
Fedora packages are available on Fedora 30.
https://koji.fedoraproject.org/koji/taskinfo?taskID=41482951
<https://koji.fedoraproject.org/koji/taskinfo?taskID=41482951> - Fedora 30
Bodhi
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9eb0691f9e
<https://bodhi.fedoraproject.org/updates/FEDORA-2020-9eb0691f9e>
The new packages and versions are:
* 389-ds-base-1.4.1.15-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.1.15.tar.bz2>
Highlights in 1.4.1.15
* Bug fixes
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
steps required.
There are no upgrade steps besides installing the new rpms
See Install_Guide
<http://www.port389.org/docs/389ds/howto/howto-install-389.html> for
more information about the initial installation and setup
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
New UI Progress (Cockpit plugin)
The new UI is fully functional. There are still parts that need to be
converted to ReactJS, but every feature is available.
Configuration Tab
Functional
Written in ReactJS
Server Tab Yes Yes
Security Tab Yes Yes
Database Tab Yes Yes
Replication Tab Yes Yes
Schema Tab Yes Yes
Plugin Tab Yes Yes
Monitor Tab Yes Yes
Navigiation Bar Yes No
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.4.1.15
* Issue 50855 - remove unused file from UI
* Issue 50855 - UI: Port Server Tab to React
* Issue 50636 - Crash during sasl bind
* Issue 49623 - cenotaph errors on modrdn operations (part 2)
* Issue 50882 - Fix healthcheck errors for instances that do not have
TLS enabled
* Issue 50886 - Typo in the replication debug message
* Issue 50873 - Fix healthcheck and virtual attr check
* Issue 50873 - Fix issues with healthcheck tool
* Issue 50857 - Memory leak in ACI using IP subject
* Issue 49624 - DB Deadlock on modrdn appears to corrupt database and
entry cache (part 2)
* Issue 50823 - dsctl doesn’t work with ‘slapd-‘ in the instance name
* Issue 50824 - dsctl remove fails with “name ‘ensure_str’ is not defined”
* Issue 50798 - incorrect bytes in format string(fix import issue)
* Issue 50798 - incorrect bytes in format string
* Issue 50850 - Fix dsctl healthcheck for python36
* Issue 49990 - Need to enforce a hard maximum limit for file descriptors
--
389 Directory Server Development Team
4 years, 1 month
Sequence rollover; local offset updated
by Christophe Trefois
First off, apologies for double posting to here and ipa mailing list, but we are getting a bit uneasy, and also the issue seems to come from the code in 389-ds directly, so this seems more appropriate.
We are using ipa-server ipa-server-4.6.5-11.el7.centos.3.x86_64 with 389-ds-base-1.3.9.1-10.el7.x86_64 on CentOS 7.7.
Since couple days some of our replicas are coming with "csngen_new_csn - Sequence rollover; local offset updated." messages in the slapd erorr logs.
We use the python "ipa_check_consistency" and replication seems to be fine.
We checked all replicas, and they are all in time sync with ntp (updated) with no visible offset.
is this anything to worry about, and how can we make those messages to stop appearing?
4 years, 1 month
MAP_MONITOR_DISABLED
by CHAMBERLAIN James
I’ve started getting a lot of messages in 389-ds errors log - so many, in fact, that /var/log filled up and 389-ds stopped running. Has anyone ever seen anything like this? Any idea what to do about it? It’s been mentioned to me that schemacompat comes from FreeIPA. I'm not running FreeIPA, but do have some IPA-related packages installed which I've never done anything with. I’m running 389-ds-1.3.9.1-10.el7.x86_64 on CentOS 7.6.1810.
[03/Feb/2020:12:33:01.221082648 -0500] - ERR - schemacompat - map rdlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.223069563 -0500] - ERR - schema-compat - map_unlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.227811577 -0500] - ERR - schemacompat - map rdlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.229733129 -0500] - ERR - schema-compat - map_unlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.265329950 -0500] - ERR - schemacompat - map rdlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.267374384 -0500] - ERR - schema-compat - map_unlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.320586601 -0500] - ERR - schemacompat - map rdlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.322592539 -0500] - ERR - schema-compat - map_unlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.345331958 -0500] - ERR - schemacompat - map rdlock: old way MAP_MONITOR_DISABLED
[03/Feb/2020:12:33:01.347268893 -0500] - ERR - schema-compat - map_unlock: old way MAP_MONITOR_DISABLED
Thanks,
James
This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at 3DS.compliance-privacy(a)3ds.com<mailto:3DS.compliance-privacy@3ds.com>
For other languages, go to https://www.3ds.com/terms/email-disclaimer
4 years, 1 month
healthcheck problems
by Alberto Viana
Hi Guys,
In 389 version 1.4.2.4 healthcheck works fine:
~# dsconf RNP healthcheck
Enter password for cn=Directory Manager on ldaps://localhost:
Beginning lint report, this could take a while ...
Checking Backends ...
Checking Config ...
Checking Encryption ...
Checking ReferentialIntegrityPlugin ...
Healthcheck complete!
And seems that function was moved to dsctl
but in 1.4.2.5 I got this error:
~# dsctl RNP healthcheck
Beginning lint report, this could take a while ...
Checking Backends ...
Checking Config ...
Checking Encryption ...
Checking FSChecks ...
Checking ReferentialIntegrityPlugin ...
Checking MonitorDiskSpace ...
Checking Replica ...
Checking Changelog5 ...
Checking DSEldif ...
Error: [Errno 2] No such file or directory:
'/etc/dirsrv/slapd-{instance_name}/dse.ldif'
Is that a bug?
Thanks
Alberto Viana
4 years, 1 month