Any benefit to extracting the PEM files?
by Trevor Vaughan
I noticed that the server was extracting the PEM files from the keystore by
default and was wondering if there was really any use for this being on by
default.
The relevant setting is nsslapd-extract-pemfiles.
Thanks,
Trevor
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
3 years, 2 months
Disable LDAPv2
by Sahin, Erhan
Hello everyone,
is it possible to deactivate LDAPv2 completely on server side and only allow LDAPv3?
Stay safe!
Best regards
3 years, 2 months
ACI with groupdn to target multiple groups
by N R
Hi everyone,
I'm not an English native speaker, so please forgive me if there's
mistakes in this e-mail.
OS : Fedora 30
389ds version / build number : 1.4.1.14 / 2020.023.2226
I'm struggling with ACI and despite hours of documentation reading, I
don't understand how to make it work as I want.
Basic directory structure
==================
dc=domain,dc=tld
|
+---ou=Servers
|
+---cn=proxy <---- here is where I add the ACI
|
+---cn=group1
|
+---cn=group2
===================
Container "proxy" is a "iphost" object.
I'm trying to allow only members of any group inside "cn=proxy" to
access attributes of "cn=proxy".
Relying on redhat directory server documentation, I've tried the
following ACI which didn't worked the way I wanted:
(targetattr = "*") (target =
"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld") (version 3.0;acl
"Allow only groups members to query this object";allow (all)(groupdn =
"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld??sub");)
(targetattr = "*") (target =
"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld") (version 3.0;acl
"Allow only groups members to query this object";allow (all)(groupdn =
"ldap:///cn=*,cn=proxy,ou=Servers,dc=domain,dc=tld");)
I used informations provided on
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
but I don't understand how to adapt them to my use-case.
The ugly and suboptimal way of solving it would be to list every group
within "cn=proxy" in the ACI, but I'm almost sure there's a better way
to do it.
Thanks in advance for your replies and any possible help.
Cheers,
--
Nicolas Randrianarisoa
3 years, 2 months
ZSTD for Flatpak's dir?
by jiiren89＠protonmail.com
hello, I would like to know if there is a possibility to just activate ZSTD (on F34/BTRFS) compression for directory / var / lib / flatpak? and how to do?
hoping it will affect the app's performance ..
3 years, 2 months
Cockpit not creating new attributes
by Nelson Bartley
Good day,
Fedora 33
389-d 1.4.4.11-1.fc33
cockpit 236-1
on AWS T3.medium
Attempting to add new attributes to LDAP instance created through
cockpit interface. Getting an error each time. I've tried minimal
selecting and selecting all drop downs, same result.
Other types of save/view actions appear fine. I have been able to
adjust other settings like plugins and paging limits. Login and
Directory Manager account working correctly via Apache Directory
Studio.
Console tells me the following:
(My operation to the server)
CMD: cmdOperationAttribute: Do the add operation on Attribute ==>
dsconf -j ldapi://%2fvar%2frun%2fslapd-JPREP.socket schema
attributetypes add manageruid --syntax 1.3.6.1.4.1.1466.115.121.1.15
--multi-value --user-mod --oid manageruid --usage userApplications
--desc manageruid --sup --equality --substr --ordering
(Server Response)
cockpit.js:1
{
"desc": "values has to be a tuple, was None"
}
p @ cockpit.js:1
v @ cockpit.js:1
(anonymous) @ cockpit.js:1
C.n.onmessage.e.dispatch_data @ cockpit.js:1
(anonymous) @ cockpit.js:1
postMessage (async)
(anonymous) @ index.js:69
C.n.onmessage.e.dispatch_data @ cockpit.js:1
(Refreshing the display list)
tools.jsx:58
CMD: loadSchemaData: Get schema objects in one batch ==> dsconf -j
ldapi://%2fvar%2frun%2fslapd-JPREP.socket schema list
389-ds access logs tell me it refreshed, but didn't try to submit
anything. (following log is from clicking add in the web interface.)
[08/Feb/2021:18:22:18.556793436 +0900] conn=62 fd=64 slot=64
connection from local to /var/run/slapd-JPREP.socket
[08/Feb/2021:18:22:18.556989064 +0900] conn=62 AUTOBIND
dn="cn=Directory Manager"
[08/Feb/2021:18:22:18.556994258 +0900] conn=62 op=0 BIND
dn="cn=Directory Manager" method=sasl version=3 mech=EXTERNAL
[08/Feb/2021:18:22:18.557008502 +0900] conn=62 op=0 RESULT err=0
tag=97 nentries=0 wtime=0.000032658 optime=0.000084615
etime=0.000116527 dn="cn=Directory Manager"
[08/Feb/2021:18:22:18.566523301 +0900] conn=62 op=1 SRCH base=""
scope=0 filter="(objectClass=*)" attrs="vendorVersion"
[08/Feb/2021:18:22:18.567024996 +0900] conn=62 op=1 RESULT err=0
tag=101 nentries=1 wtime=0.000377704 optime=0.000507869
etime=0.000884496
[08/Feb/2021:18:22:18.570011283 +0900] conn=62 op=2 SRCH
base="cn=schema" scope=0 filter="(objectClass=*)"
attrs="attributeTypes"
[08/Feb/2021:18:22:18.658651228 +0900] conn=62 op=2 RESULT err=0
tag=101 nentries=1 wtime=0.000074365 optime=0.088643844
etime=0.088713528
[08/Feb/2021:18:22:18.700696946 +0900] conn=62 op=3 UNBIND
[08/Feb/2021:18:22:18.700724509 +0900] conn=62 op=3 fd=64 closed error - U1
[08/Feb/2021:18:22:19.170926376 +0900] conn=63 fd=64 slot=64
connection from local to /var/run/slapd-JPREP.socket
[08/Feb/2021:18:22:19.171135124 +0900] conn=63 AUTOBIND
dn="cn=Directory Manager"
[08/Feb/2021:18:22:19.171141657 +0900] conn=63 op=0 BIND
dn="cn=Directory Manager" method=sasl version=3 mech=EXTERNAL
[08/Feb/2021:18:22:19.171164005 +0900] conn=63 op=0 RESULT err=0
tag=97 nentries=0 wtime=0.000062135 optime=0.000086143
etime=0.000147130 dn="cn=Directory Manager"
[08/Feb/2021:18:22:19.178546405 +0900] conn=63 op=1 SRCH base=""
scope=0 filter="(objectClass=*)" attrs="vendorVersion"
[08/Feb/2021:18:22:19.179031874 +0900] conn=63 op=1 RESULT err=0
tag=101 nentries=1 wtime=0.000090083 optime=0.000490590
etime=0.000579185
[08/Feb/2021:18:22:19.181349759 +0900] conn=63 op=2 SRCH
base="cn=schema" scope=0 filter="(objectClass=*)"
attrs="objectClasses"
[08/Feb/2021:18:22:19.241626328 +0900] conn=63 op=2 RESULT err=0
tag=101 nentries=1 wtime=0.000046914 optime=0.060277774
etime=0.060320011
[08/Feb/2021:18:22:19.253746627 +0900] conn=63 op=3 SRCH
base="cn=schema" scope=0 filter="(objectClass=*)"
attrs="attributeTypes"
[08/Feb/2021:18:22:19.313622859 +0900] conn=63 op=3 RESULT err=0
tag=101 nentries=1 wtime=0.000085110 optime=0.059880913
etime=0.059961435
[08/Feb/2021:18:22:19.369497524 +0900] conn=63 op=4 SRCH
base="cn=schema" scope=0 filter="(objectClass=*)"
attrs="matchingRules"
[08/Feb/2021:18:22:19.429621377 +0900] conn=63 op=4 RESULT err=0
tag=101 nentries=1 wtime=0.000085058 optime=0.060128129
etime=0.060208306
[08/Feb/2021:18:22:19.499857862 +0900] conn=63 op=5 UNBIND
[08/Feb/2021:18:22:19.499878548 +0900] conn=63 op=5 fd=64 closed error - U1
Any help would be appreciated. I'd rather not go to LDIF to add all
these scheme modifications I need to do. Last time I did this I did it
via the old Java Console.
Cheers,
Nelson
3 years, 2 months
Configure CRL check with TLS authentication
by ADELIN Arnaud
Hello,
Could you help me understanding how to configure 389-ds to enable CRL checking at TLS authentication ?
I am working on the master/master replication between two instances.
The TLS communication thanks to certificate works without problem but the CRL url is ignored.
By checking the source code of 389-ds-base, I found the configuration item "nsslapd-tls-check-crl".
I set this item to "peer" mode in order to check the CRL referenced in the received certificate.
Note: This option is not described in the "Configuration, Command, and File Reference" documentation.
After this configuration, each time a TLS communication is initiated, this communication fails with the following error :
ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement-ldap1-to-ldap2" (ldap2-server:389) - Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (unable to get certificate CRL))
I try to initiate the TLS communication with certificates that do not containt the CRL url. The communication fails.
I check that the CRL is available thanks to a wget command.
I found a ticket https://bugzilla.redhat.com/show_bug.cgi?id=1541108 indicating a bug on the CRL management. The reported bug is the same error that I have encountered.
However, this bug is reported as fixed in the 1.3.7.5 version of 389-ds-base and I am working with the 2.0.1 version of 389-ds (operating system : Opensuse 15.2)
I suppose that more configuration should be performed in my setup.
Thanks.
3 years, 2 months
Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers
I'm trying to setup a replication with a certificate based authentication between supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server certificates in the certdbs have been signed. The certificates all have the 'u' flag, and the CA has the C and T flag.
The replication (on the supplier) has been setup such that TLS and certificate based authentication is used, see extract from the replication agreement object:
objectclass: nsds5ReplicationAgreement
nsds5replicahost: <consumer-hostname>
nsds5replicaport: 389
nsds5replicatransportinfo: TLS
nsds5replicabindmethod: SSLCLIENTAUTH
Trying to initialize the consumer raises this error in the error-log of the supplier (the host sending the starttls connection request):
Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication) (missing client certificate)
The certificate that the server should have sent can, however, be used with the ldap commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the client sends the certificate during the TLS handshake, while in the above case it doesn't.
The TLS handshake defines that the client has to send an "empty certificate" if it does not have a certificate that has been issued by a CA offered by the server during the handshake. I can't see a reason for the client to think the condition isn't met. The certificate with which the server (supplier) is setup is the only one available.
Is it possible that the server does not know which certificate it has to use for authentication with the consumer server? And if so, how do I make the server know?
The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with 1.4.0.3.
Thanks,
Eugen
3 years, 2 months
lib389 question
by Marco Favero
Hello,
I'm new in this list, thank you for developing 389ds!
I would like some hints about lib389.
dscreate allows to set some parameters only when you create an instance.
So it' very difficult to maintain all configuration parameters among db and instances and replicated instances.
I'm writing my tool to manage all configuration parameters in one place (a yaml file). Just a wrapper for dsconf. See at
https://github.com/falon/ds-easyconf
I would like to call dsconf from an external host only, different from hosts where the 389ds run. So I have installed the python3-lib389 rpm in that different host.
Let suppose I have
tst1.example.com
tst2.example.com
tst3.example.com
where 389ds Directory Server run after dscreate process.
I have another host:
manage.example.com
where I have installed lib389 rpm only, and from that remote host I configure the tst*.example.com servers through dsconf.
The problem is that dsconf exit with the error "defaults.inf not found in any well known location!".
So I have taken the defaults.inf from a 389ds host (one of tst*.example.com) and I have placed it in the new path /usr/share/dirsrv/inf of manage.example.com.
Now dsconf works fine.
I would like to know if there are some reason to avoid to do that. Or, if simply the python3-lib389 forgot to install the defaults.inf in the proper path.
Thank you very much
Warm Regards
Marco
3 years, 2 months
