Re: minssf and TLS cipher ordering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Trevor Vaughan wrote:
> How odd, maybe it's the version in EPEL.

I tested on a Fedora 32 VM I had lying around with an IPA installation.

nss-3.62.0-1.fc32.x86_64

And this excluded 389-ds other than using its NSS database.

rob

> 
> On Tue, Apr 27, 2021 at 6:32 PM Rob Crittenden <rcritten@xxxxxxxxxx
> <mailto:rcritten@xxxxxxxxxx>> 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@xxxxxxx
>     <mailto:wbrown@xxxxxxx>
>     > <mailto:wbrown@xxxxxxx <mailto:wbrown@xxxxxxx>>> wrote:
>     >
>     >     Then youll need to disable everything except aes256 then I suspect
>     >     ... :(
>     >
>     >     > On 25 Apr 2021, at 11:39, Trevor Vaughan
>     <tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>
>     >     <mailto:tvaughan@xxxxxxxxxxxxx
>     <mailto:tvaughan@xxxxxxxxxxxxx>>> 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@xxxxxxx
>     <mailto:wbrown@xxxxxxx>
>     >     <mailto:wbrown@xxxxxxx <mailto:wbrown@xxxxxxx>>> wrote:
>     >     >
>     >     >
>     >     > > On 24 Apr 2021, at 22:30, Trevor Vaughan
>     <tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>
>     >     <mailto:tvaughan@xxxxxxxxxxxxx
>     <mailto:tvaughan@xxxxxxxxxxxxx>>> 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@xxxxxxxxxx <mailto:msauton@xxxxxxxxxx>
>     >     <mailto:msauton@xxxxxxxxxx <mailto:msauton@xxxxxxxxxx>>> 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@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>
>     <mailto:tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>>> 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@xxxxxxx <mailto:wbrown@xxxxxxx>
>     >     <mailto:wbrown@xxxxxxx <mailto:wbrown@xxxxxxx>>> 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@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>
>     <mailto:tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>>> 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@xxxxxxxxxx <mailto:progier@xxxxxxxxxx>
>     <mailto:progier@xxxxxxxxxx <mailto:progier@xxxxxxxxxx>>> 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@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>
>     <mailto:tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>>> 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@xxxxxxx <mailto:wbrown@xxxxxxx>
>     >     <mailto:wbrown@xxxxxxx <mailto:wbrown@xxxxxxx>>> wrote:
>     >     > > > Hi there,
>     >     > > >
>     >     > > > > On 22 Apr 2021, at 03:52, Trevor Vaughan
>     >     <tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>
>     <mailto:tvaughan@xxxxxxxxxxxxx <mailto:tvaughan@xxxxxxxxxxxxx>>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > Do not reply to spam on the list, report it:
>     >     https://pagure.io/fedora-infrastructure
>     >     > > _______________________________________________
>     >     > > 389-users mailing list --
>     389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > Do not reply to spam on the list, report it:
>     >     https://pagure.io/fedora-infrastructure
>     >     > > _______________________________________________
>     >     > > 389-users mailing list --
>     389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > Do not reply to spam on the list, report it:
>     >     https://pagure.io/fedora-infrastructure
>     >     > > _______________________________________________
>     >     > > 389-users mailing list --
>     389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > Do not reply to spam on the list, report it:
>     >     https://pagure.io/fedora-infrastructure
>     >     > _______________________________________________
>     >     > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     To unsubscribe send an email to
>     >     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     >     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>>
>     >     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@xxxxxxxxxxxxxxxxxxxxxxx
>     >     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@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
>     > To unsubscribe send an email to
>     389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>     <mailto:389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx>
>     > 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@xxxxxxxxxxxxxxxxxxxxxxx
>     > 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux