389-users March 2022

389-users@lists.fedoraproject.org

18 participants
21 discussions

Announcing 389 Directory Server 2.0.15
by Mark Reynolds 25 Mar '22

25 Mar '22

389 Directory Server 2.0.15 The 389 Directory Server team is proud to announce 389-ds-base version 2.0.15 Fedora packages are available on Fedora 34, and 35 Fedora 35: https://koji.fedoraproject.org/koji/taskinfo?taskID=84608760 <https://koji.fedoraproject.org/koji/taskinfo?taskID=84608760> - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2022-40544b5314 <https://bodhi.fedoraproject.org/updates/FEDORA-2022-40544b5314> - Bodhi Fedora 34: https://koji.fedoraproject.org/koji/taskinfo?taskID=84609037 <https://koji.fedoraproject.org/koji/taskinfo?taskID=84609037> - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2022-2558f14c58 <https://bodhi.fedoraproject.org/updates/FEDORA-2022-2558f14c58> - Bodhi The new packages and versions are: * 389-ds-base-2.0.15-1 Source tarballs are available for download at Download 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-2.0.15.tar.gz> Highlights in 2.0.15 * Bug and Security 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. 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 GitHub project: https://github.com/389ds/389-ds-base * Bump version to 2.0.15 * Issue 5230 - Race condition in RHDS disk monitoring functions * Issue 4299 - UI - Add CoS funtionality (#5196) * Issue 5225 - UI - impossible to manually set entry cache * Issue 5186 - UI - Fix SASL Mapping regex test feature * Issue 5221 - User with expired password can still login with full privledges * Issue 5218 - double-free of the virtual attribute context in persistent search (#5219) * Issue 5200 - dscontainer should use environment variables with DS_ prefix * Issue 5193 - Incomplete ruv occasionally returned from ruv search (#5194) * Issue 5189 - memberOf plugin exclude subtree not cleaning up groups on modrdn * Issue 5188 - UI - LDAP editor - add entry and group types * Issue 5184 - memberOf does not work correctly with multiple include scopes * Issue 5162 - BUG - error on importing chain files (#5164) * Issue 5186 - UI - Fix SASL Mapping regex validation and other minor improvements * Issue 5048 - Support for nsslapd-tcp-fin-timeout and nsslapd-tcp-keepalive-time (#5179) * Issue 5122 - dsconf instance backend suffix set doesn’t accept backend name (#5178) * Issue 5160 - BUG - x- prefix in descr-oid can confuse oid parser (#5161) * Issue 5098 - Multiple issues around replication and CI test test_online_reinit_may_hang (#5109) * Issue 5102 - BUG - container may fail with bare uid/gid (#5140) * Issue 5137 - RFE - improve sssd conf output (#5138) * Issue 5145 - Fix covscan errors * Issue 4721 - UI - attribute uniqueness crashes UI when there are no configs * Issue 5155 - RFE - Provide an option to abort an Auto Member rebuild task * Issue 4299 - UI - Add Role funtionality (#5163) * Issue 5050 - bdb bulk op fails if fs page size > 8K (#5150) * Issue 4775 - Add entryuuid CLI and Fixup (#4776) * Issue 5142 - CLI - dsctl dbgen is broken * Issue 4299 - UI - fix minor issues with ldap editor (table view) * Issue 4299 - UI - fix minor issues with ldap editor * Issue 5103 - UI - Add support for TPR to web console (#5111) -- Directory Server Development Team

1 0

389ds for Dummies: How to get started with an empty 389ds server?
by Johannes Kastl 24 Mar '22

24 Mar '22

Hi everyone, sorry if this question was asked before, but as I found nothing in the docs I am blocked at the moment. I got 389ds running in Kubernetes, which uses a very simple container.inf file: > [localhost] > # Note that '/' is replaced to '%%2f' for ldapi url format. > # So this is pointing to /data/run/slapd-localhost.socket > uri = ldapi://%%2fdata%%2frun%%2fslapd-localhost.socket > binddn = cn=Directory Manager > # Set your basedn here > basedn = dc=example,dc=com So no sample entries are being generated (no "sample_entries = yes"). I tried to follow and see which steps I need from the quickstart: https://www.port389.org/docs/389ds/howto/quickstart.html Checking the status is the first thing that does not work, as dsctl inside the container does not have a "status" subcommand: > 389server-6fff4cb6d8-kjjd4:/ # dsctl slapd-localhost status > usage: dsctl [-h] [-v] [-j] [-l] [instance] {db2index,db2bak,db2ldif,dbverify,bak2db,ldif2db,backups,ldifs,tls,healthcheck,get-nsstate,ldifgen,dsrc,cockpit,dblib} ... > dsctl: error: invalid choice: 'status' (choose from 'db2index', 'db2bak', 'db2ldif', 'dbverify', 'bak2db', 'ldif2db', 'backups', 'ldifs', 'tls', 'healthcheck', 'get-nsstate', 'ldifgen', 'dsrc', 'cockpit', 'dblib') > 389server-6fff4cb6d8-kjjd4:/ # The "healthcheck" seems to be successful. Puuh. Adding a user fails with "Error: 105 - 4 - 32 - No such object - []", most probably because there is no content inside the server yet (no base object, users OU or similar). So I tried to query the server using ldapsearch (from the outside) and got a working connection, even with "-ZZ": > $ ldapsearch -x -W -H ldap://my-389ds-server -D "cn=Directory Manager" -ZZ -b cn=config > [...] > # search result > search: 3 > result: 0 Success > > # numResponses: 161 > # numEntries: 160 OK, let's add a base object using ldapadd: > dn: dc=example,dc=com > objectClass: domain > objectClass: dcObject > $ ldapadd -x -f base_only.ldif -D "cn=Directory Manager" -W -H ldap://my-389ds-server > Enter LDAP Password: > adding new entry "dc=example,dc=com" > ldap_add: No such object (32) I tried different combinations of objectClass'es, but always got error 32. Question: How do I get content into the server initially? It seems I have an empty server, but I found no documentation on what to do at this point. Am I missing some schema? If so, how would I bootstrap it? Sorry if those are obvious questions, but either I am lacking the deep LDAP knowledge to answer them myself or there is an error in my setup. Thanks in advance! Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 2

Re: docker, 389ds/dirsrv:2.0, vendorVersion 2.1.0, ssca, certificate chain, orphan key, cert9.db, key4.db
by Lutz Berger 22 Mar '22

22 Mar '22

3 6

docker, 389ds/dirsrv:2.0, vendorVersion 2.1.0, ssca, certificate chain, orphan key, cert9.db, key4.db
by Lutz Berger 18 Mar '22

18 Mar '22

3 6

question about replicating between two versions
by Lewis Robson 16 Mar '22

16 Mar '22

Hello all, I have an EL8 (alma) running 389ds, I have put 389ds on another server (el7, centos) is it possible to replicate between the two completely different versions? Thanks

2 1

Re: SSO and 389
by N R 12 Mar '22

12 Mar '22

Hi, I've done some SAML SSO integrations and work regularly with FreeIPA. SSO is usually handled via a protocol like SAML, OpenID or Shibboleth, FreeIPA only serves as LDAP Identity database in these architectures. Our deployments used a "proxy" to handle these authentications and link them with LDAP, SimpleSAMLPHP. The implementation also depends a lot on the way you want to do SSO, centralized, federated, or cooperative. I would recommend to take a look at simplesamlphp documentation as it supports almost every SSO protocols and can easily be integrated to proxy SSO web requests. Regards, Nicolas Le lun. 10 janv. 2022 à 19:50, Jonathan Aquilina <jaquilina(a)eagleeyet.net> a écrit : > Good Evening, > > > > I am just wondering can 389 along side free ipa be used to offer SSO > capabilities? > > > > Regards, > > Jonathan > _______________________________________________ > 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… > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >

2 1

[SOLVED] multi-supplier replication with certificate-based authentication
by Giacomo Comes 09 Mar '22

09 Mar '22

Hi, I finally managed to setup multi-supplier replication with certificate-based authentication. I now understand why people says it is a complicated stuff and they wish luck to the guy trying to do it. It is actually not that much complicated, once you know what to do. Follow my instructions and see for yourself. Start with reading the documentation (Red Hat Directory Server 11) especially: 9. Configuring Secure Connections 15. Managing Replication and in particular: 9.9.1. Setting up Certificate-based Authentication 15.4. Multi-Supplier Replication 15.6. Configuring Replication Partners to use Certificate-based Authentication In the following examples I'll assume the two hosts are called host1.example.com and host2.example.com you have setup on each host a directory server instance called "ldaptest" with self-signed CA certificate. The root suffix stored in the database is: dc=example,dc=com You have to execute the steps described in 15.6: - create two accounts for both servers - add to the accounts the user certificate - create the replication group - add both server accounts to such group - create the replica entry (dsconf ... replication enable ... --bind-group-dn=<replication group>) - initialize the server using a temporary replication agreement on host1 and a temporary replication manager on host2 (to be more precise on host2 you have to enable replication for the suffix and create the temporary replication manager account [15.4.1 step 3]) - after initialization remove the temporary replication agreement on host1 and the temporary replication manager on host2 - create a replication agreement on both servers that use certificate-based authentication. You do everything as described, but when you create the replication agreement on host1 (as showed in 15.6 step 5/a), things do not work. The error log shows: ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636) - Replication bind with EXTERNAL auth failed: LDAP error 49 (Invalid credentials) the cause is that host2 does not know from which account to retrieve the user certificate. To fix this problem you have to set the parameter CmapLdapAttr in certmap.conf in the following way: 1) Set the parameter CmapLdapAttr to nsCertSubjectDN nsCertSubjectDN is the attribute that will contain the subject DN required to locate the host account. 2) When you create the account for the server and add to such account the client certificate (15.6 step 2/a) add also the attribute nsCertSubjectDN with the value I'm going to describe below. Run the command: certutil -L -d /etc/dirsrv/slapd-ldaptest -n "Server-Cert" | grep "Subject" You will see the subject of the server certificate. Something similar to: CN=host1.example.com,givenName=6562ddf6-4594-4ef7-8b5d-8ae9a32ffa29,O=testing,L=389ds,ST=Queensland,C=AU for such subject the value to assign to the attribute nsCertSubjectDN is: cn=host1.example.com,GIVENnAME=6562ddf6-4594-4ef7-8b5d-8ae9a32ffa29,o=testing,l=389ds,st=Queensland,c=AU That is: you have to flip the case of the attribute type (cn,o,ou,st,c, etc.) Why it is like that and more important why it is not documented I don't know. Once nsCertSubjectDN is set correctly and you create the replication agreement on host1 (as described in 15.6 step 5/a) you will now get this error message in the log: ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=agreement" (host2:636): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. This error is due to the fact that on host2 the replication is still enabled for bind-dn="cn=replication manager,cn=config" you have to disable such replica entry and create a new replica entry with --bind-group-dn=<replication group> similar to the one you did on host1. After you do that the replication should work. Unless it doesn't. If you have created a self signed CA certificate and you are in a timezone with negative offset (GMT-<n>) like in America, then a bug will not make the replication work. Here is what happens. Assume you are in the timezone GMT-4. It's 10:00 and a self signed CA certificate is created while running the command dscreate. Check the validity of the certificate with: certutil -L -d /etc/dirsrv/ssca -n Self-Signed-CA | grep Not the output is something like: Not Before: Tue Mar 08 14:00:00 2022 Not After : Fri Mar 08 14:00:00 2024 As you can see the certificate uses UTC time: 14:00 UTC corresponds to 10:00 GMT-4 Now somewhere in the directory server code the time stored in the CA certificate is assumed to be in local time, therefore since it is 10:00 and the certificate is not valid before 14:00, the replication does not work. In the error log you will see the message: ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=agreement" (host2:636): Unable to acquire replica: permission denied. The bind dn "uid=host1.example.com,ou=people,dc=example,dc=com" does not have permission to supply replication updates to the replica. Will retry later. You can either wait few hours until the certificate becomes valid, or you can change the system clock just before you are running dscreate: date -s "$(date +%:::z) hours" #move the clock backwards dscreate <arguments> date -s "$(( $(date +%:::z) * -1)) hours" #restore the correct time Continuing with the previous example, the CA certificate will be now valid since 10:00 GMT leaving the replication process unaffected by the bug. To resume: add the attribute nsCertSubjectDN with correct value to the host accounts, update the replica entry on host2 after the temporary agreement has done its job, consider changing the system clock when you use the command dscreate. I wish to thank David and William for their help. I have never used 389-ds before and what they said helped me investigate the proper cause of my problems. Cheers. Giacomo Comes System Administrator Arecibo Observatory

1 0

Re: multi-supplier replication with certificate-based authentication
by William Brown 08 Mar '22

08 Mar '22

Thanks David! This is absolutely correct :) > On 5 Mar 2022, at 00:34, David Ritenour <d.ritenour(a)martinfed.com> wrote: > > Hello Giacomo, > > Per the error log, it appears that the certificate is not mapping to the desired user entry. Make sure your certmap.conf file is properly configured per Section 9.9.1 found here: > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/h… > > Restart the directory after modifying the certmap.conf file. > > Also, it is helpful to look at the access log and follow the conn=xxxx for the connection. > > Here is a certificate-based authentication failure example (RHEL 7): > # grep $(grep "SSL connection from" access|tail -1|cut -f3 -d' ') access > [04/Mar/2022:09:00:02.932646113 -0500] conn=21 fd=4098 slot=4098 SSL connection from 192.168.150.189 to 192.168.150.187 > [04/Mar/2022:09:00:02.986129181 -0500] conn=21 TLS1.2 256-bit AES; client CN=mfed-rh7ds1.martinfederal.local,DC=martinfed,DC=local; issuer CN=dev-IntermediateCA1.martinfederal.local,OU=pki-tomcat,O=MartinFederalLab > [04/Mar/2022:09:00:02.986149974 -0500] conn=21 TLS1.2 failed to map client certificate to LDAP DN (Cert mapping function failed) > [04/Mar/2022:09:00:02.986643636 -0500] conn=21 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL > [04/Mar/2022:09:00:02.986749253 -0500] conn=21 op=0 RESULT err=49 tag=97 nentries=0 wtime=0.053972758 optime=0.000109274 etime=0.054077979 - Client certificate mapping failed > [04/Mar/2022:09:00:02.987740508 -0500] conn=21 op=1 UNBIND > [04/Mar/2022:09:00:02.987760181 -0500] conn=21 op=1 fd=4098 closed - U1 > > Here is a successful certificate-based authentication connection (RHEL 7) with properly configured certmap.conf: > # grep $(grep "SSL connection from" access|tail -1|cut -f3 -d' ') access > [04/Mar/2022:09:13:14.980664619 -0500] conn=3 fd=4098 slot=4098 SSL connection from 192.168.150.189 to 192.168.150.187 > [04/Mar/2022:09:13:15.021509726 -0500] conn=3 TLS1.2 256-bit AES; client CN=mfed-rh7ds1.martinfederal.local,DC=martinfed,DC=local; issuer CN=dev-IntermediateCA1.martinfederal.local,OU=pki-tomcat,O=MartinFederalLab > [04/Mar/2022:09:13:15.022228628 -0500] conn=3 TLS1.2 client bound as cn=repman_mfed-rh7ds4-doe.martinfederal.local,cn=config > [04/Mar/2022:09:13:15.022313670 -0500] conn=3 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL > [04/Mar/2022:09:13:15.022446873 -0500] conn=3 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.041625548 optime=0.000136346 etime=0.041760960 dn="cn=repman_mfed-rh7ds4-doe.martinfederal.local,cn=config" > > Good luck. > > David Ritenour > Senior Directory Engineer > 513 Madison Street SE > Huntsville, AL 35801 > > > -----Original Message----- > From: Giacomo Comes <comes(a)naic.edu> > Sent: Friday, March 4, 2022 12:47 AM > To: 389-users(a)lists.fedoraproject.org > Subject: [389-users] multi-supplier replication with certificate-based authentication > > ** WARNING: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hi, > I'm trying to setup multi-supplier replication with certificate-based authentication. > The only documentation I have found on the subject is: > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/h… > however it doesn't seems to be complete. > > I have been doing my test with openSUSE 15.3 and RHEL/CentOS 8 with SELinux disabled. > > Attached there are a couple of scripts (dmtest-init and dmtest-agmt) that will help you reproduce my setup so you can tell me what I'm missing or doing wrong. > > For testing you need two (virtual) machines and their ip addresses. > A minimum text/server installation will do. > > Run on the first machine: > ./dmtest-init <IP1> <IP2> > > The script will configure /etc/hosts so that the machine with IP1 can be reached as host1.example.com and the other as host2.example.com. > 389-ds will be installed if not present. > A new ds instance will be created, started (password is: password) and configured. > /etc/openldap/ldap.conf is configured appropriately. > group1 and user1 are created. > > Now run on the second machine the same command: > ./dmtest-init <IP1> <IP2> > the script will setup the second machine in the same way but with the following differences: > The CA database is imported with rsync from host1. > A new Server-Cert is created using the CA certificate from host1. > group1 and user1 are not created. They should appear on host2 after host1 will replicate his database. > A temporary replication manager account is created. > > At this point the following commands should work on both machines: > > ldapsearch -H ldaps://host1.example.com -D "cn=Directory Manager" -w password > ldapsearch -H ldaps://host2.example.com -D "cn=Directory Manager" -w password > > Binding with a user certificate should also work: > openssl req -subj "/DC=com/DC=example/OU=people/UID=user1" -newkey rsa:2048 -nodes -keyout cert.key -new -out cert.csr > certutil -C -d /etc/dirsrv/ssca -f /etc/dirsrv/ssca/pwdfile.txt -a -i cert.csr -o cert.crt -c Self-Signed-CA > LDAPTLS_CERT=$PWD/cert.crt LDAPTLS_KEY=$PWD/cert.key ldapsearch -H ldaps://host1.example.com -D "uid=user1,ou=people,dc=example,dc=com" > > The next step is the replication setup. Run on host1: > ./dstest-agmt > this script will: > - create the group repl_server for nsds5ReplicaBindDNGroup > - create accounts for both hosts > - add the client certificates to the corresponding accounts > - add both accounts to the group repl_server > - create the replica entry > - create the replication agreement (with bootstrapt parameters) > > These are essentially the steps described in the RedHat Directory Server 11 documentation: 15.6 > > Now a look at /var/log/dirsrv/slapd-ldaptest/errors shows that the replication bind with the bootstrap parameters works (group1 and user1 are now present on host2) but the replication bind with EXTERNAL auth fails. > > - ERR - slapi_ldap_bind - Error: could not bind id [(anon)] authentication mechanism [EXTERNAL]: error 49 (Invalid credentials) > - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636) - Replication bind with EXTERNAL auth failed: LDAP error 49 (Invalid credentials) () > - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636): Replication bind with SIMPLE auth resumed > > Clearly there is something wrong with the client certificate setup, but I could not figure out what. > Any help is appreciated. > > Giacomo Comes > > This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email and any such files in error and that any use, dissemination, forwarding, printing or copying of this email and/or any such files is strictly prohibited. If you have received this email in error please immediately notify hr(a)martinfed.com- (855) 212-1810 , and destroy the original message and any such files. > _______________________________________________ > 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… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia

3 3

multi-supplier replication with certificate-based authentication
by Giacomo Comes 04 Mar '22

04 Mar '22

Hi, I'm trying to setup multi-supplier replication with certificate-based authentication. The only documentation I have found on the subject is: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/h… however it doesn't seems to be complete. I have been doing my test with openSUSE 15.3 and RHEL/CentOS 8 with SELinux disabled. Attached there are a couple of scripts (dmtest-init and dmtest-agmt) that will help you reproduce my setup so you can tell me what I'm missing or doing wrong. For testing you need two (virtual) machines and their ip addresses. A minimum text/server installation will do. Run on the first machine: ./dmtest-init <IP1> <IP2> The script will configure /etc/hosts so that the machine with IP1 can be reached as host1.example.com and the other as host2.example.com. 389-ds will be installed if not present. A new ds instance will be created, started (password is: password) and configured. /etc/openldap/ldap.conf is configured appropriately. group1 and user1 are created. Now run on the second machine the same command: ./dmtest-init <IP1> <IP2> the script will setup the second machine in the same way but with the following differences: The CA database is imported with rsync from host1. A new Server-Cert is created using the CA certificate from host1. group1 and user1 are not created. They should appear on host2 after host1 will replicate his database. A temporary replication manager account is created. At this point the following commands should work on both machines: ldapsearch -H ldaps://host1.example.com -D "cn=Directory Manager" -w password ldapsearch -H ldaps://host2.example.com -D "cn=Directory Manager" -w password Binding with a user certificate should also work: openssl req -subj "/DC=com/DC=example/OU=people/UID=user1" -newkey rsa:2048 -nodes -keyout cert.key -new -out cert.csr certutil -C -d /etc/dirsrv/ssca -f /etc/dirsrv/ssca/pwdfile.txt -a -i cert.csr -o cert.crt -c Self-Signed-CA LDAPTLS_CERT=$PWD/cert.crt LDAPTLS_KEY=$PWD/cert.key ldapsearch -H ldaps://host1.example.com -D "uid=user1,ou=people,dc=example,dc=com" The next step is the replication setup. Run on host1: ./dstest-agmt this script will: - create the group repl_server for nsds5ReplicaBindDNGroup - create accounts for both hosts - add the client certificates to the corresponding accounts - add both accounts to the group repl_server - create the replica entry - create the replication agreement (with bootstrapt parameters) These are essentially the steps described in the RedHat Directory Server 11 documentation: 15.6 Now a look at /var/log/dirsrv/slapd-ldaptest/errors shows that the replication bind with the bootstrap parameters works (group1 and user1 are now present on host2) but the replication bind with EXTERNAL auth fails. - ERR - slapi_ldap_bind - Error: could not bind id [(anon)] authentication mechanism [EXTERNAL]: error 49 (Invalid credentials) - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636) - Replication bind with EXTERNAL auth failed: LDAP error 49 (Invalid credentials) () - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636): Replication bind with SIMPLE auth resumed Clearly there is something wrong with the client certificate setup, but I could not figure out what. Any help is appreciated. Giacomo Comes

2 1

Re: aci sanity check
by Mark Reynolds 04 Mar '22

04 Mar '22

On 3/3/22 10:26 AM, David Ritenour wrote: > Hi Morgan, > > Try changing your target as follows: > > From: (target = "cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org") > To: (target = "ldap:///cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org") Correct, all "dn's" in an aci must be in an LDAP URL format. You should also add "(targetattr="*"). So try this: aci: (target = "ldap:///cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org") (targetattr="*")(targetfilter = "(objectclass=groupofuniquenames)") (version 3.0; acl "duo access"; allow (read, search, compare) groupdn = "ldap:///cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org";) HTH, Mark > > David Ritenour > MartinFederal Consulting, LLC > Senior Directory Engineer > 513 Madison Street SE > Huntsville, AL 35801 > > -----Original Message----- > From: Morgan Jones <morgan(a)morganjones.org> > Sent: Thursday, March 3, 2022 9:36 AM > To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org> > Subject: [389-users] aci sanity check > > ** WARNING: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hello, > > Would someone mind taking a look at the below and tell me what I am missing?? I have a requirement to make a group readable by its members: > > > > morgan@m1macbook ~ % ldapmodify -H ldaps://prdds22.domain.org -x -y pass.txt -f duo_aci_example.ldif modifying entry "cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org" > ldap_modify: Invalid syntax (21) > additional info: ACL Syntax Error(-5):(target = \22cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org\22)(targetfilter = \22(objectclass=groupofuniquenames)\22)(version 3.0; acl \22duo access\22;allow (read, search, compare) groupdn = \22ldap:///cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org\22;) > > > morgan@m1macbook ~ % > > > duo_aci_example.ldif: > dn: cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org > changetype: modify > replace: aci > aci: (target = "cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org") > (targetfilter = "(objectclass=groupofuniquenames)") > (version 3.0; acl "duo access"; > allow (read, search, compare) groupdn = "ldap:///cn=vpnall,ou=vpnaccess,ou=groups,dc=domain,dc=org";) > > > thank you! > > -morgan > _______________________________________________ > 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… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email and any such files in error and that any use, dissemination, forwarding, printing or copying of this email and/or any such files is strictly prohibited. If you have received this email in error please immediately notify hr(a)martinfed.com - (855) 212-1810 , and destroy the original message and any such files. > _______________________________________________ > 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… > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Directory Server Development Team

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 March 2022