Hi all,
Is there a way to either permanently disable attribute encryption, or to have
the symmetric keys generated from an alternate RSA private key to that used for
TLS (given by cn=RSA,cn=encryption,cn=config)? I may be missing something, but
this seems to be completely tied to TLS.
We
at 15:45, Grant Byers wrote:
>
> FWIW, Red Hat don't want a bar of it given we're not running their IPA or
> RHDS products. We've enabled anonymous binds on our production masters to
> work around this issue, but as far as I'm concerned, the bug can languish.
That doesn't seem right .
eck. I'd
prefer the toggle just to help limit what we need to test though, and it makes
configuration and admin a bit easier.
>
> Regards
>Pierre
>
> On Mon, Mar 8, 2021 at 5:56 AM Grant Byers wrote:
> Confirmed. I made the following simple change and it allows cb_ping_farm to
s will break any functionality, but since we're running
RHEL7, i'll raise this with Red Hat directly and they can review and/or push
upstream.
Regards,
Grant
____
From: Grant Byers
Sent: Monday, March 8, 2021 12:27 PM
To: 389-users@lists.fedoraproject.org <
[External Mail]
> On 5 Mar 2021, at 12:03, Grant Byers wrote:
>
> Hi All,
>
> Version: 1.3.10
>
> In our environment, we'd like to use a chaining backend to push BIND
> operations up to masters by way of the consumer (rather than client
> referral). We'd like to do
Hi All,
Version: 1.3.10
In our environment, we'd like to use a chaining backend to push BIND operations
up to masters by way of the consumer (rather than client referral). We'd like
to do this to ensure password lockout attributes are propagated to all
consumers equally via our standard
Hi,
I'm looking at applying local password policy to our existing users.
Reading the Red Hat Directory Server Deployment Guide, I see the
paragraphs below[1].
If I'm reading this correctly, it would appear that users will no
longer be able to bind to the directory server after application of the
On 18/2/20 7:56 am, William Brown wrote:
>
>> On 17 Feb 2020, at 19:25, thierry bordaz wrote:
>>
>>
>>
>> On 2/17/20 5:26 AM, Grant Byers wrote:
>>> Got it..
>>>
>>>
>>> (userattr = "uniqueMember#USERDN")
>> It a
Got it..
(userattr = "uniqueMember#USERDN")
Thanks!
On 17/2/20 2:02 pm, Grant Byers wrote:
> On 17/2/20 1:24 pm, William Brown wrote:
>>> On 17 Feb 2020, at 12:19, Grant Byers wrote:
>>>
>>> Hi,
>>>
>>> In an effort to tighten search
On 17/2/20 1:24 pm, William Brown wrote:
>
>> On 17 Feb 2020, at 12:19, Grant Byers wrote:
>>
>> Hi,
>>
>> In an effort to tighten search and read permissions on our internal
>> directory server, we've limited accounts to read certain attributes of
>>
ay, 8 November 2019 12:18 AM
To: General discussion list for the 389 Directory server project.
<389-users@lists.fedoraproject.org>
Subject: [389-users] Re: Using sec-activate to enable SSL for admin server
Hi Grant,
On Thu, Nov 7, 2019 at 2:16 AM Grant Byers
mailto:grant.by...@aarnet.edu.a
:24 AM
To: General discussion list for the 389 Directory server project.
<389-users@lists.fedoraproject.org>; Grant Byers
Subject: Re: [389-users] Using sec-activate to enable SSL for admin server
On 11/6/19 12:42 AM, Grant Byers wrote:
Hi,
I've mostly completed automated deployment of a
Hi,
I've mostly completed automated deployment of a 389ds cluster via Ansible. The
final piece of the puzzle is the enablement of SSL/TLS for the Admin server.
From what I understand, I should be able to use the sec-activate tool to do
this;
/usr/lib64/dirsrv/cgi-bin/sec-activate
13 matches
Mail list logo
