admin and Directory Manager accounts cannot log into 389-console

[warron.french]

Please help.

I know that I am running on CentOS-6.6,
I know that the software is at version-level *1.1.8-1*.
I know that it was working over 1 year ago.
I know that the 389-ds my workstations authenticated against were working
and with LDAPS (port 636/tcp).
I also know that I tried to secure the admin server through web access also
with an LDAPS.


I had the password for the admin, and the cn=Directory Manager account
entries documented, and they no longer work anymore.

I attempted to execute:
pwdhash <newPassword> and copied the new {SSHA} hash into the appropriate
field in the /etc/dirsrv/slapd-*E2WAN/dse.ldif *file *after shutting down
both services*.

I don't know how to troubleshoot this application?  What log file where and
when.

Please help.


--------------------------
Warron French

[William Brown]

>  
>  I had the password for the admin, and the cn=Directory Manager account
>  entries documented, and they no longer work anymore. 
Can you describe "they don't work". Directory Server fails to start? The
cn=directory manager account will not bind? What error message do you get?

>  
>  I attempted to execute:
>  pwdhash <newPassword> and copied the new {SSHA} hash into the appropriate
>  field in the /etc/dirsrv/slapd-*E2WAN/dse.ldif *file *after shutting down
>  both services*. 
*what field* did you update? Did you do it for Directory Manager? cn=admin?
Both? 

Did you copy the hash to look like:

{SSHA}aAAsVqh3/CE+ITeD+g1cuflaLhYaYAjGW/RxRA==

Including the {ALGO} stanza at the front? 

>  
>  I don't know how to troubleshoot this application?  What log file where and
>  when.
>   
/var/log/dirsrv/slapd-<INSTANCE NAME>/errors is good for if the server won't
start, and will tell you if the hash format is messed up.

/var/log/dirsrv/slapd-<INSTANCE NAME>/access will tell you more about why an
account cannot bind.


Please provide *more* detail as this helps us to solve your issue. Exact steps,
what you changed, reasonable fake values for passwords for example. 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

[warron.french]

Hello Mr. Brown,

The 'they' I am referring to are the two accounts:  1- "admin", and 2-
"cn=Directory Manager" .

As for the error message, this is what I see in the little dialog box that pops up after a
failed attempted:
[                                        Error                                           
]
Cannot logon because of an incorrect User ID, Incorrect password or Directory problem.

HttpException:
Response: HTTP/1.1 401 Authorization Required
Status:  401
URL:   http://localhost:9830/admin-serv/authenticate

                  [OK]

/////////////
As for which field(s) I updated the single one-liner in the /etc/dirsrv/admin-serv/admpq
file, and yes - I definitely included the {SHA}<gibberish> hash into the file,
overwriting the original.  P.S.  I did make a backup copy of the original -admpw.orig.

I also updated the hash for "cn=Directory Manager" inside the
/etc/dirsrv/slapd-E2WAN/dse.ldif file updating the nsslapd-rootpw: to have an
{SSHA}<gibberish> hash.

///////////
As you suggested, I looked into the /var/log/dirsrv/slapd-E2WAN/errors file, I decided to
purposely restart the whole server and at the very bottom, I found the following:
[05/Apr/2016:15:43:01 -0400] - Information: Non-Secure Port Disabled
[05/Apr/2016:15:43:01 -0400] - SSL alert: CERT_VerifyCertificateNow: verify certificate
failed for cert wsf-LabLDAP.crt of family cn=RSA,cn=encryption,cn=config (Netscape
Portable Runtime error -8181 - Peer's Certificate has expired.)
[05/Apr/2016:15:43:01 -0400] - 389-Directory/1.2.11.15 B2014.314.1342 starting up
[05/Apr/2016:15:43:02 -0400] - slapd started.  Listening on All Interfaces port 636 for
LDAPS requests

What draws my attention is the second line of output, SSL alert: CERT_VerifyCertificateNow
etc... etc... etc...  I would like to update the certificate, because I did generate a new
CA-signed certificate with the same name wsf-LabLDAP.crt; and I did copy it into the same
folder that the original 'expired' certificate was stored in.

I also looked into the /var/log/dirsrv/slapd-E2WAN/access file, after the same reboot, and
found the following:
[05/Apr/2016:15:43:03 -0400] conn=1 fd=64 slot=64 SSL connection from 192.168.2.243 to
192.168.2.243
[05/Apr/2016:15:43:03 -0400] conn=1 op=-1 fd=64 closed - SSL peer cannot verify your
certificate.
[05/Apr/2016:15:43:03 -0400] conn=2 fd=64 slot=64 SSL connection from 192.168.2.243 to
192.168.2.243
[05/Apr/2016:15:43:03 -0400] conn=2 op=-1 fd=64 closed - SSL peer cannot verify your
certificate.
[05/Apr/2016:15:43:04 -0400] conn=3 fd=64 slot=64 SSL connection from 192.168.2.243 to
192.168.2.243
[05/Apr/2016:15:43:04 -0400] conn=3 op=-1 fd=64 closed - SSL peer cannot verify your
certificate.
[05/Apr/2016:15:43:04 -0400] conn=4 fd=64 slot=64 SSL connection from 192.168.2.243 to
192.168.2.243
[05/Apr/2016:15:43:04 -0400] conn=4 op=-1 fd=64 closed - SSL peer cannot verify your
certificate.
[05/Apr/2016:15:43:09 -0400] conn=5 fd=64 slot=64 SSL connection from 192.168.2.243 to
192.168.2.243
[05/Apr/2016:15:43:09 -0400] conn=5 op=-1 fd=64 closed - SSL peer cannot verify your
certificate.
[05/Apr/2016:15:43:10 -0400] conn=6 fd=64 slot=64 SSL connection from 192.168.2.243 to
192.168.2.243
[05/Apr/2016:15:43:10 -0400] conn=6 op=-1 fd=64 closed - SSL peer cannot verify your
certificate.
[05/Apr/2016:15:44:34 -0400] conn=7 fd=64 slot=64 SSL connection from 192.168.2.243 to
192.168.2.243
[05/Apr/2016:15:44:34 -0400] conn=7 op=-1 fd=64 closed - SSL peer cannot verify your
certificate.
[05/Apr/2016:15:46:52 -0400] conn=8 fd=64 slot=64 SSL connection from 192.168.2.243 to
192.168.2.243
[05/Apr/2016:15:46:52 -0400] conn=8 op=-1 fd=64 closed - SSL peer cannot verify your
certificate.

I don't know how to fix this problem.


I hope I provided proper and full details for your questions.  I don't mind sharing
clear text passwords, the real system is not reachable from the internet, and I am having
this problem also in my virtual lab (where the data from above is copy/pasted).

Thank you.

[William Brown]

>  
>  ///////////
>  As you suggested, I looked into the /var/log/dirsrv/slapd-E2WAN/errors file, I
>  decided to purposely restart the whole server and at the very bottom, I found
>  the following:
>  [05/Apr/2016:15:43:01 -0400] - Information: Non-Secure Port Disabled
>  [05/Apr/2016:15:43:01 -0400] - SSL alert: CERT_VerifyCertificateNow: verify
>  certificate failed for cert wsf-LabLDAP.crt of family
>  cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's
>  Certificate has expired.)
>  [05/Apr/2016:15:43:01 -0400] - 389-Directory/1.2.11.15 B2014.314.1342 starting
>  up
>  [05/Apr/2016:15:43:02 -0400] - slapd started.  Listening on All Interfaces port
>  636 for LDAPS requests
>  
>  What draws my attention is the second line of output, SSL alert:
>  CERT_VerifyCertificateNow etc... etc... etc...  I would like to update the
>  certificate, because I did generate a new CA-signed certificate with the same
>  name wsf-LabLDAP.crt; and I did copy it into the same folder that the original
>  'expired' certificate was stored in. 
Do you have the CA certificate in your /etc/dirsrv/slapd-<instance>/ nssdb? You
should be able to see it with certutil, and the trust flags CT. Try:

certutil -L -d /etc/dirsrv/slapd-<instance>/



Do you have a ca referenced in /etc/openldap/ldap.conf as well? That ca location
will need the CA certificate too. 

What distro and version are you running (IE RHEL7)

I think this is an SSL issue at this point, not a password one. The password
parts all looked fine to me. 

>  
>  
>  [05/Apr/2016:15:46:52 -0400] conn=8 fd=64 slot=64 SSL connection from
>  192.168.2.243 to 192.168.2.243
>  [05/Apr/2016:15:46:52 -0400] conn=8 op=-1 fd=64 closed - SSL peer cannot verify
>  your certificate.
>  
>  
>  
>  I hope I provided proper and full details for your questions.  I don't mind
>  sharing clear text passwords, the real system is not reachable from the
>  internet, and I am having this problem also in my virtual lab (where the data
>  from above is copy/pasted). 
I don't think we'll need these. 



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

[warron.french]

Good morning Mr. Brown,

Here is the results of your first query; executing the certutil command as you presented
it (with adding my instance):
certutil -L -d /etc/dirsrv/slapd-E2WAN/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

wsf-LabCA.lab.aero.org                                       CT,, 
wsf-LabLDAP.crt                                              u,u,u

/////////
Here is the answer to your question about a CA referenced in my /etc/openldap/ldap.conf; I
executed:
root@wsf-LabLDAP:~> cat /etc/openldap/ldap.conf 
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE	dc=example,dc=com
#URI	ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT	12
#TIMELIMIT	15
#DEREF		never


TLS_CACERTDIR /etc/openldap/cacerts
URI ldaps://wsf-LabLDAP.lab.aero.org/
BASE dc=lab,dc=aero,dc=org

MY QUESTION is why do I need to reference anything with OpenLDAP, if I am using 389-ds, is
it simply a place to put things without creating a separate directory structure?   I do
not know if my CA certificate is in the correct place; perhaps it is not because I knew I
wasn't using OpenLDAP, I am using 389-ds, and I didn't understand the
implementation steps properly and so I 'did it my way.'

I store my certs up under /etc/pki/CA/certs; as shown below:
root@wsf-LabLDAP:/etc/pki/CA/certs> ls
wsf-LabCA.crt  wsf-LabLDAP-AdminServer.crt  wsf-LabLDAP.crt

I am running CentOS-6.6; can I still get support here in this website?

Mr. Brown, I can produce the output of an ldapsearch command and something that I believe
confirms your suspicion; but I don't know what to do to fix the problem (in my VMs or
on my REAL server).  Here is the ldapsearch I executed and the results:
root@wsf-LabLDAP:/> ldapsearch -d 5 -x -L -b 'dc=lab,dc=aero,dc=org'
ldap_create
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP wsf-LabLDAP.lab.aero.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.2.243:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
TLS: certdb config: configDir='/etc/openldap/cacerts'
tokenDescription='ldap(0)' certPrefix='' keyPrefix=''
flags=readOnly
TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11
error.
TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.0 from CA certificate
directory /etc/openldap/cacerts.
TLS: skipping 'authconfig_downloaded.pem' - filename does not have expected format
(certificate hash with numeric suffix)
TLS: certificate
[CN=wsf-LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US] is not
valid - error -8181:Peer's Certificate has expired..
TLS: error: connect - force handshake failure: errno 0 - moznss error -8157
TLS: can't connect: TLS error -8157:Certificate extension not found..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Can you please lead me down the path of solving this?  I noticed you are a Red Hat
Software Engineer; I hope that means you will still be able to support me on CentOS (but I
guess RedHat owns CentOS now).

Thank you,
Warron

[William Brown]

On Wed, 2016-04-06 at 12:03 +0000, warron.french(a)gmail.com wrote:
>  Good morning Mr. Brown,
>  
>  Here is the results of your first query; executing the certutil command as you
>  presented it (with adding my instance):
>  certutil -L -d /etc/dirsrv/slapd-E2WAN/
>  
>  Certificate Nickname                                         Trust Attributes
>                                                               SSL,S/MIME,JAR/XPI
>  
>  wsf-LabCA.lab.aero.org                                       CT,, 
>  wsf-LabLDAP.crt                                              u,u,u
>  
>  /////////
>  Here is the answer to your question about a CA referenced in my
>  /etc/openldap/ldap.conf; I executed:
>  root@wsf-LabLDAP:~> cat /etc/openldap/ldap.conf 
>  #
>  # LDAP Defaults
>  #
>  
>  # See ldap.conf(5) for details
>  # This file should be world readable but not world writable.
>  
>  #BASE	dc=example,dc=com
>  #URI	ldap://ldap.example.com ldap://ldap-master.example.com:666
>  
>  #SIZELIMIT	12
>  #TIMELIMIT	15
>  #DEREF		never
>  
>  
>  TLS_CACERTDIR /etc/openldap/cacerts
>  URI ldaps://wsf-LabLDAP.lab.aero.org/
>  BASE dc=lab,dc=aero,dc=org
>  
>  MY QUESTION is why do I need to reference anything with OpenLDAP, if I am using
>  389-ds, is it simply a place to put things without creating a separate
>  directory structure?   I do not know if my CA certificate is in the correct
>  place; perhaps it is not because I knew I wasn't using OpenLDAP, I am using
>  389-ds, and I didn't understand the implementation steps properly and so I 'did
>  it my way.' 
389-ds is the server component.

However, the ldapsearch utility comes from openldap and has it's OWN ca store.


This is why you need to configure both parts. 


>  
>  I store my certs up under /etc/pki/CA/certs; as shown below:
>  root@wsf-LabLDAP:/etc/pki/CA/certs> ls
>  wsf-LabCA.crt  wsf-LabLDAP-AdminServer.crt  wsf-LabLDAP.crt
>  
>  I am running CentOS-6.6; can I still get support here in this website?
>  
>  Mr. Brown, I can produce the output of an ldapsearch command and something that
>  I believe confirms your suspicion; but I don't know what to do to fix the
>  problem (in my VMs or on my REAL server).  Here is the ldapsearch I executed
>  and the results:
>  root@wsf-LabLDAP:/> ldapsearch -d 5 -x -L -b 'dc=lab,dc=aero,dc=org'
>  ldap_create
>  ldap_sasl_bind
>  ldap_send_initial_request
>  ldap_new_connection 1 1 0
>  ldap_int_open_connection
>  ldap_connect_to_host: TCP wsf-LabLDAP.lab.aero.org:636
>  ldap_new_socket: 3
>  ldap_prepare_socket: 3
>  ldap_connect_to_host: Trying 192.168.2.243:636
>  ldap_pvt_connect: fd: 3 tm: -1 async: 0
>  attempting to connect: 
>  connect success
>  TLS: certdb config: configDir='/etc/openldap/cacerts'
>  tokenDescription='ldap(0)' certPrefix='' keyPrefix=''
> flags=readOnly
>  TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11
>  error.
>  TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.0 from CA
>  certificate directory /etc/openldap/cacerts.
>  TLS: skipping 'authconfig_downloaded.pem' - filename does not have expected
>  format (certificate hash with numeric suffix)
>  TLS: certificate [CN=wsf-
>  LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US] is
>  not valid - error -8181:Peer's Certificate has expired..
>  TLS: error: connect - force handshake failure: errno 0 - moznss error -8157
>  TLS: can't connect: TLS error -8157:Certificate extension not found..
>  ldap_err2string
>  ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>  
>  Can you please lead me down the path of solving this?  I noticed you are a Red
>  Hat Software Engineer; I hope that means you will still be able to support me
>  on CentOS (but I guess RedHat owns CentOS now).
>   
This is a public mailing list, so my corporate affiliation means little in terms
of whether I help you or not! 

For this, it looks like it's not able to find the ca. Look at these lines:

TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11
>  error.> TLS: loaded CA certificate file
> /etc/openldap/cacerts/415ee41f.0 from 
CA
>  certificate directory /etc/openldap/cacerts.> TLS: skipping
'authconfig_downloaded.pem' - filename does not have expected
>  format (certificate hash with numeric suffix)> TLS: certificate
> [CN=wsf-
>  LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US] is
>  not valid - error -8181:Peer's Certificate has expired.. 

So you should take the current CA cert from the slapd instance:

certutil -L -d /etc/dirsrv/slapd-E2WAN/ -n wsf-LabCA.lab.aero.org -a >
/etc/openldap/cacerts/wsf-LabCA.lab.aero.org.pem

Then you can make these valid for openldap to use:

cd /etc/openldap/cacerts
cacertdir_rehash

This will recreate the hash -> cert symlinks.

From there, re-run your ldap search command:

 ldapsearch -d 5 -x -L -b 'dc=lab,dc=aero,dc=org'


If you still fail with: 

not valid - error -8181:Peer's Certificate has expired..> 

You have bigger problems than ldap.

Otherwise, I hope this works for you.



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

[warron.french]

Hello Mr. Brown,
     the problem is still not resolved.

I ran, as you suggested:
root@wsf-LabLDAP:/etc/openldap/cacerts> certutil -L -d /etc/dirsrv/slapd-E2WAN/ -n
wsf-LabCA.lab.aero.org -a > wsf-LabCA.lab.aero.org.pem

Then I ran the cacertdir_hash command (not realizing I needed to provide a directory, I
have never heard of the command), in the following manner:
root@wsf-LabLDAP:/etc/openldap/cacerts> cacertdir_rehash /etc/openldap/cacerts/

I confirmed the link is in place:
root@wsf-LabLDAP:/etc/openldap/cacerts> ls -l
total 8
lrwxrwxrwx. 1 root root   25 Apr  7 07:04 415ee41f.0 -> authconfig_downloaded.pem
lrwxrwxrwx. 1 root root   26 Apr  7 07:04 415ee41f.1 -> wsf-LabCA.lab.aero.org.pem
-rw-r--r--. 1 root root 1501 Apr  5 16:54 authconfig_downloaded.pem
-rw-r--r--. 1 root root 1523 Apr  7 07:03 wsf-LabCA.lab.aero.org.pem



and Re-executed the ldapsearch command from before:
root@wsf-LabLDAP:/etc/openldap/cacerts> ldapsearch -d 5 -x -L -b
'dc=lab,dc=aero,dc=org'
ldap_create
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP wsf-LabLDAP.lab.aero.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.2.243:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
TLS: certdb config: configDir='/etc/openldap/cacerts'
tokenDescription='ldap(0)' certPrefix='' keyPrefix=''
flags=readOnly
TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11
error.
TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.0 from CA certificate
directory /etc/openldap/cacerts.
TLS: skipping 'authconfig_downloaded.pem' - filename does not have expected format
(certificate hash with numeric suffix)
TLS: skipping 'wsf-LabCA.lab.aero.org.pem' - filename does not have expected
format (certificate hash with numeric suffix)
TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.1 from CA certificate
directory /etc/openldap/cacerts.
TLS: certificate
[CN=wsf-LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US] is not
valid - error -8181:Peer's Certificate has expired..
TLS: error: connect - force handshake failure: errno 0 - moznss error -8157
TLS: can't connect: TLS error -8157:Certificate extension not found..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)


My CA cert is not expired, but my wsf-LabLDAP certificate WAS expired.  I renewed the
certificate (using the original CSR for wsf-LabLDAP) and I did copy it over to the
wsf-LabLDAP server into the same place as the original .crt file; which is /etc/pki/CA.
root@wsf-LabLDAP:/etc/pki/CA/certs> ls -l 
total 20
-rw-r--r--. 1 root root 1501 Mar 24  2014 wsf-LabCA.crt
-rw-r--r--. 1 root root 4693 Apr  1 13:40 wsf-LabLDAP-AdminServer.crt
-rw-r--r--. 1 root root 4694 Apr  1 13:40 wsf-LabLDAP.crt

What I don't know how to do is get (is it called the?) certdb file for 389-ds updated
with the new certificates you see listed above.  Considering when I installed them in the
first place I use the 389-console to make those exact updates.

If RedHat/CentOS uses /etc/openldap/cacerts as the location to store the authconfig-gtk
downloaded file from the CA it was pointed at, how does it get it into the appropriate
database? automatically?

[warron.french]

Mr. Brown, you sort of lead me down the path; thank you.

It turns out that I needed to use  the certutil (something I didn't know how to use
properly for this problem to diagnose or FIX the problem with) to remove the OLD
wsf-LabLDAP.crt, Then I needed to add the NEW wsf-LabLDAP.crt (from the file I had placed
on the server in the last week, REMEMBER the other one was over 1 year old).

I did that within the /etc/dirsrv/slapd-E2WAN directory.  I got the ldapsearch -d to come
back with no (I mean, 0) problems.  I feel great again.

I will say that you REALLY helped me to learn instead of solving my problems; thank you
sincerely and very much from 12 timezones behind.


Here were the general steps:
1) Run the certutil and figure out what certs are in the chain for the LDAP certificate
for the LDAP server itself, not the LDAP-AdminServer:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -L -d /etc/dirsrv/slapd-E2WAN/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
wsf-LabLDAP.crt                                              u,u,u
wsf-LabCA.crt                                                ,,   

2) Remove both of the certificates, if you have the CRT (.crt) files for both:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -D -d /etc/dirsrv/slapd-E2WAN/ -n
"wsf-LabCA.crt"
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -D -d /etc/dirsrv/slapd-E2WAN/ -n
"wsf-LabLDAP.crt"

3) Confirm they are gone from the database:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -L -d /etc/dirsrv/slapd-E2WAN/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

4) Add back both certificates; you should have recreated both CRT files or at least have a
copy of them on the server:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -A -n "wsf-LabCA.crt" -t
"CT,," -d /etc/dirsrv/slapd-E2WAN/ -i /etc/pki/CA/certs/wsf-LabCA.crt 
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -A -n "wsf-LabLDAP.crt" -t
"u,u,u" -d /etc/dirsrv/slapd-E2WAN/ -i /etc/pki/CA/certs/wsf-LabLDAP.crt 
Notice: Trust flag u is set automatically if the private key is present.

5) Confirm both certificates are 'loaded' into the cert8.db (database):
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -L -d /etc/dirsrv/slapd-E2WAN/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
wsf-LabCA.crt                                                CT,, 
wsf-LabLDAP.crt                                              u,u,u

**Pay attention to the "CT,," Trust Attributes for wsf-LabCA.crt; and attention
to the "u,u,u" Trust Attributes for the wsf-LabLDAP.crt certificate.

6) Confirm the chain relationship (noting that wsf-LabLDAP.crt should be lower and
indented in comparison to the wsf-LabCA.crt certificate:
root@wsf-LabLDAP:/etc/dirsrv/slapd-E2WAN> certutil -O -d /etc/dirsrv/slapd-E2WAN/ -n
"wsf-LabLDAP.crt"
"wsf-LabCA.crt"
[E=root(a)wsf-LabCA.lab.aero.org,CN=wsf-LabCA.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US]

    "wsf-LabLDAP.crt"
[CN=wsf-LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US]


7) Restart the dirsrsv service on your machine:
oot@wsf-LabLDAP:/etc/openldap/cacerts> service dirsrv restart
Shutting down dirsrv: 
    E2WAN...                                               [  OK  ]
Starting dirsrv: 
    E2WAN...[07/Apr/2016:08:25:49 -0400] - Information: Non-Secure Port Disabled
                                                           [  OK  ]

8) Ensure the ldapsearch works (using debug might be helpful, in the case things are
different on your end):
root@wsf-LabLDAP:/etc/openldap/cacerts> ldapsearch -d 5 -x -L -b
'dc=lab,dc=aero,dc=org'
ldap_create
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP wsf-LabLDAP.lab.aero.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.2.243:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
TLS: certdb config: configDir='/etc/openldap/cacerts'
tokenDescription='ldap(0)' certPrefix='' keyPrefix=''
flags=readOnly
TLS: cannot open certdb '/etc/openldap/cacerts', error -8018:Unknown PKCS #11
error.
TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.0 from CA certificate
directory /etc/openldap/cacerts.
TLS: skipping 'authconfig_downloaded.pem' - filename does not have expected format
(certificate hash with numeric suffix)
TLS: skipping 'wsf-LabCA.lab.aero.org.pem' - filename does not have expected
format (certificate hash with numeric suffix)
TLS: loaded CA certificate file /etc/openldap/cacerts/415ee41f.1 from CA certificate
directory /etc/openldap/cacerts.
TLS: certificate
[CN=wsf-LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US] is
valid
TLS certificate verification: subject:
CN=wsf-LabLDAP.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US, issuer:
E=root(a)wsf-LabCA.lab.aero.org,CN=wsf-LabCA.lab.aero.org,OU=Aerospace,O=Aerospace,L=Chantilly,ST=Virginia,C=US,
cipher: AES-256, security level: high, secret key bits: 256, total key bits: 256, cache
hits: 0, cache misses: 0, cache not reusable: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 14 bytes to sd 3
ldap_result ld 0xb0a300 msgid 1
<...snip...>
# search result
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree

# numResponses: 22
# numEntries: 21
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed

It WORKS!  Yes!  This is such a load off of my chest.

Thanks for helping me,
Warron

[warron.french]

Mr. Brown,
  As much as I can now log into 389-console to access the Directory Server and the Admin
Server entities through the GUI console, and I can also perform ldapsearch successfully, I
am still having one irksome problem.

I still cannot log into the 389-console with the account cn=Directory Manager; which is
strange to me, because ldapsearch uses the cn=Directory Manager account to authenticate -
and it does it successfully.

Can you advise please, on how to fix this problem?
Or am I trying to do something that isn't permitted, should I not be allowed to
authenticate "cn=Directory Manager" into 389-console at all?  Maybe I made that
up (I misinformed myself somehow)?

[Mark Reynolds]

On 04/07/2016 09:50 AM, Warron French wrote:
>  Mr. Brown,
>     As much as I can now log into 389-console to access the Directory Server and the Admin
> Server entities through the GUI console, and I can also perform ldapsearch successfully, I
> am still having one irksome problem.
>
>  I still cannot log into the 389-console with the account cn=Directory Manager; which is
> strange to me, because ldapsearch uses the cn=Directory Manager account to authenticate -
> and it does it successfully.
>
>  Can you advise please, on how to fix this problem?
>  Or am I trying to do something that isn't permitted, should I not be allowed to
> authenticate "cn=Directory Manager" into 389-console at all?  Maybe I made that
> up (I misinformed myself somehow)? 
You need to recheck the DS access/errors logs to
see if its the same 
problem or a new one.

Also run the console is debug mode - it might provide more info:

./389-consle -D 9

Regards,
Mark
>  --
>  389 users mailing list
>  389-users@%(host_name)s
>  http://lists.fedoraproject.org/admin/lists/[e-mail]

[Mark Reynolds]

On 04/07/2016 10:34 AM, Mark Reynolds wrote:
>  On 04/07/2016 09:50 AM, Warron French wrote:
> > Mr. Brown,
> >    As much as I can now log into 389-console to access the Directory 
> > Server and the Admin Server entities through the GUI console, and I 
> > can also perform ldapsearch successfully, I am still having one 
> > irksome problem.
> >
> > I still cannot log into the 389-console with the account cn=Directory 
> > Manager; which is strange to me, because ldapsearch uses the 
> > cn=Directory Manager account to authenticate - and it does it 
> > successfully.
> >
> > Can you advise please, on how to fix this problem?
> > Or am I trying to do something that isn't permitted, should I not be 
> > allowed to authenticate "cn=Directory Manager" into 389-console at 
> > all?  Maybe I made that up (I misinformed myself somehow)?
>  You need to recheck the DS access/errors logs to see if its the same 
>  problem or a new one.
>
>  Also run the console is debug mode - it might provide more info:
>
>  ./389-consle -D 9 
Also, you should remove the old console cert db and try logging
in 
again.  The console caches certificates, so it might still have your old 
ones, and it just keeps reusing them.

rm ~./389-console/*.db

You aren't running the console from a Windows machine are you?

Mark
>  Regards,
>  Mark
> > -- 
> > 389 users mailing list
> > 389-users@%(host_name)s
> > http://lists.fedoraproject.org/admin/lists/[e-mail] 
> >
>  -- 
>  389 users mailing list
>  389-users@%(host_name)s
>  http://lists.fedoraproject.org/admin/lists/[e-mail]

[Mark Reynolds]

On 04/07/2016 10:45 AM, Mark Reynolds wrote:
>  On 04/07/2016 10:34 AM, Mark Reynolds wrote:
> >
> >
> > On 04/07/2016 09:50 AM, Warron French wrote:
> >> Mr. Brown,
> >>    As much as I can now log into 389-console to access the Directory 
> >> Server and the Admin Server entities through the GUI console, and I 
> >> can also perform ldapsearch successfully, I am still having one 
> >> irksome problem.
> >>
> >> I still cannot log into the 389-console with the account 
> >> cn=Directory Manager; which is strange to me, because ldapsearch 
> >> uses the cn=Directory Manager account to authenticate - and it does 
> >> it successfully.
> >>
> >> Can you advise please, on how to fix this problem?
> >> Or am I trying to do something that isn't permitted, should I not be 
> >> allowed to authenticate "cn=Directory Manager" into 389-console at 
> >> all?  Maybe I made that up (I misinformed myself somehow)?
> > You need to recheck the DS access/errors logs to see if its the same 
> > problem or a new one.
> >
> > Also run the console is debug mode - it might provide more info:
> >
> > ./389-consle -D 9
>  Also, you should remove the old console cert db and try logging in 
>  again.  The console caches certificates, so it might still have your 
>  old ones, and it just keeps reusing them.
>
>  rm ~./389-console/*.db 
Typo, I mean:

rm ~/.389-console/*.db
>  You aren't running the console from a Windows machine are you?
>
>  Mark
> >
> > Regards,
> > Mark
> >> -- 
> >> 389 users mailing list
> >> 389-users@%(host_name)s
> >> http://lists.fedoraproject.org/admin/lists/[e-mail] 
> >>
> > -- 
> > 389 users mailing list
> > 389-users@%(host_name)s
> > http://lists.fedoraproject.org/admin/lists/[e-mail] 
> >
>  -- 
>  389 users mailing list
>  389-users@%(host_name)s
>  http://lists.fedoraproject.org/admin/lists/[e-mail]