From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 0b0e4490 for ; Tue, 6 Nov 2018 06:40:10 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id BEF95A2310; Tue, 6 Nov 2018 16:40:09 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 402F3A2422; Tue, 6 Nov 2018 16:39:44 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 20635A22EA; Tue, 6 Nov 2018 15:23:46 +1000 (AEST) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [45.33.28.24]) by minnie.tuhs.org (Postfix) with ESMTPS id 6D8C6A215E for ; Tue, 6 Nov 2018 15:23:40 +1000 (AEST) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id wA65NcHT004776 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 5 Nov 2018 23:23:39 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1541481819; bh=N0xSpoMYpXsmNjq8ORuCmG+pvNubZPD9xgmU8FO/S3Q=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=Ytr2Pr80328mSVOy4B0QDrIi556KzvPSZ6/P8pXcPeERibHDCOQMjfpMKouUaXxwZ vQqV/CTE686YygacKpF7fsMPR9puPo/UNm5VzkKJLpwSSRDsxyHsNlx7EJbMWXn3SC ZikkKpxJzlRMVnYZfxoCYk+isp6aMHQAPVIWGpRc= To: tuhs@minnie.tuhs.org References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Organization: TNet Consulting Message-ID: <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> Date: Mon, 5 Nov 2018 22:24:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050207090204000707090907" Subject: Re: [TUHS] YP / NIS / NIS+ / LDAP X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Grant Taylor via TUHS Reply-To: Grant Taylor Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a cryptographically signed message in MIME format. --------------ms050207090204000707090907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/05/2018 03:34 PM, Dan Cross wrote: > You can use a modified `login` that will validate you against a KDC. ACK > The way it works is to set up a host key for the host you're logging=20 > into; that is then used to authenticate the *host* to the KDC, which=20 > then allows it to validate a user against the KDC and issue the user a = > TGT at the same time. This works well for e.g. console and X logins. That makes sense. > Modifications have been made to e.g. SSH so that one can authenticate a= n=20 > SSH session via GSSAPI, which usually wraps Kerberos. If I recall,=20 > GSSAPI might be one of the lasting legacies of the DCE, though I may be= =20 > misremembering history. *nod* Generic Security Service Application Program Interface - The abstraction = layer that (as far as I know) only had one service behind it. > Security, in general, usually seeks to address five questions: >=20 > 1. Authentication - Is some entity who it claims to be? > 2. Authorization - Is some entity allowed to perform some action? > 3. Privacy - Can a third party snoop on a private conversation between = > two entities? > 4. Integrity - Can a third party alter communications between two=20 > entities in an undetectable way? > 5. Non-repudiation - Can it be definitively shown that some entity was = a=20 > party to some communication? The 3rd A that I'm used to is "Access Control". Is the requested action = allowed given the above information. > Kerberos is a authentication protocol. >=20 > LDAP, YP (retroactively named NIS after a lawsuit involving, I believe,= =20 > British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all = > examples of directory services. To a first-order approximation, one=20 > might think of a directory service as providing an oracle allowing one = > to discover what entities exist in some domain. >=20 > Authentication protocols and directory services solve different=20 > problems. Though in true Micro$oft-of-old fashion, AD sort of merged bo= th. I would argue that a directory including shadow information (like=20 NIS(+)) does both too. > Kerberos solves the authentication problem, but does not provide a=20 > directory service nor does it solve the authorization problem (though=20 > some "kerberized" services could use a library to consult a=20 > user-provided file of ACLs mapping principals to privileges). On Unix, = > "authorization data" includes things like your UID and the set of group= s=20 > you belong to (or more precisely, your process's UIDs and GIDs/groups).= =20 > Kerberos provided support for privacy via encryption libraries, and it = > provided support for integrity via hashing/checksumming/signature=20 > libraries. "Kerberized" versions of network services such as telnet,=20 > FTP, rsh/rlogin/rcp etc all provided support for authentication via the= =20 > baseline Kerberos protocol as well as privacy and integrity via=20 > connection-level encryption and checksumming. I was not aware that Kerberos could provide privacy (encryption) for=20 kerberized services. I (naively) thought that Kerberos was=20 authentication that other things could use to make access control decisio= ns. > Kerberos provided a replay cache, but otherwise provided only limited=20 > support for non-repudiation via mutual authentication through the=20 > KDC (that is, clients authenticated to servers, but servers also=20 > authenticated to clients). *nod* I think NT4 domains and AD both had the same type of client to=20 server mutual trust. (At least for NT derived clients with machine=20 trust accounts.) > So while a KDC might tell you whether the principal connecting to your = > SSH service is really "cross@GAJENDRA.NET ",= =20 > it won't tell you your UID, what shell you use, the path to your home=20 > directory, what groups you are a member of, or what finger should say=20 > for your real name. *nod*nod*nod* That's why the directory component is so important. Somewhere to get=20 all that other information. > In its pure form, SSH provides support for limited authentication (via = > public key cryptography and the wide distribution of public keys) and=20 > limited authorization (via the `authorized_keys` file), privacy and=20 > integrity. I think that OpenSSH's certificate support extends that a bit. > LDAP might provide you some mechanism to look up a user record that=20 > provides those details; it may also provide some kind of hashed passwor= d=20 > that a system can use to validate a password, but it won't do much=20 > better than that. I suppose you could put an authorized SSH public key = > into an LDAP directory in the same way you would put a hashed password.= I've always viewed LDAP as a directory that can have various content in=20 it. It then makes this content relatively easy to access. What the=20 content is is up to the content consumer. Be it names, email addresses, = shells, or password hashes. > NIS was based on Sun RPC; as was mentioned earlier, anyone on a network= =20 > could bind to an NIS server and query it to get e.g., hashed password=20 > file entries that they could run crack against. Nothing was encrypted. Even if communications with the NIS server was encrypted, I'm not=20 hearing anything that prevents an authenticated user from enumerating=20 NIS. Even if it was over encrypted channels. > There was a system for a user to update his/her information in the NIS = > database (e.g., this was how you changed your password or set your shel= l=20 > or updated your office phone number...), but the "authentication" was=20 > just checking your password; again nothing was encrypted, so a maliciou= s=20 > third party on your network could in theory mount a man-in-the-middle=20 > attack against you and inject his/her own data into the transaction and= =20 > take over your account. ACK > NIS+ improved on this, but wasn't universally supported across systems = > and we lost some useful NIS functionality: back in the NIS days, you=20 > could supplement the contents of /etc/passwd with the NIS passwd maps, = > but keep local overrides (e.g., for anyone not in the `@staff` netgroup= ,=20 > set shell to `/sbin/nologin` on servers); perhaps there was a way to do= =20 > this with NIS+ but it felt very much like a binary thing: you were=20 > either all in on NIS+ or not at all. Mixing and matching just wasn't as= =20 > easy as it had been. Also, the symmetric crypto was, I think, DES based= =20 > and as that fell apart I don't recall it getting much better. So unless= =20 > you were all Sun based (and many of us had heterogenous systems to worr= y=20 > about; my shops supported Suns running SunOS 4 and Solaris 2, SGIs=20 > running Irix, HP-UX machines, Alphas running OSF/1 then DEC Unix then=20 > Tru64, DECstations running Ultrix, RS/6000's running AIX, RTs running=20 > AOS, a few NeXTs, PCs running Linux *BSD and PCs running Windows and=20 > Macs. Oh, and VMS on VAXen and Alphas. Yay. Elsewhere on campus we had = a=20 > mainframe running VM/ESA, a couple of Crays, some AS/400s; we also had = a=20 > few plan9 machines. We even had a PDP-10 running TOPS-10 at some point.= =20 > Good ol' YP cut across the widest swath of these so that's what we ran = > the longest, but it was a more innocent time, network access was more=20 > tightly controlled and it wasn't quite as dangerous to run something=20 > like ypserv. *nod* > I thought for a while that LDAP would be the light and the way, but it = > was really a lot more general than what I cared about just for Unix=20 > system administration. Setting it up wasn't as easy as NIS, or even NIS= +=20 > for that matter. That's what I've gathered from a number of sources. Which is why I've=20 heard people avoid LDAP directly. Or at least use something like=20 Samba+Winbind or SSSD as an abstraction layer into LDAP+Kerberos. > Netinfo came from NeXT and survived into Macos for a little while. It=20 > was kind of neat but again the all-singing, all-dancing solution to the= =20 > world. No one else really used it. Typical. > Hesiod, which seems unique to Athena, was kind of neat; it piggy-backed= =20 > the need for a directory service on DNS, which is already a distributed= =20 > directory service. You embedded relevant data into DNS TXT records, so = > imagine doing a DNS query to look up a user's /etc/passwd entry: after = > all, DNS already scaled and was well-proven Internet-wide. I don't know= =20 > that anyone ever really supported it, though. I know that Red Hat Linux did have support for it. One of my colleagues = was a Hesiod maintainer for a while. > So yeah. Kerberos is plenty fine for authentication for small to medium= =20 > sites (up to mid tens of thousands of users, I'd guess), but won't help= =20 > you distribute your authorization data. You need a directory service or= =20 > some other mechanism for that. Directory services will help you with=20 > that, but usually don't do a great job at authentication, though they=20 > may provide the means to distributed the data that other systems can us= e=20 > for that. Of the directory services out there these days, LDAP seems to= =20 > have "won". (Raw) LDAP and AD seem to be what I see the most of. I've worked in a=20 few shops that evolved their NDS into eDirectory with appropriate=20 clients for other platforms. --=20 Grant. . . . unix || die --------------ms050207090204000707090907 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 CxcwggUpMIIEEaADAgECAhAIzwdZriPvq7FXSbc0jGReMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNzExMTcwMDAw MDBaFw0xODExMTcyMzU5NTlaMCsxKTAnBgkqhkiG9w0BCQEWGmd0YXlsb3JAdG5ldGNvbnN1 bHRpbmcubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvhfMhFM6CDAWL4Mg xrKLLbzTCILpI7uBzgG/HFXxV92MX4fba+pAotqOV8of7uF4YykVw94lCsOmFeVkb8VNSn6Q KSFbfnjXmYgU7XRtFHioTZihIynEXXI1LPMhnDXV9jCEzVvrlBx/6mSPdQcWhG1oMAlGd62w uu/CRE5U70LngVVat0wDJhdzrHxZabQlHhAPAvwMex8ObGDAkuieUCn5pQj2xqVKMB65vdcE ZydA8d8X8mvqHHOrEOg5xIwpca7E4JeUMxzYrdp3kVS7V+wXUui1nPwMb6o8WUe72FnL27BY mGqmtUGUc/ajGDUMS4xvabJ0M4Qc/NVGf56qDwIDAQABo4IB2jCCAdYwHwYDVR0jBBgwFoAU gq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFD8vJWpDFBkhAbiZGgx0EIUgH1EoMA4G A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls Q0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuY29tb2Rv Y2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRpn dGF5bG9yQHRuZXRjb25zdWx0aW5nLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEArDRhn6+otAvz JNgWiGsEeKawiBwqIlR8NSoiOpNYfpmZWS7A+X2mn/47nUT1KypbS3Mf8j8N1rf/FU53p0So WBsnqPAYajAaLjXnGoOEs8pOW0nK/vFYGJHdh8RXvxpPBOd7HUQCqsc4MGJUgasfrWdwqfAZ C1C0G7rNxY5Uvj8RFBPb7d+RfOaegUBMc5FDiXB3Xs43lUEWoWiMi6R3Y5PlQyrvLJB39cLw iLWlOom79addldgAaWZsxnwUDgQgth5ARr1Jw+nfNIimmauAtxDJMgaV17B4ODeuHI1jlPoG HS4+u/qVAwSYq4vtaCN1PSPHwqrrnERAj40c6yPyvzCCBeYwggPOoAMCAQICEGqb4Tg7/ytr nwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI5Or1u6zf +bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+RKwrB 6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4 yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv 5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgw HwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D T01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYI KwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEM BQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42aw GGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZBy WPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7 ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7 vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2 xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4jkhJiA7EuTec P/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJM/1tyZR2niOY ihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJUmpvVdZ4ognzg Xtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8YXLI8nAb R9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIENTCCBDECAQEwgawwgZcxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0 jGReMA0GCWCGSAFlAwQCAQUAoIICWTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODExMDYwNTI0NDJaMC8GCSqGSIb3DQEJBDEiBCAfoW+yGHI8SL8wUbW5 y9kDtrZhmb0WTlERzMVBLE76OTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG9BgkrBgEEAYI3EAQxga8wgawwgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAIzwdZriPvq7FXSbc0jGReMIG/ BgsqhkiG9w0BCRACCzGBr6CBrDCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEAjPB1muI++rsVdJtzSMZF4wDQYJKoZIhvcNAQEBBQAEggEAJMKwFL+v i2woECqjT3Cd/a/Z8ulwaHMaYZw8QjwuuWfvrDQJehKsafLjCzZuDTRaify4ieYi/UZKT8r8 tY3vrzh/M1AGYL15EcFotuYU7sJhxyxJaOy+Bc7qE+1xOv51M3f7NVS+xCV0dG+Fsz7k8/7Y w3oI7syvUMk3rLQc+dDqEjZ0RVXyCS5Gep1Qw1+xrFbKZ6ep5qG8SQ555U9AzvSpGle/kcD7 tskva4FbrZ5qxYZjvL2RH+9rfIu75HnMjKN4WOIelYlGoccoiZ1anrqiIWsNjaW2SLQCrYYx 0DFuPAJtpTtWiqpaM4ytoC2xpZ3FkHUyoyxpdtQ0n7ym/AAAAAAAAA== --------------ms050207090204000707090907--