[OpenAFS] Kerberos + Windows

Jeffrey E Altman jaltman@auristor.com
Wed, 24 Aug 2022 21:49:32 -0400


This is a cryptographically signed message in MIME format.

--------------ms020905080500060005060002
Content-Type: multipart/alternative;
 boundary="------------W2oh18fWsCn7SjCHLfotxtb0"

--------------W2oh18fWsCn7SjCHLfotxtb0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 8/24/2022 12:53 PM, Ben Huntsman (ben@huntsmans.net) wrote:
>
>    Here's some configuration info:
>
>    Let's say my cell is going to be mydomain.com.  My Active Directory 
> is ad.mydomain.com, and my AFS service account is srvAFS.

When installing Active Directory for a domain "mydomain.com" it is best 
if the Active Directory domain is "MYDOMAIN.COM" instead of 
"AD.MYDOMAIN.COM".  This is because Kerberos clients will attempt to use 
the DNS name of the host as the Kerberos realm name.   The use of 
"AD.MYDOMAIN.COM" or "WIN.MYDOMAIN.COM" naming is common only in cases 
where there is a pre-existing Kerberos realm for "MYDOMAIN.COM".


> Here's my krb5.conf:
>
> [libdefaults]
>         default_realm = AD.MYDOMAIN.COM
>         default_keytab_name = FILE:/etc/krb5/krb5.keytab
>         dns_lookup_realm = true
>         dns_lookup_kdc = true
>         forwardable = true
>
> [realms]
>         AD.MYDOMAIN.COM = {
>                 kdc = ad.mydomain.com:88
>                 admin_server = ad.mydomain.com:749
>                 default_domain = ad.mydomain.com
>         }
>
> [domain_realm]
>         .ad.mydomain.com = AD.MYDOMAIN.COM
>         ad.mydomain.com = AD.MYDOMAIN.COM


You also need to add


     .mydomain.com = AD.MYDOMAIN.COM

     mydomain.com = AD.MYDOMAIN.COM


since the Kerberos realm is not the same as the DNS domain name used for 
the AFS service principal.

>
> [logging]
>         kdc = FILE:/var/krb5/log/krb5kdc.log
>         admin_server = FILE:/var/krb5/log/kadmin.log
>         kadmin_local = FILE:/var/krb5/log/kadmin_local.log
>         default = FILE:/var/krb5/log/krb5lib.log
>
>
> I then created the service account srvAFS, and extracted a keytab on 
> the Domain Controller using the following command:
>
> ktpass /princ afs/mydomain.com@AD.MYDOMAIN.COM /mapuser srvAFS /mapop 
> add /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL 
> +dumpsalt

The use of "afs/mydomain.com@AD.MYDOMAIN.COM" is correct.     The 
"afs@AD.MYDOMAIN.COM" service principal name should no longer be used 
and must never be used with Active Directory.


>
> I verified that the account did not have the "Use only Kerberos DES 
> encryption types for this account" box checked. I then copied the 
> rxkad.keytab over to the UNIX host.  I built OpenAFS with a prefix of 
> /opt/openafs, so I put the keytab in /opt/openafs/etc/openafs/server
>
> I used ktutil to delete the two des entries in the keytab. ktutil 
> indicates that the KVNO is 5.
>
> I then added the keys to OpenAFS using the command:
>
> asetkey add rxkad_krb5 5 17 
> /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com
> asetkey add rxkad_krb5 5 18 
> /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com

For an Active Directory realm you most likely also need to add rc4-hmac, 
enctype 23.


Did the above "asetkey" commands succeed?   Since the cell is named 
"mydomain.com" I would expect asetkey to expand "afs/mydomain.com" to 
"afs/mydomain.com@MYDOMAIN.COM" which is not going to be present in the 
rxkad.keytab file.


What is the output of "asetkey list" after the above commands were executed?

>
> But things aren't quite working:
>
> # ls /afs
> afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded 
> (rxkad error=19270408, server 192.168.0.114)
> ls: /afs: The file access permissions do not allow the specified action.
>
> # kvno adUser@AD.MYDOMAIN.COM
> kvno: Server not found in Kerberos database while getting credentials 
> for adUser@AD.MYDOMAIN.COM
This is not expected to work.
>
> # vos listvol myserver
> Could not fetch the list of partitions from the server
> rxk: ticket contained unknown key version number
> Error in vos listvol command.
> rxk: ticket contained unknown key version number

19270408 = rxk: ticket contained unknown key version number


It means the OpenAFS servers are not finding the expected key entry.   
There is not a match for the combination of enctype and key version 
number and name.


> # kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab 
> afs/mydomain.com@AD.MYDOMAIN.COM
>
The above command is using the afs/mydomain.com@AD.MYDOMAIN.COM keytab 
entry to obtain a client Ticket Granting Ticket.    I doubt that is what 
you intended.


Instead you wanted to "kinit" using a client principal and then execute 
the kvno command below.

> # kvno afs/mydomain.com@AD.MYDOMAIN.COM
> afs/mydomain.com@AD.MYDOMAIN.COM: kvno = 5

In addition to the key version number you also need to know the 
encryption type used to encrypt the service private portion of the 
afs/mydomain.com@AD.MYDOMAIN.COM service ticket.  It is that encryption 
type which does not need to match either the encryption type used to 
encrypt the client private portion of the ticket or the session key 
which needs to match the keys added via asetkey.


After adding the keys via "asetkey" did you install KeyFileExt on every 
server in the cell?


Did you restart the services or touch the server instance of the 
CellServDB file to force the new keys to be loaded?


>
> Did I miss something, or make a mistake along the way somewhere?

Ben mentions in a separate reply that the OpenAFS krb.conf file needs to 
be created and specify the local authentication realm as 
"AD.MYDOMAIN.COM".  Failure to do so will prevent authorization from 
succeeding but would not result in a key version not found error.


Jeffrey Altman


--------------W2oh18fWsCn7SjCHLfotxtb0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 8/24/2022 12:53 PM, Ben Huntsman
      (<a class="moz-txt-link-abbreviated" href="mailto:ben@huntsmans.net">ben@huntsmans.net</a>) wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
             Here's some configuration info:</div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
             Let's say my cell is going to be mydomain.com.  My Active
          Directory is ad.mydomain.com, and my AFS service account is
          srvAFS.</div>
      </div>
    </blockquote>
    <p>When installing Active Directory for a domain "mydomain.com" it
      is best if the Active Directory domain is "MYDOMAIN.COM" instead
      of "AD.MYDOMAIN.COM".  This is because Kerberos clients will
      attempt to use the DNS name of the host as the Kerberos realm
      name.   The use of "AD.MYDOMAIN.COM" or "WIN.MYDOMAIN.COM" naming
      is common only in cases where there is a pre-existing Kerberos
      realm for "MYDOMAIN.COM".<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> 
          Here's my krb5.conf:</div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          [libdefaults]
          <div>        default_realm = AD.MYDOMAIN.COM</div>
          <div>        default_keytab_name = <a class="moz-txt-link-freetext" href="FILE:/etc/krb5/krb5.keytab">FILE:/etc/krb5/krb5.keytab</a></div>
          <div>        dns_lookup_realm = true</div>
          <div>        dns_lookup_kdc = true</div>
          <div>        forwardable = true</div>
          <div><br>
          </div>
          <div>[realms]</div>
          <div>        AD.MYDOMAIN.COM = {</div>
          <div>                kdc = ad.mydomain.com:88</div>
          <div>                admin_server = ad.mydomain.com:749</div>
          <div>                default_domain = ad.mydomain.com</div>
          <div>        }</div>
          <div><br>
          </div>
          <div>[domain_realm]</div>
          <div>        .ad.mydomain.com = AD.MYDOMAIN.COM</div>
          <div>        ad.mydomain.com = AD.MYDOMAIN.COM</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>You also need to add</p>
    <p><br>
    </p>
    <p>    .mydomain.com = AD.MYDOMAIN.COM</p>
    <p>    mydomain.com = AD.MYDOMAIN.COM</p>
    <p><br>
    </p>
    <p>since the Kerberos realm is not the same as the DNS domain name
      used for the AFS service principal.<br>
    </p>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <div><br>
          </div>
          <div>[logging]</div>
          <div>        kdc = <a class="moz-txt-link-freetext" href="FILE:/var/krb5/log/krb5kdc.log">FILE:/var/krb5/log/krb5kdc.log</a></div>
          <div>        admin_server = <a class="moz-txt-link-freetext" href="FILE:/var/krb5/log/kadmin.log">FILE:/var/krb5/log/kadmin.log</a></div>
          <div>        kadmin_local =
            <a class="moz-txt-link-freetext" href="FILE:/var/krb5/log/kadmin_local.log">FILE:/var/krb5/log/kadmin_local.log</a></div>
          <div>        default = <a class="moz-txt-link-freetext" href="FILE:/var/krb5/log/krb5lib.log">FILE:/var/krb5/log/krb5lib.log</a></div>
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          I then created the service account srvAFS, and extracted a
          keytab on the Domain Controller using the following command:</div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          ktpass /princ <a class="moz-txt-link-abbreviated" href="mailto:afs/mydomain.com@AD.MYDOMAIN.COM">afs/mydomain.com@AD.MYDOMAIN.COM</a> /mapuser srvAFS
          /mapop add /out rxkad.keytab +rndpass /crypto all /ptype
          KRB5_NT_PRINCIPAL +dumpsalt<br>
        </div>
      </div>
    </blockquote>
    <p>The use of <a class="moz-txt-link-rfc2396E" href="mailto:afs/mydomain.com@AD.MYDOMAIN.COM">"afs/mydomain.com@AD.MYDOMAIN.COM"</a> is correct.     The
      <a class="moz-txt-link-rfc2396E" href="mailto:afs@AD.MYDOMAIN.COM">"afs@AD.MYDOMAIN.COM"</a> service principal name should no longer be
      used and must never be used with Active Directory.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          I verified that the account did not have the "Use only
          Kerberos DES encryption types for this account" box checked. 
          I then copied the rxkad.keytab over to the UNIX host.  I built
          OpenAFS with a prefix of /opt/openafs, so I put the keytab in
          /opt/openafs/etc/openafs/server</div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          I used ktutil to delete the two des entries in the keytab. 
          ktutil indicates that the KVNO is 5.</div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          I then added the keys to OpenAFS using the command:</div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          asetkey add rxkad_krb5 5 17
          /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com<br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          asetkey add rxkad_krb5 5 18
          /opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com<br>
        </div>
      </div>
    </blockquote>
    <p>For an Active Directory realm you most likely also need to add
      rc4-hmac, enctype 23.</p>
    <p><br>
    </p>
    <p>Did the above "asetkey" commands succeed?   Since the cell is
      named "mydomain.com" I would expect asetkey to expand
      "afs/mydomain.com" to <a class="moz-txt-link-rfc2396E" href="mailto:afs/mydomain.com@MYDOMAIN.COM">"afs/mydomain.com@MYDOMAIN.COM"</a> which is not
      going to be present in the rxkad.keytab file.</p>
    <p><br>
    </p>
    <p>What is the output of "asetkey list" after the above commands
      were executed?<br>
    </p>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        But things aren't quite working:
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          # ls /afs
          <div>afs: Tokens for user of AFS id 204 for cell mydomain.com
            are discarded (rxkad error=19270408, server 192.168.0.114)</div>
          <div>ls: /afs: The file access permissions do not allow the
            specified action.</div>
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          # kvno <a class="moz-txt-link-abbreviated" href="mailto:adUser@AD.MYDOMAIN.COM">adUser@AD.MYDOMAIN.COM</a><br>
          kvno: Server not found in Kerberos database while getting
          credentials for <a class="moz-txt-link-abbreviated" href="mailto:adUser@AD.MYDOMAIN.COM">adUser@AD.MYDOMAIN.COM</a><br>
        </div>
      </div>
    </blockquote>
    This is not expected to work.<br>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          # vos listvol myserver
          <div>Could not fetch the list of partitions from the server</div>
          <div>rxk: ticket contained unknown key version number</div>
          <div>Error in vos listvol command.</div>
          <div>rxk: ticket contained unknown key version number</div>
        </div>
      </div>
    </blockquote>
    <p>19270408 = rxk: ticket contained unknown key version number</p>
    <p><br>
    </p>
    <p>It means the OpenAFS servers are not finding the expected key
      entry.   There is not a match for the combination of enctype and
      key version number and name.</p>
    <br>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <div># kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab
            <a class="moz-txt-link-abbreviated" href="mailto:afs/mydomain.com@AD.MYDOMAIN.COM">afs/mydomain.com@AD.MYDOMAIN.COM</a></div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>The above command is using the <a class="moz-txt-link-abbreviated" href="mailto:afs/mydomain.com@AD.MYDOMAIN.COM">afs/mydomain.com@AD.MYDOMAIN.COM</a>
      keytab entry to obtain a client Ticket Granting Ticket.    I doubt
      that is what you intended.</p>
    <p><br>
    </p>
    <p>Instead you wanted to "kinit" using a client principal and then
      execute the kvno command below.<br>
    </p>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <div># kvno <a class="moz-txt-link-abbreviated" href="mailto:afs/mydomain.com@AD.MYDOMAIN.COM">afs/mydomain.com@AD.MYDOMAIN.COM</a><br>
            <a class="moz-txt-link-abbreviated" href="mailto:afs/mydomain.com@AD.MYDOMAIN.COM">afs/mydomain.com@AD.MYDOMAIN.COM</a>: kvno = 5</div>
        </div>
      </div>
    </blockquote>
    <p>In addition to the key version number you also need to know the
      encryption type used to encrypt the service private portion of the
      <a class="moz-txt-link-abbreviated" href="mailto:afs/mydomain.com@AD.MYDOMAIN.COM">afs/mydomain.com@AD.MYDOMAIN.COM</a> service ticket.  It is that
      encryption type which does not need to match either the encryption
      type used to encrypt the client private portion of the ticket or
      the session key which needs to match the keys added via asetkey.</p>
    <p><br>
    </p>
    <p>After adding the keys via "asetkey" did you install KeyFileExt on
      every server in the cell?</p>
    <p><br>
    </p>
    <p>Did you restart the services or touch the server instance of the
      CellServDB file to force the new keys to be loaded?<br>
    </p>
    <p> <br>
    </p>
    <blockquote type="cite"
cite="mid:MWHPR0701MB367402C828251E2A551932D5A7739@MWHPR0701MB3674.namprd07.prod.outlook.com">
      <div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          <br>
        </div>
        <div class="elementToProof" style="font-family: Calibri, Arial,
          Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
          Did I miss something, or make a mistake along the way
          somewhere?</div>
      </div>
    </blockquote>
    <p>Ben mentions in a separate reply that the OpenAFS krb.conf file
      needs to be created and specify the local authentication realm as
      "AD.MYDOMAIN.COM".  Failure to do so will prevent authorization
      from succeeding but would not result in a key version not found
      error.<br>
    </p>
    <p><br>
    </p>
    <p>Jeffrey Altman</p>
    <p><br>
    </p>
  </body>
</html>

--------------W2oh18fWsCn7SjCHLfotxtb0--

--------------ms020905080500060005060002
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz
MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew
MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt
YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3
xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN
fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI
EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg
9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG
IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr
BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF
BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx
My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG
A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov
L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt
bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g
aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj
YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp
ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v
dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY
MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s
gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV
eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c
WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq
utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo
Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt
a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA
AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe
Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L
wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/
15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn
o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0
3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2
VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG
CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu
dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t
L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C
5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0
dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl
eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg
YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy
dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v
Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0
dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy
bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG
CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2
bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s
0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u
6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88
QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4
Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu
db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb
rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d
UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn
p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA
MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG
A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg
ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDgyNTAx
NDkzMlowLwYJKoZIhvcNAQkEMSIEINSdCJXRlMms1dG+CkIC5rnZSAUS+h8djb+jVLmzRWKD
MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX
MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ
AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy
dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAGWMv
M9EuUQAnpzYFRBg89GYJMtgdWJd0/F3w3CiKv82aFrEgmtuFhnSZzE+0UnkZmZV2x2nD1Dzx
gIPkpYW7jSa7E4URtLXqsoTmXbV7qGZgC2DHdJd5TbDKHF+IpfZxYIiMQ1redGuhV0eWEwQm
/ht+dBaTRYsNZ/fvYImSTibI4Yf9HUgkgmcozNKVTtBbcSvNoBH/JaHdcKeMqvrNBXRZk+QR
Z46Q6NymNlFh0Z4BFaKSHyFc+OzMwXla3lrBc2gKBG1BnHRNfQSVFBWoor/K5GYesyKim2Du
wZlNhfpnCbtqX14SFmDDbFkSIOcXPybTnwec53kZunbTHpkalQAAAAAAAA==
--------------ms020905080500060005060002--