Wednesday, April 28, 2021

[389-users] Re: minssf and TLS cipher ordering

Trevor Vaughan wrote:
> Interestingly, if I remove the cipher specification, I get the result of
> ECDHE-RSA-AES128-GCM-SHA256.
>
> Can you see if this also happens with your version of nss?

Same as you're seeing, ECDHE-RSA-AES128-GCM-SHA256 is picked.

rob

>
> Thanks,
>
> Trevor
>
> On Wed, Apr 28, 2021 at 8:27 AM Trevor Vaughan <tvaughan@onyxpoint.com
> <mailto:tvaughan@onyxpoint.com>> wrote:
>
> So, I just ran this test with selfserv as you have above and
> everything worked as expected with s_client.
>
> It seems to be something in 389 itself.
>
> On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden <rcritten@redhat.com
> <mailto:rcritten@redhat.com>> wrote:
>
> Trevor Vaughan wrote:
> > Going full circle on this, I confirmed using s_client that
> what I was
> > seeing was indeed happening but not for the reason that I
> thought it was.
> >
> > Given that the min_ssf is 256, the connection requires a
> 256-bit cipher
> > and hash to communicate with the server.
> >
> > Strangely, the internal strength logic on the 389-DS side
> appears to
> > pick ECDHE-RSA-AES128-GCM-SHA256 *before*
> ECDHE-RSA-AES256-GCM-SHA384.
> > Likewise, if I add any of the AES128 ciphers to the list after the
> > AES256 ciphers, one of the 128-bit ciphers will be chosen
> first. This
> > seems incorrect given that the server should be using the
> strongest
> > cipher suite available if possible.
> >
> > The client cipher order preference is completely ignored
> (which is fine).
> >
> > As pointed out in the last response, I did indeed need to
> explicitly
> > enable only the 256-bit+ hash/cipher combinations in the
> > confusingly-named nsSSL3Ciphers attribute.
> >
> > After figuring this out and dumping the internal supported
> cipher list,
> > I can confirm that the ciphers in the nsSSL3Ciphers list are
> the only
> > ones that are presented to the client.
> >
> > While not ideal, this does provide a solution to the issue
> where I don't
> > have to tell all system users that they need to nail up the
> cipher lists
> > on the client side in order for things to function properly.
> >
> > But that leaves me with two questions:
> >
> > 1) Why, when the nsslapd-minssf option is set in the global
> > configuration, does 389-DS not automatically prune any options
> that will
> > result in an unsuccessful connection.
> >
> > 2) Why is the internal cipher sorting order choosing weaker cipher
> > suites before stronger ones?
>
> I'm pretty sure that 389-ds still uses NSS for server-side
> crypto and
> unless something has changed NSS doesn't do cipher sorting. It
> picks the
> "best" for you. AFAIR the server has no say in the matter.
>
> But, as a goof I used a pure NSS server tool to see what happens
> and it
> picked the expected cipher.
>
> Enable your two ciphers (in hex form):
>
> $ /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d
> /etc/dirsrv/slapd-EXAMPLE-TEST/ -p 8389 -f
> /etc/dirsrv/slapd-EXAMPLE-TEST/pwdfile.txt -c :C02F -c :C030 -v -V
> tls1.2:tls1.2
>
> run s_client:
>
> New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
>     Session-ID:
> 2AF9EFDDB3EA99C101C4E4F99A47CD479D294C15309D7E994ADA21C083D8E096
>     Session-ID-ctx:
>     Master-Key:
> 85646A59B24D5A88080227BD59E328C688910FB0B2E2BAD77D7B1A96F6A9A3ACBF74EEC6C844A7D59527152928580743
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1619562457
>     Timeout   : 7200 (sec)
>     Verify return code: 0 (ok)
>     Extended master secret: yes
>
> So even more confusing unless I've goofed something up, sorry. I
> didn't
> mess with minssf, maybe that does make a difference.
>
> The ciphers are:
>
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   0xC02F
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   0xC030
>
> Don't mean to stir up the mud but this may be a question for the
> NSS team.
>
> rob
>
> > On Mon, Apr 26, 2021 at 11:50 PM William Brown <wbrown@suse.de
> <mailto:wbrown@suse.de>
> > <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote:
> >
> >     Then youll need to disable everything except aes256 then I
> suspect
> >     ... :(
> >
> >     > On 25 Apr 2021, at 11:39, Trevor Vaughan
> <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>
> >     <mailto:tvaughan@onyxpoint.com
> <mailto:tvaughan@onyxpoint.com>>> wrote:
> >     >
> >     > Well, in this case, I've got to be able to work with
> regulatory
> >     requirements so not much I can do there.
> >     >
> >     > Trevor
> >     >
> >     > On Sat, Apr 24, 2021, 9:03 PM William Brown
> <wbrown@suse.de <mailto:wbrown@suse.de>
> >     <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote:
> >     >
> >     >
> >     > > On 24 Apr 2021, at 22:30, Trevor Vaughan
> <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>
> >     <mailto:tvaughan@onyxpoint.com
> <mailto:tvaughan@onyxpoint.com>>> wrote:
> >     > >
> >     > > Hi Marc,
> >     > >
> >     > > I was under the impression that it would pick the highest
> >     supported, but that doesn't seem to be what is happening
> based on my
> >     previous example.
> >     > >
> >     > > Instead, it seems to just be picking the first compatible,
> >     regardless of strength.
> >     >
> >     > It choose aes128 over 256 because of processing speed,
> and "strong
> >     enough".
> >     >
> >     > >
> >     > > Trevor
> >     > >
> >     > > On Fri, Apr 23, 2021, 10:03 PM Marc Sauton
> <msauton@redhat.com <mailto:msauton@redhat.com>
> >     <mailto:msauton@redhat.com <mailto:msauton@redhat.com>>>
> wrote:
> >     > > about ciphers order and TLS cipher suite discovery,
> NSS will
> >     pick the one with highest strength from the available
> ciphers, and
> >     compatible with the TLS client ( handshake)
> >     > >
> >     > > you can check the configuration with for example
> (replace the
> >     string m1 with an instance name):
> >     > > dsconf m1 security get
> >     > > dsconf m1 security ciphers list
> >     > > dsconf m1 security ciphers list --supported | less
> >     > > dsconf m1 security ciphers list --enabled
> >     > > ldapsearch -o ldif-wrap=no -LLLxD "cn=Directory
> Manager" -W  -b
> >     cn=encryption,cn=config | less
> >     > >
> >     > > and to set ciphers (can be "delicate"):
> >     > > /usr/lib64/nss/unsupported-tools/listsuites | grep -B1
> >     --no-group-separator "Enabled" | less
> >     > > dsconf m1 security ciphers set xxxxx
> >     > >
> >     > > doc ref:
> >     > >
> >   
>  https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/enabling_tls#setting_encryption_ciphers
> >     > >
> >     > > and NSS source:
> >     > > ./lib/ssl/ssl3con.c
> >     > > ./lib/ssl/sslenum.c
> >     > >
> >     > >
> >     > > On Fri, Apr 23, 2021 at 4:57 PM Trevor Vaughan
> >     <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>
> <mailto:tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>>>
> wrote:
> >     > > William,
> >     > >
> >     > > I do apologize! I'll keep that in mind in the future.
> >     > >
> >     > > Thanks again for your help,
> >     > >
> >     > > Trevor
> >     > >
> >     > > On Fri, Apr 23, 2021, 7:50 PM William Brown
> <wbrown@suse.de <mailto:wbrown@suse.de>
> >     <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote:
> >     > > Sorry to call this out, but my name is "William" not
> "Bill". I
> >     have personal reasons to dislike being called that name.
> >     > >
> >     > > Regardless, happy to help out :)
> >     > >
> >     > > > On 23 Apr 2021, at 22:11, Trevor Vaughan
> >     <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>
> <mailto:tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>>>
> wrote:
> >     > > >
> >     > > > Bill and Pierre,
> >     > > >
> >     > > > Thanks for the responses!
> >     > > >
> >     > > > It sounds like I have to figure out how to configure
> the NSS
> >     library for 389-DS specifically.
> >     > > >
> >     > > > In EL8+ I know that I can configure the global
> crypto policy
> >     but I'm hoping that I can do it for the specific
> application. I
> >     haven't found anything in the documentation so far but at
> least this
> >     gets me pointed in the right direction.
> >     > > >
> >     > > > Thanks,
> >     > > >
> >     > > > Trevor
> >     > > >
> >     > > > On Fri, Apr 23, 2021 at 4:42 AM Pierre Rogier
> >     <progier@redhat.com <mailto:progier@redhat.com>
> <mailto:progier@redhat.com <mailto:progier@redhat.com>>> wrote:
> >     > > > Hi Trevor,
> >     > > >
> >     > > > I do not think it is possible to specify the cypher
> order
> >     negotiation:
> >     > > >      I am not sure whether TLS protocol allow to
> specify an
> >     order when negotiating the cypher,
> >     > > >      but at 389 level there is no way to specify an
> order:
> >     > > > The NSS security layer provides the list of
> supported cypher
> >     and 389 use
> >     > > > nsSSL3Ciphers config parameter to enable/disable theses
> >     cyphers in the list (without changing the order)
> >     > > >
> >     > > >     So my feeling is that if there is an order it is
> up to the
> >     different
> >     > > >      security layer implementations and may differs
> between
> >     the applications,
> >     > > >
> >     > > > Regards,
> >     > > >    Pierre
> >     > > >
> >     > > > On Thu, Apr 22, 2021 at 7:28 PM Trevor Vaughan
> >     <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>
> <mailto:tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>>>
> wrote:
> >     > > > Hi William,
> >     > > >
> >     > > > In terms of the STARTTLS bits (in theory) properly
> configuring
> >     your client software mitigates the password leak risk. But
> this also
> >     happens with pure (non-RFC) LDAPS connections.
> >     > > >
> >     > > > The docs note that minssf applies to the crypto
> required bits
> >     as well as the SASL layer.
> >     > > >
> >     > > > Ignoring most of that, my issue is that I don't
> understand why
> >     I have to nail my client software to ciphers explicitly
> known by
> >     389-DS instead of the two negotiating the strongest things
> possible
> >     out of the gate.
> >     > > >
> >     > > > For instance, if I use AES256 with a minssf=256,
> everything
> >     works just fine.
> >     > > >
> >     > > > But, if I use AES128:AES256:@STRENGTH (which should sort
> >     strongest to weakest) then access is denied.
> >     > > >
> >     > > > How do I get 389-DS to negotiate the strongest
> ciphers first
> >     (regardless of the method)?
> >     > > >
> >     > > > Thanks,
> >     > > >
> >     > > > Trevor
> >     > > >
> >     > > > On Wed, Apr 21, 2021 at 7:34 PM William Brown
> <wbrown@suse.de <mailto:wbrown@suse.de>
> >     <mailto:wbrown@suse.de <mailto:wbrown@suse.de>>> wrote:
> >     > > > Hi there,
> >     > > >
> >     > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan
> >     <tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>
> <mailto:tvaughan@onyxpoint.com <mailto:tvaughan@onyxpoint.com>>>
> wrote:
> >     > > > >
> >     > > > > Hi All,
> >     > > > >
> >     > > > > OS Version: CentOS 8
> >     > > > > 389-DS Version: 1.4.3.22 from EPEL
> >     > > > >
> >     > > > > I have a server set up with minssf=256 and have been
> >     surprised that either 389-DS, or openssl, does not appear
> to be
> >     doing what I would consider a logical TLS negotiation.
> >     > > > >
> >     > > > > I had thought that the system would start with the
> strongest
> >     cipher and then negotiate down to something that was
> acceptable.
> >     > > > >
> >     > > > > Instead, I'm finding that I have to nail up the
> ciphers to
> >     something that the 389-DS server both recognizes and is
> within the
> >     expected SSF.
> >     > > > >
> >     > > > > Is this expected behavior or do I have something
> configured
> >     incorrectly?
> >     > > >
> >     > > > That's not what minssf does.
> >     > > >
> >     > > > minssf says "during a bind operation, reject if the
> encryption
> >     strength used is less than 256 bits or equivalent".
> >     > > >
> >     > > > The "bit strength" is arbitrary though, because it's
> a concept
> >     from sasl, and generally is very broken.
> >     > > >
> >     > > > Remember, minssf does NOT do what you think though!
> Because
> >     bind is the *first* message on the wire, the series of
> operations is
> >     > > >
> >     > > >
> >     > > >    client                   server
> >     > > > open plain text conn  ->   
> >     > > >                       <-   accept connection
> >     > > > send bind on conn     ->   
> >     > > >                       <-   reject due to minsff too
> weak.
> >     > > >
> >     > > >
> >     > > > So you have already leaked the password!
> >     > > >
> >     > > >
> >     > > > The only way to ensure this does not occur is to set
> >     "nsslapd-port: 0" which disables plaintext. Then you
> *only* use
> >     ldaps on port 636, which is guarantee encrypted from the
> start.
> >     > > >
> >     > > > It is worth noting that the use of starttls over
> ldap, does
> >     *NOT* mitigate this issue, for a similar reason.
> >     > > >
> >     > > >
> >     > > > Caveat: If you are using kerberos/gssapi you can NOT
> disable
> >     plaintext ldap due to these protocols attempting to
> install their
> >     own encryption layers.
> >     > > >
> >     > > >
> >     > > > Hope that helps,
> >     > > >
> >     > > >
> >     > > > >
> >     > > > > Thanks,
> >     > > > >
> >     > > > > Trevor
> >     > > > >
> >     > > > > --
> >     > > > > Trevor Vaughan
> >     > > > > Vice President, Onyx Point, Inc
> >     > > > > (410) 541-6699 x788
> >     > > > >
> >     > > > > -- This account not approved for unencrypted
> proprietary
> >     information --
> >     > > > > _______________________________________________
> >     > > > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > > >
> >     > > > —
> >     > > > Sincerely,
> >     > > >
> >     > > > William Brown
> >     > > >
> >     > > > Senior Software Engineer, 389 Directory Server
> >     > > > SUSE Labs, Australia
> >     > > > _______________________________________________
> >     > > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > > >
> >     > > >
> >     > > > --
> >     > > > Trevor Vaughan
> >     > > > Vice President, Onyx Point, Inc
> >     > > > (410) 541-6699 x788
> >     > > >
> >     > > > -- This account not approved for unencrypted proprietary
> >     information --
> >     > > > _______________________________________________
> >     > > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > > >
> >     > > >
> >     > > > --
> >     > > > --
> >     > > >
> >     > > > 389 Directory Server Development Team
> >     > > > _______________________________________________
> >     > > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > > >
> >     > > >
> >     > > > --
> >     > > > Trevor Vaughan
> >     > > > Vice President, Onyx Point, Inc
> >     > > > (410) 541-6699 x788
> >     > > >
> >     > > > -- This account not approved for unencrypted proprietary
> >     information --
> >     > > > _______________________________________________
> >     > > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > >
> >     > > —
> >     > > Sincerely,
> >     > >
> >     > > William Brown
> >     > >
> >     > > Senior Software Engineer, 389 Directory Server
> >     > > SUSE Labs, Australia
> >     > > _______________________________________________
> >     > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > > _______________________________________________
> >     > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > > _______________________________________________
> >     > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > > _______________________________________________
> >     > > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     >
> >     > —
> >     > Sincerely,
> >     >
> >     > William Brown
> >     >
> >     > Senior Software Engineer, 389 Directory Server
> >     > SUSE Labs, Australia
> >     > _______________________________________________
> >     > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >     > _______________________________________________
> >     > 389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     > To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     > Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     > List Guidelines:
> >     https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     > List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     > Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >
> >     —
> >     Sincerely,
> >
> >     William Brown
> >
> >     Senior Software Engineer, 389 Directory Server
> >     SUSE Labs, Australia
> >     _______________________________________________
> >     389-users mailing list --
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> >     <mailto:389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>>
> >     To unsubscribe send an email to
> >     389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> >     <mailto:389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>>
> >     Fedora Code of Conduct:
> >     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >     List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> >     List Archives:
> >   
>  https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> >     Do not reply to spam on the list, report it:
> >     https://pagure.io/fedora-infrastructure
> >
> >
> >
> > --
> > Trevor Vaughan
> > Vice President, Onyx Point, Inc
> > (410) 541-6699 x788
> >
> > -- This account not approved for unencrypted proprietary
> information --
> >
> > _______________________________________________
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> > To unsubscribe send an email to
> 389-users-leave@lists.fedoraproject.org
> <mailto:389-users-leave@lists.fedoraproject.org>
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788
>
> -- This account not approved for unencrypted proprietary information --
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788
>
> -- This account not approved for unencrypted proprietary information --
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

No comments:

Post a Comment