Is it possible to restrict some users to read,search,compare just specific
attributes but still use objectclass=* as a filter?
aci: (targetattr="uid || givenName || cn || sn || manager ||
mail")(targetfilter="(objectclass=*)")(version 3.0;aci "Access for app to
specific needed attributes";allow (read,compare,search)
If I do a ldapsearch with this user (myuser is in the group my-group):
ldapsearch -b "dc=rnp,dc=local" -W -D "uid=myuser" uid=alberto.viana
Returns me the user alberto.viana and the attributes that acis allows
but if I do:
ldapsearch -b "dc=rnp,dc=local" -W -D "uid=myuser" objectclass=*
returns me nothing.
I'm looking at the RH documentation for passwordMaxSeqSets, found here:
Their wording seems a little unclear, to me. The paragraph, before the
example states: "If you set the passwordMaxSeqSets parameter to a
value higher than 0, Directory Server rejects passwords with duplicate
monotonic sequences exceeding the length set in the parameter."
But, in their example, they list a password with two sequences of "XYZ".
And they say that setting the value to 2 would prevent that password.
But according to the paragraph before the example, shouldn't it be set
I have passwordMaxSequence set to 3. Can somebody clarify how
passwordMaxSeqSets should be set to prevent any duplicate sequences?
I recently upgraded my system from RHEL7 to RHEL8, together with 389ds.
Apparently this has caused to upgrade the storage scheme of the user
passwords to PBKDF2_SHA256. Everything works fine except freeradius does
not support this storage scheme at the moment.
How can I downgrade the storage scheme in 389ds to something that is
supported by freeradius in such a way, that doesn't force my users to
change their passwords?
I have one historical plug-in (from times of SunOne Directory), it was
in past ported for 1.2 version of 389 DS. But it fails to work with 1.4.
It is a bit more complicated than the one I was seeking help before, but
maybe it is possible to replace it with some standard plug-in. However,
I didn't find any suitable. :(
We are using attribute named entryStatus with several possible values
like prepared, active, marked, dead - those are used for keeping status
of user entry.
I need to keep track when and by whom was entryStatus attribute
modified. For those informations, we have two attributes
entryStatusTimestamp and entryStatusModifier attributes. And every time
entryStatus is changed, our plugin changes automatically those two
Is there any standard, or maybe some contributed plugin how I can
Jan Tomasek aka Semik
in past, I've created a simple plug-in for disabling authenticated binds
over non-encrypted lines. But still allowing anonymous binds over LDAP.
I did know about nsslapd-require-secure-binds but if recall correctly it
is including SASL authenticated binds which I believe protects only user
password and not transferred data.
I published plug-in here:
but it is maybe obsoleted today.
Today I think is TLS a must. Is it possible to disable 389 port at all?
Or instruct 389 DS to bind port 389 on localhost?
Jan Tomasek aka Semik
We have the following scenario:
We use a "global" password policy at cn=config where a customer of ours defines:
We provide as default configuration "passwordMustChage: on" to force a new user to chage the initial password. In this setup a user whose password expired, i.e. also after this user is created and needs to change its initial password, cannot login to the account, but he can change the password.
The customer now wants a setup which prevents a user whose password expired from changing the password. A plugin "Account Policy Plugin" can therefore be activated by the customer, which uses the following configuration:
dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
As a consequence, the initial password change does not work anymore, thus the customer must change to "passwordMustChange: off". This would probably be acceptable.
A problem is, however, that a user account which has its own user password policy with "passwordexp: off" and "passwordmustchange: off" is affected by the plugin in such a way that the attribute passwordExpirationTime of the user itself is evaluated and the attribute passwordexp of the user password policy is ignored. That means, a user password policy for special user accounts without password expiration cannot be used in combination with the Account Policy Plugin.
Can the plugin be configured to enable this possiblity or is there another way to achieve the desired behaviour?
All developers, and any other interested individuals, should make sure
to "watch" this repo. We moved off of Pagure and onto github, but the
Pagure subscribers were not migrated. So if you want to keep an eye on
what's happening make sure to watch this project!
389 Directory Server Development Team