3:43 p.m.
Hi I’m in the process of migrating from 389-Directory/1.2.11.15 ->
389-Directory/1.3.7.5. I’m trying to automate the setup. I’m finding that I can no longer
enable SSL via the command line using ldapmodify. For V1.3.7.5 setup I followed
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10....
After restarting the service, SSL is not enabled. I am able to use the Admin Console to
enable SSL. I found that the following is missing from when I setup via ldapmodify vs
Admin Console.
Following is missing even after following the RedHat documentation.
nsSSL3: on
nsSSL3Ciphers: -rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+
sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+
,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_exp
56_sha,+tls_rsa_export1024_with_des_cbc_sha,+tls_rsa_aes_128
_256_sha
nsKeyfile: alias/slapd-XXXXX-key3.db
nsCertfile: alias/slapd-XXXXX-cert8.db
# RSA, encryption, config
dn: cn=RSA,cn=encryption,cn=config
nsSSLToken: internal (software)
nsSSLPersonalitySSL: server-cert
nsSSLActivation: on
objectClass: top
objectClass: nsEncryptionModule
cn: RSA
I do notice that when I make the changes via ldapmodify it says that the changes have been
successfully made, but they don’t show up in a search before and after a service restart.
Also “nsslapd-security” never changes from off to on via command line edit. Here is some
info about my system.
OS: CentOS Linux release 7.5.1804 (Core)
389 packages installed:
389-adminutil-1.1.21-2.el7.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-admin-console-1.1.12-1.el7.noarch
389-ds-base-libs-1.3.7.5-28.el7_5.x86_64
389-ds-console-1.2.16-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-ds-base-1.3.7.5-28.el7_5.x86_64
389-ds-console-doc-1.2.16-1.el7.noarch
389-admin-1.1.46-1.el7.x86_64
389-console-1.1.18-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
Version of Directory Server: 389-Directory/1.3.7.5 B2018.269.1826
Commands executing:
ldapmodify -x -D "cn=Directory Manager" -w XXXX << EOF
dn: cn=config
changetype: modify
replace: nsslapd-securePort
nsslapd-securePort: 636
-
replace: nsslapd-security
nsslapd-security: on
dn: cn=RSA,cn=encryption,cn=config
changetype: modify
replace: nsSSLToken
nsSSLToken: internal (software)
-
replace: nsSSLPersonalitySSL
nsSSLPersonalitySSL: server-cert
-
replace: nsSSLActivation
nsSSLActivation: on
EOF
systemctl restart dirsrv(a)XXXXX.service
3:58 p.m.
New subject: Unable to enable SSL using ldapmodify on 389-Directory/1.3.7.5
On 11/6/18 4:43 PM, Jason Jenkins wrote:
Hi I’m in the process of migrating from 389-Directory/1.2.11.15 ->
389-Directory/1.3.7.5. I’m trying to automate the setup. I’m finding
that I can no longer enable SSL via the command line using ldapmodify.
For V1.3.7.5 setup I followed
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10....
After restarting the service, SSL is not enabled. I am able to use the
Admin Console to enable SSL. I found that the following is missing
from when I setup via ldapmodify vs Admin Console.
Following is missing even after following the RedHat documentation.
nsSSL3: on
nsSSL3Ciphers: -rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+
sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+
,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_exp
56_sha,+tls_rsa_export1024_with_des_cbc_sha,+tls_rsa_aes_128
_256_sha
^^^ This is not required, and in fact most of the ciphers seem outdated,
but that should not be contributing to the problem.
nsKeyfile: alias/slapd-XXXXX-key3.db
nsCertfile: alias/slapd-XXXXX-cert8.db
# RSA, encryption, config
dn: cn=RSA,cn=encryption,cn=config
nsSSLToken: internal (software)
nsSSLPersonalitySSL: server-cert
nsSSLActivation: on
objectClass: top
objectClass: nsEncryptionModule
cn: RSA
This is mentioned in the admin guide link you provided
I do notice that when I make the changes via ldapmodify it says that
the changes have been successfully made, but they don’t show up in a
search before and after a service restart. Also “nsslapd-security”
never changes from off to on via command line edit. Here is some info
about my system.
Is there anything in the errors log after the restart? FYI, I've never
heard of config settings that get reverted after a restart.
One thing to try for debugging purposes is to enable the audit log to
verify the server accepted the changes in the first place.
So I would start over again using ldapmodify (with the audit log
enabled.) When things get messed up after the restart please provide us
the audit and errors log.
Thanks,
Mark
*OS*: CentOS Linux release 7.5.1804 (Core)
*389 packages installed*:
389-adminutil-1.1.21-2.el7.x86_64
389-admin-console-doc-1.1.12-1.el7.noarch
389-admin-console-1.1.12-1.el7.noarch
389-ds-base-libs-1.3.7.5-28.el7_5.x86_64
389-ds-console-1.2.16-1.el7.noarch
389-ds-1.2.2-6.el7.noarch
389-ds-base-1.3.7.5-28.el7_5.x86_64
389-ds-console-doc-1.2.16-1.el7.noarch
389-admin-1.1.46-1.el7.x86_64
389-console-1.1.18-1.el7.noarch
389-dsgw-1.1.11-5.el7.x86_64
*Version of Directory Server*: 389-Directory/1.3.7.5 B2018.269.1826
*Commands executing*:
ldapmodify -x -D "cn=Directory Manager" -w XXXX << EOF
dn: cn=config
changetype: modify
replace: nsslapd-securePort
nsslapd-securePort: 636
-
replace: nsslapd-security
nsslapd-security: on
dn: cn=RSA,cn=encryption,cn=config
changetype: modify
replace: nsSSLToken
nsSSLToken: internal (software)
-
replace: nsSSLPersonalitySSL
nsSSLPersonalitySSL: server-cert
-
replace: nsSSLActivation
nsSSLActivation: on
EOF
systemctl restart dirsrv(a)XXXXX.service
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
4:26 p.m.
New subject: Unable to enable SSL using ldapmodify on 389-Directory/1.3.7.5
On Tue, 2018-11-06 at 16:58 -0500, Mark Reynolds wrote:
On 11/6/18 4:43 PM, Jason Jenkins wrote:
> Hi I’m in the process of migrating from 389-Directory/1.2.11.15 ->
> 389-Directory/1.3.7.5. I’m trying to automate the setup. I’m
> finding that I can no longer enable SSL via the command line using
> ldapmodify. For V1.3.7.5 setup I followed https://access.redhat.com
> /documentation/en-
> us/red_hat_directory_server/10/html/administration_guide/enabling_t
> ls. After restarting the service, SSL is not enabled. I am able to
> use the Admin Console to enable SSL. I found that the following is
> missing from when I setup via ldapmodify vs Admin Console.
>
>
> Following is missing even after following the RedHat documentation.
>
> nsSSL3: on
> nsSSL3Ciphers: -rsa_null_md5,-rsa_null_sha,+rsa_rc4_128_md5,+
> sa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+
> ,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_exp
> 56_sha,+tls_rsa_export1024_with_des_cbc_sha,+tls_rsa_aes_128
> _256_sha
^^^ This is not required, and in fact most of the ciphers seem
outdated, but that should not be contributing to the problem.
If I were you, I'd just remove this line because we ship ciphers that
are "good by default". The best TLS setup guide is here:
http://www.port389.org/docs/389ds/howto/howto-ssl.html
> nsKeyfile: alias/slapd-XXXXX-key3.db
> nsCertfile: alias/slapd-XXXXX-cert8.db
>
> # RSA, encryption, config
> dn: cn=RSA,cn=encryption,cn=config
> nsSSLToken: internal (software)
> nsSSLPersonalitySSL: server-cert
> nsSSLActivation: on
> objectClass: top
> objectClass: nsEncryptionModule
> cn: RSA
This is mentioned in the admin guide link you provided
>
>
>
>
> I do notice that when I make the changes via ldapmodify it says
> that the changes have been successfully made, but they don’t show
> up in a search before and after a service restart.
This could also be access controls, but it's hard to know. I'd like it
if you could show me the commands you are using to do the modify and
the search (with bind username included, obviously we do not need the
password).
> Also “nsslapd-security” never changes from off to on via
command
> line edit. Here is some info about my system.
Is there anything in the errors log after the restart? FYI, I've
never heard of config settings that get reverted after a restart.
You need to stop the ds service *before* you make the change. We write
dse.ldif during the operation of the server and at shutdown, so if you
have:
ns-slapd is running
edit dse.ldif
ns-slapd is stopped (dse.ldif is overwritten here!)
view dse.ldif - your changes are missing!
That could certainly be the issue you are encountering.
> One thing to try for debugging purposes is to enable the audit log to
> verify the server accepted the changes in the first place.
> So I would start over again using ldapmodify (with the audit log
> enabled.) When things get messed up after the restart please provide
> us the audit and errors log.
> Thanks,
> Mark
> >
> >
> > OS: CentOS Linux release 7.5.1804 (Core)
> > 389 packages installed:
> > 389-adminutil-1.1.21-2.el7.x86_64
> > 389-admin-console-doc-1.1.12-1.el7.noarch
> > 389-admin-console-1.1.12-1.el7.noarch
> > 389-ds-base-libs-1.3.7.5-28.el7_5.x86_64
> > 389-ds-console-1.2.16-1.el7.noarch
> > 389-ds-1.2.2-6.el7.noarch
> > 389-ds-base-1.3.7.5-28.el7_5.x86_64
> > 389-ds-console-doc-1.2.16-1.el7.noarch
> > 389-admin-1.1.46-1.el7.x86_64
> > 389-console-1.1.18-1.el7.noarch
> > 389-dsgw-1.1.11-5.el7.x86_64
> >
> > Version of Directory Server: 389-Directory/1.3.7.5 B2018.269.1826
> >
> > Commands executing:
> >
> > ldapmodify -x -D "cn=Directory Manager" -w XXXX << EOF
> > dn: cn=config
> > changetype: modify
> > replace: nsslapd-securePort
> > nsslapd-securePort: 636
> > -
> > replace: nsslapd-security
> > nsslapd-security: on
> >
> > dn: cn=RSA,cn=encryption,cn=config
> > changetype: modify
> > replace: nsSSLToken
> > nsSSLToken: internal (software)
> > -
> > replace: nsSSLPersonalitySSL
> > nsSSLPersonalitySSL: server-cert
> > -
> > replace: nsSSLActivation
> > nsSSLActivation: on
> > EOF
> >
> >
> > systemctl restart dirsrv(a)XXXXX.service
> >
> >
> > _______________________________________________
> > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject
> > .org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidel
> > ines
> > List Archives: https://lists.fedoraproject.org/archives/list/389-us
> > ers(a)lists.fedoraproject.org
>
> _______________________________________________
> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
> rg
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/389-user
> s(a)lists.fedoraproject.org
2002
days inactive
2003
days old
389-users@lists.fedoraproject.org
2 comments
3 participants
participants (3)
-
Jason Jenkins -
Mark Reynolds -
William Brown