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
audit log doesn't log adding a entry
by Picture Book
Hi, version: 1.2.10.2build: 2012.180.1655 After audit log is enable, I do not see any record in the audit log after a entry is added. Thanks. $grep changetype log/audit changetype: modify
changetype: modify
changetype: modify
changetype: modify
changetype: modify
changetype: modify
changetype: delete
changetype: modify
changetype: modrdn
changetype: modify
10 years, 11 months
Start TLS and 389 Directory
by Kyle Flavin
Hi, I've been struggling to setup 389 Directory server with Start TLS.
I have a multi-master replication working with four server. From an
external client running openldap's ldapsearch, I'm trying to do the
following:
ldapsearch -ZZ -x -h "myserver" -b "dc=example,dc=com" -D "cn=Directory
Manager" -W ""
I get an unsupported protocol error on servers that do not have
certificates installed.
In an attempt to resolve this, I tried to install a self-signed cert. I
created a ca.cert and a server.crt, and imported them into the Directory
Server. I then imported the ca.cert to the admin server. When I attempted
to import the same server.crt to the admin server, I got an error message
stating the certificate was for another host. Since the admin server and
directory server reside on the same host, if I generate a new request, it
will have an identical host name (I'm not sure if that's relevant to my
issue). After all of that, I now receive a "Connect Error
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed". I'm guessing I
need to import the root cert onto the client somehow, but I'm not sure how
to go about doing that.
This has become pretty time consuming, so I was hoping that someone more
knowledgeable could confirm that I'm at least travelling down the right
path. I've been following this Red Hat document:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9...
Thanks,
Kyle
10 years, 12 months
pwdUpdateTime when password policies are applied.
by Juan Carlos Camargo
I've installed 10.2.11.15 on a lab machine (fedora17) and set passwordTrackUpdateTime to on in config. This is the first time I'm testing this feature, I dont know if this also happens in former 10.2.11x versions. I've noticed that whenever a password policy is applied to an user, either directly or inherited from branch/ou, the pwdUpdateTime stops updating upon password changes. If I remove the password policy then the attribute works as expected. Is this the correct behaviour?
Regards.
JC.
--
J u an Carlos Camargo Carrillo
957-211157 , 650932877
10 years, 12 months
389-ds + CentOS 6.2 + TLS (self-signed, setupssl2.sh-script) + 389-console : complete FAIL. Would appreciate help.
by upen
Hi Raimund Eimann,
Am 09.07.2012 13:27, schrieb Ray:
> Hi Alberto,
>
> I got it working, logical, actually:
>
> When you start out the way I did, i.e. fresh installation, then
> running setup-ds-admin.pl, then setupssl2.sh both services (dirsrv
> and
> dirsrv-admin) will be restarable cleanly, i.e. they do actually run
> (see details below in my initial posting).
>
> When you then run 389-console, all you need to make sure is
>
> 1) use the fqdn you configured in /etc/hosts and setup-ds-admin.pl
> in the URI.
> 2) change from http to https in the URI string.
>
> Please try that out. It works now for me. You should be able to log
> into 389-console and populate you directory at this point.
>
> The next confusing thing (for the client side) that noone tells you
> (because it's sooo obvious?! - I don't think so…) is that there are
> two ldap.conf files to take care of:
>
> 1) /etc/openldap/ldap.conf (this one is for the openldap-clients
> [ldapsearch et al.]
> 2) /etc/pam_ldap.conf (this one takes care of the actual OS
> user/group resolution
>
> Here are mine:
>
> /etc/openldap/ldap.conf:
>
> URI ldap://ldap.baar.intra.bbcomputing.org/
> BASE dc=bbcomputing,dc=org
> TLS_CACERTDIR /etc/openldap/cacerts
> TLS_REQCERT allow
>
>
>
>
> /etc/pam_ldap.conf:
>
> base dc=bbcomputing,dc=org
> uri ldaps://ldap.baar.intra.bbcomputing.org/
> ssl start_tls
> tls_cacertdir /etc/openldap/cacerts
> pam_password md5
>
>
> Now, in both configs you see the tls_cacertdir parameter.
>
> 1) Make sure you have that directory.
> 2) After you ran setupssl.sh, you should find a certificate in
> /etc/dirsrv/slapd-<server identifier you chose in
> setup-ds-admin.pl>/cacert.asc. Copy this certificate: cp
> /etc/dirsrv/slapd-<server identifier you chose in
> setup-ds-admin.pl>/cacert.asc
> /etc/openldap/cacerts/cacert_389_ldap.pem
>
> This is not enough. The clients will only pick up certs with
> hashed filenames, so (not very prominent information in the docs
> also):
>
> 3) cd /etc/openldap/cacerts/
> 4) ln -s cacert_389_ldap.pem `openssl x509 -in
> cacert_389_ldap.pem -noout -hash`.0
>
> You'll need to repeat that on each and every client you plan to use.
>
> After all this things should work. You can try
>
> id <username from your directory>
>
> And see whta comes back. Alternatively you can try
>
> "getent passwd" to see all users you configures in your directory, or
> "getent group" for the groups
>
> ldapsearch -x -ZZ -h <fqdn of your ldap machine> should also work and
> return all entries as ldifs.
>
> Let me know how the things are going
I recently had same trouble with setupssl2.sh on RHEL 5.8 box with
389-console. Your post has been really useful to me. Everything you
have mentioned in the last two posts in this topic have worked
successfully for me. Thanks so much!
389-ds rocks as well as 389-console too :)
Aero
10 years, 12 months
ACL doesn't works
by Satish Patel
Hello ALL,
I have a web base application and user authenticate web application using
Directory Service (FDS). I want to restrict some user to not allow to login
so i have implement host base deny ACL. But somehow it doesn't works. may
be i am missing something. following acl i have.
(targetattr = "*") (version 3.0;acl "Host ACL";deny (all)(userdn =
> "ldap:///uid=test,ou=People,dc=example,dc=com") and (ip="10.101.100.236");)
>
But interesting thing is, it works with ldapsearch but not with Web
application?
~S
10 years, 12 months
Announcing 389 Directory Server version 1.2.11.15 Testing
by Rich Megginson
The 389 Project team is pleased to announce the release of
389-ds-base-1.2.11.15 for Testing. This release fixes another issue
with CLEANALLRUV, some schema and userpassword related fixes, and other
fixes.
The new packages and versions are:
389-ds-base 1.2.11.15
NOTE: 1.2.11 will not be available for Fedora 16 or earlier, nor for EL6
or earlier - 1.2.11 will only be available for Fedora 17 and later. We
are trying to stabilize current, stable releases - upgrades to 1.2.11
will disrupt stability.
Installation
yum install 389-ds --enablerepo=updates-testing
# or for EPEL
yum install 389-ds --enablerepo=epel-testing
setup-ds-admin.pl
Upgrade
yum upgrade 389-ds-base --enablerepo=updates-testing
# or for EPEL
yum upgrade 389-ds-base --enablerepo=epel-testing
setup-ds-admin.pl -u
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
Go to https://admin.fedoraproject.org/updates
In the Search box in the upper right hand corner, type in the name
of the package
In the list, find the version and release you are using (if you're
not sure, use rpm -qi <package name> on your system) and click on the
release
On the page for the update, scroll down to "Add a comment" and
provide your input
Or just send us an email to 389-users(a)lists.fedoraproject.org
Reporting Bugs
If you find a bug, or would like to see a new feature, use the 389 Trac
- https://fedorahosted.org/389
More Information
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
10 years, 12 months
ACI question
by Vesa Alho
Hi,
One ACI related question. I've been learning to use ACIs and read
various documentation. Let's say we have the following structure.
...
cn=Customer1,ou=Sales,dc=domain,dc=com
cn=Customer2,ou=Sales,dc=domain,dc=com
....
Then we have servers authenticating using credentials.
...
uid=server1,cn=VirtualServers,ou=Servers,dc=domain,dc=com
uid=server2,cn=VirtualServers,ou=Servers,dc=domain,dc=com
...
Question: What kind of ACI is needed to limit server1 access to read
Customer1 entry only?
Would I need to create an ACI for each server separately? I was
wondering that one should limit the amount of ACIs, so is there some
other way to achieve this? Thanks for help!
10 years, 12 months
Allow to add a user (userpassword)
by Alberto Viana
How Can allow a normal user from my directory (for example
uid=my.appuid,ou=test,dc=test,dc=com ) to add an user entry in the tree?
(Remebering that I dont want this user as a administrator, I just want that
user to be able to add users into a specific subtree in my directory). Is
that possible?
ldapmodify -a -c -h 389_ds_host -D "uid=my.appuid,ou=test,dc=test,dc=com"
-w - -f test.ldif
adding new entry uid=testando,ou=test,dc=test,dc=com
ldap_add: Insufficient access
ldap_add: additional info: Insufficient 'add' privilege to the
'userPassword' attribute
I tried this kind of ACI:
dn: ou=test,dc=test,dc=com
changetype: modify
add: aci
aci: (targetattr="userPassword")(version 3.0;aci "shib writer";allow
(add,write,compare) userdn="ldap:///uid=my.appuid,ou=test,dc=test,dc=com";)
or
aci: (targetattr="*")(version 3.0;aci "shib writer";allow
(add,write,compare) userdn="ldap:///uid=my.appuid,ou=test,dc=test,dc=com";)
Thanks
10 years, 12 months
