389-users July 2019

389-users@lists.fedoraproject.org

12 participants
25 discussions

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

ldif2db for single cn import
by Ghiurea, Isabella 31 Jul '19

31 Jul '19

Hi List I am looking how can I import a single user/cn entry using lidf2db from an an export taken using db2ldif -s option thank you Isabella

3 2

Setting Up 389 DS for Load Balancing with SSL Wildcard Certs
by Fong, Trevor 30 Jul '19

30 Jul '19

Hi Everyone, I've configured 2 new 389 DS hubs (eg new1.example.com, new2.example.com) and have connected them to our main 389 DS cluster. They each have their own self-signed certificate, and replication is working well. I now want to load-balance these 2 nodes under their own VIP/hostname: downtown.example.com. I have added our wildcard cert for *.example.com to each node's NSS cert DB in /etc/dirsrv/slapd-<instance> to cover the "downtown.example.com" address. However, querying the VIP's SSL, I see that the new node's self-signed cert is still presented instead of the wildcard: $ echo | openssl s_client -connect downtown.example.com:636 CONNECTED(00000003) depth=1 CN = self-ca.example.com verify error:num=19:self signed certificate in certificate chain --- <server cert details redacted> I thought that perhaps the node's own new1.example.com self-signed cert was taking precedence over the wildcard cert. But removing it resulted in: $ echo | openssl s_client -connect downtown.example.com:636 socket: Bad file descriptor connect:errno=9 Would anyone be able to tell me how to achieve this correctly, or point me in the right/another direction? Thanks a lot, Trev

2 3

Re: Latest Version of 389-ds-base for CentOS 7
by Viktor Ashirov 24 Jul '19

24 Jul '19

On Mon, Jul 8, 2019 at 7:17 PM Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > I was looking up the latest version of 389-ds and noticed that an update > has not been released since March 2019. Has there not been anymore updates > to this bundle? > There is an update to 389-ds-base in the upcoming batch update for RHEL 7.6. After it is released it should be available in CentOS 7. > > Paul M. Whitney, RHCSA, CISSP > Chesapeake IT Consulting, Inc. > 2680 Tobacco Rd > Chesapeake Beach, MD 20732 > > Work: 443-492-2872 > Cell: 410.493.9448 > Email: paul.whitney(a)chesapeake-it.com > *CONFIDENTIALITY NOTICE* > The information contained in this facsimile or electronic message is > confidential information intended for the use of the individual or entity > named above. If the reader of this message is not the intended recipient, > or an employee or agent responsible for delivering this facsimile message > to the intended recipient, you are hereby notified that any dissemination, > or copying of this communication is strictly prohibited. If this message > contains non-public personal information about any consumer or customer of > the sender or intended recipient, you are further prohibited under penalty > of law from using or disclosing the information to any third party by > provisions of the federal Gramm-Leach-Bliley Act. If you have received this > facsimile or electronic message in error, please immediately notify us by > telephone and return or destroy the original message to assure that it is > not read, copied, or distributed by others. > > _______________________________________________ > 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… > -- Viktor

1 0

Announcing 389 Directory Server 1.4.0.26
by Mark Reynolds 19 Jul '19

19 Jul '19

389 Directory Server 1.4.0.26 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.0.26 Fedora packages are available on Fedora 29 Fedora 29 https://koji.fedoraproject.org/koji/taskinfo?taskID=36350217 <https://koji.fedoraproject.org/koji/taskinfo?taskID=36350217> Bodhi F29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-6957eea289 <https://bodhi.fedoraproject.org/updates/FEDORA-2019-6957eea289> The new packages and versions are: * 389-ds-base-1.4.0.26-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.26.tar.bz2> Highlights in 1.4.0.26 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*. To install the 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. New UI Progress (Cockpit plugin) The new UI is fully functional. There are still parts that need to be converted to ReactJS, but it is fully functional. Configuration Tab Finished Written in ReachJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes No 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.0.26 * Issue 50499 - Fix audit issues and remove jquery from the whitelist * Issue 50355 - SSL version min and max not correctly applied * Issue 50325 - Add Security tab to UI * Issue 50177 - Add a new CI test case, also added fixes in lib389 -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.1.6
by Mark Reynolds 19 Jul '19

19 Jul '19

389 Directory Server 1.4.1.6 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.1.6 Fedora packages are available on Fedora 30 and rawhide. https://koji.fedoraproject.org/koji/taskinfo?taskID=36349721 <https://koji.fedoraproject.org/koji/taskinfo?taskID=36349721> - Rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=36350813 <https://koji.fedoraproject.org/koji/taskinfo?taskID=36350813> - Fedora 30 Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2019-73802bbbc9 <https://bodhi.fedoraproject.org/updates/FEDORA-2019-73802bbbc9> The new packages and versions are: * 389-ds-base-1.4.1.6-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.1.6.tar.bz2> Highlights in 1.4.1.6 * 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 it is fully functional. Configuration Tab Finished Written in ReactJS Server Tab Yes No Security Tab Yes Yes Database Tab Yes Yes Replication Tab Yes No 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.6 * Issue 50355 - SSL version min and max not correctly applied * Issue 50497 - Port cl-dump.pl tool to Python using lib389 * Issue 48851 - investigate and port TET matching rules filter tests(Final) * Issue 50417 - fix regression from previous commit * Issue 50425 - Add jemalloc LD_PRELOAD to systemd drop-in file * Issue 50325 - Add Security tab to UI * Issue 49789 - By default, do not manage unhashed password * Issue 49421 - Implement password hash upgrade on bind. * Issue 49421 - on bind password upgrade proof of concept * Issue 50493 - connection_is_free to trylock * Issue 50459 - Correct issue with allocation state * Issue 50499 - Fix audit issues and remove jquery from the whitelist * Issue 50459 - c_mutex to use pthread_mutex to allow ns sharing * Issue 50484 - Add a release build dockerfile and dscontainer improvements * Issue 50486 - Update jemalloc to 5.2.0 -- 389 Directory Server Development Team

1 0

LDAP Groups in sudoers file.
by Abhisheyk Deb 19 Jul '19

19 Jul '19

Hi, We have a ldap group called *ldapadmin *defined on our LDAP servers running 389 Directory Server. On the LDAP Client side. We have the following line added in */etc/sudoers* *%ldapadmin ALL=(ALL:ALL) ALL* We are able to login as a LDAP user which is part of the *ldapadmin *group and are able to get sudo privileges for that user by calling sudo before a command. Now these LDAP Client machines also have a local admin user which has been added to their local /etc/sudoers file. If we get our LDAP Servers down and try to do sudo when we are logged in as the local admin user, we are seeing a delay before sudo command can finish. When we remove the line *%ldapadmin ALL=(ALL:ALL) ALL *from */etc/sudoers*, the slowdowns do not happen anymore when we try to do sudo as the local admin user. That means every time we are trying to do sudo, it is reading the sudoers file and on parsing the file when it comes across the line *%ldapadmin ALL=(ALL:ALL) ALL*, it is not able to find this group since it is not a local group, but a group present on a LDAP Server which is currently unavailable. My question is why sudo command is trying to do a lookup for *ldapadmin *group when it is ran by the local admin user? Is there any way to bypass this check, because our LDAPClients have the need to have a local admin user. Any help would be appreciated. Thank you Abhishek Deb

3 4

Unable to login to admin console after upgrade
by Leonard 18 Jul '19

18 Jul '19

After upgrading to the following versions, I cannot login to the console. I am presented with the error "error result (49): invalid credentials". 389-admin-1.1.38-1.3.amzn1.x86_64 389-ds-base-libs-1.3.8.4-18.60.amzn1.x86_64 389-adminutil-1.1.21-1.1.amzn1.x86_64 389-ds-base-1.3.8.4-18.60.amzn1.x86_64 I don't remember exactly what the versions were prior. In the slapd access log, I see the following error associated with the login attempt "conn=160830 op=0 RESULT err=49 tag=97 nentries=0 etime=0.0026096322 - No suffix for bind dn found" I am using the username "admin" when logging in. I am however able to bind successfully as "uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot" when using ldapsearch, etc on the same host as running the console. SSLv2/3 are disabled and only TLS 1.2 is enabled on the server. adm.conf has: sslVersionMax: TLS1.2 sslVersionMin: TLS1.2 ssl bits from console.conf: NSSNickname Admin-Console NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha NSSProtocol TLSv1.2 NSSVerifyClient none NSSPassPhraseDialog file:/etc/dirsrv/admin-serv/pin.txt certutil: Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u CA Certificate CTu,u,u Admin-Console u,u,u So far I've tried running setup-ds-admin.pl -u, deleting my .389 directory, and changing the password of "uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot"

3 5

Re: Recommended SLAPD cache sizes
by William Brown 18 Jul '19

18 Jul '19

Generally the advice is: * autotune everything * handtune everything. IMO, autotuning is better (but I did write it, so I'm biased), and don't touch the "split" because we've seen lots of communication issues and challenges trying to educate about how the query processing works in the server core. I can write a longer piece of how all the query server layers fit together and what each tuning does, but I won't be able to for a few weeks (I'm traveling). > On 17 Jul 2019, at 02:30, Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > > Hi Mark, > > What I was referring to is: > > "nsslapd-cache-autosize-split > The value sets the percentage of RAM that is used for the database cache. The remaining percentage is used for the entry cache. > More than 512 MB RAM database cache do not improve the performance. Therefore, the database cache is limited to 512 MB." - https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h… > Then further down is a table that tops off at 512MB for dbcache in the same document. But even further down it contradicts by suggesting the results of the dbmon.sh script can provide insight into how much more the dbcache can be to improve performance with the 2.2% free example. > All these tuning features are great, but gets confusing when trying to mix and match the best combination of settings. > I did go over your recommendations and have settled for now on increasing the dbcache to 5GB. Our consumers are configured with 64GB and the masters 128GB. While the percentage of free space in the dbcache is not optimal (more than 12%), we are achieving a hit ratio of 99%. It's confusing because we never explain how queries and cache's affect each other in a coherent document ... :) Which is tottaly our fault. summary version - dbcache will cache the raw pages for bdb (IE indexes, serialised entry pages etc). entry cahce is deserialised entries in a seperate hashmap internal to the server. So entries go through: BDB -> dbcache -> entrycache -> entries in results etc. You generally want to cache more in the entrycache because the deserialisation between dbcachce -> entrycache is really expensive. If your entrycache is sized properly, the dbcacche ends up caching index pages instead. This goes through: BDB -> dbcache -> IDL -> Query processing There is a "slight" cost from dbccache -> IDL, but not enough to justify a cacche. So your dbccache becomes an index cache effectively, and as a result, generally is "smaller" because IDLs are very very small - you can probably size what a dbcache should be by listing the content in var/lib/dirsrv/slapd-instance/db/userRoot/*.db, excluding "id2entry". Then add maybe 50% or so to get some breathing room. You can size your entrycache by looking at the size of the id2entry file, and again, add a bit extra fro breathing room and struct overheads. Hope that helps - perhaps a future autotuning will do this same process. > > Paul M. Whitney, RHCSA, CISSP > Chesapeake IT Consulting, Inc. > 2680 Tobacco Rd > Chesapeake Beach, MD 20732 > > Work: 443-492-2872 > Cell: 410.493.9448 > Email: paul.whitney(a)chesapeake-it.com > CONFIDENTIALITY NOTICE > The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others. > > > From: Mark Reynolds <mreynolds(a)redhat.com> > Sent: Tuesday, July 16, 2019 9:30 AM > To: General discussion list for the 389 Directory server project.; Paul Whitney > Subject: Re: [389-users] Recommended SLAPD cache sizes > > Hi Paul, > > On 7/16/19 9:16 AM, Paul Whitney wrote: >> Is there some formula or recommendation on determining what would be the optimal cache settings for a directory server (389-ds of course) with following sizes? I looked at the DS 10 Admin Guide online and am getting conflicting information. But the manual shows a table and suggests that the max size for the cn=config dbcache is 512MB. > There is no limit on the cache size value besides what you are limited to by a unsigned long integer. Do you have a link to where it says 512 MB is a maximum? >> But I tried with 5GB and it appears to work fine with it, although over time start to see negative values (prob not enough cache) and roevicts while running the dbmon.sh script. >> >> __db files = ~6GB >> groupRoot = 1.5GB >> userRoot = 20GB >> >> What values would yield best performance for: >> >> cn=config dbcache? currently set to 5GB but are still seeing lots of roevicts. As much >> >> userRoot entry cache? currently set to 21GB (hit ratio so far at 95%) >> >> groupRoot entry cache? currently set to 2GB (hit ration so far at 96%) >> >> Virtual machine configured with 8CPU, 128GB RAM. Load is in the low 20's with occasional spikes to high 20's. > If you have 128 GB available to you then I would continue to increase the cache sizes until you get to 99% hit ratio for the two entry caches, and the db cache. Also make sure the DN and NDN caches also have a 99% cache hit ratio: > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h… > > https://www.port389.org/docs/389ds/design/normalized-dn-cache.html > > > > I would also look into running the DB on a RAM disk since you have the resources to do so: > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h… > > > HTH, > Mark > >> >> Paul M. Whitney, RHCSA, CISSP >> Chesapeake IT Consulting, Inc. >> 2680 Tobacco Rd >> Chesapeake Beach, MD 20732 >> >> Work: 443-492-2872 >> Cell: 410.493.9448 >> Email: paul.whitney(a)chesapeake-it.com >> CONFIDENTIALITY NOTICE >> The information contained in this facsimile or electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this facsimile message to the intended recipient, you are hereby notified that any dissemination, or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this facsimile or electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others. >> >> >> >> _______________________________________________ >> 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… > -- > > 389 Directory Server Development Team > > _______________________________________________ > 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2019