Lovely. Is this something that the 389 team is willing to take up to NSS or shall I go it alone?
Given that most things will work (if accidentally) anyone setting minssf is likely to be quite surprised.
Thanks,
Trevor
On Wed, Apr 28, 2021 at 9:24 AM Rob Crittenden <rcritten@redhat.com> wrote:
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 --
--
Trevor Vaughan
Vice President, Onyx Point, Inc
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
No comments:
Post a Comment