389-users January 2017

389-users@lists.fedoraproject.org

13 participants
11 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

ldapsearch doesn't return the userpassword field
by Janet Houser 14 May '18

14 May '18

Hi, I've been looking through the archives for information, but I haven't stumbled on a solution to my problem. I'm running ds-389 (389-ds-base-1.3.4.0) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly. I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has of the password when an ldapsearch is issued. However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't quite get it right. Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password. Thanks,

5 12

Odd issue with 389 and updating to Cent 6.8 with TLS/SSL
by John McKee 27 Jan '17

27 Jan '17

We had to update our server from CentOS 6.7 to CentOS 6.8 due to security compliance. When doing so however, it caused 389 to be unstable for TLS/SSL port 636. It would be up for a minute or two, then fail with the following error when a server/script tried to connect. Non-TLS/SSL port 389 would work fine without any issues/errors. Before we patched, it would work without issues. Connection to port shows no issue with certificate. [26/Jan/2017:01:02:39 -0500] conn=97 fd=64 slot=64 SSL connection from X.X.X.X to X.X.X.X [26/Jan/2017:01:02:39 -0500] conn=97 op=-1 fd=64 closed - Unspecified failure while processing SSL Client Key Exchange handshake. From the client: TLS: loaded CA certificate file /etc/pki/tls/certs/bundle.crt. TLS: certificate [CN=XXXXXX.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated] is valid TLS: error: tlsm_PR_Recv returned -1 - error 104:Connection reset by peer TLS: error: connect - force handshake failure: errno 104 - moznss error -5961 TLS: can't connect: TLS error -5961:TCP connection reset by peer. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS error -5961:TCP connection reset by peer ldap_sasl_bind Normal Connection: [26/Jan/2017:05:29:35 -0500] conn=904 fd=65 slot=65 SSL connection from X.X.X.X to X.X.X.X [26/Jan/2017:05:29:35 -0500] conn=904 TLS1.2 256-bit AES Current Version of 389: 389-adminutil-1.1.19-1.el6.x86_64 389-ds-base-libs-1.2.11.15-74.el6.x86_64 389-ds-console-doc-1.2.6-1.el6.noarch 389-admin-1.1.35-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-dsgw-1.1.11-1.el6.x86_64 389-ds-base-1.2.11.15-74.el6.x86_64 389-console-1.1.7-1.el6.noarch NSS: nss-3.21.0-8.el6.x86_64 nss-softokn-3.14.3-23.el6_7.x86_64 nss-softokn-freebl-3.14.3-23.el6_7.i686 nss-softokn-freebl-3.14.3-23.el6_7.x86_64 nss-sysinit-3.21.0-8.el6.x86_64 nss-tools-3.21.0-8.el6.x86_64 nss-util-3.21.0-2.el6.x86_64 Port is open: tcp 0 0 :::636 :::* LISTEN Approx Strace: getpeername(8, 0x7ffe450d5980, [112]) = -1 ENOTCONN (Transport endpoint is not connected) poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=-1}], 4, 250) = 1 ([{fd=8, revents=POLLIN}]) accept(8, {sa_family=AF_INET6, sin6_port=htons(52890), inet_pton(AF_INET6, "::ffff:X.X.X.X", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 36 fcntl(36, F_GETFL) = 0x2 (flags O_RDWR) fcntl(36, F_SETFL, O_RDWR|O_NONBLOCK) = 0 fcntl(36, F_DUPFD, 64) = 64 close(36) = 0 setsockopt(64, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 setsockopt(64, SOL_TCP, TCP_NODELAY, [0], 4) = 0 getsockname(64, {sa_family=AF_INET6, sin6_port=htons(636), inet_pton(AF_INET6, "::ffff:X.X.X.X", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 getpeername(8, 0x7ffe450d5980, [112]) = -1 ENOTCONN (Transport endpoint is not connected) poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=-1}, {fd=64, events=POLLIN}], 5, 250) = 1 ([{fd=64, revents=POLLIN}]) futex(0x16ee83c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x16ee838, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 getpeername(8, 0x7ffe450d5980, [112]) = -1 ENOTCONN (Transport endpoint is not connected) poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=-1}], 4, 250) = 1 ([{fd=40, revents=POLLIN}]) read(40, "\0", 200) = 1 close(64) = 0 getpeername(8, 0x7ffe450d5980, [112]) = -1 ENOTCONN (Transport endpoint is not connected) poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=-1}], 4, 250) = 0 (Timeout)

4 10

Pass-Through authentication configured to delegate the password verification on specifics LDAP accounts
by Romain Esnault 26 Jan '17

26 Jan '17

Hello, We have an Active Directory with windows accounts and we need to have these accounts in another 389 DS to expose to applications. We will have these accounts in both LDAP ; 389 DS in front and Active Directory in back We want that the password verification is done with the one stored into the Active Directory even if applications bind the 389 DS. With OpenLDAP, it's possible to use Pass-Through authentication configured to delegate the password verification on specifics LDAP accounts. --> http://www.openldap.org/doc/admin24/security.html#Pass-Through authentication But the 389 DS documentation seems indicate that for Pass-Through authentication is possible only if accounts are not existing ... Is it possible with 389 DS to implement the Pass-Through authentication only to delegate password like openLDAP can do ? Thanks for your help

2 1

sslversionMin supported in 389-DS 1.3.5
by ghiureai 26 Jan '17

26 Jan '17

Hi List, I 'm running 389-DS : 389-ds-base-1.3.5.15-1.fc24.x86_64 with TLS enable and the following cfg , is the last update version of TLS supported in this version? i try using ( sslVersionMin: TLS1.1 and sslVersionMax: TLS2.0) but will not work, seems works for (sslVersionMin: TLS1.1 and sslVersionMax: TLS1.2) dn: cn=encryption,cn=config objectClass: top objectClass: nsEncryptionConfig cn: encryption nsSSLSessionTimeout: 0 nsSSLClientAuth: allowed sslVersionMin: TLS1.0 sslVersionMax: TLS2.0 nsSSL3Ciphers: default allowWeakCipher: off nsKeyfile: alias/slapd*********** nsCertfile: alias/slapd*********

2 1

CentOS 6.7 upgrade to CentOS 6.8 and TLS/SSL issues
by J McKee 26 Jan '17

26 Jan '17

We had to update our server from CentOS 6.7 to CentOS 6.8 due to security compliance. When doing so however, it caused 389 to be unstable for TLS/SSL port 636. It would be up for a minute or two (and take connections), then fail with the following error when a server/script tried to connect. Non-TLS/SSL port 389 would work fine without any issues/errors. Before we patched, it would work without issues. Connection to port shows no issue with certificate. [26/Jan/2017:01:02:39 -0500] conn=97 fd=64 slot=64 SSL connection from X.X.X.X to X.X.X.X [26/Jan/2017:01:02:39 -0500] conn=97 op=-1 fd=64 closed - Unspecified failure while processing SSL Client Key Exchange handshake. From the client: TLS: loaded CA certificate file /etc/pki/tls/certs/bundle.crt. TLS: certificate [CN=XXXXXX.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated] is valid TLS: error: tlsm_PR_Recv returned -1 - error 104:Connection reset by peer TLS: error: connect - force handshake failure: errno 104 - moznss error -5961 TLS: can't connect: TLS error -5961:TCP connection reset by peer. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS error -5961:TCP connection reset by peer ldap_sasl_bind Normal Connection: [26/Jan/2017:05:29:35 -0500] conn=904 fd=65 slot=65 SSL connection from X.X.X.X to X.X.X.X [26/Jan/2017:05:29:35 -0500] conn=904 TLS1.2 256-bit AES Current Version of 389 (389 was already updated and working well before the 6.8 upgrade): 389-adminutil-1.1.19-1.el6.x86_64 389-ds-base-libs-1.2.11.15-74.el6.x86_64 389-ds-console-doc-1.2.6-1.el6.noarch 389-admin-1.1.35-1.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-dsgw-1.1.11-1.el6.x86_64 389-ds-base-1.2.11.15-74.el6.x86_64 389-console-1.1.7-1.el6.noarch NSS (some updated during the upgrade): nss-3.21.0-8.el6.x86_64 nss-softokn-3.14.3-23.el6_7.x86_64 nss-softokn-freebl-3.14.3-23.el6_7.i686 nss-softokn-freebl-3.14.3-23.el6_7.x86_64 nss-sysinit-3.21.0-8.el6.x86_64 nss-tools-3.21.0-8.el6.x86_64 nss-util-3.21.0-2.el6.x86_64 Port is open: tcp 0 0 :::636 :::* LISTEN Approx Strace: getpeername(8, 0x7ffe450d5980, [112]) = -1 ENOTCONN (Transport endpoint is not connected) poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=-1}], 4, 250) = 1 ([{fd=8, revents=POLLIN}]) accept(8, {sa_family=AF_INET6, sin6_port=htons(52890), inet_pton(AF_INET6, "::ffff:X.X.X.X", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 36 fcntl(36, F_GETFL) = 0x2 (flags O_RDWR) fcntl(36, F_SETFL, O_RDWR|O_NONBLOCK) = 0 fcntl(36, F_DUPFD, 64) = 64 close(36) = 0 setsockopt(64, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 setsockopt(64, SOL_TCP, TCP_NODELAY, [0], 4) = 0 getsockname(64, {sa_family=AF_INET6, sin6_port=htons(636), inet_pton(AF_INET6, "::ffff:X.X.X.X", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 getpeername(8, 0x7ffe450d5980, [112]) = -1 ENOTCONN (Transport endpoint is not connected) poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=-1}, {fd=64, events=POLLIN}], 5, 250) = 1 ([{fd=64, revents=POLLIN}]) futex(0x16ee83c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x16ee838, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 getpeername(8, 0x7ffe450d5980, [112]) = -1 ENOTCONN (Transport endpoint is not connected) poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=-1}], 4, 250) = 1 ([{fd=40, revents=POLLIN}]) read(40, "\0", 200) = 1 close(64) = 0 getpeername(8, 0x7ffe450d5980, [112]) = -1 ENOTCONN (Transport endpoint is not connected) poll([{fd=40, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=-1}], 4, 250) = 0 (Timeout)

2 1

use of wildcards in ACIs
by Crocker, Deborah 24 Jan '17

24 Jan '17

We have used directory 389 for many years having migrated forward from the iPlanet/Sun version. Back when we were on Sun we discovered that any attribute listed in an ACI where we wanted to use a wildcard had to have the attribute name in all lower case. For instance, if we wanted to reference myAttribute* when we had (myAttributeName1, myAttributeName2, etc) then in the ACI it had to be myattribute*. This holds true up through at least 1.2.11.15 which is our current production. We are now testing 1.3.5.13, hoping to move our production forward into that. We'd been having trouble with some of our processes and have discovered that in the ACIs now the wildcard problem has switched its case sensitivity. In the newer server we have to change all our wildcard attributes to myAttribute*. I haven't checked through all our schema values to see if there will be some spec'd with all lowercase (that is not our naming policy but we need to check). I also note that if the attribute is spelled out completely then it doesn't care about the case at all. This seems to me to have been a bug in the old one and is a bug in the new one. Has anyone come up against this and have anything to add? Deborah Crocker, PhD Systems Engineer III Office of Information Technology The University of Alabama Box 870346 Tuscaloosa, AL 36587 Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu

2 1

IMPORTANT - Fedorahosted trac ticket system is being replaced by Pagure
by Mark Reynolds 18 Jan '17

18 Jan '17

On February 28th the fedorahosted trac ticket system/repo is being decommissioned, and we will be moving to Pagure (https://pagure.io/) as our ticketing system and source code repository. The Pagure work flow is very similar to trac, and we will be adding a wiki doc on how to use it once we get closer to doing our migration to Pagure. We are currently planning on doing the migration in the middle of February. As for the trac ticket migration there is one issue. All cc'ed users will be lost. If you are the assignee or the reporter you will still get notifications, but you won't if you were only in the cc list of a ticket. Also, the pagure tickets (Issues) that are migrated will continue to use the same trac ticket IDs. So you can still easily track/follow tickets you were previously interested in. If you have previously filed tickets, or you might want to, please goto the pagure web site https://pagure.io/ and simply log in using for FAS credentials. This will automatically add you to the Pagure system. Please do this sooner than later so you don't experience any disruptions with notifications. We will keep you posted as we get closer to the migration. Feel free to email me with any questions. Regards, Mark

2 2

389 DS - Choosing certificate to authenticate
by alex.duarte92＠gmail.com 09 Jan '17

09 Jan '17

How do you get certificates to populate in the authenticate section. At the moment i have my 389 DS to do optional certificate enforcement but i want to require it... Just not sure why my certificates are not showing up in the list.

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users January 2017