Re: minssf and TLS cipher ordering

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

 



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@xxxxxxxxxxxxx
> <mailto:tvaughan@xxxxxxxxxxxxx>> 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@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 --
> 
> 
> 
> -- 
> 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