Problem browsing LDAP with Outlook
by Chris Bryant
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 years, 3 months
MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser
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-grou...)
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.
3 years, 3 months
ldapsearch doesn't return the userpassword field
by Janet Houser
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 years, 6 months
Odd issue with 389 and updating to Cent 6.8 with TLS/SSL
by John McKee
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)
6 years, 10 months
Pass-Through authentication configured to delegate the password verification on specifics LDAP accounts
by Romain Esnault
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
6 years, 10 months
sslversionMin supported in 389-DS 1.3.5
by ghiureai
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*********
6 years, 10 months
CentOS 6.7 upgrade to CentOS 6.8 and TLS/SSL issues
by J McKee
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)
6 years, 10 months
use of wildcards in ACIs
by Crocker, Deborah
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
6 years, 10 months
IMPORTANT - Fedorahosted trac ticket system is being replaced by Pagure
by Mark Reynolds
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
6 years, 10 months
389 DS - Choosing certificate to authenticate
by alex.duarte92＠gmail.com
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.
6 years, 10 months
