Problem browsing LDAP with Outlook
by Chris Bryant
When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
Thanks,
Chris
USA.NET
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
3 years, 3 months
MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser
Hi,
I'm new to 389-ds and last week downloaded and installed the software.
I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query
the server using TLS/SSL, and all appears working.
I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client
can see the unix users and groups using the "getent password" or "getent group" commands.
Now, here's where I'm getting tripped up..........
I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations.
I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-grou...)
which is close enough to CentOS that the initial commands worked.
I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system.
I created a test group (that I didn't enable a posix GID) and tried to add a single user via:
Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add.
When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error:
"Cannot save to directory server.
netscape.ldap.LDAPException: error resiult(65): Object class violation"
And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors:
"Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed
[17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)"
So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before
I even try to filter login access via groups on my client system.
I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I
should set the "value" to be.
I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute
on individual users, only groups.
This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions.
Any suggestions would be appreciated.
3 years, 4 months
ldapsearch doesn't return the userpassword field
by Janet Houser
Hi,
I've been looking through the archives for information, but I haven't stumbled on a solution to my problem.
I'm running ds-389 (389-ds-base-1.3.4.0) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS
which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly.
I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has
of the password when an ldapsearch is issued.
However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have
to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't
quite get it right.
Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password.
Thanks,
5 years, 6 months
389ds on lxc debian
by Angel Bosch Mora
hi,
I'm trying to install 1.1.43-1+b1 package on lxc with debian 9 and I get th=
is error:
invoke-rc.d: initscript dirsrv-admin, action "start" failed.
=E2=97=8F dirsrv-admin.service - 389 Administration Server.
Loaded: loaded (/lib/systemd/system/dirsrv-admin.service; disabled; vend=
or preset: enabled)
Active: failed (Result: exit-code) since Tue 2018-01-30 12:32:36 CET; 6m=
s ago
Process: 15226 ExecStart=3D/usr/sbin/apache2 -k start -f /etc/dirsrv/admi=
n-serv/httpd.conf (code=3Dexited, status=3D1/FAILURE)
gen 30 12:32:35 Jafar systemd[1]: dirsrv-admin.service: Failed to reset dev=
ices.list: Operation not permitted
gen 30 12:32:35 Jafar systemd[1]: Starting 389 Administration Server....
gen 30 12:32:36 Jafar systemd[1]: dirsrv-admin.service: Control process exi=
ted, code=3Dexited status=3D1
gen 30 12:32:36 Jafar systemd[1]: Failed to start 389 Administration Server=
..
gen 30 12:32:36 Jafar systemd[1]: dirsrv-admin.service: Unit entered failed=
state.
gen 30 12:32:36 Jafar systemd[1]: dirsrv-admin.service: Failed with result =
'exit-code'.
it seems a problema about lxc privileges.
is there anyone running 389 with lxc?
regards,
abosch
-- Institut Mallorquí d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'és destinatària i pot contenir informació confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permís exprés de l'IMAS. Si no sou la persona destinatària que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreça electrònica de la persona remitent.
-- Abans d'imprimir aquest missatge, pensau si és realment necessari.
5 years, 10 months
Announcing 389 Directory Server 1.4.0.5
by Mark Reynolds
389 Directory Server 1.4.0.5
The 389 Directory Server team is proud to announce 389-ds-base
version 1.4.0.5
Fedora packages are available on Fedora 28(rawhide).
https://koji.fedoraproject.org/koji/taskinfo?taskID=24602683
<https://koji.fedoraproject.org/koji/taskinfo?taskID=24602683>
The new packages and versions are:
* 389-ds-base-1.4.0.5-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.0.5.tar.bz2>
Highlights in 1.4.0.5
* Security and 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, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
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.0.5
* CVE-2017-15134 389-ds-base: Remote DoS via search filters
in slapi_filter_sprintf
* Ticket 49554 - Update Makefile for README.md
* Ticket 49554 - update readme
* Ticket 49546 - Fix broken snmp MIB file
* Ticket 49400 - Make CLANG configurable
* Ticket 49530 - Add pseudolocalization option for dbgen
* Ticket 49523 - Fixed skipif marker, topology fixture and log message
* Ticket 49544 - Double check pw prompts
* Ticket 49548 - Cockpit UI - installer should also setup Cockpit
5 years, 10 months
Announcing 389 Directory Server 1.3.7.9
by Mark Reynolds
389 Directory Server 1.3.7.9
The 389 Directory Server team is proud to announce 389-ds-base
version 1.3.7.9
Fedora packages are available on Fedora 27.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1022742
<https://koji.fedoraproject.org/koji/buildinfo?buildID=1022742>
https://bodhi.fedoraproject.org/updates/FEDORA-2018-3d60a6932b
<https://bodhi.fedoraproject.org/updates/FEDORA-2018-3d60a6932b>
The new packages and versions are:
* 389-ds-base-1.3.7.9-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.3.7.9.tar.bz2>
Highlights in 1.3.7.9
* Security and 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, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
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.3.7.9
* CVE-2017-15134 - Remote DoS via search filters in slapi_filter_sprintf
* Ticket 49546 - Fix broken snmp MIB file
* Ticket 49541 - Replica ID config validation fix
* Ticket 49370 - Crash when using a global and local pw policies
* Ticket 49540 - Indexing task is reported finished too early
regarding the backend status
* Ticket 49534 - Fix coverity regression
* Ticket 49541 - repl config should not allow rid 65535 for masters
* Ticket 49370 - Add all the password policy defaults to a new
local policy
* Ticket 49526 - Improve create_test.py script
* Ticket 49534 - Fix coverity issues and regression
* Ticket 49523 - memberof: schema violation error message is confusing
as memberof will likely repair target entry
* Ticket 49532 - coverity issues - fix compiler warnings & clang issues
* Ticket 49463 - After cleanALLruv, there is a flow of keep alive DEL
* Ticket 48184 - close connections at shutdown cleanly.
* Ticket 49509 - Indexing of internationalized matching rules is failing
* Ticket 49531 - coverity issues - fix memory leaks
* Ticket 49529 - Fix Coverity warnings: invalid deferences
* Ticket 49413 - Changelog trimming ignores disabled replica-agreement
* Ticket 49446 - cleanallruv should ignore cleaned replica Id in
processing changelog if in force mode
* Ticket 49278 - GetEffectiveRights gives false-negative
* Ticket 49524 - Password policy: minimum token length fails when the
token length is equal to attribute length
* Ticket 49493 - heap use after free in csn_as_string
* Ticket 49495 - Fix memory management is vattr.
* Ticket 49471 - heap-buffer-overflow in ss_unescape
* Ticket 49449 - Load sysctl values on rpm upgrade.
* Ticket 49470 - overflow in pblock_get
* Ticket 49474 - sasl allow mechs does not operate correctly
* Ticket 49460 - replica_write_ruv log a failure even when it succeeds
5 years, 10 months
Announcing 389 Directory Server 1.3.6.13
by Mark Reynolds
389 Directory Server 1.3.6.13
The 389 Directory Server team is proud to announce 389-ds-base
version 1.3.6.13
Fedora packages are available from the Fedora 26.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1022740
<https://koji.fedoraproject.org/koji/buildinfo?buildID=1022740>
https://bodhi.fedoraproject.org/updates/FEDORA-2018-7f7f7051e9
<https://bodhi.fedoraproject.org/updates/FEDORA-2018-7f7f7051e9>
The new packages and versions are:
* 389-ds-base-1.3.6.13-1 Fedora 26
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.3.6.13.tar.bz2>
Highlights in 1.3.6.13
* Security and 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, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
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.3.6.13
* CVE-2017-15134 - Remote DoS via search filters in slapi_filter_sprintf
* Ticket 49463 - After cleanALLruv, there is a flow of keep alive DEL
* Ticket 49509 - Indexing of internationalized matching rules is failing
* Ticket 49524 - Password policy: minimum token length fails when the
token length is equal to attribute length
* Ticket 49495 - Fix memory management is vattr.
* Ticket 48118 - Changelog can be erronously rebuilt at startup
* Ticket 49474 - sasl allow mechs does not operate correctly
5 years, 10 months
Re: [SOLVED] Password expiration with 389-ds and sssd on CentOS
by Mitch Patenaude
After doing some digging, I found a piece of advice that setting 'ChallengeResponseAuthentication yes' in sshd_config would give better error messages. However, it seems to have solved the problem entirely, though I can't say I understand how.
-- Mitch Patenaude
On 1/31/18, 9:19 AM, "Mitch Patenaude" <mpatenaude(a)shutterfly.com> wrote:
Hi, following some advice I received here a few months back, I'm trying to get sssd set up for auth with a 389-ds backend. Almost everything works well, except for the ability to change expired passwords. When A user has an expired password, he/she is unable to change it. The exchange looks like:
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user testacct2.
Current Password:
New password:
Retype new password:
Password change failed. Server message: Failed to update password
passwd: Authentication token is no longer valid; new one required
And the entry in /var/log/secure looks like:
Jan 30 16:44:37 ldap01 passwd: pam_sss(passwd:chauthtok): User info message: Password change failed. Server message: Failed to update password
Jan 30 16:44:37 ldap01 passwd: pam_sss(passwd:chauthtok): Password change failed for user testacct2: 12 (Authentication token is no longer valid; new one required)
And the associated entry in /etc/pam.d/system-auth is:
password sufficient pam_sss.so use_authtok
I'm hoping that somebody else here has solved this problem.
-- Mitch Patenaude
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
5 years, 10 months
Password expiration with 389-ds and sssd on CentOS
by Mitch Patenaude
Hi, following some advice I received here a few months back, I'm trying to get sssd set up for auth with a 389-ds backend. Almost everything works well, except for the ability to change expired passwords. When A user has an expired password, he/she is unable to change it. The exchange looks like:
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user testacct2.
Current Password:
New password:
Retype new password:
Password change failed. Server message: Failed to update password
passwd: Authentication token is no longer valid; new one required
And the entry in /var/log/secure looks like:
Jan 30 16:44:37 ldap01 passwd: pam_sss(passwd:chauthtok): User info message: Password change failed. Server message: Failed to update password
Jan 30 16:44:37 ldap01 passwd: pam_sss(passwd:chauthtok): Password change failed for user testacct2: 12 (Authentication token is no longer valid; new one required)
And the associated entry in /etc/pam.d/system-auth is:
password sufficient pam_sss.so use_authtok
I'm hoping that somebody else here has solved this problem.
-- Mitch Patenaude
5 years, 10 months
CVE-2017-15135
by Torgersen, Eric A
Are there any details or guidance available regarding the following:
https://bugzilla.redhat.com/show_bug.cgi?id=1525628
Eric Torgersen
Systems Architect | Information Technology Services | Enterprise Infrastructure Services
518-442-6471 | etorgersen(a)albany.edu
University at Albany
1400 Washington Ave | Albany, NY 12222
Confidentiality Notice: The information contained in this electronic transmission is confidential and is intended for the use of the individual(s) or entity(ies) named above only. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this transmission is strictly prohibited. If you have received this transmission in error, please destroy any and all copies of the transmission and notify the sender immediately.
5 years, 10 months
