I need to deploy multiple 389 directory server instances into production environment. I want to know if 389 directory server supports wildcard server certificate. Currently the subject for my instance is:
Subject: "CN=dmdev1.christianbook.com,OU=389 Directory Server"
When using wildcard, it will be:
Subject: "CN=*.christianbook.com,OU=389 Directory Server"
Is it possible?
I guess GoDaddy might be able to support wildcard certificate but I am not sure. Does anyone know about it?
We are configuring password policy in 389 directory. We’re running what I believe is the latest stable version form the Epel repository on CentOS 6:
[root@devldapm03 ~]# rpm -qa|grep 389
[morgan@devldapm03 ~]$ uname -a
Linux devldapm03.philasd.net 2.6.32-573.26.1.el6.x86_64 #1 SMP Wed May 4 00:57:44 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[morgan@devldapm03 ~]$ cat /etc/redhat-release
CentOS release 6.7 (Final)
I just did a yum update, rebooted and installed 389 anew.
The password policy works well if configured globally (from the Data node under Configuration)
However when I attempt to create a subtree level policy (Directory->domain->employees, right click Manage Password Policy->for subtree) under ou=employees,dc=domain,dc=org the effect is as if there is no policy. If I subsequently disable the subtree policy I cannot get the global policy to take over. In fact the only way I’ve been able to get the global policy to work is to re-install from scratch.
I also tried command line configuration and was unable to get the policy working at all though I have more confidence of my understanding of the process via the console.
We’ve tried different policy settings but for testing purposes I’m just setting a minimum password length of 8 characters.
Is there something I’m missing?
I have been looking for a comprehensive, easy to understand writeup on how to use ldapsearch.
I am troubleshooting a connectivity problem, that may be related to SSL/TLS, or some change to that config.
it may be related to permissions.
The problem manifested itself several months ago. In troubleshooting the issues I discovered some basic connectivity problems that I believe are solved. I was attempting to use ldapsearch and had several questions.
This is what is installed at the 389 DS:
From 389 console:
Installation date: October 4, 2013 10:49:53 AM PDT
This was setup and then the configuration modified to use SSL/TLS so the directory server runs on port 636.
So for my questions:
What is mozldap-tools and should I be using that version of ldapsearch? I found several references searching for information on how to use ldapsearch that were confusing.
I would normally test connectivity to the server from the client with a command like (modified to protect the guilty):
ldapsearch -H ldaps://ds1.domain.com [-x] -D "cn=directory manager" -W "cn=admin-serv-ds1,cn=389 Administration Server,cn=Server Group,cn=ds1.domain.com,ou=domain.com,o=NetscapeRoot"
This produces results, but it seems like when I experiment with it I always get the same results, or just slightly different results.
What variations should produce different results?
How can I show all of the attributes for all of the entries? Is that smart? I thought this saved to a file would help in an emergency backup situation.
Can ldapsearch break anything?
How can I use it to check schema? Is there a better way?
How can I use it to determine if a user exists, and if so what are his attributes and the contents of the attributes?
How can I see what permissions a user has in 389ds?
I have been pouring over material on the web, but I feel the answers are just a bit more elusive than they ought to be. A guide would be nice. the man page omits examples with authentication. Is there a way to set defaults for the auth to clean up the command?