September 2019 - 389-users - Fedora mailing-lists

Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers 01 Feb '21

01 Feb '21

I'm trying to setup a replication with a certificate based authentication between supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server certificates in the certdbs have been signed. The certificates all have the 'u' flag, and the CA has the C and T flag. The replication (on the supplier) has been setup such that TLS and certificate based authentication is used, see extract from the replication agreement object: objectclass: nsds5ReplicationAgreement nsds5replicahost: <consumer-hostname> nsds5replicaport: 389 nsds5replicatransportinfo: TLS nsds5replicabindmethod: SSLCLIENTAUTH Trying to initialize the consumer raises this error in the error-log of the supplier (the host sending the starttls connection request): Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication) (missing client certificate) The certificate that the server should have sent can, however, be used with the ldap commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the client sends the certificate during the TLS handshake, while in the above case it doesn't. The TLS handshake defines that the client has to send an "empty certificate" if it does not have a certificate that has been issued by a CA offered by the server during the handshake. I can't see a reason for the client to think the condition isn't met. The certificate with which the server (supplier) is setup is the only one available. Is it possible that the server does not know which certificate it has to use for authentication with the consumer server? And if so, how do I make the server know? The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with 1.4.0.3. Thanks, Eugen

3 11

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

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 2

MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser 06 Aug '20

06 Aug '20

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-groups…) 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.

6 19

Re: urp_fixup_add_cenotaph errors
by Morgan, Iain (ARC-TN)[InuTeq, LLC] 05 Nov '19

05 Nov '19

On 9/8/19, 15:40, "William Brown" <wbrown(a)suse.de> wrote: > On 7 Sep 2019, at 08:33, Morgan, Iain (ARC-TN)[InuTeq, LLC] <iain.morgan(a)nasa.gov> wrote: > > Hello Marc, > > Yes, it is 389-ds-base1.3.9.1-10.el7, but we are not using IPA and there are no memberOf plugin errors. The actual modrdn operations have error=0. If we may, can we ask what the modrdn operations were, and to ask a little about your tree layout so we could try to understand more about this? Sure, there's nothing unusual regarding the tree layout. There's a single backend with ou=People,.... and ou=Groups,.... One thing that may be relevant is that this is a stand-alone server -- replication has not been configured. From the access log: [09/Sep/2019:15:05:08.577399600 -0700] conn=2233897 op=2 SRCH base="ou=Groups,dc=nas,dc=nasa,dc=gov" scope=2 filter="(|(cn=temp)(cn=testgroup))" attrs="cn" [09/Sep/2019:15:05:08.577630700 -0700] conn=2233897 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000323261 [09/Sep/2019:15:05:08.578316196 -0700] conn=2233897 op=3 MODRDN dn="cn=temp,ou=Groups,dc=nas,dc=nasa,dc=gov" newrdn="cn=testgroup" newsuperior="(null)" [09/Sep/2019:15:05:08.581595207 -0700] conn=2233897 op=3 RESULT err=0 tag=109 nentries=0 etime=0.0003326527 From the errors log: [09/Sep/2019:15:05:08.580235717 -0700] - ERR - conn=2233897 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 -- Iain Morgan

3 6

Limiting connections from openLDAP Clients to 389 Directory Server
by Abhisheyk Deb 30 Sep '19

30 Sep '19

Hi, I know this might be a very vague question, but is there any way I can limit the number of connections that a 389 Directory Server Instance accepts from OpenLDAP Clients (for example like 10) running nslcd. Once this maximum number of connections are achieved, any further requests will not be worked upon. Any help would be greatly appreciated. Thank you Abhishek Deb

2 1

Announcing 389 Directory Server 1.4.1.8
by Mark Reynolds 28 Sep '19

28 Sep '19

389 Directory Server 1.4.1.8 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.1.8 Fedora packages are available on Fedora 30 and rawhide. https://koji.fedoraproject.org/koji/taskinfo?taskID=37896488 <https://koji.fedoraproject.org/koji/taskinfo?taskID=37896488> - Fedora 31 https://koji.fedoraproject.org/koji/taskinfo?taskID=37898073 <https://koji.fedoraproject.org/koji/taskinfo?taskID=37898073> - Fedora 30 Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2019-27733d7112 <https://bodhi.fedoraproject.org/updates/FEDORA-2019-27733d7112> - Fedora 31 https://bodhi.fedoraproject.org/updates/FEDORA-2019-511a7e401d <https://bodhi.fedoraproject.org/updates/FEDORA-2019-511a7e401d> - Fedora 30 The new packages and versions are: * 389-ds-base-1.4.1.8-3 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.8.tar.bz2> Highlights in 1.4.1.8 * 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 No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes No (coming soon!) Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes 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.1.8 * Issue 50545 - Port repl-monitor.pl to lib389 CLI * Issue 50620 - Fix regressions from 50506 (slapi_enry_attr_get_ref) * Bump version to 1.4.1.7 * Issue 50581 - ns-slapd crashes during ldapi search * Issue 50604 - Fix UI validation * Issue 50593 - Investigate URP handling on standalone instance * Issue 50506 - Fix regression for relication stripattrs * Issue 50546 - fix more UI issues(part 2) * Issue 50546 - fix more UI issues * Issue 50546 - Fix various issues in UI * Issue 50576 - Same proc uid/gid maps to rootdn for ldapi sasl * Issue 50567, 50568 - strict host check disable and display container version * Issue 50550 - DS installer debug messages leaking to ipa-server-install * Issue 50545 - Port fixup-memberuid and add the functionality to CLI and UI * Issue 50572 - After running cl-dump dbdir/cldb/*ldif.done are not deleted * Issue 50578 - Add SKIP_AUDIT_CI flag for Cockpit builds * Issue 50349 - filter schema validation * Issue 48055 - CI test-(Plugin configuration should throw proper error messages if not configured properly) * Issue 49324 - idl_new fix assert * Issue 50564 - Fix rust libraries by default and improve docker * Issue 50206 - Refactor lock, unlock and status of dsidm account/role * Issue 49324 - idl_new report index name in error conditions * Issue 49761 - Fix CI test suite issues * Issue 50506 - Fix regression from slapi_entry_attr_get_ref refactor * Issue 50499 - Audit fix - Update npm ‘eslint-utils’ version * Issue 49624 - modrdn silently fails if DB deadlock occurs * Issue 50542 - fix crash in filter tests * Issue 49761 - Fix CI test suite issues * Issue 50542 - Entry cache contention during base search * Issue 50462 - Fix CI tests * Issue 50490 - objects and memory leaks * Issue 50538 - Move CI test to individual file * Issue 50538 - cleanAllRUV task limit is not enforced for replicated tasks * Issue 50536 - Audit log heading written to log after every update * Issue 50525 - nsslapd-defaultnamingcontext does not change when the assigned suffix gets deleted * Issue 50534 - CLI change schema edit subcommand to replace * Issue 50506 - cont Fix invalid frees from pointer reference calls * Issue 50507 - Fix Cockpit UI styling for PF4 * Issue 48851 - investigate and port TET matching rules filter tests(indexing final) * Issue 48851 - Add more test cases to the match test suite(mode replace) * Issue 50530 - Directory Server not RFC 4511 compliant with requested attr “1.1” * Issue 50529 - LDAP server returning PWP controls in different sequence * Issue 50506 - Fix invalid frees from pointer reference calls. * Issue 50506 - Replace slapi_entry_attr_get_charptr() with slapi_entry_attr_get_ref() * Issue 50521 - Add regressions in CI tests * Issue 50510 - etime can contain invalid nanosecond value * Issue 50488 - Create a monitor for disk space usagedisk-space-mon * Issue 50511 - lib389 PosixGroups type can not handle rdn properly * Issue 50508 - UI - fix local password policy form -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.2.2
by Mark Reynolds 28 Sep '19

28 Sep '19

389 Directory Server 1.4.2.2 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.2.2 Fedora packages are available on Fedora (rawhide). https://koji.fedoraproject.org/koji/taskinfo?taskID=37898643 <https://koji.fedoraproject.org/koji/taskinfo?taskID=37898643> - Rawhide The new packages and versions are: * 389-ds-base-1.4.2.2-3 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.2.2.tar.bz2> Highlights in 1.4.2.2 * 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 No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes No (coming soon!) Schema Tab Yes No Plugin Tab Yes Yes Monitor Tab Yes Yes 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.2.2 * Issue 50627 - Add ASAN logs to HTML report * Issue 50545 - Port repl-monitor.pl to lib389 CLI * Issue 50622 - ds_selinux_enabled may crash on suse * Issue 50595 - remove syslog.target requirement * Issue 50617 - disable cargo lock * Issue 50620 - Fix regressions from 50506 (slapi_enry_attr_get_ref) * Issue 50615 - Log current test name to journald * Issue 50610 - memory leak in dbscan * Bump version to 1.4.2.1 * Issue 50581 - ns-slapd crashes during ldapi search * Issue 50604 - Fix UI validation * Issue 50510 - etime can contain invalid nanosecond value * Issue 50593 - Investigate URP handling on standalone instance * Issue 50506 - Fix regression for relication stripattrs * Issue 50580 - Perl can’t be disabled in configure * Issue 50584, 49212 - docker healthcheck and configuration * Issue 50546 - fix more UI issues(part 2) * Lib389 - Do not use comparision with “is” for empty value * Issue 50546 - fix more UI issues * Issue 50586 - lib389 - Fix DSEldif long line processing * Issue 50173 - Add the validate-syntax task to the dsconf schema * Issue 50546 - Fix various issues in UI * Bump version to 1.4.2.0 * Issue 50576 - Same proc uid/gid maps to rootdn for ldapi sasl * Issue 50567, 50568 - strict host check disable and display container version * Issue 50550 - DS installer debug messages leaking to ipa-server-install * Issue 50545 - Port fixup-memberuid and add the functionality to CLI and UI * Issue 50572 - After running cl-dump dbdir/cldb/*ldif.done are not deleted * Issue 50578 - Add SKIP_AUDIT_CI flag for Cockpit builds * Issue 50349 - filter schema validation * Issue 48055 - CI test-(Plugin configuration should throw proper error messages if not configured properly) * Issue 49324 - idl_new fix assert * Issue 50564 - Fix rust libraries by default and improve docker * Issue 50206 - Refactor lock, unlock and status of dsidm account/role * Issue 49324 - idl_new report index name in error conditions * Issue 49761 - Fix CI test suite issues * Issue 50506 - Fix regression from slapi_entry_attr_get_ref refactor * Issue 50499 - Audit fix - Update npm ‘eslint-utils’ version * Issue 49624 - modrdn silently fails if DB deadlock occurs * Issue 50542 - Fix crashes in filter tests * Issue 49761 - Fix CI test suite issues * Issue 50542 - Entry cache contention during base search * Issue 50462 - Fix CI tests * Issue 50490 - objects and memory leaks * Issue 50538 - Move CI test to individual file * Issue 50538 - cleanAllRUV task limit is not enforced for replicated tasks * Issue 50536 - Audit log heading written to log after every update * Issue 50525 - nsslapd-defaultnamingcontext does not change when the assigned suffix gets deleted * Issue 50534 - CLI change schema edit subcommand to replace * Issue 50506 - cont Fix invalid frees from pointer reference calls * Issue 50507 - Fix Cockpit UI styling for PF4 * Issue 48851 - investigate and port TET matching rules filter tests(indexing final) * Issue 48851 - Add more test cases to the match test suite(mode replace) * Issue 50530 - Directory Server not RFC 4511 compliant with requested attr “1.1” * Issue 50529 - LDAP server returning PWP controls in different sequence * Issue 50506 - Fix invalid frees from pointer reference calls. * Issue 50506 - Replace slapi_entry_attr_get_charptr() with slapi_entry_attr_get_ref() * Issue 50521 - Add regressions in CI tests * Issue 50510 - etime can contain invalid nanosecond value * Issue 50488 - Create a monitor for disk space usagedisk-space-mon * Issue 50511 - lib389 PosixGroups type can not handle rdn properly * Issue 50508 - UI - fix local password policy form -- 389 Directory Server Development Team

1 0

Error after installing 389-admin
by Todor Petkov 26 Sep '19

26 Sep '19

Hello, I am trying to install 389 server on CentOS7. After running setup-ds-admin.pl, 389-ds started, I can connect successfully to it, but the admin server gives an error on start: do_admserv_post_config(): unable to create AdmldapInfo I searched for this error, people suggested checking ownership permissions of /etc/dirsrv/admin-serv and the files, but it seems OK (I may miss something). Anyone with this issue? These are the versions of the packages: 389-admin-1.1.46-1.el7.x86_64 389-admin-console-1.1.12-1.el7.noarch 389-admin-console-doc-1.1.12-1.el7.noarch 389-adminutil-1.1.22-2.el7.x86_64 389-console-1.1.19-6.el7.noarch 389-ds-1.2.2-6.el7.noarch 389-ds-base-1.3.9.1-10.el7.x86_64 389-ds-base-libs-1.3.9.1-10.el7.x86_64 389-ds-base-snmp-1.3.9.1-10.el7.x86_64 389-ds-console-1.2.16-1.el7.noarch 389-ds-console-doc-1.2.16-1.el7.noarch 389-dsgw-1.1.11-5.el7.x86_64 Thanks in advance.

1 0

Configuring the 389-ds-base on Fedora 30
by rtbell＠GRANITEMOUNTAIN.COM 25 Sep '19

25 Sep '19

I have hit a roadblock and would appreciate any help I can get. I am running in a VM Workstation virtualization platform on a Windows 10 host machine. I created a LAMP version of Fedora 30 using mariadb instead of mysql. I changed the host name to cn-poc-pki.granitemountain.com rebooted the system and verified that the host name was correct. I added cn-poc-pki.granitemountain.com to the hosts table and rebooted again. I then used dnf install 389-ds-base to retrieve the 389-ds subsystem. I used dscreate create-template ds.tmp to create a template. I used vim to update the fields in the template file I am attaching the template file. When I try to assert an ldapadd -h $HOSTNAME -x -D "cn=DirectoryManager" -W <<EOF with a number of additional parameters, I get an ldap_bind: Invalid credentials (49) error message. Obviously I have misconfigured something but I have been unable to discover what it might be. Could some of you experts please look at my configuration and tell me what I screwed up, please? Bob Bell Granite Mountain Security Consultancy, LLC. 90 W 500 South, #404 Bountiful UT 84010 801-971-4200 (cell) rtbell(a)granitemountain.com <mailto:rtbell@granitemountain.com> "Beware the engineers of society, I say, who would make everyone in all the world equal. Opportunity should be equal, must be equal, but achievement must remain individual." ---Drizzt Do'Urden

2 12

Configuring the 389-ds-base on Fedora 30
by rtbell＠GRANITEMOUNTAIN.COM 24 Sep '19

24 Sep '19

I have hit a roadblock and would appreciate any help I can get. I am running in a VM Workstation virtualization platform on a Windows 10 host machine. I created a LAMP version of Fedora 30 using mariadb instead of mysql. I changed the host name to cn-poc-pki.granitemountain.com rebooted the system and verified that the host name was correct. I added cn-poc-pki.granitemountain.com to the hosts table and rebooted again. I then used dnf install 389-ds-base to retrieve the 389-ds subsystem. I used dscreate create-template ds.tmp to create a template. I used vim to update the fields in the template file I am attaching the template file. [Note: I had to rename ds.tmp to ds.txt to get it past the email filters. When I try to assert an ldapadd -h $HOSTNAME -x -D "cn=DirectoryManager" -W <<EOF with a number of additional parameters, I get an ldap_bind: Invalid credentials (49) error message. Obviously I have misconfigured something but I have been unable to discover what it might be. Could some of you experts please look at my configuration and tell me what I screwed up, please? Bob Bell Granite Mountain Security Consultancy, LLC. 90 W 500 South, #404 Bountiful UT 84010 801-971-4200 (cell) rtbell(a)granitemountain.com <mailto:rtbell@granitemountain.com> "Beware the engineers of society, I say, who would make everyone in all the world equal. Opportunity should be equal, must be equal, but achievement must remain individual." ---Drizzt Do'Urden

1 0

sudoers tree missing on a 389-ds replica
by Sergei Gerasenko 23 Sep '19

23 Sep '19

Hello, I’ve run into an interesting situatuion with the sudoers tree in 389-ds. All the nodes in the 389-ds cluster have it, but one doesn’t. I’ve tried dumping the database on a good node with db2ldif and reloading on the bad node with ldif2db, but the situation is not changing. I’ve also tried db2index on the bad node without much luck. Any ideas? Thanks, Sergei

3 4

Monitoring 389ds with telegraf
by Olivier JUDITH 19 Sep '19

19 Sep '19

Hi all , For all those who are interested , i started to develop with the help of Marco Favero <aka falon> a monitoring solution based on telegraf to gather metrics from my 389 instances . All metrics are stored in influxdb ( timeseries db) and can be visualized on Grafana. The code source is available here : https://github.com/influxdata/telegraf/pull/5691 Grafana Dashboard is here : https://grafana.com/grafana/dashboards/10587 Regards

2 3

389ds ldaps issue after upgrade
by Mihai Carabas 17 Sep '19

17 Sep '19

Hello, After upgrading to the latest 389ds (1.4.0.27) with FC29, I have the following issue on LDAPS: ldap_url_parse_ext(ldaps://ldap.curs.pub.ro) ldap_create ldap_url_parse_ext(ldaps://ldap.curs.pub.ro:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.curs.pub.ro:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 141.85.241.48:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization tls_write: want=303, written=303 0000: 16 03 01 01 2a 01 00 01 26 03 03 72 71 d6 83 08 ....*...&..rq... 0010: 7a 5f 26 69 2b f7 f7 4f 59 76 87 c0 07 bc 6c db z_&i+..OYv....l. 0020: fe 51 69 e4 2c dc 65 3d 52 48 f6 20 2b c1 75 d1 .Qi.,.e=RH. +.u. 0030: 98 3b dc 70 3e 69 82 a4 41 91 7f 89 0e fc 52 43 .;.p>i..A.....RC 0040: ab be c9 77 0b 02 a7 f1 9f ec a7 d0 00 48 13 02 ...w.........H.. 0050: 13 03 13 01 13 04 c0 2c c0 30 cc a9 cc a8 c0 ad .......,.0...... 0060: c0 2b c0 2f c0 ac c0 23 c0 27 c0 0a c0 14 c0 09 .+./...#.'...... 0070: c0 13 00 9d c0 9d 00 9c c0 9c 00 3d 00 3c 00 35 ...........=.<.5 0080: 00 2f 00 9f cc aa c0 9f 00 9e c0 9e 00 6b 00 67 ./...........k.g 0090: 00 39 00 33 00 ff 01 00 00 95 00 0b 00 04 03 00 .9.3............ 00a0: 01 02 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00 19 ................ 00b0: 00 18 00 23 00 00 00 16 00 00 00 17 00 00 00 0d ...#............ 00c0: 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08 09 .0.............. 00d0: 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06 01 ................ 00e0: 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05 02 ................ 00f0: 06 02 00 2b 00 09 08 03 04 03 03 03 02 03 01 00 ...+............ 0100: 2d 00 02 01 01 00 33 00 26 00 24 00 1d 00 20 4c -.....3.&.$... L 0110: 3f b1 bc f8 d0 a1 54 e7 a2 6f d4 d4 d1 ab b3 77 ?.....T..o.....w 0120: 67 2c ea 51 94 f3 fa 43 de 96 5f 9b eb 12 10 g,.Q...C.._.... TLS trace: SSL_connect:SSLv3/TLS write client hello tls_read: want=5, got=5 0000: 15 03 03 00 02 ..... tls_read: want=2, got=2 0000: 02 50 .P TLS trace: SSL3 alert read:fatal:internal error TLS trace: SSL_connect:error in error TLS: can't connect: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) All the things remained the same like before upgrading. I see tihs internal error and I could not find any hints about it. Did someone hit this issue? Thank you, Mihai Carabas

3 6

Re: FIPS 140-2 and dirsrv-admin
by William Brown 13 Sep '19

13 Sep '19

If memory serves correctly ... there are some un-resolved issues between dirsrv-admin + fips. I remember discussing this with Mark as something that may fall into the "fix when someone runs into it" because that combination we thought would be rare. But I'm not sure that this issue here is a fips one? I've seen another issue lately where the dirsrv-admin used a different pin.txt to the dirsrvinstances, but I'm not sure of the details. Are there fresh installs of ds? Or upgrades? > On 28 Aug 2019, at 05:51, Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > > Hi guys, > > I have SSL enabled both slapd instances and dirsrv-admin on FIPS enabled CentOS 7. The instances seem to start up no problem. However, the admin console (dirsrv-admin) is complaining the password credentials are not valid for the NSS FIPS 140-2 DB even through the exact same credentials are presented to the SLAPD instances. I am using a pin.txt file in the correct format for both SLAPD and DIRSRV-ADMIN. > > Are there compatibility issues with FIPS and 389-DS admin-serv? > > Paul M. Whitney > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs

4 12

groupofuniquenames vs. groupofnames / post hooks or actions after object creation
by Weigel Stefan 11 Sep '19

11 Sep '19

Hi, I need a little help with two topics: 1. users should be able to use a simple web frontend to change ldap password and manage ssh pubkeys. We evaluated Fusion Directory (https://www.fusiondirectory.org/) for this. In Fusion Directory group membership is using groupofnames rather than groupofuniquenames used in 389. I played around but can't find a solution to fix this. I tried to modify cn=group,cn=defaultobjectclassescontainer,ou=1.1,ou=admin,ou=global preferences,ou=genua.de,o=netscaperoot -> nsDefaultObjectClass from groupofuniquenames to groupofnames and renamed cn=groupofuniquenames,cn=ResourceEditorExtension,ou=1.1,ou=Admin,ou=Global Preferences,ou=genua.de,o=netscaperoot to cn=groupofnames,cn=ResourceEditorExtension,ou=1.1,ou=Admin,ou=Global Preferences,ou=genua.de,o=netscaperoot but in 389-console it shows me message: uniqueMember is not allowed. Is it possible to change the default object class of the group? How to to do it? Otherwise could you point me to a simple webgui to edit values? 2. When creating a user object under I want to trigger some post actions (create directories, copy files, etc.) As I understand this should be possible with the plugins. I'm asking myself if there's already such a plugin or could you provide me some more infos. Thanks in advance, Stefan

2 2

Re: urp_fixup_add_cenotaph errors
by Morgan, Iain (ARC-TN)[InuTeq, LLC] 10 Sep '19

10 Sep '19

On 9/5/19, 18:11, "Iain Morgan" <Iain.Morgan(a)nasa.gov> wrote: Hello, While testing 389-ds 1.3.9.1 on RHEL 7.7, I noticed the the errors listed below. The actual LDAP operations all succeed, but I find the errors disconcerting. [28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 These all appear to be related to modrdn operations. -- Iain Morgan

3 2

Re: Docker official image
by Olivier JUDITH 09 Sep '19

09 Sep '19

Hi all, I'm back on this topic, Can you tell me with the docker image how to create the root suffix ? I tried this step but othing appears on Apache Directory server IDE ldapmodify -a -D "cn=Directory manager" -w mypass -p 3389 -h 10.109.139.63 -x dn: cn="dc=domain,dc=net",cn=mapping tree,cn=config changetype: add cn: dc=domain,dc=net objectclass: top objectclass: extensibleObject objectclass: nsMappingTree nsslapd-state: backend nsslapd-backend: UserData Regards

3 7

Re: urp_fixup_add_cenotaph errors
by Morgan, Iain (ARC-TN)[InuTeq, LLC] 08 Sep '19

08 Sep '19

Hello Marc, Yes, it is 389-ds-base1.3.9.1-10.el7, but we are not using IPA and there are no memberOf plugin errors. The actual modrdn operations have error=0. -- Iain Morgan On 9/6/19, 15:05, "Marc Sauton" <msauton(a)redhat.com> wrote: could you check the system has 389-ds-base-1.3.9.1-10.el7 <https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_down…> or above? do the MODRDN fail with err=53? is it in IPA context with memberof-plugin errors? there was a bug fix in bz 1680245 that seem related to this, may be there is till something going on, or may be it can be ignored. we would likely need to privately review more logs to tell (open a RH case?) Thanks, M. On Fri, Sep 6, 2019 at 10:38 AM Morgan, Iain (ARC-TN)[InuTeq, LLC] <iain.morgan(a)nasa.gov> wrote: On 9/5/19, 18:11, "Iain Morgan" <Iain.Morgan(a)nasa.gov> wrote: Hello, While testing 389-ds 1.3.9.1 on RHEL 7.7, I noticed the the errors listed below. The actual LDAP operations all succeed, but I find the errors disconcerting. [28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 These all appear to be related to modrdn operations. -- Iain Morgan _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org…> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki…> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.or…>

2 1

urp_fixup_add_cenotaph errors
by Iain Morgan 06 Sep '19

06 Sep '19

Hello, While testing 389-ds 1.3.9.1 on RHEL 7.7, I noticed the the errors listed below. The actual LDAP operations all succeed, but I find the errors disconcerting. [28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 -- Iain Morgan

1 0

sync AD account state
by DaV 05 Sep '19

05 Sep '19

Hi guys, How can I sync account state from Windows AD to 389ds 1. account disabled 2. account lockout 3. password expired I want to sync these attributes from Windows AD to 389ds, would you please tell me? Thanks in advance. Sincerely, -- DaV

2 1

BIND (DNS)
by Fernando Fuentes 04 Sep '19

04 Sep '19

Is there a plugin or a default schema for BIND (named) on Fedora389? Or do I have to import the included schema with bind9? Thanks! Regards, -

2 10

Reminder of 389-admin, console, and webapp deprecation & removal
by Mark Reynolds 04 Sep '19

04 Sep '19

This is just a reminder that the old Java Console and Admin Server have been deprecated, and these packages will be removed from future versions of the product. Starting in Fedora 31, RHEL 8, CentOS 8, and SUSE 15 there will no longer be a Java Console (389-console), Admin Express, or Directory Server Gateway. Instead, we have a new web UI that is a Cockpit plugin (cockpit-389-ds) [1]. The new Cockpit UI is solely for administering and configuring the server. As previously announced there will not be an LDAP browser as part of the new UI. So User & Group management needs to be done via the new CLI tools or via free products like Apache Directory Studio. We do plan to add a simple LDAP browser in the near future, but that work has not begun yet. Sorry for any inconvenience this presents, but we needed to move off of the old java technology so we did not get stuck in another 8 year support cycle. We hope you like the new UI and CLI tools, and we will continue to improve them with each release. Feel free to file tickets for RFE's and bugs here: https://pagure.io/389-ds-base/new_issue Sincerely, 389 Directory Server Development Team [1] https://cockpit-project.org/ -- 389 Directory Server Development Team

2 1

Windows Sync Agreement issue
by DaV 04 Sep '19

04 Sep '19

Hi all, I'm using a new 389 directory server on CentOS 7.6 with 389-ds-base.x86_64 (1.3.8.4-15.el7), and I want to sync user and password from Windows 2016 to 389ds one way. The Synchronization Agreement like this: DS Host: 389ds:389 Windows Host: dc01.example.com:389 DS Subtree: ou=Users,dc=example,dc=com Windows Subtree: OU=Accounts, DC=example,DC=com Replicated subtree: dc=example,dc=com Here is my question: The sync agreement can only sync top-level OU=Accounts, DC=example, DC=com from Win2016 to 389ds server. In fact, I have ou=ou1,ou=accounts,dc=example,dc=com ou=ou2,ou=accounts,dc=example,dc=com on Win2016 server. I want the sync agreement can sync not only the top-level but also the child ou. This is the error log for your reference. Thanks! > [20/Aug/2019:07:58:40.307031692 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)". > [20/Aug/2019:07:58:40.309113230 +0800] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests > [20/Aug/2019:08:34:21.730939271 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized. > [20/Aug/2019:08:34:21.733526550 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized. > [20/Aug/2019:08:34:24.735819391 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized. > [20/Aug/2019:08:34:27.738228528 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized. > [20/Aug/2019:08:34:30.873896680 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)". > [20/Aug/2019:08:34:33.170822223 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica "agmt="cn=389ds" (tc-dc-2:389)". Sent 5 entries. > [20/Aug/2019:08:34:33.186359842 +0800] - ERR - NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=389ds" (tc-dc-2:389): Replication bind with SIMPLE auth resumed > [20/Aug/2019:08:47:30.032935119 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)". > [20/Aug/2019:08:47:31.035850854 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica "agmt="cn=389ds" (tc-dc-2:389)". Sent 5 entries. > [20/Aug/2019:08:47:31.051614890 +0800] - ERR - NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=389ds" (tc-dc-2:389): Replication bind with SIMPLE auth resumed > [20/Aug/2019:08:50:59.533268105 +0800] - WARN - NSMMReplicationPlugin - prot_stop - Incremental protocol for replica "agmt="cn=389ds" (tc-dc-2:389)" did not shut down properly. > [20/Aug/2019:09:01:00.155477769 +0800] - WARN - NSMMReplicationPlugin - prot_stop - Total protocol for replica "agmt="cn=389ds" (tc-dc-2:389)" did not shut down properly. Sincerely, -- DaV

4 15

Central authentication using 389 DS
by Nicolas Kovacs 02 Sep '19

02 Sep '19

Hi, I've just completed a detailed blog article series about central authentication using 389 Directory Server. It's in French, and I published it on my tech blog. * https://www.microlinux.fr/389-ds-centos-7/ * https://www.microlinux.fr/389-ds-utilisateurs-centos-7/ * https://www.microlinux.fr/389-ds-tls-centos-7/ * https://www.microlinux.fr/opensuse-leap-15-1-389-ds/ Cheers from the sunny South of France, Niki Kovacs -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users September 2019