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.
2 years, 9 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.
2 years, 10 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
Console hang after 4th server install
by Morgan Jones
I’m in the process of installing 389 in CentOS 7 from epel (versions below) and find that the console becomes unresponsive after I install the 4th server. I can open the console and expand a few servers but within 30 seconds it consistently hangs. I am storing configuration data in one server.
Has anyone else seen this or do you have any insight?
Thanks,
-morgan
[morgan@devldap03 ~]$ rpm -qa|grep 389
pcp-pmda-ds389log-3.11.3-4.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
389-adminutil-1.1.21-2.el7.x86_64
389-admin-1.1.46-1.el7.x86_64
389-ds-console-doc-1.2.16-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-ds-base-libs-1.3.5.10-21.el7_3.x86_64
389-ds-base-1.3.5.10-21.el7_3.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-console-1.1.18-1.el7.noarch
pcp-pmda-ds389-3.11.3-4.el7.x86_64
389-ds-console-1.2.16-1.el7.noarch
[morgan@devldap03 ~]$
5 years, 9 months
LDAP: error code 19 - invalid password syntax - passwords with storage scheme are not allowed
by Kirk MacDonald
Hello
I am migrating an LDAP system from CentOS-Directory/8.1.0 B2009.134.1334 to 389-Directory/1.3.5.10 B2017.145.2037
We have an external app/too for user password management.
The tool binds as a special user when changing passwords in the "forgot password" use case, and as the regular user in the "I know my password but want to change it" use case.
In both use cases the tool has the behavior of generating an SSHA hash string and then doing an ldapmodify to change the userPassword value to that string. When we tested the tool against the new instances we got the error in the subject.
I had already defined the proper ACI for the special user. Digging around I found if I provided the dn for special user in the passwordAdminDN attribute value in cn=config the "forgot password" use case worked. However the application will of course continue to fail when it binds as the regular users.
One additional item - the systems we are coming from do have a Password Policy configured, but I have not explicitly configured one yet on the new systems, even though the relevant per-user attributes came over in the db migration. However, the password policy is only for when the passwords need to be changed/expired, as opposed to syntax/strength.
Is there a way around this without changing our app/tool to send the plain password over SSL/TLS/STARTTLS?
Thanks
Kirk MacDonald
Eastlink
5 years, 9 months
Re: Last update message time stamp
by Paul Whitney
I am referring to the admin console in "Last Update Message" section where "Begin time of last update:" and "End time of last update:" If there is a problem with replication, the time stamps reset to "Wed Dec 31 1900 EST 1969" and not the last successful replication time.
Ditto for the Consumer Initialization Status, the time stamps get reset to "Wed Dec 31 1900 EST 1969"
Paul M. Whitney
E-mail: paul.whitney(a)mac.com
Sent from my browser.
On Aug 28, 2017, at 12:41 PM, Mark Reynolds <mareynol(a)redhat.com> wrote:
On 08/28/2017 11:54 AM, Paul Whitney wrote:
Hi guys,
Is there a reason why the update time stamp defaults to Dec 31, 19:00 EST 1969 in the console?
Hey Paul,
What exactly are you referring to? Modifytimestamp? Which entry?
Mark
Is there a way to preserve the last successful or failed timestamp?
Paul M. Whitney
E-mail: paul.whitney(a)mac.com
Sent from my browser.
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
5 years, 9 months
Last update message time stamp
by Paul Whitney
Hi guys,
Is there a reason why the update time stamp defaults to Dec 31, 19:00 EST 1969 in the console? Is there a way to preserve the last successful or failed timestamp?
Paul M. Whitney
E-mail: paul.whitney(a)mac.com
Sent from my browser.
5 years, 9 months
Choice of version?
by Jeff Smith
Hello,
I am currently running an old Centos DS and looking to building a new 389 ds and import my users. I see that both 1.3.5 and 1.3.6 are currently supported. The EPEL repo for CentOS 7 installs 1.3.5.10. Any recommendations to go to 1.3.6 or stick with the default version?
Thanks!
5 years, 9 months
Announcing Directory Server 1.3.6.8-1
by Mark Reynolds
389 Directory Server 1.3.6.8
The 389 Directory Server team is proud to announce 389-ds-base
version 1.3.6.8
Fedora packages are available from the Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-c95a212f02
The new packages and versions are:
* 389-ds-base-1.3.6.8-1 Fedora 26
Source tarballs are available for download at Download
389-ds-base Source
<http://www.port389.org/binaries/389-ds-base-1.3.6.8.tar.bz2>
Highlights in 1.3.6.8
* Bug fix
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://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...
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.3.6.8
* Ticket 49356 - mapping tree crash can occur during tot init
5 years, 9 months