389-users November 2018

389-users@lists.fedoraproject.org

14 participants
17 discussions

Announcing 389 Directory Server 1.4.0.19
by Mark Reynolds 15 Nov '18

15 Nov '18

389 Directory Server 1.4.0.19 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.19 Fedora packages are available on Fedora 28, 29, and rawhide. Rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=30902290 <https://koji.fedoraproject.org/koji/taskinfo?taskID=30902290> Fedora 29 https://koji.fedoraproject.org/koji/taskinfo?taskID=30903702 <https://koji.fedoraproject.org/koji/taskinfo?taskID=30903702> Fedora 28 https://koji.fedoraproject.org/koji/taskinfo?taskID=30903727 <https://koji.fedoraproject.org/koji/taskinfo?taskID=30903727> Bodhi F29 https://bodhi.fedoraproject.org/updates/FEDORA-2018-84b6b36c4d <https://bodhi.fedoraproject.org/updates/FEDORA-2018-84b6b36c4d> F28 https://bodhi.fedoraproject.org/updates/FEDORA-2018-e9447b1910 <https://bodhi.fedoraproject.org/updates/FEDORA-2018-e9447b1910> The new packages and versions are: * 389-ds-base-1.4.0.19-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.19.tar.bz2> Highlights in 1.4.0.19 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, use *dnf install 389-ds-base*, then run *dscreate*. For Cockput UI plugin use “dnf install cockpit-389-ds” See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation, setup, and upgrade See Source <https://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.o… 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.19 * Ticket 50026 - audit logs does not capture the operation where nsslapd-lookthroughlimit is modified * Ticket 50020 - during MODRDN referential integrity can fail erronously while updating large groups * Ticket 49999 - Finish up the transfer to React * Ticket 50004 - lib389 - improve X-ORIGIN schema parsing * Ticket 50013 - Log warn instead of ERR when aci target does not exist. * Ticket 49975 - followup for broken prefix deployment * Ticket 49999 - Add dist-bz2 target for Koji build system * Ticket 49814 - Add specfile requirements for python3-libselinux * Ticket 49814 - Add specfile requirements for python3-selinux * Ticket 49999 - Integrate React structure into cockpit-389-ds * Ticket 49995 - Fix issue with internal op logging * Ticket 49997 - RFE: ds-replcheck could validate suffix exists and it’s replicated * Ticket 49985 - memberof may silently fails to update a member * Ticket 49967 - entry cache corruption after failed MODRDN * Ticket 49975 - Add missing include file to main.c * Ticket 49814 - skip standard ports for selinux labelling * Ticket 49814 - dscreate should set the port selinux labels * Ticket 49856 - Remove backend option from bak2db * Ticket 49926 - Fix various issues with replication UI * Ticket 49975 - SUSE rpmlint issues * Ticket 49939 - Fix ldapi path in lib389 * Ticket 49978 - Add CLI logging function for UI * Ticket 49929 - Modifications required for the Test Case Management System * Ticket 49979 - Fix regression in last commit * Ticket 49979 - Remove dirsrv tests subpackage * Ticket 49928 - Fix various small WebUI schema issues * Ticket 49926 - UI - comment out dev cli patchs * Ticket 49926 - Add replication functionality to UI

1 0

Host based authentication not working as desired
by Leonard Lawton 08 Nov '18

08 Nov '18

I'm looking to setup HBAC for linux servers. People currently login to the hosts(via ssh) using ssh keys(no password). I was thinking that one way to control access is by denying the sshPublicKey(or even the uid, many options here) from being visible on the host by default, and creating an aci that allows the attribute to be visible based on the host. The visibility would be controlled by applying the aci to a group, and if the person is a member, then it's allowed. This does not work as I hoped though, since there is no bind performed as the user when the user logs in to the host. My questions.. 1) if is this a sane approach, how might I get around this issue? 2) If this is not a good way, what might be a better way to accomplish this? The caveats are I don't want to rely on posix group membership in the allowgroups in sshd.conf, nor do I want to require passwords to login

2 1

Configuring Account lockout policy for a individual user or a specific OU
by Zombie fork 08 Nov '18

08 Nov '18

Hi, Today we have a global account lockout policy in 389 which is applied to a specific instance. With many countries applying different compliance rules for securing personal data of their cititizen we see an increasing demand to have a seperate account lockout policy for special types of accounts or to be applied on a Country specific OU. Example. If we want to have the accountlockoutduration set to 60 minutes for a specific OU instead of the standard duration applied on a global policy , can it be done? I can see we can apply different password policies but that doesnt cover the account Lockout policies. Any help would be appreciated.

2 1

deref interop question
by Michael Ströder 08 Nov '18

08 Nov '18

HI! I vaguely remember that 389-DS also implements deref search control [1]. My question as a client developer: How does 389-DS deal with reference attributes being absent? Ciao, Michael. [1] https://tools.ietf.org/html/draft-masarati-ldap-deref-00

3 4

Unable to enable SSL using ldapmodify on 389-Directory/1.3.7.5
by Jason Jenkins 07 Nov '18

07 Nov '18

Hi I’m in the process of migrating from 389-Directory/1.2.11.15 -> 389-Directory/1.3.7.5. I’m trying to automate the setup. I’m finding that I can no longer enable SSL via the command line using ldapmodify. For V1.3.7.5 setup I followed https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h…. After restarting the service, SSL is not enabled. I am able to use the Admin Console to enable SSL. I found that the following is missing from when I setup via ldapmodify vs Admin Console. Following is missing even after following the RedHat documentation. nsSSL3: on nsSSL3Ciphers: -rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+ sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+ ,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_exp 56_sha,+tls_rsa_export1024_with_des_cbc_sha,+tls_rsa_aes_128 _256_sha nsKeyfile: alias/slapd-XXXXX-key3.db nsCertfile: alias/slapd-XXXXX-cert8.db # RSA, encryption, config dn: cn=RSA,cn=encryption,cn=config nsSSLToken: internal (software) nsSSLPersonalitySSL: server-cert nsSSLActivation: on objectClass: top objectClass: nsEncryptionModule cn: RSA I do notice that when I make the changes via ldapmodify it says that the changes have been successfully made, but they don’t show up in a search before and after a service restart. Also “nsslapd-security” never changes from off to on via command line edit. Here is some info about my system. OS: CentOS Linux release 7.5.1804 (Core) 389 packages installed: 389-adminutil-1.1.21-2.el7.x86_64 389-admin-console-doc-1.1.12-1.el7.noarch 389-admin-console-1.1.12-1.el7.noarch 389-ds-base-libs-1.3.7.5-28.el7_5.x86_64 389-ds-console-1.2.16-1.el7.noarch 389-ds-1.2.2-6.el7.noarch 389-ds-base-1.3.7.5-28.el7_5.x86_64 389-ds-console-doc-1.2.16-1.el7.noarch 389-admin-1.1.46-1.el7.x86_64 389-console-1.1.18-1.el7.noarch 389-dsgw-1.1.11-5.el7.x86_64 Version of Directory Server: 389-Directory/1.3.7.5 B2018.269.1826 Commands executing: ldapmodify -x -D "cn=Directory Manager" -w XXXX << EOF dn: cn=config changetype: modify replace: nsslapd-securePort nsslapd-securePort: 636 - replace: nsslapd-security nsslapd-security: on dn: cn=RSA,cn=encryption,cn=config changetype: modify replace: nsSSLToken nsSSLToken: internal (software) - replace: nsSSLPersonalitySSL nsSSLPersonalitySSL: server-cert - replace: nsSSLActivation nsSSLActivation: on EOF systemctl restart dirsrv(a)XXXXX.service

3 2

How to define templates and add an entry to the menu?
by "Stefan Günther" 02 Nov '18

02 Nov '18

Hello, when adding a new entry, the menu already contains entries like user, group or organizational unit, with preselected attributes. Is possible to add further entries to this menu, e.g. a kopano user with attributes out of the already imported kopano schema? Thanks for any hints in advance. Regards, Stefan

2 1

When binding non-anonymously, error code 48 - Anonymous access is not allowed
by Graham Leggett 02 Nov '18

02 Nov '18

Hi all, My Jira server just forgot all of it’s LDAP settings for no clear reason. While trying to put the settings back, Jira is logging into 389ds by binding as the user "cn=Atlassian,dc=x”. 389ds is in return responding as follows: [LDAP: error code 48 - Anonymous access is not allowed]; nested exception is javax.naming.AuthenticationNotSupportedException: [LDAP: error code 48 - Anonymous access is not allowed] [02/Nov/2018:17:11:23 +0200] conn=140630 op=0 BIND dn="cn=Atlassian,dc=x" method=128 version=3 [02/Nov/2018:17:11:23 +0200] conn=140630 op=0 RESULT err=48 tag=97 nentries=0 etime=1 [02/Nov/2018:17:11:23 +0200] conn=140630 op=-1 fd=134 closed - B1 Why would 389ds complain that anonymous access is not allowed on a non-anonymous bind? What am I missing? (389-ds-base-1.2.11.15-97.el6_10.x86_64 on RHEL6) Regards, Graham —

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2018