From ralf.brunckhorst@hp.com Mon Jul 1 10:50:42 2013 From: ralf.brunckhorst@hp.com (Brunckhorst, Ralf) Date: Mon, 1 Jul 2013 09:50:42 +0000 Subject: [OpenAFS] volscan for RHEL5 Message-ID: --_000_E3A882F104F6304D89C62FB119B729800FCB4CB4G5W2743americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have compiled the volinfo binary from the MASTER-tree to be able to use t= he volscan utility (by creating a link to volinfo) on RHEL6 with openafs-1.= 6.2 I would also like to use these utilities on RHEL5 openafs-1.6.2 but I'm not= able to compile it due to some too old compiler and make file tools shippe= d with RHEL5. At the moment I cannot update those packages. So my question: Has someone already compiled those special volinfo (volscan= ) binaries + the librokenafs.so.1 lib for RHEL5 (32bit +64bit) and can prov= ide me those? That would be great. Thanks, /Ralf --_000_E3A882F104F6304D89C62FB119B729800FCB4CB4G5W2743americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have compiled the volinfo binary from the MASTER-t= ree to be able to use the volscan utility (by creating a link to volinfo) o= n RHEL6 with openafs-1.6.2

 

I would also like to use these utilities on RHEL5 op= enafs-1.6.2 but I’m not able to compile it due to some too old compil= er and make file tools shipped with RHEL5.

At the moment I cannot update those packages.

 

So my question: Has someone already compiled those s= pecial volinfo (volscan) binaries + the librokenafs.so.1 lib for RHEL5 = (32bit +64bit) and can provide me those?

 

That would be great.

 

Thanks,

 

/Ralf

--_000_E3A882F104F6304D89C62FB119B729800FCB4CB4G5W2743americas_-- From mmeffie@sinenomine.net Mon Jul 1 15:33:55 2013 From: mmeffie@sinenomine.net (Michael Meffie) Date: Mon, 1 Jul 2013 10:33:55 -0400 Subject: [OpenAFS] volscan for RHEL5 In-Reply-To: References: Message-ID: <20130701103355.6c04b570.mmeffie@sinenomine.net> On Mon, 1 Jul 2013 09:50:42 +0000 "Brunckhorst, Ralf" wrote: > Hello, > > I have compiled the volinfo binary from the MASTER-tree to be able to use the volscan utility (by creating a link to volinfo) on RHEL6 with openafs-1.6.2 > > I would also like to use these utilities on RHEL5 openafs-1.6.2 but I'm not able to compile it due to some too old compiler and make file tools shipped with RHEL5. > At the moment I cannot update those packages. I think you may hitting the issue of the autotools which ship with rhel5 are too out of date to build openafs. If that is the case, you can use the configure script created on your rhel6 to configure and build on rhel5. > So my question: Has someone already compiled those special volinfo (volscan) > binaries + the librokenafs.so.1 lib for RHEL5 (32bit +64bit) and can provide > me those? -- Michael Meffie From Coy.Hile@COYHILE.COM Mon Jul 1 16:44:16 2013 From: Coy.Hile@COYHILE.COM (Coy Hile) Date: Mon, 1 Jul 2013 15:44:16 +0000 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <51CF06D7.5060401@your-file-system.com> References: <51CF06D7.5060401@your-file-system.com> Message-ID: Wouldn't most organizations disable these defaults via a global GPO?=A0=0A= =0A= =0A= ________________________________________=0A= From: openafs-info-admin@openafs.org on behalf of Jeffrey Altman=0A= Sent: Saturday, June 29, 2013 4:09 PM=0A= To: OpenAFS=0A= Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles=0A= =0A= Last Wednesday Microsoft released the one and only preview release of=0A= Windows 8.1 in conjunction with the Microsoft Build conference which I=0A= attended.=A0 The one big change relating to file systems is the=0A= integration of SkyDrive into the Shell and its selection as the primary=0A= storage location for end user documents.=0A= =0A= The SkyDrive integration adds shell recognition for files that are=0A= located in the locally sync'd copy of the SkyDrive directory tree but=0A= which have not been copied locally.=A0=A0 Microsoft now represents these=0A= files with a new Reparse Point (Tag: 0x80000015) which is a "sparse=0A= file" and an "offline" file.=A0 The file will not be visible to=0A= applications that browse the directory from the command line but will be=0A= displayed in the Explorer Shell and Modern application views of the=0A= SkyDrive directory.=0A= =0A= The SkyDrive folder tree is stored in the user's profile at=0A= \Users\\SkyDrive.=A0=A0 When the profile is on NTFS this works=0A= fine.=A0 When the roaming profile is stored in AFS this is going to cause= =0A= problems because at logout an error will be generated when attempts are=0A= made to copy this new reparse point to AFS.=0A= =0A= I urge organizations to begin testing Windows 8.1 Preview immediately=0A= and to file bug reports with Microsoft as soon as possible.=A0 This is a=0A= feature that will not be altered once Windows 8.1 RTM is cut.=A0=A0 It is= =0A= critical that Microsoft hear about issues that will effect their=0A= customers while there is time to make adjustments.=0A= =0A= Jeffrey Altman=0A= =0A= From jaltman@your-file-system.com Mon Jul 1 17:18:49 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Mon, 01 Jul 2013 12:18:49 -0400 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: References: <51CF06D7.5060401@your-file-system.com> Message-ID: <51D1ABE9.4080301@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms040307020008050204080707 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A university would not. An organization that is supporting Bring Your Own Device (BYOD) cannot. On 7/1/2013 11:44 AM, Coy Hile wrote: > Wouldn't most organizations disable these defaults via a global GPO?=20 >=20 >=20 > ________________________________________ > From: openafs-info-admin@openafs.org on behalf of Jeffrey Altman > Sent: Saturday, June 29, 2013 4:09 PM > To: OpenAFS > Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles >=20 > Last Wednesday Microsoft released the one and only preview release of > Windows 8.1 in conjunction with the Microsoft Build conference which I > attended. The one big change relating to file systems is the > integration of SkyDrive into the Shell and its selection as the primary= > storage location for end user documents. >=20 > The SkyDrive integration adds shell recognition for files that are > located in the locally sync'd copy of the SkyDrive directory tree but > which have not been copied locally. Microsoft now represents these > files with a new Reparse Point (Tag: 0x80000015) which is a "sparse > file" and an "offline" file. The file will not be visible to > applications that browse the directory from the command line but will b= e > displayed in the Explorer Shell and Modern application views of the > SkyDrive directory. >=20 > The SkyDrive folder tree is stored in the user's profile at > \Users\\SkyDrive. When the profile is on NTFS this works > fine. When the roaming profile is stored in AFS this is going to cause= > problems because at logout an error will be generated when attempts are= > made to copy this new reparse point to AFS. >=20 > I urge organizations to begin testing Windows 8.1 Preview immediately > and to file bug reports with Microsoft as soon as possible. This is a > feature that will not be altered once Windows 8.1 RTM is cut. It is > critical that Microsoft hear about issues that will effect their > customers while there is time to make adjustments. >=20 > Jeffrey Altman >=20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >=20 --------------ms040307020008050204080707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzAxMTYxODQ5WjAjBgkqhkiG9w0BCQQxFgQUiOF3qlJkdyHEkuzzroRbXHjyP5kwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AIAZZdwuNmx9e0MENW/NbqJL8cXaZz3ydbCihxYBJyHEem5l6zG4u/nwHYCba0tNVRKlDcgp la1GTOzd4hKEPx1G85N806TzJ3XSzfD+64q9LIQW9NaiEbBfVOVLD2cwvaNUe+jRgpXnT/7y K26SLpTQ/0Y4AmcA0/3liDAcOOlpAm0YDScp8ck5it8B+cEVeZ7o42S2cQlAaxGGgLf1sJsm VWYxFaSyPZcKonAZk9BpaGBFKdhjplFYVijmM1Z0O9EwWQbIIu2UiAtsbDJSbNkno8XXPjAr RPM3OwC9hQ7/xxl1cFUNyoklu/R/BpP4ugsGYY3DGfuh/sbgP3GAZUUAAAAAAAA= --------------ms040307020008050204080707-- From botsch@cnf.cornell.edu Mon Jul 1 17:31:47 2013 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Mon, 1 Jul 2013 12:31:47 -0400 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <51CF06D7.5060401@your-file-system.com> References: <51CF06D7.5060401@your-file-system.com> Message-ID: <20130701163147.GZ6639@cnf.cornell.edu> What would be the suggested resolution from Microsoft? Any reason OAFSWin can't add support for these reparse points? thanks. On Sat, Jun 29, 2013 at 12:09:59PM -0400, Jeffrey Altman wrote: > Last Wednesday Microsoft released the one and only preview release of > Windows 8.1 in conjunction with the Microsoft Build conference which I > attended. The one big change relating to file systems is the > integration of SkyDrive into the Shell and its selection as the primary > storage location for end user documents. > > The SkyDrive integration adds shell recognition for files that are > located in the locally sync'd copy of the SkyDrive directory tree but > which have not been copied locally. Microsoft now represents these > files with a new Reparse Point (Tag: 0x80000015) which is a "sparse > file" and an "offline" file. The file will not be visible to > applications that browse the directory from the command line but will be > displayed in the Explorer Shell and Modern application views of the > SkyDrive directory. > > The SkyDrive folder tree is stored in the user's profile at > \Users\\SkyDrive. When the profile is on NTFS this works > fine. When the roaming profile is stored in AFS this is going to cause > problems because at logout an error will be generated when attempts are > made to copy this new reparse point to AFS. > > I urge organizations to begin testing Windows 8.1 Preview immediately > and to file bug reports with Microsoft as soon as possible. This is a > feature that will not be altered once Windows 8.1 RTM is cut. It is > critical that Microsoft hear about issues that will effect their > customers while there is time to make adjustments. > > Jeffrey Altman > -- ******************************** David William Botsch Programmer/Analyst CNF Computing botsch@cnf.cornell.edu ******************************** From stephen@physics.unc.edu Mon Jul 1 18:02:15 2013 From: stephen@physics.unc.edu (Stephen Joyce) Date: Mon, 1 Jul 2013 13:02:15 -0400 (EDT) Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <51D1ABE9.4080301@your-file-system.com> References: <51CF06D7.5060401@your-file-system.com> <51D1ABE9.4080301@your-file-system.com> Message-ID: On Mon, 1 Jul 2013, Jeffrey Altman wrote: > A university would not. Why not? > An organization that is supporting Bring Your Own Device (BYOD) cannot. Is there a use case for roaming profiles in a BYOD environment? (Not trying to troll; I don't support Windows currently but am always interested in OAFS in an enterprise environment. I would assume if SkyDrive can be turned off via GP, any institution with an articulated security stance will do so.) Cheers, Stephen > On 7/1/2013 11:44 AM, Coy Hile wrote: >> Wouldn't most organizations disable these defaults via a global GPO? >> >> >> ________________________________________ >> From: openafs-info-admin@openafs.org on behalf of Jeffrey Altman >> Sent: Saturday, June 29, 2013 4:09 PM >> To: OpenAFS >> Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles >> >> Last Wednesday Microsoft released the one and only preview release of >> Windows 8.1 in conjunction with the Microsoft Build conference which I >> attended. The one big change relating to file systems is the >> integration of SkyDrive into the Shell and its selection as the primary >> storage location for end user documents. >> >> The SkyDrive integration adds shell recognition for files that are >> located in the locally sync'd copy of the SkyDrive directory tree but >> which have not been copied locally. Microsoft now represents these >> files with a new Reparse Point (Tag: 0x80000015) which is a "sparse >> file" and an "offline" file. The file will not be visible to >> applications that browse the directory from the command line but will be >> displayed in the Explorer Shell and Modern application views of the >> SkyDrive directory. >> >> The SkyDrive folder tree is stored in the user's profile at >> \Users\\SkyDrive. When the profile is on NTFS this works >> fine. When the roaming profile is stored in AFS this is going to cause >> problems because at logout an error will be generated when attempts are >> made to copy this new reparse point to AFS. >> >> I urge organizations to begin testing Windows 8.1 Preview immediately >> and to file bug reports with Microsoft as soon as possible. This is a >> feature that will not be altered once Windows 8.1 RTM is cut. It is >> critical that Microsoft hear about issues that will effect their >> customers while there is time to make adjustments. >> >> Jeffrey Altman >> >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > > From dboyes@sinenomine.net Mon Jul 1 18:09:04 2013 From: dboyes@sinenomine.net (David Boyes) Date: Mon, 1 Jul 2013 17:09:04 +0000 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: References: <51CF06D7.5060401@your-file-system.com> <51D1ABE9.4080301@your-file-system.com> Message-ID: <2748AD71D96C2B42B7E5176021026FC307B9E7C6@ORD2MBX03A.mex05.mlsrvr.com> > > A university would not. >=20 > Why not? Because:=20 1) Universities tend toward maximum freedom of usage, even if the "feature"= is actually hazardous.=20 2) If you disable something on a machine that you don't own, you're likely = to get all sorts of grief. Most machines in university environments are own= ed by individuals.=20 3) Somewhere in the process of getting a PhD, most faculty members seem to = have been given a golden God card that says they can do anything they want,= no matter how stupid. If you prevent them from using Skydrive, they will c= all your manager, call the dean, and call everyone they can find to make yo= ur life miserable. You won't like this.=20 =20 > > An organization that is supporting Bring Your Own Device (BYOD) cannot. >=20 > Is there a use case for roaming profiles in a BYOD environment? Yes. Consider #2 above. How else would you handle it? Or devices with no/mi= nimal local storage.=20 > (Not trying to troll; I don't support Windows currently but am always > interested in OAFS in an enterprise environment. I would assume if SkyDri= ve > can be turned off via GP, any institution with an articulated security st= ance > will do so.) Your last phrase encapsulates it neatly. "with an articulated security stan= ce" rarely =3D university. Universities block things they get sued about. N= o further, unless you wish to experience #3 above.=20 From rra@stanford.edu Mon Jul 1 20:43:07 2013 From: rra@stanford.edu (Russ Allbery) Date: Mon, 01 Jul 2013 12:43:07 -0700 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <20130701163147.GZ6639@cnf.cornell.edu> (Dave Botsch's message of "Mon, 1 Jul 2013 12:31:47 -0400") References: <51CF06D7.5060401@your-file-system.com> <20130701163147.GZ6639@cnf.cornell.edu> Message-ID: <87sizym5h0.fsf@windlord.stanford.edu> Dave Botsch writes: > What would be the suggested resolution from Microsoft? > Any reason OAFSWin can't add support for these reparse points? You can't do that only in the Windows client, at least if I'm understanding the nature of reparse points correctly. The AFS file server would also have to be able to store the reparse point. Think of it as akin to a UNIX device file. So this means new data structures available inside AFS volumes, which has rather wide-ranging implementation effects. -- Russ Allbery (rra@stanford.edu) From botsch@cnf.cornell.edu Mon Jul 1 20:49:14 2013 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Mon, 1 Jul 2013 15:49:14 -0400 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <87sizym5h0.fsf@windlord.stanford.edu> References: <51CF06D7.5060401@your-file-system.com> <20130701163147.GZ6639@cnf.cornell.edu> <87sizym5h0.fsf@windlord.stanford.edu> Message-ID: <20130701194914.GD6639@cnf.cornell.edu> So, how does Windows then deal with storing those on non-NTFS filesystem? NFS or FAT32 usb sticks? Etc. Does all of that just break, does it do some sort of de-reference to the actual file, or do something akin to the mac data/resource fork splitting ? On Mon, Jul 01, 2013 at 12:43:07PM -0700, Russ Allbery wrote: > Dave Botsch writes: > > > What would be the suggested resolution from Microsoft? > > > Any reason OAFSWin can't add support for these reparse points? > > You can't do that only in the Windows client, at least if I'm > understanding the nature of reparse points correctly. The AFS file server > would also have to be able to store the reparse point. Think of it as > akin to a UNIX device file. So this means new data structures available > inside AFS volumes, which has rather wide-ranging implementation effects. > > -- > Russ Allbery (rra@stanford.edu) > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info -- ******************************** David William Botsch Programmer/Analyst CNF Computing botsch@cnf.cornell.edu ******************************** From prochazka.nicolas@gmail.com Tue Jul 2 07:15:59 2013 From: prochazka.nicolas@gmail.com (nicolas prochazka) Date: Tue, 2 Jul 2013 08:15:59 +0200 Subject: [OpenAFS] Openafs 1.6.4 Release Message-ID: --047d7b3442925ee72f04e0814740 Content-Type: text/plain; charset=UTF-8 Hello, Is there any reason why openafs 1.6.4 is not release ? ( source tar.gz in openafs site is more usuable for ebuild gentoo packager for example) Regards, Nicoolas Prochazka. --047d7b3442925ee72f04e0814740 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0
Is there any reason why openaf= s 1.6.4 is not release ?
( source tar.gz in openafs site =C2=A0is= more usuable for ebuild gentoo packager for example)

<= div>

Regards,=C2=A0
Nicoolas Pro= chazka.
--047d7b3442925ee72f04e0814740-- From rra@stanford.edu Tue Jul 2 08:21:52 2013 From: rra@stanford.edu (Russ Allbery) Date: Tue, 02 Jul 2013 00:21:52 -0700 Subject: [OpenAFS] Openafs 1.6.4 Release In-Reply-To: (nicolas prochazka's message of "Tue, 2 Jul 2013 08:15:59 +0200") References: Message-ID: <87li5ppgtr.fsf@windlord.stanford.edu> nicolas prochazka writes: > Is there any reason why openafs 1.6.4 is not release ? ( source tar.gz > in openafs site is more usuable for ebuild gentoo packager for example) Just that the release manager has been busy. It's all but released (I've already uploaded packages based on it to Debian, for example). -- Russ Allbery (rra@stanford.edu) From l.schimmer@cgv.tugraz.at Tue Jul 2 09:09:43 2013 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Tue, 02 Jul 2013 10:09:43 +0200 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <2748AD71D96C2B42B7E5176021026FC307B9E7C6@ORD2MBX03A.mex05.mlsrvr.com> References: <51CF06D7.5060401@your-file-system.com> <51D1ABE9.4080301@your-file-system.com> <2748AD71D96C2B42B7E5176021026FC307B9E7C6@ORD2MBX03A.mex05.mlsrvr.com> Message-ID: <51D28AC7.8080904@cgv.tugraz.at> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HAFJFKECXILRQTMCHPLV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-01 19:09, David Boyes wrote: >>> A university would not. >> >> Why not? >=20 > Because:=20 >=20 > 1) Universities tend toward maximum freedom of usage, even if the "feat= ure" is actually hazardous.=20 Not everywhere. Depending on the level of security you want. With the new events of Prism and co being real and not more hidden, the chances to lock some features down are really high. We e.g. do propose to NOT upload any data to any internet service we cannot control. Thats why we do run OpenAFS - we want a own cloud to be reachable secure from everywhere. > 2) If you disable something on a machine that you don't own, you're lik= ely to get all sorts of grief. Most machines in university environments a= re owned by individuals.=20 Hell, NO! If foreign workstations to resist in our network, they are a BIG risk for security. They do go into a seperate, closed down subnet. Really. > 3) Somewhere in the process of getting a PhD, most faculty members seem= to have been given a golden God card that says they can do anything they= want, no matter how stupid. If you prevent them from using Skydrive, the= y will call your manager, call the dean, and call everyone they can find = to make your life miserable. You won't like this.=20 They get a own subnet without OpenAFS features. Really. >>> An organization that is supporting Bring Your Own Device (BYOD) canno= t. >> >> Is there a use case for roaming profiles in a BYOD environment? >=20 > Yes. Consider #2 above. How else would you handle it? Or devices with n= o/minimal local storage.=20 Blackberry setup? Remote wipe, encrypted storage,... all fine builtinto android (and if needed: Apple iOS). >=20 > Your last phrase encapsulates it neatly. "with an articulated security = stance" rarely =3D university. Universities block things they get sued ab= out. No further, unless you wish to experience #3 above.=20 I do not know which university you do know and think about, but at least in europe some do work different. MfG, Lars Schimmer --=20 ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ------enig2HAFJFKECXILRQTMCHPLV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHSiscACgkQmWhuE0qbFyOEvQCcCZN1dfI2vjacJy5eW3E9f0nH 0IIAniBpS2AiM4CswN2f6UtsRdtjM1Dw =v563 -----END PGP SIGNATURE----- ------enig2HAFJFKECXILRQTMCHPLV-- From dboyes@sinenomine.net Tue Jul 2 16:46:18 2013 From: dboyes@sinenomine.net (David Boyes) Date: Tue, 2 Jul 2013 15:46:18 +0000 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <51D28AC7.8080904@cgv.tugraz.at> References: <51CF06D7.5060401@your-file-system.com> <51D1ABE9.4080301@your-file-system.com> <2748AD71D96C2B42B7E5176021026FC307B9E7C6@ORD2MBX03A.mex05.mlsrvr.com> <51D28AC7.8080904@cgv.tugraz.at> Message-ID: <2748AD71D96C2B42B7E5176021026FC307BA397D@ORD2MBX03A.mex05.mlsrvr.com> > -----Original Message----- > [examples of one sane voice amidst the madness] > > I do not know which university you do know and think about, but at least = in > europe some do work different. Mostly American universities, I'm afraid. It's my great consolation that th= e European and Asian universities still retain some vestige of sanity. It's= amazing what a few hundred years of practice can do for civility and good = sense.=20 From ralf.brunckhorst@hp.com Mon Jul 8 09:14:29 2013 From: ralf.brunckhorst@hp.com (Brunckhorst, Ralf) Date: Mon, 8 Jul 2013 08:14:29 +0000 Subject: [OpenAFS] DAFS dasalvager: cannot be running from cron Message-ID: --_000_E3A882F104F6304D89C62FB119B729800FCC7136G5W2743americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have noticed the following behavior of dasalvager: (Tested on RHEL5 + RHEL6 with openafs-1.6.2 + openafs-1.6.4) Salvaging a RW-volume on a DAFS server like the following works fine: /usr/afs/bin/dasalvager -partition PARTITION -volumeid RW-VOLID -showlog -f= orceDAFS -debug Putting this into a script and execute the script from CMD-line works also = fine. # /tmp/salvage.sh @(#) OpenAFS 1.6.4 built 2013-06-28 07/08/2013 16:12:59 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/dasalvager -par= tition /vicephf -volumeid 536912830 -showlog -forceDAFS -debug) 07/08/2013 16:12:59 2 nVolumesInInodeFile 56 07/08/2013 16:12:59 CHECKING CLONED VOLUME 536912831. 07/08/2013 16:12:59 A.e.seka.readonly (536912831) updated 07/06/2013 18:29 07/08/2013 16:12:59 SALVAGING VOLUME 536912830. 07/08/2013 16:12:59 A.e.seka (536912830) updated 07/06/2013 18:29 07/08/2013 16:12:59 totalInodes 345 07/08/2013 16:12:59 Salvaged A.e.seka (536912830): 338 files, 481 blocks But executing the script from cron doesn't work. Here the output from the scripts: (RHEL5 openafs-1.6.4) @(#) OpenAFS 1.6.4 built 2013-06-28 07/08/2013 15:58:01 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/dasalvager -par= tition /vicephf -volumeid 536912830 -showlog -forceDAFS -debug) 07/08/2013 15:58:01 _VLockFd: fcntl failed with error 9 when trying to lock= fd 0 (locktype=3D2, offset=3D536912830) Error 5 trying to lock volume 536912830; Aborted /tmp/salvage.sh: line 1: 743 Aborted /usr/afs/bin/dasalva= ger -partition /vicephf -volumeid 536912830 -showlog -forceDAFS -debug Same behavior (RHEL6 openafs-1.6.2) @(#) OpenAFS 1.6.2 built 2013-02-22 07/08/2013 10:02:01 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/dasalvager -par= tition /vicepf -volumeid 536884732 -showlog -forceDAFS -debug) 07/08/2013 10:02:01 _VLockFd: fcntl failed with error 9 when trying to lock= fd 0 (locktype=3D2, offset=3D536884732) Error 5 trying to lock volume 536884732; Aborted /tmp/salvage.sh: line 1: 8690 Aborted (core dumped) /usr/a= fs/bin/dasalvager -partition /vicepf -volumeid 536884732 -showlog -forceDAF= S -debug Is there any chance to get this also running via cron? -- Kind regards Ralf --_000_E3A882F104F6304D89C62FB119B729800FCC7136G5W2743americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have noticed the following behavior of dasalvager:=

(Tested on RHEL5 + RHEL6 with openafs-1.6.2 += ; openafs-1.6.4)

 

Salvaging a RW-volume on a DAFS server like the foll= owing works fine:

/usr/afs/bin/dasalvager -partition PARTITION -volume= id RW-VOLID -showlog -forceDAFS –debug

Putting this into a script and execute the script fr= om CMD-line works also fine.

# /tmp/salvage.sh

@(#) OpenAFS 1.6.4 built  2013-06-28

07/08/2013 16:12:59 STARTING AFS SALVAGER 2.4 (/usr/= afs/bin/dasalvager -partition /vicephf -volumeid 536912830 -showlog -forceD= AFS -debug)

07/08/2013 16:12:59 2 nVolumesInInodeFile 56

07/08/2013 16:12:59 CHECKING CLONED VOLUME 536912831= .

07/08/2013 16:12:59 A.e.seka.readonly (536912831) up= dated 07/06/2013 18:29

07/08/2013 16:12:59 SALVAGING VOLUME 536912830.=

07/08/2013 16:12:59 A.e.seka (536912830) updated 07/= 06/2013 18:29

07/08/2013 16:12:59 totalInodes 345

07/08/2013 16:12:59 Salvaged A.e.seka (536912830): 3= 38 files, 481 blocks

 

But executing the script from cron doesn’t wor= k.

Here the output from the scripts:

 

(RHEL5 openafs-1.6.4)

@(#) OpenAFS 1.6.4 built  2013-06-28

07/08/2013 15:58:01 STARTING AFS SALVAGER 2.4 (/usr/= afs/bin/dasalvager -partition /vicephf -volumeid 536912830 -showlog -forceD= AFS -debug)

07/08/2013 15:58:01 _VLockFd: fcntl failed with erro= r 9 when trying to lock fd 0 (locktype=3D2, offset=3D536912830)<= /p>

Error 5 trying to lock volume 536912830; Aborted

/tmp/salvage.sh: line 1:   743 Aborted&nbs= p;            &= nbsp;   /usr/afs/bin/dasalvager -partition /vicephf -volumeid 536= 912830 -showlog -forceDAFS –debug

 

Same behavior (RHEL6 openafs-1.6.2)

@(#) OpenAFS 1.6.2 built  2013-02-22

07/08/2013 10:02:01 STARTING AFS SALVAGER 2.4 (/usr/= afs/bin/dasalvager -partition /vicepf -volumeid 536884732 -showlog -forceDA= FS -debug)

07/08/2013 10:02:01 _VLockFd: fcntl failed with erro= r 9 when trying to lock fd 0 (locktype=3D2, offset=3D536884732)<= /p>

Error 5 trying to lock volume 536884732; Aborted

/tmp/salvage.sh: line 1:  8690 Aborted &nb= sp;            =    (core dumped) /usr/afs/bin/dasalvager -partition /vicepf -volu= meid 536884732 -showlog -forceDAFS -debug

 

Is there any chance to get this also running via cro= n?

 

-- Kind regards

 

        &nbs= p;            &= nbsp;      Ralf

 

 

--_000_E3A882F104F6304D89C62FB119B729800FCC7136G5W2743americas_-- From adeason@sinenomine.net Mon Jul 8 17:38:41 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Mon, 8 Jul 2013 11:38:41 -0500 Subject: [OpenAFS] Re: DAFS dasalvager: cannot be running from cron References: Message-ID: <20130708113841.dc4dbf09.adeason@sinenomine.net> On Mon, 8 Jul 2013 08:14:29 +0000 "Brunckhorst, Ralf" wrote: > Is there any chance to get this also running via cron? Short answer: dasalvager is apparently unsafe for single-volume salvages; avoid it for now if you can. Running 'salvageserver -client' is another way to manually salvage a single volume, which does not have this problem. Longer answer: This is a bug in dasalvager where it is not initializing the structure properly for locking volumes on disk. So, it thinks it has fd 0 already open for locking, and tries to use that fd without opening the proper file. When you run under a terminal, it uses whatever happens to be fd 0 (this is obviously not safe/correct). When you run under cron (or 'at' or probably a number of other things), fd 0 happens to be closed, so we fail. It is very fortunate that it does fail, because otherwise I don't know when we would have discovered this. Because of all of that, even when dasalvager seems to be running along fine, it is not accessing volumes in a safe manner (this is a bug; the same bug). So, in certain edge cases, it would be possible for dasalvager to cause corruption of volumes. While I haven't completely thought through the scenarios, I believe this would only cause whole volumes to become unusable due to volume metadata problems; it wouldn't corrupt data inside volumes or anything like that. If you don't care, or if this server is relatively inactive or is otherwise low-risk for some reason, you could work around this by forcing fd 0 to be open when you run dasalvager from cron. Obviously, I don't really recommend that, but it should be possible. What would probably be better is if you don't use dasalvager for single-volume salvages at all until we can get this fixed. If you must manually cause a single-volume salvage, you can run 'salvageserver -client' instead of dasalvager, which uses the same code paths as demand-salvages. >From a developer perspective: This is due to the DAFS_FS / DAFS_UTIL mess; all of the DAFS stuff in partition.c should be for _UTIL or _FS instead of just _FS. I started going through fixing them, but there are so many cases that seem to need fixing (e.g. all vutil.c references), and it's becoming clear that the current scheme is becoming increasingly... ridiculously cumbersome and error-prone. I can think of a few possible ways of improving this: - Make DAFS_FS imply DAFS_UTIL. We still have to go manually fix all of the instances to see if they really are _FS or should be _UTIL, but at least it's less verbose. - Remove DAFS_UTIL, make all DAFS utilities use DAFS_FS, and fix existing code to handle the non-pthread DAFS_FS case. - Just use DAFS_FS everywhere and make all DAFS utilities pthreaded, reducing the number of different codepaths. Is there any reason we were avoiding this? It's not like we need LWP DAFS, and any further granularity of "what type of program is running" should be handled at runtime by programType anyway. I'll probably try the latter and see if it's more work than I thought or if I forgot about some big blocker issue for that. Just mentioning options here if anyone has opinions on it. -- Andrew Deason adeason@sinenomine.net From botsch@cnf.cornell.edu Mon Jul 8 18:38:13 2013 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Mon, 8 Jul 2013 13:38:13 -0400 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <51CF06D7.5060401@your-file-system.com> References: <51CF06D7.5060401@your-file-system.com> Message-ID: <20130708173813.GT6639@cnf.cornell.edu> Being somewhat unfamiliar with Windows 8 / 8.1... what are the suggested steps for recreating the conditions to replicate the failure? I've got a skydrive login setup, so, now what? thanks. On Sat, Jun 29, 2013 at 12:09:59PM -0400, Jeffrey Altman wrote: > Last Wednesday Microsoft released the one and only preview release of > Windows 8.1 in conjunction with the Microsoft Build conference which I > attended. The one big change relating to file systems is the > integration of SkyDrive into the Shell and its selection as the primary > storage location for end user documents. > > The SkyDrive integration adds shell recognition for files that are > located in the locally sync'd copy of the SkyDrive directory tree but > which have not been copied locally. Microsoft now represents these > files with a new Reparse Point (Tag: 0x80000015) which is a "sparse > file" and an "offline" file. The file will not be visible to > applications that browse the directory from the command line but will be > displayed in the Explorer Shell and Modern application views of the > SkyDrive directory. > > The SkyDrive folder tree is stored in the user's profile at > \Users\\SkyDrive. When the profile is on NTFS this works > fine. When the roaming profile is stored in AFS this is going to cause > problems because at logout an error will be generated when attempts are > made to copy this new reparse point to AFS. > > I urge organizations to begin testing Windows 8.1 Preview immediately > and to file bug reports with Microsoft as soon as possible. This is a > feature that will not be altered once Windows 8.1 RTM is cut. It is > critical that Microsoft hear about issues that will effect their > customers while there is time to make adjustments. > > Jeffrey Altman > -- ******************************** David William Botsch Programmer/Analyst CNF Computing botsch@cnf.cornell.edu ******************************** From jaltman@secure-endpoints.com Mon Jul 8 18:59:58 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 08 Jul 2013 13:59:58 -0400 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <20130708173813.GT6639@cnf.cornell.edu> References: <51CF06D7.5060401@your-file-system.com> <20130708173813.GT6639@cnf.cornell.edu> Message-ID: <51DAFE1E.60701@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms030204020708070506060802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Configure 8.1 to use roaming profiles and produce a situation in which SkyDrive has synchronized the directory structure but not the contents and files. Then logout and let the SkyDrive folder in the user profile be written back to AFS. On 7/8/2013 1:38 PM, Dave Botsch wrote: > Being somewhat unfamiliar with Windows 8 / 8.1... >=20 > what are the suggested steps for recreating the conditions to replicate= > the failure? I've got a skydrive login setup, so, now what? >=20 > thanks. >=20 > On Sat, Jun 29, 2013 at 12:09:59PM -0400, Jeffrey Altman wrote: >> Last Wednesday Microsoft released the one and only preview release of >> Windows 8.1 in conjunction with the Microsoft Build conference which I= >> attended. The one big change relating to file systems is the >> integration of SkyDrive into the Shell and its selection as the primar= y >> storage location for end user documents. >> >> The SkyDrive integration adds shell recognition for files that are >> located in the locally sync'd copy of the SkyDrive directory tree but >> which have not been copied locally. Microsoft now represents these >> files with a new Reparse Point (Tag: 0x80000015) which is a "sparse >> file" and an "offline" file. The file will not be visible to >> applications that browse the directory from the command line but will = be >> displayed in the Explorer Shell and Modern application views of the >> SkyDrive directory. >> >> The SkyDrive folder tree is stored in the user's profile at >> \Users\\SkyDrive. When the profile is on NTFS this works >> fine. When the roaming profile is stored in AFS this is going to caus= e >> problems because at logout an error will be generated when attempts ar= e >> made to copy this new reparse point to AFS. >> >> I urge organizations to begin testing Windows 8.1 Preview immediately >> and to file bug reports with Microsoft as soon as possible. This is a= >> feature that will not be altered once Windows 8.1 RTM is cut. It is >> critical that Microsoft hear about issues that will effect their >> customers while there is time to make adjustments. >> >> Jeffrey Altman >> >=20 >=20 >=20 --------------ms030204020708070506060802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzA4MTc1OTU4WjAjBgkqhkiG9w0BCQQxFgQUgs+8p4ImeL4M2r2K+I96OPJ31BgwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AITt8FgG6A7v371ushYOU/MVD+wecVWR6rm9NhMsFdtUkuQoYx3m1L3eMixPhlFi65qheerv uS7BHrFT6HOMiBA+hHyVFg2lOVI3YsdnzqSWAsoKZQvMKTm/FZSIfyneCrs8B+vEWMEF8Pp1 W9KfhRYkn1tIiSQkrYfZAi+5CFwjLS1FS20qqz5P9ayS3QuPQ6YzPtJ6WRp/KLZaM4oHA2TV Y5Ws6HSlP5p0/4QvBdVgaaPDH0qIdGQf1AEiH2ryfe5wf4rMCKYf2uFW1yw8l7V/NzSPIUQK 07NUDhJ+w8yq6FLZEUI30MDIXqi164puCbJSKqnKCsGH18lrOGqIUDgAAAAAAAA= --------------ms030204020708070506060802-- From botsch@cnf.cornell.edu Mon Jul 8 19:09:46 2013 From: botsch@cnf.cornell.edu (Dave B) Date: Mon, 08 Jul 2013 14:09:46 -0400 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles Message-ID: ImEgc2l0dWF0aW9uIGluCndoaWNoIFNreURyaXZlIGhhcyBzeW5jaHJvbml6ZWQgdGhlIGRpcmVj dG9yeSBzdHJ1Y3R1cmUgYnV0IG5vdAp0aGUgY29udGVudHMgYW5kIGZpbGVzIgoKUmlnaHQuIFRo YXQncyB3aGF0IEkgYW0gY3VyaW91cyBhYm91dCBob3cgdG8gZG8uCgoKCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqCkRhdmlkIFdpbGxpYW0gQm90c2NoClByb2dyYW1tZXIvQW5hbHlz dApDTkYgQ29tcHV0aW5nCmJvdHNjaEBjbmYuY29ybmVsbC5lZHUKKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioKCkplZmZyZXkgQWx0bWFuIDxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tPiB3cm90ZToKCj5Db25maWd1cmUgOC4xIHRvIHVzZSByb2FtaW5nIHByb2ZpbGVzIGFuZCBw cm9kdWNlIGEgc2l0dWF0aW9uIGluCj53aGljaCBTa3lEcml2ZSBoYXMgc3luY2hyb25pemVkIHRo ZSBkaXJlY3Rvcnkgc3RydWN0dXJlIGJ1dCBub3QKPnRoZSBjb250ZW50cyBhbmQgZmlsZXMuICBU aGVuIGxvZ291dCBhbmQgbGV0IHRoZSBTa3lEcml2ZSBmb2xkZXIKPmluIHRoZSB1c2VyIHByb2Zp bGUgYmUgd3JpdHRlbiBiYWNrIHRvIEFGUy4KPgo+T24gNy84LzIwMTMgMTozOCBQTSwgRGF2ZSBC b3RzY2ggd3JvdGU6Cj4+IEJlaW5nIHNvbWV3aGF0IHVuZmFtaWxpYXIgd2l0aCBXaW5kb3dzIDgg LyA4LjEuLi4KPj4gCj4+IHdoYXQgYXJlIHRoZSBzdWdnZXN0ZWQgc3RlcHMgZm9yIHJlY3JlYXRp bmcgdGhlIGNvbmRpdGlvbnMgdG8gcmVwbGljYXRlCj4+IHRoZSBmYWlsdXJlPyBJJ3ZlIGdvdCBh IHNreWRyaXZlIGxvZ2luIHNldHVwLCBzbywgbm93IHdoYXQ/Cj4+IAo+PiB0aGFua3MuCj4+IAo+ PiBPbiBTYXQsIEp1biAyOSwgMjAxMyBhdCAxMjowOTo1OVBNIC0wNDAwLCBKZWZmcmV5IEFsdG1h biB3cm90ZToKPj4+IExhc3QgV2VkbmVzZGF5IE1pY3Jvc29mdCByZWxlYXNlZCB0aGUgb25lIGFu ZCBvbmx5IHByZXZpZXcgcmVsZWFzZSBvZgo+Pj4gV2luZG93cyA4LjEgaW4gY29uanVuY3Rpb24g d2l0aCB0aGUgTWljcm9zb2Z0IEJ1aWxkIGNvbmZlcmVuY2Ugd2hpY2ggSQo+Pj4gYXR0ZW5kZWQu ICBUaGUgb25lIGJpZyBjaGFuZ2UgcmVsYXRpbmcgdG8gZmlsZSBzeXN0ZW1zIGlzIHRoZQo+Pj4g aW50ZWdyYXRpb24gb2YgU2t5RHJpdmUgaW50byB0aGUgU2hlbGwgYW5kIGl0cyBzZWxlY3Rpb24g YXMgdGhlIHByaW1hcnkKPj4+IHN0b3JhZ2UgbG9jYXRpb24gZm9yIGVuZCB1c2VyIGRvY3VtZW50 cy4KPj4+Cj4+PiBUaGUgU2t5RHJpdmUgaW50ZWdyYXRpb24gYWRkcyBzaGVsbCByZWNvZ25pdGlv biBmb3IgZmlsZXMgdGhhdCBhcmUKPj4+IGxvY2F0ZWQgaW4gdGhlIGxvY2FsbHkgc3luYydkIGNv cHkgb2YgdGhlIFNreURyaXZlIGRpcmVjdG9yeSB0cmVlIGJ1dAo+Pj4gd2hpY2ggaGF2ZSBub3Qg YmVlbiBjb3BpZWQgbG9jYWxseS4gICBNaWNyb3NvZnQgbm93IHJlcHJlc2VudHMgdGhlc2UKPj4+ IGZpbGVzIHdpdGggYSBuZXcgUmVwYXJzZSBQb2ludCAoVGFnOiAweDgwMDAwMDE1KSB3aGljaCBp cyBhICJzcGFyc2UKPj4+IGZpbGUiIGFuZCBhbiAib2ZmbGluZSIgZmlsZS4gIFRoZSBmaWxlIHdp bGwgbm90IGJlIHZpc2libGUgdG8KPj4+IGFwcGxpY2F0aW9ucyB0aGF0IGJyb3dzZSB0aGUgZGly ZWN0b3J5IGZyb20gdGhlIGNvbW1hbmQgbGluZSBidXQgd2lsbCBiZQo+Pj4gZGlzcGxheWVkIGlu IHRoZSBFeHBsb3JlciBTaGVsbCBhbmQgTW9kZXJuIGFwcGxpY2F0aW9uIHZpZXdzIG9mIHRoZQo+ Pj4gU2t5RHJpdmUgZGlyZWN0b3J5Lgo+Pj4KPj4+IFRoZSBTa3lEcml2ZSBmb2xkZXIgdHJlZSBp cyBzdG9yZWQgaW4gdGhlIHVzZXIncyBwcm9maWxlIGF0Cj4+PiBcVXNlcnNcPHVzZXJuYW1lPlxT a3lEcml2ZS4gICBXaGVuIHRoZSBwcm9maWxlIGlzIG9uIE5URlMgdGhpcyB3b3Jrcwo+Pj4gZmlu ZS4gIFdoZW4gdGhlIHJvYW1pbmcgcHJvZmlsZSBpcyBzdG9yZWQgaW4gQUZTIHRoaXMgaXMgZ29p bmcgdG8gY2F1c2UKPj4+IHByb2JsZW1zIGJlY2F1c2UgYXQgbG9nb3V0IGFuIGVycm9yIHdpbGwg YmUgZ2VuZXJhdGVkIHdoZW4gYXR0ZW1wdHMgYXJlCj4+PiBtYWRlIHRvIGNvcHkgdGhpcyBuZXcg cmVwYXJzZSBwb2ludCB0byBBRlMuCj4+Pgo+Pj4gSSB1cmdlIG9yZ2FuaXphdGlvbnMgdG8gYmVn aW4gdGVzdGluZyBXaW5kb3dzIDguMSBQcmV2aWV3IGltbWVkaWF0ZWx5Cj4+PiBhbmQgdG8gZmls ZSBidWcgcmVwb3J0cyB3aXRoIE1pY3Jvc29mdCBhcyBzb29uIGFzIHBvc3NpYmxlLiAgVGhpcyBp cyBhCj4+PiBmZWF0dXJlIHRoYXQgd2lsbCBub3QgYmUgYWx0ZXJlZCBvbmNlIFdpbmRvd3MgOC4x IFJUTSBpcyBjdXQuICAgSXQgaXMKPj4+IGNyaXRpY2FsIHRoYXQgTWljcm9zb2Z0IGhlYXIgYWJv dXQgaXNzdWVzIHRoYXQgd2lsbCBlZmZlY3QgdGhlaXIKPj4+IGN1c3RvbWVycyB3aGlsZSB0aGVy ZSBpcyB0aW1lIHRvIG1ha2UgYWRqdXN0bWVudHMuCj4+Pgo+Pj4gSmVmZnJleSBBbHRtYW4KPj4+ Cj4+IAo+PiAKPj4gCj4K From l.schimmer@cgv.tugraz.at Tue Jul 9 09:43:35 2013 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Tue, 09 Jul 2013 10:43:35 +0200 Subject: [OpenAFS] OpenAFS EU confernece 2013? Message-ID: <51DBCD37.1050604@cgv.tugraz.at> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EIOJRDPEMAHAWCAJPFNH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Moin! As I already got no information yet: Is a European conference on OpenAFS 2013 in schedule or not? Thank you. MfG, Lars Schimmer --=20 ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ------enig2EIOJRDPEMAHAWCAJPFNH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHbzTcACgkQmWhuE0qbFyOIjACeOuP1yeVZcAGjGC45wWsoSZnc xt8AoITswXFy0+nz3m5ulsmHPacP0T5E =jkF2 -----END PGP SIGNATURE----- ------enig2EIOJRDPEMAHAWCAJPFNH-- From jaltman@your-file-system.com Tue Jul 9 12:21:00 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Tue, 09 Jul 2013 07:21:00 -0400 Subject: [OpenAFS] OpenAFS EU confernece 2013? In-Reply-To: <51DBCD37.1050604@cgv.tugraz.at> References: <51DBCD37.1050604@cgv.tugraz.at> Message-ID: <51DBF21C.4020703@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms050608050003070605010505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/9/2013 4:43 AM, Lars Schimmer wrote: > Moin! >=20 > As I already got no information yet: > Is a European conference on OpenAFS 2013 in schedule or not? >=20 > Thank you. >=20 > MfG, > Lars Schimmer At the present time there is no conference scheduled for 2013. There are tentative plans to hold one in Europe in the Spring. The potential hosts have yet to obtain approvals from management. Jeffrey Altman --------------ms050608050003070605010505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzA5MTEyMTAwWjAjBgkqhkiG9w0BCQQxFgQUInjLGSao57hYVyOQiFc6p0HCZXkwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AAmB+2QcxgPdPR3l6Gybm6NWXWJtVnVwToNiy0iVYNVwwfYwzjtpGB/p/aJshZ5RJCP391P4 IMIn38xP0320ANFykIBjXz2++/ucSREGwKVyNAm9FK808MCyE/ifR9K0anaTiKhN2JsiWxMP Tw3cO0BdNwwrJmdKa1UXLWEpEkHO7JUD8orAXDoXigrbTw7fzo5yO5M4kpd/A6o+BuwPTIqc gpwdSHR6RoJkbpXmwFuJDPiyVyrgv0BfmnNzkbmPVtU5x0LrvWsgI5/aFwJQl2xN1xqvc9mM 9rdPKtf+zelY2IDH83/FmGo8xmL1BCpk8jMcdiXApplyZEI5yaCVReEAAAAAAAA= --------------ms050608050003070605010505-- From timothy@telmate.com Wed Jul 10 00:17:44 2013 From: timothy@telmate.com (Timothy Balcer) Date: Tue, 9 Jul 2013 16:17:44 -0700 Subject: [OpenAFS] Re: Client Cache Question In-Reply-To: <20130628181526.e5f9e38e.adeason@sinenomine.net> References: <20130624153909.108d5b74.adeason@sinenomine.net> <20130625141435.8497be19.adeason@sinenomine.net> <20130625155905.82eeeb0f.adeason@sinenomine.net> <20130628181526.e5f9e38e.adeason@sinenomine.net> Message-ID: --001a11c2b80e531c3e04e11c5e6a Content-Type: text/plain; charset=ISO-8859-1 FYI folks, after some offline discussion and clarification on interesting developments in AFS, I've regressed this and I am bulk transferring to an rsync module pointed right on top of the AFS client running on the fileserver itself. This gives me almost rsync native speeds for bulk transfers to AFS. It breaks security, of course. But for performance purposes, and on a private VLAN, it serves my purpose well. On Fri, Jun 28, 2013 at 4:15 PM, Andrew Deason wrote: > On Fri, 28 Jun 2013 12:29:38 -0700 > Timothy Balcer wrote: > > > On another VM in the same local colo, I am seeing an order of > > magnitude (20 - 35 minutes vs 2-3 minutes) longer transfers of even > > large single files (900M file in this case, on a cache of 500M). > > Strace on a simple 'cat' redirect from a local disk into AFS shows > > blocking on a write: > > I'm not sure if I'm following this entirely; you're getting an order of > magnitude slower when cat'ing to /afs compared to... scp? > > I thought before you were just trying to see why performance was varying > so wildly and due to different parameters; if you're just asking why the > client is performing so slowly compared to non-AFS methods, from the > numbers above I don't think there's any configuration you can do you > change that. > > If you have a consistent RTT of 64ms, the maximum theoretical throughput > you'll get from an AFS transfer with the code you're running is less > than 700 KiB/s if I did my math right (32 * ~1400bytes / .064s). > Additionally, any individual new file will take at least 128-192ms each > (1 RTT for creating the file, 1 RTT for sending data, and possibly 1 > more RTT for changing file status). Note that those are theoretical > limits; that is, if the client and server run infinitely fast. From the > numbers above, it looks like they fall within the normal range. > > AFS network communication is currently very heavily affected by network > latency. Anything with TCP is going to appear much faster beacuse the > TCP window sizes will be huge, relatively speaking. Any performance > benchmarking with UDP is going to appear much faster because it doesn't > need to keep track of data windows, or it uses a different protocol on > top of UDP that uses a much larger window. > > Does that clear up any confusion you may have had through all of this? > AFS' poor high-latency network performance has been known for a while; > there are / have been a few efforts to improve it, one of which I'm > working on right now. I can talk more about that, but if this stuff > isn't what you were asking about, then nevermind :) > > -- > Andrew Deason > adeason@sinenomine.net > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Timothy Balcer / IT Services Telmate / San Francisco, CA Direct / (415) 300-4313 Customer Service / (800) 205-5510 --001a11c2b80e531c3e04e11c5e6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI folks,=A0 after some offline discussion and clari= fication on interesting developments in AFS, I've regressed this and I = am bulk transferring to an rsync module pointed right on top of the AFS cli= ent running on the fileserver itself.

This gives me almost rsync native speeds for bulk transfers to AF= S. It breaks security, of course. But for performance purposes, and on a pr= ivate VLAN, it serves my purpose well.


On Fri, Jun 28, 2013 at 4:15 PM, Andrew = Deason <adeason@sinenomine.net> wrote:
On Fri, 28 Jun 2013 12:29:38 -0700
Timothy Balcer <timothy@telmate.c= om> wrote:

> On another VM in the same local colo, I am seeing an order of
> magnitude (20 - 35 minutes vs 2-3 minutes) longer transfers of even > large single files (900M file in this case, on a cache of 500M).
> Strace on a simple 'cat' redirect from a local disk into AFS s= hows
> blocking on a write:

I'm not sure if I'm following this entirely; you're getti= ng an order of
magnitude slower when cat'ing to /afs compared to... scp?

I thought before you were just trying to see why performance was varying so wildly and due to different parameters; if you're just asking why th= e
client is performing so slowly compared to non-AFS methods, from the
numbers above I don't think there's any configuration you can do yo= u
change that.

If you have a consistent RTT of 64ms, the maximum theoretical throughput you'll get from an AFS transfer with the code you're running is les= s
than 700 KiB/s if I did my math right (32 * ~1400bytes / .064s).
Additionally, any individual new file will take at least 128-192ms each
(1 RTT for creating the file, 1 RTT for sending data, and possibly 1
more RTT for changing file status). Note that those are theoretical
limits; that is, if the client and server run infinitely fast. From the
numbers above, it looks like they fall within the normal range.

AFS network communication is currently very heavily affected by network
latency. Anything with TCP is going to appear much faster beacuse the
TCP window sizes will be huge, relatively speaking. Any performance
benchmarking with UDP is going to appear much faster because it doesn't=
need to keep track of data windows, or it uses a different protocol on
top of UDP that uses a much larger window.

Does that clear up any confusion you may have had through all of this?
AFS' poor high-latency network performance has been known for a while;<= br> there are / have been a few efforts to improve it, one of which I'm
working on right now. I can talk more about that, but if this stuff
isn't what you were asking about, then nevermind :)

--
Andrew Deason
adeason@sinenomine.net

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info



--
Timothy Balcer / IT Services
Telmate / San Fr= ancisco, CA
Direct / (415) 300-4313
Customer Service /=A0(800) 205-5510
--001a11c2b80e531c3e04e11c5e6a-- From ralf.brunckhorst@hp.com Wed Jul 10 13:38:19 2013 From: ralf.brunckhorst@hp.com (Brunckhorst, Ralf) Date: Wed, 10 Jul 2013 12:38:19 +0000 Subject: [OpenAFS] DAFS dasalvager: cannot be running from cron In-Reply-To: <20130708113841.dc4dbf09.adeason@sinenomine.net> References: <20130708113841.dc4dbf09.adeason@sinenomine.net> Message-ID: --_000_E3A882F104F6304D89C62FB119B729800FCCEA2FG5W2743americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for this detailed explanation. So I have some follow-up question. Is salvaging of volumes needed afterwards in the following scenarios? * vos dump -id UNTAG-volume.readonly -time 0 -server SERVER -partition PAR= T | vos restore -server SERVER -partition PART -name TAG-volume -overwrite = incremental * vos dump -id UNTAG-volume.readonly -time 0 -server SERVER -partition PA= RT | dump-scan_mp | vos restore -server SERVER -partition PART -name TAG-vo= lume -overwrite full We are using this 'strange' workflow to have a workaround for the limit in = openafs of having not more than 11 RO-replicas. The dump-scan_mp in the pipe is used to change Volumes that have mounpoints= inside and change those mounpoints so that the point to TAG-volumes. /Ralf Am 08.07.2013 um 18:38 schrieb Andrew Deason >: On Mon, 8 Jul 2013 08:14:29 +0000 "Brunckhorst, Ralf" > wrote: Is there any chance to get this also running via cron? Short answer: dasalvager is apparently unsafe for single-volume salvages; avoid it for now if you can. Running 'salvageserver -client' is another way to manually salvage a single volume, which does not have this problem. Longer answer: This is a bug in dasalvager where it is not initializing the structure properly for locking volumes on disk. So, it thinks it has fd 0 already open for locking, and tries to use that fd without opening the proper file. When you run under a terminal, it uses whatever happens to be fd 0 (this is obviously not safe/correct). When you run under cron (or 'at' or probably a number of other things), fd 0 happens to be closed, so we fail. It is very fortunate that it does fail, because otherwise I don't know when we would have discovered this. Because of all of that, even when dasalvager seems to be running along fine, it is not accessing volumes in a safe manner (this is a bug; the same bug). So, in certain edge cases, it would be possible for dasalvager to cause corruption of volumes. While I haven't completely thought through the scenarios, I believe this would only cause whole volumes to become unusable due to volume metadata problems; it wouldn't corrupt data inside volumes or anything like that. If you don't care, or if this server is relatively inactive or is otherwise low-risk for some reason, you could work around this by forcing fd 0 to be open when you run dasalvager from cron. Obviously, I don't really recommend that, but it should be possible. What would probably be better is if you don't use dasalvager for single-volume salvages at all until we can get this fixed. If you must manually cause a single-volume salvage, you can run 'salvageserver -client' instead of dasalvager, which uses the same code paths as demand-salvages. >From a developer perspective: This is due to the DAFS_FS / DAFS_UTIL mess; all of the DAFS stuff in partition.c should be for _UTIL or _FS instead of just _FS. I started going through fixing them, but there are so many cases that seem to need fixing (e.g. all vutil.c references), and it's becoming clear that the current scheme is becoming increasingly... ridiculously cumbersome and error-prone. I can think of a few possible ways of improving this: - Make DAFS_FS imply DAFS_UTIL. We still have to go manually fix all of the instances to see if they really are _FS or should be _UTIL, but at least it's less verbose. - Remove DAFS_UTIL, make all DAFS utilities use DAFS_FS, and fix existing code to handle the non-pthread DAFS_FS case. - Just use DAFS_FS everywhere and make all DAFS utilities pthreaded, reducing the number of different codepaths. Is there any reason we were avoiding this? It's not like we need LWP DAFS, and any further granularity of "what type of program is running" should be handled at runtime by programType anyway. I'll probably try the latter and see if it's more work than I thought or if I forgot about some big blocker issue for that. Just mentioning options here if anyone has opinions on it. -- Andrew Deason adeason@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info --_000_E3A882F104F6304D89C62FB119B729800FCCEA2FG5W2743americas_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Thanks for this detailed explanation.

 

So I have some follow-up question.

 

Is salvaging of volumes needed afterwards in the fol= lowing scenarios?

 

 * vos dump –id UNTAG-volume.readonly = 211;time 0 –server SERVER –partition PART | vos restore –= server SERVER –partition PART –name TAG-volume –overwrite= incremental

 

 * vos dump –id UNTAG-volume.readonly &nb= sp;–time 0 –server SERVER –partition PART | dump-scan_mp = | vos restore –server SERVER –partition PART –name TAG-vo= lume –overwrite full

 

We are using this ‘strange’ workflow to = have a workaround for the limit in openafs of having not more than 11 RO-re= plicas.

The dump-scan_mp in the pipe is used to change Volum= es that have mounpoints inside and change those mounpoints so that the poin= t to TAG-volumes.

 

/Ralf

 

 

Am 08.07.2013 um 18:38 schrieb Andrew Deason <adeason@sinenomine.net>:=



On Mon, 8 Jul 2013 08:14:29 +0000
"Brunckhorst, Ralf" <ralf.brunckhorst@hp.com> wrote:


Is there any chance to get this also running via cro= n?


Short answer: dasalvager is apparently unsafe for single-volume
salvages; avoid it for now if you can. Running 'salvageserver -client'
is another way to manually salvage a single volume, which does not have
this problem.

Longer answer:

This is a bug in dasalvager where it is not initializing the structure
properly for locking volumes on disk. So, it thinks it has fd 0 already
open for locking, and tries to use that fd without opening the proper
file. When you run under a terminal, it uses whatever happens to be fd 0 (this is obviously not safe/correct). When you run under cron (or 'at'
or probably a number of other things), fd 0 happens to be closed, so we
fail. It is very fortunate that it does fail, because otherwise I don't
know when we would have discovered this.

Because of all of that, even when dasalvager seems to be running along
fine, it is not accessing volumes in a safe manner (this is a bug; the
same bug). So, in certain edge cases, it would be possible for
dasalvager to cause corruption of volumes. While I haven't completely
thought through the scenarios, I believe this would only cause whole
volumes to become unusable due to volume metadata problems; it wouldn't
corrupt data inside volumes or anything like that. If you don't care, or if this server is relatively inactive or is otherwise low-risk for some
reason, you could work around this by forcing fd 0 to be open when you
run dasalvager from cron. Obviously, I don't really recommend that, but
it should be possible.

What would probably be better is if you don't use dasalvager for
single-volume salvages at all until we can get this fixed. If you must
manually cause a single-volume salvage, you can run 'salvageserver
-client' instead of dasalvager, which uses the same code paths as
demand-salvages.

>From a developer perspective:

This is due to the DAFS_FS / DAFS_UTIL mess; all of the DAFS stuff in
partition.c should be for _UTIL or _FS instead of just _FS. I started
going through fixing them, but there are so many cases that seem to need fixing (e.g. all vutil.c references), and it's becoming clear that the
current scheme is becoming increasingly... ridiculously cumbersome and
error-prone. I can think of a few possible ways of improving this:

- Make DAFS_FS imply DAFS_UTIL. We still have to go manually fix all of
  the instances to see if they really are _FS or should be _UTIL,= but
  at least it's less verbose.

- Remove DAFS_UTIL, make all DAFS utilities use DAFS_FS, and fix
  existing code to handle the non-pthread DAFS_FS case.

- Just use DAFS_FS everywhere and make all DAFS utilities pthreaded,
  reducing the number of different codepaths. Is there any reason= we
  were avoiding this? It's not like we need LWP DAFS, and any fur= ther
  granularity of "what type of program is running" shou= ld be handled at
  runtime by programType anyway.

I'll probably try the latter and see if it's more work than I thought or if I forgot about some big blocker issue for that. Just mentioning
options here if anyone has opinions on it.

--
Andrew Deason
adeason@sinenomine.net

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org https:/= /lists.openafs.org/mailman/listinfo/openafs-info

 

--_000_E3A882F104F6304D89C62FB119B729800FCCEA2FG5W2743americas_-- From adeason@sinenomine.net Wed Jul 10 15:40:46 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 10 Jul 2013 09:40:46 -0500 Subject: [OpenAFS] Re: DAFS dasalvager: cannot be running from cron References: <20130708113841.dc4dbf09.adeason@sinenomine.net> Message-ID: <20130710094046.335441a3.adeason@sinenomine.net> On Wed, 10 Jul 2013 12:38:19 +0000 "Brunckhorst, Ralf" wrote: > Is salvaging of volumes needed afterwards in the following scenarios? > > * vos dump -id UNTAG-volume.readonly -time 0 -server SERVER -partition PART | vos restore -server SERVER -partition PART -name TAG-volume -overwrite incremental > > * vos dump -id UNTAG-volume.readonly -time 0 -server SERVER -partition PART | dump-scan_mp | vos restore -server SERVER -partition PART -name TAG-volume -overwrite full No, you shouldn't need to do that. (Are you sure you don't mean "-overwrite full" in the first example, though?) If you need to salvage after a simple restore, that's probably an issue we need to fix. > We are using this 'strange' workflow to have a workaround for the > limit in openafs of having not more than 11 RO-replicas. It may be easier to use different cells for that (then you can keep the same volume name, and possibly volume id, though the latter might be confusing). If you don't want to duplicate the entire contents of the cell, you can make a cell a kind of "overlay" over an existing cell by using a feature called "linked cells". I can go further into that if you want; I just wanted to mention it. -- Andrew Deason adeason@sinenomine.net From botsch@cnf.cornell.edu Wed Jul 10 21:19:30 2013 From: botsch@cnf.cornell.edu (Dave Botsch) Date: Wed, 10 Jul 2013 16:19:30 -0400 Subject: [OpenAFS] Windows 8.1, SkyDrive and Roaming Profiles In-Reply-To: <51DAFE1E.60701@secure-endpoints.com> References: <51CF06D7.5060401@your-file-system.com> <20130708173813.GT6639@cnf.cornell.edu> <51DAFE1E.60701@secure-endpoints.com> Message-ID: <20130710201930.GI6639@cnf.cornell.edu> It looks like Windows 8.1 still stores Roaming Profiles in C:\users\username\AppData\Roaming ... which is different than C:\users\SkyDrive ... So, are you referring to somehow making the whole C:\Users\username the "roaming" profile, which would then include the SkyDrive folder? Or are you referring to some sort of way to do a "folder redirection" of the entire home folder into AFS? Thanks. On Mon, Jul 08, 2013 at 01:59:58PM -0400, Jeffrey Altman wrote: > Configure 8.1 to use roaming profiles and produce a situation in > which SkyDrive has synchronized the directory structure but not > the contents and files. Then logout and let the SkyDrive folder > in the user profile be written back to AFS. > > On 7/8/2013 1:38 PM, Dave Botsch wrote: > > Being somewhat unfamiliar with Windows 8 / 8.1... > > > > what are the suggested steps for recreating the conditions to replicate > > the failure? I've got a skydrive login setup, so, now what? > > > > thanks. > > > > On Sat, Jun 29, 2013 at 12:09:59PM -0400, Jeffrey Altman wrote: > >> Last Wednesday Microsoft released the one and only preview release of > >> Windows 8.1 in conjunction with the Microsoft Build conference which I > >> attended. The one big change relating to file systems is the > >> integration of SkyDrive into the Shell and its selection as the primary > >> storage location for end user documents. > >> > >> The SkyDrive integration adds shell recognition for files that are > >> located in the locally sync'd copy of the SkyDrive directory tree but > >> which have not been copied locally. Microsoft now represents these > >> files with a new Reparse Point (Tag: 0x80000015) which is a "sparse > >> file" and an "offline" file. The file will not be visible to > >> applications that browse the directory from the command line but will be > >> displayed in the Explorer Shell and Modern application views of the > >> SkyDrive directory. > >> > >> The SkyDrive folder tree is stored in the user's profile at > >> \Users\\SkyDrive. When the profile is on NTFS this works > >> fine. When the roaming profile is stored in AFS this is going to cause > >> problems because at logout an error will be generated when attempts are > >> made to copy this new reparse point to AFS. > >> > >> I urge organizations to begin testing Windows 8.1 Preview immediately > >> and to file bug reports with Microsoft as soon as possible. This is a > >> feature that will not be altered once Windows 8.1 RTM is cut. It is > >> critical that Microsoft hear about issues that will effect their > >> customers while there is time to make adjustments. > >> > >> Jeffrey Altman > >> > > > > > > > -- ******************************** David William Botsch Programmer/Analyst CNF Computing botsch@cnf.cornell.edu ******************************** From ralf.brunckhorst@hp.com Wed Jul 17 10:31:58 2013 From: ralf.brunckhorst@hp.com (Brunckhorst, Ralf) Date: Wed, 17 Jul 2013 09:31:58 +0000 Subject: [OpenAFS] Re: DAFS dasalvager: cannot be running from cron In-Reply-To: <20130710094046.335441a3.adeason@sinenomine.net> References: <20130708113841.dc4dbf09.adeason@sinenomine.net> <20130710094046.335441a3.adeason@sinenomine.net> Message-ID: Hi Andrew, We are using the restore incremental function in the first example to have = only a delta-release when it comes to releasing the TAG-volume. If the TAG volume doesn't exist, it will be created and vos restore switch = automatically to full. It would be great to hear more about alternatives like you mentioned below. /Ralf -----Original Message----- From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org= ] On Behalf Of Andrew Deason Sent: Wednesday, July 10, 2013 4:41 PM To: openafs-info@openafs.org Subject: [OpenAFS] Re: DAFS dasalvager: cannot be running from cron On Wed, 10 Jul 2013 12:38:19 +0000 "Brunckhorst, Ralf" wrote: > Is salvaging of volumes needed afterwards in the following scenarios? >=20 > * vos dump -id UNTAG-volume.readonly -time 0 -server SERVER=20 > -partition PART | vos restore -server SERVER -partition PART -name=20 > TAG-volume -overwrite incremental >=20 > * vos dump -id UNTAG-volume.readonly -time 0 -server SERVER=20 > -partition PART | dump-scan_mp | vos restore -server SERVER -partition=20 > PART -name TAG-volume -overwrite full No, you shouldn't need to do that. (Are you sure you don't mean "-overwrite= full" in the first example, though?) If you need to salvage after a simple= restore, that's probably an issue we need to fix. > We are using this 'strange' workflow to have a workaround for the=20 > limit in openafs of having not more than 11 RO-replicas. It may be easier to use different cells for that (then you can keep the sam= e volume name, and possibly volume id, though the latter might be confusing= ). If you don't want to duplicate the entire contents of the cell, you can = make a cell a kind of "overlay" over an existing cell by using a feature ca= lled "linked cells". I can go further into that if you want; I just wanted = to mention it. -- Andrew Deason adeason@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From ciprian.craciun@gmail.com Wed Jul 17 15:43:12 2013 From: ciprian.craciun@gmail.com (Ciprian Dorin Craciun) Date: Wed, 17 Jul 2013 17:43:12 +0300 Subject: [OpenAFS] Multi-homed server and NAT-ed client issues Message-ID: Hello all! I've encountered quite a blocking issue in my OpenAFS setup... I hope someone is able to help me... :) The setup is as follows: * multi-homed server with, say S-IP-1 (i.e. x.x.x.5) and S-IP-2 (i.e. x.x.x.7), multiple IP addresses, all from the public range; * the second IP, S-IP-2 (i.e. x.x.x.7), is the one listed in `NetInfo` and DNS record (and correctly listed when queried via `vos listaddrs`); * the first IP, S-IP-1 (i.e. x.x.x.5), is listed in `NetRestricted` (and doesn't appear in `vos listaddrs`); * NAT-ed client (no multi-home on the client side); The actual problem is: * the client sends the authentication request to S-IP-2; * the client's router source-NAT's the IP to its own public IP, and adds the UDP "connection" with S-IP-2 as the other peer to its conntrack table; * the server receives the request on S-IP-2; * !!! however it replies from S-IP-1 (i.e. x.x.x.5) !!! (probably because the UDP socket is bound on `0.0.0.0`...) * the client's router receives the packet and can't find it in its conntrack table (because it expects the packet to come from S-IP-2); As a note everything works perfect with non-NAT-ed clients. Moreover on these public-IP-ed clients, I can clearly see via `tcpdump` that outgoing packets go towards S-IP-2, but the replies come from S-IP-1. (The same asymmetry is visible also on the server.) Thus my question is how can I resolve such an issue? I must say I've tried to `iptables -j SNAT ...` outgoing packets to the right S-IP-2, however this doesn't work because SNAT also changes the source port. I've also tried to `-j NETMAP` these packets, but it doesn't work because NETMAP in the `OUTPUT` or `POSTROUTING` tables actually touch the destination... Thus if someone knows of an `iptables`... Thanks, Ciprian. From shadow@gmail.com Wed Jul 17 16:09:08 2013 From: shadow@gmail.com (Derrick Brashear) Date: Wed, 17 Jul 2013 11:09:08 -0400 Subject: [OpenAFS] Multi-homed server and NAT-ed client issues In-Reply-To: References: Message-ID: --047d7b2e3e10addd2b04e1b6798d Content-Type: text/plain; charset=ISO-8859-1 bind openafs to S-IP-2; all the servers include the -rxbind option, and if exactly one IP address is available after you apply NetInfo and NetRestrict, it will do what you want. On Wed, Jul 17, 2013 at 10:43 AM, Ciprian Dorin Craciun < ciprian.craciun@gmail.com> wrote: > Hello all! I've encountered quite a blocking issue in my OpenAFS > setup... I hope someone is able to help me... :) > > > The setup is as follows: > * multi-homed server with, say S-IP-1 (i.e. x.x.x.5) and S-IP-2 > (i.e. x.x.x.7), multiple IP addresses, all from the public range; > * the second IP, S-IP-2 (i.e. x.x.x.7), is the one listed in > `NetInfo` and DNS record (and correctly listed when queried via `vos > listaddrs`); > * the first IP, S-IP-1 (i.e. x.x.x.5), is listed in > `NetRestricted` (and doesn't appear in `vos listaddrs`); > * NAT-ed client (no multi-home on the client side); > > The actual problem is: > * the client sends the authentication request to S-IP-2; > * the client's router source-NAT's the IP to its own public IP, > and adds the UDP "connection" with S-IP-2 as the other peer to its > conntrack table; > * the server receives the request on S-IP-2; > * !!! however it replies from S-IP-1 (i.e. x.x.x.5) !!! (probably > because the UDP socket is bound on `0.0.0.0`...) > * the client's router receives the packet and can't find it in its > conntrack table (because it expects the packet to come from S-IP-2); > > As a note everything works perfect with non-NAT-ed clients. > Moreover on these public-IP-ed clients, I can clearly see via > `tcpdump` that outgoing packets go towards S-IP-2, but the replies > come from S-IP-1. (The same asymmetry is visible also on the server.) > > > Thus my question is how can I resolve such an issue? > > > I must say I've tried to `iptables -j SNAT ...` outgoing packets > to the right S-IP-2, however this doesn't work because SNAT also > changes the source port. I've also tried to `-j NETMAP` these > packets, but it doesn't work because NETMAP in the `OUTPUT` or > `POSTROUTING` tables actually touch the destination... Thus if > someone knows of an `iptables`... > > Thanks, > Ciprian. > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > -- Derrick --047d7b2e3e10addd2b04e1b6798d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
bind openafs to S-IP-2; all the servers include the -rxbin= d option, and if exactly one IP address is available after you apply NetInf= o and NetRestrict, it will do what you want.


On Wed, Jul 17, 2013 at 10:43 AM, Cipria= n Dorin Craciun <ciprian.craciun@gmail.com> wrote:
=A0 =A0 Hello all! =A0I've encountered quite a blocking issue in my Ope= nAFS
setup... =A0I hope someone is able to help me... :)


=A0 =A0 The setup is as follows:
=A0 =A0 * multi-homed server with, say S-IP-1 (i.e. x.x.x.5) and S-IP-2
(i.e. x.x.x.7), multiple IP addresses, all from the public range;
=A0 =A0 * the second IP, S-IP-2 (i.e. x.x.x.7), is the one listed in
`NetInfo` and DNS record (and correctly listed when queried via `vos
listaddrs`);
=A0 =A0 * the first IP, S-IP-1 (i.e. x.x.x.5), is listed in
`NetRestricted` (and doesn't appear in `vos listaddrs`);
=A0 =A0 * NAT-ed client (no multi-home on the client side);

=A0 =A0 The actual problem is:
=A0 =A0 * the client sends the authentication request to S-IP-2;
=A0 =A0 * the client's router source-NAT's the IP to its own public= IP,
and adds the UDP "connection" with S-IP-2 as the other peer to it= s
conntrack table;
=A0 =A0 * the server receives the request on S-IP-2;
=A0 =A0 * !!! however it replies from S-IP-1 (i.e. x.x.x.5) !!! =A0(probabl= y
because the UDP socket is bound on `0.0.0.0`...)
=A0 =A0 * the client's router receives the packet and can't find it= in its
conntrack table (because it expects the packet to come from S-IP-2);

=A0 =A0 As a note everything works perfect with non-NAT-ed clients.
Moreover on these public-IP-ed clients, I can clearly see via
`tcpdump` that outgoing packets go towards S-IP-2, but the replies
come from S-IP-1. =A0(The same asymmetry is visible also on the server.)

=A0 =A0 Thus my question is how can I resolve such an issue?


=A0 =A0 I must say I've tried to `iptables -j SNAT ...` outgoing packet= s
to the right S-IP-2, however this doesn't work because SNAT also
changes the source port. =A0I've also tried to `-j NETMAP` these
packets, but it doesn't work because NETMAP in the `OUTPUT` or
`POSTROUTING` tables actually touch the destination... =A0Thus if
someone knows of an `iptables`...

=A0 =A0 Thanks,
=A0 =A0 Ciprian.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info




--
Derrick
--047d7b2e3e10addd2b04e1b6798d-- From jhutz@cmu.edu Wed Jul 17 16:28:26 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 17 Jul 2013 11:28:26 -0400 Subject: [OpenAFS] Multi-homed server and NAT-ed client issues In-Reply-To: References: Message-ID: <1374074906.23381.58.camel@destiny.pc.cs.cmu.edu> On Wed, 2013-07-17 at 17:43 +0300, Ciprian Dorin Craciun wrote: > Hello all! I've encountered quite a blocking issue in my OpenAFS > setup... I hope someone is able to help me... :) > > > The setup is as follows: > * multi-homed server with, say S-IP-1 (i.e. x.x.x.5) and S-IP-2 > (i.e. x.x.x.7), multiple IP addresses, all from the public range; Things get much easier if you just use the actual names and addresses, instead of making up placeholders. Frequently, doing that sort of thing hides critical information that may point to the source of the problem. For example, in this case, Linux's choice of source IP address on an outgoing UDP packet sent from an unbound socket (or one bound to INADDR_ANY) will depend on the interface it chooses, which will depend on the route taken, which depends on the server's actual addresses and the network topology, particularly with respect to the client (or in this case, to the public address of the NAT the client is behind). You also haven't said what version of OpenAFS you're using, so I'll assume it's some relatively recent 1.6.x. > * the second IP, S-IP-2 (i.e. x.x.x.7), is the one listed in > `NetInfo` and DNS record (and correctly listed when queried via `vos > listaddrs`); > * the first IP, S-IP-1 (i.e. x.x.x.5), is listed in > `NetRestricted` (and doesn't appear in `vos listaddrs`); So, the machine the fileserver runs on is multi-homed, but you're only interested in actually using one of those interfaces to provide AFS service? In that case, you use the -rxbind option, which tells the servers to bind to a specific address instead of INADDR_ANY. That option needs to be passed to each server process for which you want that behavior. > Thus my question is how can I resolve such an issue? Besides -rxbind, there are a couple of other options, depending on which components you control. For example, if the NAT is your home router and you only have one or two AFS clients behind it, you can assign those clients static addresses on your inside network, and then configure your router to remap the client-side addresses on both inbound and outbound traffic, mapping each inside host's port 7001 to a different outside port. For example, my router (running OpenWRT) installs the following rules: ### Static ports for AFS for i in `seq 50 249` ; do iptables -t nat -A prerouting_wan -p udp --dport $((7000+$i)) \ -j DNAT --to 192.168.202.${i}:7001 iptables -t nat -A postrouting_rule -o $WAN -p udp -s 192.168.202.$i --sport 7001 -j MASQUERADE --to-ports $((7000+$i)) done iptables -A forwarding_wan -p udp --dport 7001 -j ACCEPT (in OpenWRT's default configuration, the 'forwarding_wan' and 'prerouting_wan' chains get called from the FORWARD and nat PREROUTING chains, respectively, for traffic originating from the internet. The 'postrouting_rule' chain gets called from the nat POSTROUTING chain for all traffic). So, when 192.168.202.142 sends traffic to a fileserver from port 7001, it comes from the routers port 7142. And inbound traffic to that port gets sent back to 192.168.202.142 port 7001, regardless of where on the Internet it came from or whether the router knows about the connection. As you can see, I do this for a range of 200 addresses, which are the ones my DHCP server hands out -- anyone who visits my house gets working AFS, without keepalives, and even when talking to a multihomed server. > > I must say I've tried to `iptables -j SNAT ...` outgoing packets > to the right S-IP-2, however this doesn't work because SNAT also > changes the source port. I've also tried to `-j NETMAP` these > packets, but it doesn't work because NETMAP in the `OUTPUT` or > `POSTROUTING` tables actually touch the destination... Thus if > someone knows of an `iptables`... Well, you can give SNAT a specific port to use. Or, you can play games with routing tables to give AFS traffic a routing table that doesn't include the second interface. But that's functionally equivalent to using -rxbind but a lot more work. -- Jeff From ciprian.craciun@gmail.com Wed Jul 17 19:28:09 2013 From: ciprian.craciun@gmail.com (Ciprian Dorin Craciun) Date: Wed, 17 Jul 2013 21:28:09 +0300 Subject: [OpenAFS] Multi-homed server and NAT-ed client issues In-Reply-To: <1374074906.23381.58.camel@destiny.pc.cs.cmu.edu> References: <1374074906.23381.58.camel@destiny.pc.cs.cmu.edu> Message-ID: Problem solved! Thanks to both posters for pointing me to the right direction: adding the `-rxbind` option to the following services: `kaserver`, `ptserver`, `vlserver`, `fileserver`, and `volserver`. This was simply done by editing the `BosConfig` file in the `/etc/openafs` folder and adding that token in the lines starting with `parm`. (I must confess I feel quite dump for not finding this option myself... I must say I did add it to the `bosserver` invocation but didn't seem to work. I should have added it to each individual service.) However a note for the documentation maintainers it seems that the `-rxbind` option is missing from the manuals of the following services (at least in the HTML version on http://docs.openafs.org ): `kaserver` and `volserver`. About the words that follow bellow, because they were written while I was reading the replies, I'll leave them there, for those that one day will have similar issues with multi-homed servers. On Wed, Jul 17, 2013 at 6:28 PM, Jeffrey Hutzelman wrote: > On Wed, 2013-07-17 at 17:43 +0300, Ciprian Dorin Craciun wrote: >> Hello all! I've encountered quite a blocking issue in my OpenAFS >> setup... I hope someone is able to help me... :) >> >> >> The setup is as follows: >> * multi-homed server with, say S-IP-1 (i.e. x.x.x.5) and S-IP-2 >> (i.e. x.x.x.7), multiple IP addresses, all from the public range; > > Things get much easier if you just use the actual names and addresses, > instead of making up placeholders. Indeed it could seem that I've obscured the situation by providing placeholders for the actual IP's. (The reason revolves mainly around the fact that all these emails are public knowledge.) However the values I've chosen as placeholders have been carefully selected: * both are addresses for the same interface (configured with `ip addr add ...`, thus not with alias interfaces like Debian once had); * both are addresses from the same network (thus are routed identically); * the second IP (the one OpenAFS should use) is marked as `secondary` by `ip addr show`; Below is the output of `ip -4 addr show ethX` (blanking only the interface name and the network address): ~~~~ ethX: mtu 1500 qdisc noqueue state UP inet x.x.x.5/27 brd x.x.x.31 scope global ethX inet x.x.x.7/27 brd x.x.x.31 scope global secondary ethX ~~~~ And the output of `ip -4 route show`: ~~~~ x.x.x.0/27 dev ethX proto kernel scope link src x.x.x.5 127.0.0.0/8 via 127.0.0.1 dev lo default via x.x.x.1 dev ethX ~~~~ The full output of both `ip addr` and `ip route` includes a few more bridges and interfaces. However none share the same IP range with the addresses above, there are no other default routes except the one above, and moreover the OpenAFS clients aren't on any of the "extra" networks (i.e. the packets to them should go through the default route above). > Frequently, doing that sort of thing > hides critical information that may point to the source of the problem. I hope that the details above are sufficient to depict the overall context. > For example, in this case, Linux's choice of source IP address on an > outgoing UDP packet sent from an unbound socket (or one bound to > INADDR_ANY) will depend on the interface it chooses, which will depend > on the route taken, which depends on the server's actual addresses and > the network topology, particularly with respect to the client (or in > this case, to the public address of the NAT the client is behind). As said, the reply packet leaves the server with the source set as the first IP (x.x.x.5). And thus the behaviour is consistent with a socket bound to `INADDR_ANY` and towards a peer that takes the default route. > You also haven't said what version of OpenAFS you're using, so I'll > assume it's some relatively recent 1.6.x. Indeed, my fault. Being hurried to leave for home, I've forgot to mention that I have Linux on both the client and server, and the OpenAFS version is 1.6.2. >> * the second IP, S-IP-2 (i.e. x.x.x.7), is the one listed in >> `NetInfo` and DNS record (and correctly listed when queried via `vos >> listaddrs`); >> * the first IP, S-IP-1 (i.e. x.x.x.5), is listed in >> `NetRestricted` (and doesn't appear in `vos listaddrs`); > > So, the machine the fileserver runs on is multi-homed, but you're only > interested in actually using one of those interfaces to provide AFS > service? Exactly the server is multi-homed and I want it to use the secondary IP address. (In fact all OpenAFS services run on exactly the same server.) > In that case, you use the -rxbind option, which tells the > servers to bind to a specific address instead of INADDR_ANY. That > option needs to be passed to each server process for which you want that > behavior. Indeed this solves the issue. Maybe this could be written in a FAQ entry or in a page dedicated to multi-homed servers (there is one only for multi-homed clients). > Besides -rxbind, there are a couple of other options, depending on which > components you control. For example, if the NAT is your home router and > you only have one or two AFS clients behind it, you can assign those > clients static addresses on your inside network, and then configure your > router to remap the client-side addresses on both inbound and outbound > traffic, mapping each inside host's port 7001 to a different outside > port. For example, my router (running OpenWRT) installs the following > rules: > > ### Static ports for AFS > for i in `seq 50 249` ; do > iptables -t nat -A prerouting_wan -p udp --dport $((7000+$i)) \ > -j DNAT --to 192.168.202.${i}:7001 > iptables -t nat -A postrouting_rule -o $WAN -p udp -s 192.168.202.$i > --sport 7001 -j MASQUERADE --to-ports $((7000+$i)) > done > iptables -A forwarding_wan -p udp --dport 7001 -j ACCEPT > > (in OpenWRT's default configuration, the 'forwarding_wan' and > 'prerouting_wan' chains get called from the FORWARD and nat PREROUTING > chains, respectively, for traffic originating from the internet. The > 'postrouting_rule' chain gets called from the nat POSTROUTING chain for > all traffic). > > So, when 192.168.202.142 sends traffic to a fileserver from port 7001, > it comes from the routers port 7142. And inbound traffic to that port > gets sent back to 192.168.202.142 port 7001, regardless of where on the > Internet it came from or whether the router knows about the connection. > As you can see, I do this for a range of 200 addresses, which are the > ones my DHCP server hands out -- anyone who visits my house gets working > AFS, without keepalives, and even when talking to a multihomed server. Interesting solution, I wouldn't have thought of that. :) And only now I've seen that there is a single inbound port involved on the client side, according to: http://wiki.openafs.org/AdminFAQ/#ports However as you mention it can be scripted only if you have "shell" access to your router, and unfortunately mine doesn't run an "open" router distribution. (It could but DD-WRT has issues with the hardware and it's instable, thus I've reverted to the Linksys firmware...) On the other side, if one can't touch the router directly but only through crippled UI's, I think all that can be achieved by using either: * using the "DMZ" (potential security hole for the client? as it'll have to manage its own firewall;) * a simple "Single Port Forwarding" of the 7001 for exactly one client; * multiple "Single Port Forwarding" for a few clients as you describe above, but also to force the clients themselves (probably via `iptables -j SNAT`) to use the new range of port when sending; >> I must say I've tried to `iptables -j SNAT ...` outgoing packets >> to the right S-IP-2, however this doesn't work because SNAT also >> changes the source port. I've also tried to `-j NETMAP` these >> packets, but it doesn't work because NETMAP in the `OUTPUT` or >> `POSTROUTING` tables actually touch the destination... Thus if >> someone knows of an `iptables`... > > Well, you can give SNAT a specific port to use. Doesn't work... If you give it a port range all it does is use that port range to remap the "original" port, thus it will always change it... > Or, you can play games > with routing tables to give AFS traffic a routing table that doesn't > include the second interface. But that's functionally equivalent to > using -rxbind but a lot more work. Yes, my colleague gave me this solution including policy routing, but it is too complicated. Thanks all for the support, Ciprian. From haba@kth.se Wed Jul 17 20:23:11 2013 From: haba@kth.se (Harald Barth) Date: Wed, 17 Jul 2013 21:23:11 +0200 (CEST) Subject: [OpenAFS] Multi-homed server and NAT-ed client issues In-Reply-To: References: <1374074906.23381.58.camel@destiny.pc.cs.cmu.edu> Message-ID: <20130717.212311.111020412384312966.haba@habanero> > services: `kaserver`, .... Please consider running a KDC (or use the KDC in your AD if you have one) instead of kaserver. kaserver is so last century. Harald. From ballbery@sinenomine.net Wed Jul 17 20:28:17 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Wed, 17 Jul 2013 19:28:17 +0000 Subject: [OpenAFS] Multi-homed server and NAT-ed client issues In-Reply-To: Message-ID: T24gNy8xNy8xMyAxNDoyOCwgIkNpcHJpYW4gRG9yaW4gQ3JhY2l1biIgPGNpcHJpYW4uY3JhY2l1 bkBnbWFpbC5jb20+DQp3cm90ZToNCj4+SW4gdGhhdCBjYXNlLCB5b3UgdXNlIHRoZSAtcnhiaW5k IG9wdGlvbiwgd2hpY2ggdGVsbHMgdGhlDQo+PiBzZXJ2ZXJzIHRvIGJpbmQgdG8gYSBzcGVjaWZp YyBhZGRyZXNzIGluc3RlYWQgb2YgSU5BRERSX0FOWS4gIFRoYXQNCj4+IG9wdGlvbiBuZWVkcyB0 byBiZSBwYXNzZWQgdG8gZWFjaCBzZXJ2ZXIgcHJvY2VzcyBmb3Igd2hpY2ggeW91IHdhbnQgdGhh dA0KPj4gYmVoYXZpb3IuDQo+DQo+ICAgIEluZGVlZCB0aGlzIHNvbHZlcyB0aGUgaXNzdWUuICBN YXliZSB0aGlzIGNvdWxkIGJlIHdyaXR0ZW4gaW4gYQ0KPkZBUSBlbnRyeSBvciBpbiBhIHBhZ2Ug ZGVkaWNhdGVkIHRvIG11bHRpLWhvbWVkIHNlcnZlcnMgKHRoZXJlIGlzIG9uZQ0KPm9ubHkgZm9y IG11bHRpLWhvbWVkIGNsaWVudHMpLg0KDQpJIGFtIHNsb3dseSBvdmVyaGF1bGluZyB0aGUgRkFR OyB0aGUgbXVsdGlob21lIHN0dWZmIGluIEFkbWluRkFRIEkgdXBkYXRlZA0KbGF0ZSBsYXN0IHdl ZWssIGFuZCBJIGp1c3QgYWRkZWQgYSBwb2ludGVyIHRvIHRoZSAtcnhiaW5kIG9wdGlvbiB0byBp dC4NCihUaGVyZSAqd2FzKiBhIG11bHRpaG9tZWQgKGZpbGUpc2VydmVyIGVudHJ5LCBidXQgeW91 IHdvdWxkbid0IGhhdmUgZm91bmQNCml0IGJ5IGxvb2tpbmcgZm9yIHRoYXQgd29yZC4gSXQgc2hv dWxkIHNob3cgdXAgbm93LikNCg0KLS0gDQpicmFuZG9uIHMgYWxsYmVyeSBrZjhuaCAgICBzaW5l IG5vbWluZSBhc3NvY2lhdGVzDQphbGxiZXJ5LmJAZ21haWwuY29tICAgICAgIGJhbGxiZXJ5QHNp bmVub21pbmUubmV0DQp1bml4LCBvcGVuYWZzLCBrZXJiZXJvcywgaW5mcmFzdHJ1Y3R1cmUsIHht b25hZA0KDQoNCg0K From ciprian.craciun@gmail.com Wed Jul 17 20:35:51 2013 From: ciprian.craciun@gmail.com (Ciprian Dorin Craciun) Date: Wed, 17 Jul 2013 22:35:51 +0300 Subject: [OpenAFS] Multi-homed server and NAT-ed client issues In-Reply-To: <20130717.212311.111020412384312966.haba@habanero> References: <1374074906.23381.58.camel@destiny.pc.cs.cmu.edu> <20130717.212311.111020412384312966.haba@habanero> Message-ID: On Wed, Jul 17, 2013 at 10:23 PM, Harald Barth wrote: > >> services: `kaserver`, .... > > Please consider running a KDC (or use the KDC in your AD if you have > one) instead of kaserver. kaserver is so last century. > > Harald. Yes... The `kaserver` thingy... :) The problem is that when I've started using OpenAFS (for personal purposes), the "stable" version was 1.4 (or at least what was labeled "stable" in my distribution). And at that time `kaserver` was simple to install and manage, and I still use it today, mainly due to laziness. Moreover I only have a few users, thus migrating to a full Kerberos stack seems like an overkill to me... On the same topic, are there any serious concerns related to `kaserver`? Or is it more related with other aspects (like say scalability, integration, future, etc.)? Ciprian. From jaltman@your-file-system.com Wed Jul 17 21:10:20 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Wed, 17 Jul 2013 16:10:20 -0400 Subject: [OpenAFS] Multi-homed server and NAT-ed client issues In-Reply-To: References: <1374074906.23381.58.camel@destiny.pc.cs.cmu.edu> <20130717.212311.111020412384312966.haba@habanero> Message-ID: <51E6FA2C.6030002@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms090700060400040901060308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/17/2013 3:35 PM, Ciprian Dorin Craciun wrote: > On the same topic, are there any serious concerns related to > `kaserver`? Or is it more related with other aspects (like say > scalability, integration, future, etc.)? Please read: http://www.openafs.org/no-more-des.html http://web.mit.edu/kerberos/krb5-devel/doc/admin/advanced/retiring-des.ht= ml and then migrate away from kaserver. Jeffrey Altman --------------ms090700060400040901060308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzE3MjAxMDIwWjAjBgkqhkiG9w0BCQQxFgQUyGqH7vmhAr6G7xahFinuZaYhZvowbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB ABzTXrf26O14XBsDUIhuZIhguNv4vx7P2db4PbzKJN0bSe8Vd+kgI+Qy4DtYv4jvwMvsWEXM okXc5LfwOTShMcl2zUo9ulRPAX6E0JrdE1SoYJKn6tXGTWN7ZhPnQoJKp4EhQKtrvFfU1/Gb 84hNFKV5jVFYHJHI10p1cXOUaoJl0l0+t8x9WUhncdhoW6FaMFcecStJaprMxBz9hGvL/g9w rB0Xq1xIpOA/9wU4Wl+YFlAD2i0B1hk9AAMumimQxQIQQzO1K6GUs6OPzfNW0CBk9xYpuT3u 5wInk1zEOVNswD26XYE0kRkeI+wE5FCoR16/OxxiagWe/MJyPQBPEbcAAAAAAAA= --------------ms090700060400040901060308-- From Coy.Hile@COYHILE.COM Fri Jul 19 11:11:37 2013 From: Coy.Hile@COYHILE.COM (Coy Hile) Date: Fri, 19 Jul 2013 10:11:37 +0000 Subject: [OpenAFS] enctype issues with Heimdal and debian for afs/cell Message-ID: <065767b7641c4a0695246cc37b121f2f@exch01.COYHILE.COM> Hi all, After some time, I'm finally getting around to putting my personal cell bac= k up (this time on debian with openafs-1.6.4 from wheezy-backports and Heim= dal. My afs/cell principal is setup thusly: kadmin> get afs/coyhile.com Principal: afs/coyhile.com@COYHILE.COM Principal expires: never Password expires: never Last password change: 2013-07-19 10:00:32 UTC Max ticket life: 1 day Max renewable life: 1 week Kvno: 3 Mkvno: unknown Last successful login: never Last failed login: never Failed login count: 0 Last modified: 2013-07-19 10:00:32 UTC Modifier: kadmin/admin@COYHILE.COM Attributes: Keytypes: aes256-cts-hmac-sha1-96(pw-salt)[3], des3-cbc-sha1(p= w-salt)[3], arcfour-hmac-md5(pw-salt)[3], des-cbc-md5(pw-salt())[3] PK-INIT ACL: Aliases: kadmin> ext -k AFSKEYFILE:/etc/openafs/server/KeyFile afs/coyhile.com kadmin> and in krb5.conf, I do have allow_weak_crypto =3D true in libdefaults. All in all, Heimdal is working fine, but aklog is failing to get me tokens: chaos:/var/log # kinit admin admin@COYHILE.COM's Password: chaos:/var/log # klist Credentials cache: FILE:/tmp/krb5cc_1141449863_q94vTe Principal: admin@COYHILE.COM Issued Expires Principal Jul 19 10:07:40 2013 Jul 20 10:07:36 2013 krbtgt/COYHILE.COM@COYHILE.COM Jul 19 10:07:40 2013 Jul 20 10:07:36 2013 afs/coyhile.com@COYHILE.COM chaos:/var/log # aklog -d Authenticating to cell coyhile.com (server chaos.coyhile.com). Trying to authenticate to user's realm COYHILE.COM. Getting tickets: afs/coyhile.com@COYHILE.COM Kerberos error code returned by get_cred : -1765328370 aklog: Couldn't get coyhile.com AFS tickets: aklog: unknown RPC error (-1765328370) while getting AFS tickets chaos:/var/log # and in the KDC logs, I see this: 2013-07-19T10:07:40 ENC-TS Pre-authentication succeeded -- admin@COYHILE.CO= M using aes256-cts-hmac-sha1-96 2013-07-19T10:07:40 ENC-TS pre-authentication succeeded -- admin@COYHILE.CO= M 2013-07-19T10:07:40 AS-REQ authtime: 2013-07-19T10:07:40 starttime: unset e= ndtime: 2013-07-20T10:07:36 renew till: 2013-07-26T10:07:36 2013-07-19T10:07:40 Client supported enctypes: aes256-cts-hmac-sha1-96, aes= 128-cts-hmac-sha1-96, des3-cbc-sha1, des3-cbc-md5, arcfour-hmac-md5, des-cb= c-md5, des-cbc-md4, des-cbc-crc, using aes256-cts-hmac-sha1-96/aes256-cts-h= mac-sha1-96 2013-07-19T10:07:40 Requested flags: renewable, forwardable 2013-07-19T10:07:40 sending 738 bytes to IPv4:37.153.98.57 2013-07-19T10:07:40 TGS-REQ admin@COYHILE.COM from IPv4:37.153.98.57 for af= s/coyhile.com@COYHILE.COM [canonicalize, renewable, forwardable] 2013-07-19T10:07:40 Server (afs/coyhile.com@COYHILE.COM) has no support for= etypes 2013-07-19T10:07:40 Failed building TGS-REP to IPv4:37.153.98.57 2013-07-19T10:07:40 tgs-req: sending error: -1765328370 to client Does *everything* need a DES key, or just the afs/cell principal? -c From geza@kzsdabas.hu Fri Jul 19 12:36:29 2013 From: geza@kzsdabas.hu (=?ISO-8859-1?Q?G=E9mes_G=E9za?=) Date: Fri, 19 Jul 2013 13:36:29 +0200 Subject: [OpenAFS] enctype issues with Heimdal and debian for afs/cell In-Reply-To: <065767b7641c4a0695246cc37b121f2f@exch01.COYHILE.COM> References: <065767b7641c4a0695246cc37b121f2f@exch01.COYHILE.COM> Message-ID: <51E924BD.6040801@kzsdabas.hu> 2013-07-19 12:11 keltezéssel, Coy Hile írta: > Hi all, > > After some time, I'm finally getting around to putting my personal cell back up (this time on debian with openafs-1.6.4 from wheezy-backports and Heimdal. > > My afs/cell principal is setup thusly: > > kadmin> get afs/coyhile.com > Principal: afs/coyhile.com@COYHILE.COM > Principal expires: never > Password expires: never > Last password change: 2013-07-19 10:00:32 UTC > Max ticket life: 1 day > Max renewable life: 1 week > Kvno: 3 > Mkvno: unknown > Last successful login: never > Last failed login: never > Failed login count: 0 > Last modified: 2013-07-19 10:00:32 UTC > Modifier: kadmin/admin@COYHILE.COM > Attributes: > Keytypes: aes256-cts-hmac-sha1-96(pw-salt)[3], des3-cbc-sha1(pw-salt)[3], arcfour-hmac-md5(pw-salt)[3], des-cbc-md5(pw-salt())[3] > PK-INIT ACL: > Aliases: Maybe you should remove the non des-cbc ones and couldn't hurt to have a des-cbc-crc one as well before generating the KeyFile > kadmin> ext -k AFSKEYFILE:/etc/openafs/server/KeyFile afs/coyhile.com > kadmin> > > and in krb5.conf, I do have allow_weak_crypto = true in libdefaults. On kdc afs servers and client? > > All in all, Heimdal is working fine, but aklog is failing to get me tokens: > > chaos:/var/log # kinit admin > admin@COYHILE.COM's Password: > chaos:/var/log # klist > Credentials cache: FILE:/tmp/krb5cc_1141449863_q94vTe > Principal: admin@COYHILE.COM > > Issued Expires Principal > Jul 19 10:07:40 2013 Jul 20 10:07:36 2013 krbtgt/COYHILE.COM@COYHILE.COM > Jul 19 10:07:40 2013 Jul 20 10:07:36 2013 afs/coyhile.com@COYHILE.COM > chaos:/var/log # aklog -d > Authenticating to cell coyhile.com (server chaos.coyhile.com). > Trying to authenticate to user's realm COYHILE.COM. > Getting tickets: afs/coyhile.com@COYHILE.COM > Kerberos error code returned by get_cred : -1765328370 > aklog: Couldn't get coyhile.com AFS tickets: > aklog: unknown RPC error (-1765328370) while getting AFS tickets > chaos:/var/log # > > and in the KDC logs, I see this: > > 2013-07-19T10:07:40 ENC-TS Pre-authentication succeeded -- admin@COYHILE.COM using aes256-cts-hmac-sha1-96 > 2013-07-19T10:07:40 ENC-TS pre-authentication succeeded -- admin@COYHILE.COM > 2013-07-19T10:07:40 AS-REQ authtime: 2013-07-19T10:07:40 starttime: unset endtime: 2013-07-20T10:07:36 renew till: 2013-07-26T10:07:36 > 2013-07-19T10:07:40 Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, des3-cbc-md5, arcfour-hmac-md5, des-cbc-md5, des-cbc-md4, des-cbc-crc, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 > 2013-07-19T10:07:40 Requested flags: renewable, forwardable > 2013-07-19T10:07:40 sending 738 bytes to IPv4:37.153.98.57 > 2013-07-19T10:07:40 TGS-REQ admin@COYHILE.COM from IPv4:37.153.98.57 for afs/coyhile.com@COYHILE.COM [canonicalize, renewable, forwardable] > 2013-07-19T10:07:40 Server (afs/coyhile.com@COYHILE.COM) has no support for etypes > 2013-07-19T10:07:40 Failed building TGS-REP to IPv4:37.153.98.57 > 2013-07-19T10:07:40 tgs-req: sending error: -1765328370 to client > > Does *everything* need a DES key, or just the afs/cell principal? > > -c > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info Regards Geza Gemes From Coy.Hile@COYHILE.COM Fri Jul 19 12:42:23 2013 From: Coy.Hile@COYHILE.COM (Coy Hile) Date: Fri, 19 Jul 2013 11:42:23 +0000 Subject: [OpenAFS] enctype issues with Heimdal and debian for afs/cell In-Reply-To: <51E924BD.6040801@kzsdabas.hu> References: <065767b7641c4a0695246cc37b121f2f@exch01.COYHILE.COM> <51E924BD.6040801@kzsdabas.hu> Message-ID: <95c5234b2827419aba708df09331fbc3@exch01.COYHILE.COM> > -----Original Message----- > Maybe you should remove the non des-cbc ones and couldn't hurt to have a > des-cbc-crc one as well before generating the KeyFile I'll give that a shot. > > and in krb5.conf, I do have allow_weak_crypto =3D true in libdefaults= . > On kdc afs servers and client? > > Both . In this case, the KDC and the (first) OpenAFS dbserver are collocat= ed. -c From Coy.Hile@COYHILE.COM Fri Jul 19 13:15:44 2013 From: Coy.Hile@COYHILE.COM (Coy Hile) Date: Fri, 19 Jul 2013 12:15:44 +0000 Subject: [OpenAFS] enctype issues with Heimdal and debian for afs/cell In-Reply-To: <51E924BD.6040801@kzsdabas.hu> References: <065767b7641c4a0695246cc37b121f2f@exch01.COYHILE.COM> <51E924BD.6040801@kzsdabas.hu> Message-ID: <32928432578741d79da83fe84d93e894@exch01.COYHILE.COM> > Maybe you should remove the non des-cbc ones and couldn't hurt to have a > des-cbc-crc one as well before generating the KeyFile That certainly helped. Now I'm getting a different set of errors from aklo= g; chaos:/var/log # aklog -d Authenticating to cell coyhile.com (server chaos.coyhile.com). Trying to authenticate to user's realm COYHILE.COM. Getting tickets: afs/coyhile.com@COYHILE.COM Using Kerberos V5 ticket natively About to resolve name admin to id in cell coyhile.com. Id 1 Set username to AFS ID 1 Setting tokens. AFS ID 1 @ coyhile.com aklog: unknown cell was passed to SetToken while obtaining tokens for cell = coyhile.com Yet the server seems to know its cell: chaos:/var/log # bos listhosts chaos -localauth Cell name is coyhile.com Host 1 is chaos.coyhile.com chaos:/var/log # Am I conflating error messages since I've configured neither the client (be= sides whatever configuration debconf did on install) nor the (da)fileserver= yet? -c From geza@kzsdabas.hu Fri Jul 19 13:29:36 2013 From: geza@kzsdabas.hu (=?ISO-8859-1?Q?G=E9mes_G=E9za?=) Date: Fri, 19 Jul 2013 14:29:36 +0200 Subject: [OpenAFS] enctype issues with Heimdal and debian for afs/cell In-Reply-To: <32928432578741d79da83fe84d93e894@exch01.COYHILE.COM> References: <065767b7641c4a0695246cc37b121f2f@exch01.COYHILE.COM> <51E924BD.6040801@kzsdabas.hu> <32928432578741d79da83fe84d93e894@exch01.COYHILE.COM> Message-ID: <51E93130.2090502@kzsdabas.hu> 2013-07-19 14:15 keltezéssel, Coy Hile írta: > >> Maybe you should remove the non des-cbc ones and couldn't hurt to have a >> des-cbc-crc one as well before generating the KeyFile > That certainly helped. Now I'm getting a different set of errors from aklog; > > chaos:/var/log # aklog -d > Authenticating to cell coyhile.com (server chaos.coyhile.com). > Trying to authenticate to user's realm COYHILE.COM. > Getting tickets: afs/coyhile.com@COYHILE.COM > Using Kerberos V5 ticket natively > About to resolve name admin to id in cell coyhile.com. > Id 1 > Set username to AFS ID 1 > Setting tokens. AFS ID 1 @ coyhile.com > aklog: unknown cell was passed to SetToken while obtaining tokens for cell coyhile.com > > Yet the server seems to know its cell: > > chaos:/var/log # bos listhosts chaos -localauth > Cell name is coyhile.com > Host 1 is chaos.coyhile.com > chaos:/var/log # > > Am I conflating error messages since I've configured neither the client (besides whatever configuration debconf did on install) nor the (da)fileserver yet? > > -c The problem seems to be that the client (even if it on same box) needs to know about the dbserver(s). You have two choices: 1. Add them to the /etc/openafs/CellServDB on each client, or 2. set up two SRV records on dns: _afs3-vlserver._udp.coyhile.com _afs3-prserver._udp.coyhile.com for each db servers in your cell. IMHO first method is faster to accomplish with a small number of clients, second is more future proof as new client systems get added to your cell. Regards Geza Gemes From adeason@sinenomine.net Fri Jul 19 15:46:37 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 19 Jul 2013 09:46:37 -0500 Subject: [OpenAFS] Re: enctype issues with Heimdal and debian for afs/cell References: <065767b7641c4a0695246cc37b121f2f@exch01.COYHILE.COM> <51E924BD.6040801@kzsdabas.hu> <32928432578741d79da83fe84d93e894@exch01.COYHILE.COM> <51E93130.2090502@kzsdabas.hu> Message-ID: <20130719094637.42ac795d.adeason@sinenomine.net> On Fri, 19 Jul 2013 14:29:36 +0200 Gémes Géza wrote: > 2013-07-19 14:15 keltezéssel, Coy Hile írta: > > Am I conflating error messages since I've configured neither the > > client (besides whatever configuration debconf did on install) nor > > the (da)fileserver yet? The error message is complaining about the client config, yeah. In general, I would just wait until after you've configured the client; you need to have the client at least partially configured before you can acquire tokens. But if you want to continue anyway: > The problem seems to be that the client (even if it on same box) needs > to know about the dbserver(s). You have two choices: > 1. Add them to the /etc/openafs/CellServDB on each client, If you go this route, you also need to tell the running client about the new cell; it only reads the config files on startup. Either restart the client after editing CellServDB, or run 'fs newcell' as root to tell the running client about the new cell. -- Andrew Deason adeason@sinenomine.net From Coy.Hile@COYHILE.COM Fri Jul 19 16:12:58 2013 From: Coy.Hile@COYHILE.COM (Coy Hile) Date: Fri, 19 Jul 2013 15:12:58 +0000 Subject: [OpenAFS] enctype issues with Heimdal and debian for afs/cell In-Reply-To: <51E93130.2090502@kzsdabas.hu> References: <065767b7641c4a0695246cc37b121f2f@exch01.COYHILE.COM> <51E924BD.6040801@kzsdabas.hu> <32928432578741d79da83fe84d93e894@exch01.COYHILE.COM> <51E93130.2090502@kzsdabas.hu> Message-ID: > The problem seems to be that the client (even if it on same box) needs to > know about the dbserver(s). You have two choices: > 1. Add them to the /etc/openafs/CellServDB on each client, or 2. set up t= wo > SRV records on dns: > _afs3-vlserver._udp.coyhile.com > _afs3-prserver._udp.coyhile.com >=20 > for each db servers in your cell. >=20 > IMHO first method is faster to accomplish with a small number of clients, > second is more future proof as new client systems get added to your cell. >=20 Thanks Geza. You sorted it out. When I created the records with fs newcel= l rather than just editing cellservdb, I'm good now. Thanks for your help; it's been a while. -c From rich@nd.edu Mon Jul 22 18:21:14 2013 From: rich@nd.edu (Rich Sudlow) Date: Mon, 22 Jul 2013 13:21:14 -0400 Subject: [OpenAFS] Use of hyperthreading on AFS fileservers Message-ID: <51ED6A0A.5090603@nd.edu> Are there any recommendations on why/why not to use hyperthreading on Intel machines used as fileservers with Red Hat 6.4 OS? Thanks, Rich -- Rich Sudlow University of Notre Dame Center for Research Computing - Union Station 506 W. South St South Bend, In 46601 (574) 631-7258 (office) (574) 807-1046 (cell) From shadow@gmail.com Mon Jul 22 18:43:10 2013 From: shadow@gmail.com (Derrick Brashear) Date: Mon, 22 Jul 2013 13:43:10 -0400 Subject: [OpenAFS] Use of hyperthreading on AFS fileservers In-Reply-To: <51ED6A0A.5090603@nd.edu> References: <51ED6A0A.5090603@nd.edu> Message-ID: --001a11c20b94bd544804e21d3527 Content-Type: text/plain; charset=ISO-8859-1 The rx listener thread in a fileserver can float from thread to thread, but even if it couldn't you don't necessarily get off: work for any given client is not necessarily handled all within a single thread, and thus not necessarily on a single core. What this means is you get to incur context switches when one packet is handled on the first core and the next packet from the same client is on another core. So there's no one "right" answer. And as long as but a single port (7000) handles all traffic there is not a convenient way to bind streamless (UDP) traffic from a single client to a single core... On Mon, Jul 22, 2013 at 1:21 PM, Rich Sudlow wrote: > Are there any recommendations on why/why not to use hyperthreading on > Intel machines used as fileservers with Red Hat 6.4 OS? > > Thanks, > > Rich > > -- > Rich Sudlow > University of Notre Dame > Center for Research Computing - Union Station > 506 W. South St > South Bend, In 46601 > > (574) 631-7258 (office) > (574) 807-1046 (cell) > ______________________________**_________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/**mailman/listinfo/openafs-info > > -- Derrick --001a11c20b94bd544804e21d3527 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The rx listener thread in a fileserver can float from= thread to thread, but even if it couldn't you don't necessarily ge= t off: work for any given client is not necessarily
handled all within = a single thread, and thus not necessarily on a single core. What this means= is you get to incur context switches when one packet is handled on the fir= st
core and the next packet from the same client is on another core. So there&= #39;s no one "right" answer. And as long as but a single port (70= 00) handles all traffic there is not a
convenient way to bind= streamless (UDP) traffic from a single client to a single core...


O= n Mon, Jul 22, 2013 at 1:21 PM, Rich Sudlow <rich@nd.edu> wrote:=
Are there any recommendations on why/why not to use hyperthreading on
Intel machines used as fileservers with Red Hat 6.4 OS?

Thanks,

Rich

--
Rich Sudlow
University of Notre Dame
Center for Research Computing - Union Station
506 W. South St
South Bend, In 46601

(574) 631-7258=A0(office)
(574) 807-1046=A0(cell)
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@= openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info<= /a>




--
Derrick
--001a11c20b94bd544804e21d3527-- From wangshuaijie@gmail.com Tue Jul 23 07:14:04 2013 From: wangshuaijie@gmail.com (shuaijie wang) Date: Tue, 23 Jul 2013 14:14:04 +0800 Subject: [OpenAFS] How can I get PAG number of a certain process programmically? Message-ID: --001a11c26a5e2a59c904e227b3b7 Content-Type: text/plain; charset=ISO-8859-1 Hi all, In AFS, separate processes can be put into different PAGs, my question is: How can I get the PAG number of certain process programically? Thanks. --001a11c26a5e2a59c904e227b3b7 Content-Type: text/html; charset=ISO-8859-1
Hi all,
In AFS, separate processes can be put into different PAGs, my question is: How can I get the PAG number of certain process programically? Thanks.
--001a11c26a5e2a59c904e227b3b7-- From hans@MPA-Garching.MPG.DE Tue Jul 23 12:11:17 2013 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Tue, 23 Jul 2013 13:11:17 +0200 Subject: [OpenAFS] No buffer space available Message-ID: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> Hello, sometimes creating a file (using different programs) fails with the error message "No buffer space available". This is on amd64_linux26 with OpenAFS 1.6.2 (both client and server). Any idea? Best regards, HW --=20 Hans-Werner Paulsen hans@MPA-Garching.MPG.DE MPI f=C3=BCr Astrophysik Tel 089-30000-2602 Karl-Schwarzschild-Str. 1 Fax 089-30000-2235=09 D-85741 Garching From rra@stanford.edu Tue Jul 23 15:38:50 2013 From: rra@stanford.edu (Russ Allbery) Date: Tue, 23 Jul 2013 07:38:50 -0700 Subject: [OpenAFS] How can I get PAG number of a certain process programmically? In-Reply-To: (shuaijie wang's message of "Tue, 23 Jul 2013 14:14:04 +0800") References: Message-ID: <87a9ldtk79.fsf@windlord.stanford.edu> shuaijie wang writes: > In AFS, separate processes can be put into different PAGs, my question > is: How can I get the PAG number of certain process programically? #include #include #include #include #include int main(void) { struct ViceIoctl iob; afs_uint32 pag; int code; iob.in = NULL; iob.in_size = 0; iob.out = (void *) &pag; iob.out_size = sizeof(pag); code = pioctl(NULL, VIOC_GETPAG, &iob, 0); if (code != 0) { fprintf(stderr, "Cannot get PAG\n"); return 1; } printf("PAG number is: %lu\n", (unsigned long) pag); return 0; } -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Tue Jul 23 17:32:20 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 23 Jul 2013 11:32:20 -0500 Subject: [OpenAFS] Re: How can I get PAG number of a certain process programmically? References: <87a9ldtk79.fsf@windlord.stanford.edu> Message-ID: <20130723113220.3cc3b5e0.adeason@sinenomine.net> On Tue, 23 Jul 2013 07:38:50 -0700 Russ Allbery wrote: > #include > #include > #include > #include > #include > > int > main(void) > { > struct ViceIoctl iob; > afs_uint32 pag; > int code; > > iob.in = NULL; > iob.in_size = 0; > iob.out = (void *) &pag; > iob.out_size = sizeof(pag); > code = pioctl(NULL, VIOC_GETPAG, &iob, 0); > if (code != 0) { > fprintf(stderr, "Cannot get PAG\n"); > return 1; > } > printf("PAG number is: %lu\n", (unsigned long) pag); > return 0; > } Link this with -lafsauthent -lafsrpc, I believe. Or use the k_pioctl function from kopenafs.h, and link with -lkopenafs. -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Tue Jul 23 17:40:53 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 23 Jul 2013 11:40:53 -0500 Subject: [OpenAFS] Re: No buffer space available References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> Message-ID: <20130723114053.ea104ee2.adeason@sinenomine.net> On Tue, 23 Jul 2013 13:11:17 +0200 Hans-Werner Paulsen wrote: > sometimes creating a file (using different programs) fails with the > error message "No buffer space available". This is on amd64_linux26 > with OpenAFS 1.6.2 (both client and server). Any idea? I don't see anywhere we'd be generating that error code (ENOBUFS), and I can't see how it would show up that way if we got it back from a socket or something. Do you have any idea if the machine is under a lot of load or memory pressure, or if the directory has a lot of entries in it? -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Tue Jul 23 18:13:38 2013 From: rra@stanford.edu (Russ Allbery) Date: Tue, 23 Jul 2013 10:13:38 -0700 Subject: [OpenAFS] Re: How can I get PAG number of a certain process programmically? In-Reply-To: <20130723113220.3cc3b5e0.adeason@sinenomine.net> (Andrew Deason's message of "Tue, 23 Jul 2013 11:32:20 -0500") References: <87a9ldtk79.fsf@windlord.stanford.edu> <20130723113220.3cc3b5e0.adeason@sinenomine.net> Message-ID: <877gghqjwd.fsf@windlord.stanford.edu> Andrew Deason writes: > Link this with -lafsauthent -lafsrpc, I believe. Yeah, sorry. > Or use the k_pioctl function from kopenafs.h, and link with -lkopenafs. Yes, that also works, although you still need some of the same headers to get the VIOC_* definition. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Tue Jul 23 20:09:48 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 23 Jul 2013 14:09:48 -0500 Subject: [OpenAFS] Re: No buffer space available References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> <20130723114053.ea104ee2.adeason@sinenomine.net> Message-ID: <20130723140948.9fa93a70.adeason@sinenomine.net> On Tue, 23 Jul 2013 11:40:53 -0500 Andrew Deason wrote: > On Tue, 23 Jul 2013 13:11:17 +0200 > Hans-Werner Paulsen wrote: > > > sometimes creating a file (using different programs) fails with the > > error message "No buffer space available". This is on amd64_linux26 > > with OpenAFS 1.6.2 (both client and server). Any idea? > > I don't see anywhere we'd be generating that error code (ENOBUFS), and > I can't see how it would show up that way if we got it back from a > socket or something. Do you have any idea if the machine is under a > lot of load or memory pressure, or if the directory has a lot of > entries in it? Oh, and if you wanted a "next step" involving less guesswork, get an fstrace dump if you can reproduce the problem. That's something like: fstrace clear cm fstrace setlog cmfx -buffers 1024 fstrace sets cm -active # do something to trigger the error, then: fstrace dump cm > /tmp/whatever fstrace sets cm -inactive Providing that to a developer will let us see a lower level trace of what's going on, and should say where that error is coming from. But it can contain some sensitive information like filenames. -- Andrew Deason adeason@sinenomine.net From shadow@gmail.com Tue Jul 23 20:17:33 2013 From: shadow@gmail.com (Derrick Brashear) Date: Tue, 23 Jul 2013 15:17:33 -0400 Subject: [OpenAFS] No buffer space available In-Reply-To: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> Message-ID: --047d7b2e44021bfa7904e232a58a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is anything in the kernel message buffer when this happens? On Tue, Jul 23, 2013 at 7:11 AM, Hans-Werner Paulsen < hans@mpa-garching.mpg.de> wrote: > Hello, > sometimes creating a file (using different programs) fails with the error > message "No buffer space available". This is on amd64_linux26 with > OpenAFS 1.6.2 (both client and server). Any idea? > > Best regards, > HW > > -- > Hans-Werner Paulsen hans@MPA-Garching.MPG.DE > MPI f=FCr Astrophysik Tel 089-30000-2602 > Karl-Schwarzschild-Str. 1 Fax 089-30000-2235 > D-85741 Garching > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > > --=20 Derrick --047d7b2e44021bfa7904e232a58a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is anything in the kernel message buffer when this happens= ?


On= Tue, Jul 23, 2013 at 7:11 AM, Hans-Werner Paulsen <hans@mpa-garchi= ng.mpg.de> wrote:
Hello,
sometimes creating a file (using different programs) fails with the error message "No buffer space available". This is on amd64_linux26 wit= h
OpenAFS 1.6.2 (both client and server). Any idea?

Best regards,
HW

--
Hans-Werner Paulsen =A0 =A0 =A0 =A0 =A0 =A0 hans@MPA-Garching.MPG.DE
MPI f=FCr Astrophysik =A0 =A0 =A0 =A0 =A0 =A0 Tel 089-30000-2602
Karl-Schwarzschild-Str. 1 =A0 =A0 =A0 Fax 089-30000-2235
D-85741 Garching
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info




--
Derrick
--047d7b2e44021bfa7904e232a58a-- From wangshuaijie@gmail.com Wed Jul 24 10:02:34 2013 From: wangshuaijie@gmail.com (shuaijie wang) Date: Wed, 24 Jul 2013 17:02:34 +0800 Subject: [OpenAFS] Re: How can I get PAG number of a certain process programmically? In-Reply-To: <877gghqjwd.fsf@windlord.stanford.edu> References: <87a9ldtk79.fsf@windlord.stanford.edu> <20130723113220.3cc3b5e0.adeason@sinenomine.net> <877gghqjwd.fsf@windlord.stanford.edu> Message-ID: --089e01538afca5d93404e23e2b3e Content-Type: text/plain; charset=ISO-8859-1 Thanks very much! 2013/7/24 Russ Allbery > Andrew Deason writes: > > > Link this with -lafsauthent -lafsrpc, I believe. > > Yeah, sorry. > > > Or use the k_pioctl function from kopenafs.h, and link with -lkopenafs. > > Yes, that also works, although you still need some of the same headers to > get the VIOC_* definition. > > -- > Russ Allbery (rra@stanford.edu) > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > --089e01538afca5d93404e23e2b3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks very much!

=
2013/7/24 Russ Allbery <= ;rra@stanford.edu= >
Andrew Deason <adeason@sinenomine.net> writes:
> Link this with -lafsauthent -lafsrpc, I believe.

Yeah, sorry.

> Or use the k_pioctl function from kopenafs.h, and link with -lkopenafs= .

Yes, that also works, although you still need some of the same header= s to
get the VIOC_* definition.

--
Russ Allbery (rra@stanford.edu) =A0= =A0 =A0 =A0 =A0 =A0 <http://www.eyrie.org/~eagle/>
_____________________________= __________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info

--089e01538afca5d93404e23e2b3e-- From hans@MPA-Garching.MPG.DE Wed Jul 24 15:12:10 2013 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Wed, 24 Jul 2013 16:12:10 +0200 Subject: [OpenAFS] Re: No buffer space available In-Reply-To: <20130723114053.ea104ee2.adeason@sinenomine.net> References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> <20130723114053.ea104ee2.adeason@sinenomine.net> Message-ID: <51EFE0BA.2070703@mpa-garching.mpg.de> On 07/23/2013 06:40 PM, Andrew Deason wrote: > On Tue, 23 Jul 2013 13:11:17 +0200 > Hans-Werner Paulsen wrote: > >> sometimes creating a file (using different programs) fails with the >> error message "No buffer space available". This is on amd64_linux26 >> with OpenAFS 1.6.2 (both client and server). Any idea? > I don't see anywhere we'd be generating that error code (ENOBUFS), and I > can't see how it would show up that way if we got it back from a socket > or something. Do you have any idea if the machine is under a lot of load > or memory pressure, or if the directory has a lot of entries in it? > The client was not under heavy load, but the fileserver, and the network. From hans@MPA-Garching.MPG.DE Wed Jul 24 15:16:53 2013 From: hans@MPA-Garching.MPG.DE (Hans-Werner Paulsen) Date: Wed, 24 Jul 2013 16:16:53 +0200 Subject: [OpenAFS] Re: No buffer space available In-Reply-To: <20130723140948.9fa93a70.adeason@sinenomine.net> References: <20130723111115.GA25256@nct-3.MPA-Garching.MPG.DE> <20130723114053.ea104ee2.adeason@sinenomine.net> <20130723140948.9fa93a70.adeason@sinenomine.net> Message-ID: <51EFE1D5.4030704@mpa-garching.mpg.de> On 07/23/2013 09:09 PM, Andrew Deason wrote: > On Tue, 23 Jul 2013 11:40:53 -0500 > Andrew Deason wrote: > >> On Tue, 23 Jul 2013 13:11:17 +0200 >> Hans-Werner Paulsen wrote: >> >>> sometimes creating a file (using different programs) fails with the >>> error message "No buffer space available". This is on amd64_linux26 >>> with OpenAFS 1.6.2 (both client and server). Any idea? >> I don't see anywhere we'd be generating that error code (ENOBUFS), and >> I can't see how it would show up that way if we got it back from a >> socket or something. Do you have any idea if the machine is under a >> lot of load or memory pressure, or if the directory has a lot of >> entries in it? > Oh, and if you wanted a "next step" involving less guesswork, get an > fstrace dump if you can reproduce the problem. That's something like: > > fstrace clear cm > fstrace setlog cmfx -buffers 1024 > fstrace sets cm -active > # do something to trigger the error, then: > fstrace dump cm > /tmp/whatever > fstrace sets cm -inactive > > Providing that to a developer will let us see a lower level trace of > what's going on, and should say where that error is coming from. But it > can contain some sensitive information like filenames. > Unfortunately I cannot reproduce the problem. Thank you for the usage instructions of fstrace, anyway. From deengert@anl.gov Wed Jul 24 17:01:41 2013 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 24 Jul 2013 11:01:41 -0500 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS Security Advisory 2013-0003 In-Reply-To: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> Message-ID: <51EFFA65.4060407@anl.gov> Question: Once the 1.6.5 binaries are in place, and the servers start using the rxkad.keytab, will the server still accept existing DES based tokens that use keys and kvno that are only in the KeyFile? On 7/24/2013 9:05 AM, Simon Wilkinson wrote: > > OpenAFS Security Advisory 2013-0003 > > Topic: Brute force DES attack permits compromise of AFS cell > CVE-2013-4134 > > Issued: > Last Updated: > Affected: OpenAFS servers before 1.6.5 / 1.4.15 > > The small size of the DES key space permits an attacker to brute > force a cell's service key and then forge traffic from any user > within the cell. The key space search can be performed in under 1 > day at a cost of around $100 using publicly available services. > > SUMMARY > ======= > > OpenAFS uses Kerberos tickets to secure network traffic. For historical > reasons, it has only supported the DES encryption algorithm to encrypt > these tickets. The weakness of DES's 56 bit key space has long been > known, however it has recently become possible to use that weakness > to cheaply (around $100) and rapidly (approximately 23 hours) compromise > a service's long term key. > > An attacker must first obtain a ticket for the cell. They may then use > a brute force attack to compromise the cell's private service key. > Once an attacker has gained access to the service key, they can use this > to impersonate any user within the cell, including the super user, giving > them access to all administrative capabilities as well as all user data. > > Recovering the service key from a DES encrypted ticket is an issue > for any Kerberos service still using DES (and especially so for realms which > still have DES keys on their ticket granting ticket). The MIT Kerberos > Consortium is aware of this issue, and have produced a general guide > for sites wishing to migrate away from DES which is referenced below. > > This vulnerability is a particular problem for OpenAFS because DES is the only > encryption algorithm supported in current releases. > > IMPACT > ====== > > An attacker may gain complete control over the targeted cell. > > No publicly available exploits are currently known. > > AFFECTED SOFTWARE > ================= > > All current releases of OpenAFS. This is all releases prior to 1.4.15, all > releases in the 1.6 series prior to 1.6.5 and all releases in the 1.7 series > prior to 1.7.26. > > FIXES > ===== > > The OpenAFS project recommends that administrators upgrade to OpenAFS 1.6.5 > or later. For those sites unable, or unwilling, to upgrade to the 1.6 series, > a final release in the 1.4 series, 1.4.15, is provided. > > In addition to upgrading, some additional cell configuration is required. New > encryption types must be added to the afs@REALM or afs/cell@REALM principal in > the KDC, and extracted to a new file (rxkad.keytab) on each OpenAFS file or > database server. Links to more detailed upgrade documentation are given below. > > For sites running with kaserver, there is no fix, since kaserver still > only supports single DES. Sites running kaserver must migrate to a > Kerberos 5 environment in addition to applying the fixes in this alert, > in order to fix this issue. > > DETAILS > ======= > > These patches extend the rxkad security class with two modifications. The first, > rxkad-k5, adds support for non-DES service keys. The first modification is > sufficient to fix the immediate vulnerability. The software update must be > deployed on all OpenAFS database and file servers within a cell, > additional encryption types added to the cell's afs/cell@REALM or > afs@REALM principal, and extracted to the rxkad.keytab file on each server. > This modification requires that all OpenAFS servers are built with Kerberos > support, and that all server machines have Kerberos libraries installed. > > With the first change applied, DES is still used for the Kerberos session key > shared between client and server and, as such, DES must still be enabled in > the realm's KDC. > > In order to disable DES entirely a second change is required. This > modification, rxkad-kdf, permits the use of non-DES Kerberos session keys and > removes the dependency on DES in the KDC. Unfortunately, this modification > requires changes to the OpenAFS client software on every machine that > makes authenticated connections to the cell. Once DES support is removed in > the KDC, only updated clients will be able to connect. > > Note that the client modifications to accommodate rxkad-kdf do not > require a restart of the OpenAFS client in order to take effect. The > modifications only affect the userspace tools used to acquire tokens. > > To summarise: The immediate security issue may be resolved by a server upgrade and > configuration change. Sites who wish to turn off DES entirely in their KDCs must > also upgrade all of their clients. > > FURTHER READING > =============== > > Detailed documentation about how to deploy these changes is available from > http://www.openafs.org/ > > The MIT Kerberos Consortium provides the following documentation on moving > other services away from DES: > http://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html > > ACKNOWLEDGEMENTS > ================ > > This issue was identified by Alex Chernyakhovsky, Christy Dennison, > Patrick Hurst and Peter Iannucci as part of the MIT Computer Systems Security > course. > > These patches were developed by Derrick Brashear, Alexander Chernyakhovsky, > Andrew Deason, Chaskiel M Grundman and Benjamin Kaduk, with advice from > Mitch Berger, Adam Glasgall, Jeffrey Hutzelman, Tom Yu and Nickolai > Zeldovich. > > > _______________________________________________ > OpenAFS-announce mailing list > OpenAFS-announce@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-announce > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From kaduk@MIT.EDU Wed Jul 24 17:10:02 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Wed, 24 Jul 2013 12:10:02 -0400 (EDT) Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS Security Advisory 2013-0003 In-Reply-To: <51EFFA65.4060407@anl.gov> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <51EFFA65.4060407@anl.gov> Message-ID: On Wed, 24 Jul 2013, Douglas E. Engert wrote: > Question: Once the 1.6.5 binaries are in place, and the servers > start using the rxkad.keytab, will the server still accept > existing DES based tokens that use keys and kvno that > are only in the KeyFile? Yes. In fact, the code path for tokens using keys in the KeyFile (all single-DES keys, really) is nearly unchanged. Only non-DES enctypes take the codepath with the new decrypter that knows about rxkad.keytab. -Ben From deengert@anl.gov Wed Jul 24 17:50:37 2013 From: deengert@anl.gov (Douglas E. Engert) Date: Wed, 24 Jul 2013 11:50:37 -0500 Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS Security Advisory 2013-0003 In-Reply-To: References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <51EFFA65.4060407@anl.gov> Message-ID: <51F005DD.4040403@anl.gov> On 7/24/2013 11:10 AM, Benjamin Kaduk wrote: > On Wed, 24 Jul 2013, Douglas E. Engert wrote: > >> Question: Once the 1.6.5 binaries are in place, and the servers >> start using the rxkad.keytab, will the server still accept >> existing DES based tokens that use keys and kvno that >> are only in the KeyFile? > > Yes. In fact, the code path for tokens using keys in the KeyFile (all single-DES keys, really) is nearly unchanged. Only non-DES enctypes take the codepath with the new decrypter that knows about > rxkad.keytab. Your answer implies even if we have a single DES entry in the rxkad.keytab we also have to have it in the KeyFile. Is that correct? I was expecting you to say for single DES, it would first look in the rkkad.keytab and if the KVNO was not found look in the KeyFile. > > -Ben > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From kaduk@MIT.EDU Wed Jul 24 18:13:36 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Wed, 24 Jul 2013 13:13:36 -0400 (EDT) Subject: [OpenAFS] Re: [OpenAFS-announce] OpenAFS Security Advisory 2013-0003 In-Reply-To: <51F005DD.4040403@anl.gov> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <51EFFA65.4060407@anl.gov> <51F005DD.4040403@anl.gov> Message-ID: On Wed, 24 Jul 2013, Douglas E. Engert wrote: > > > On 7/24/2013 11:10 AM, Benjamin Kaduk wrote: >> On Wed, 24 Jul 2013, Douglas E. Engert wrote: >> >>> Question: Once the 1.6.5 binaries are in place, and the servers >>> start using the rxkad.keytab, will the server still accept >>> existing DES based tokens that use keys and kvno that >>> are only in the KeyFile? >> >> Yes. In fact, the code path for tokens using keys in the KeyFile (all >> single-DES keys, really) is nearly unchanged. Only non-DES enctypes take >> the codepath with the new decrypter that knows about >> rxkad.keytab. > > Your answer implies even if we have a single DES entry in the > rxkad.keytab we also have to have it in the KeyFile. > Is that correct? Yes. > > I was expecting you to say for single DES, it would first look in the > rkkad.keytab and if the KVNO was not found look in the KeyFile. this is an artifact of how we retained the old codepath for existing keys. Perhaps it should be better documented. -Bex From curylo@us.ibm.com Wed Jul 24 21:06:19 2013 From: curylo@us.ibm.com (Gene Curylo) Date: Wed, 24 Jul 2013 16:06:19 -0400 Subject: [OpenAFS] AUTO: Curylo, Gene is out of the office. (returning 07/25/2013) Message-ID: --0__=0ABBF121DFFDF7818f9e8a93df938690918c0ABBF121DFFDF781 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 07/25/2013. I will be on vacation. Please contact my manager, Paul Crutcher, if you= need assistance. Thanks. Note: This is an automated response to your message "[OpenAFS-announce= ] OpenAFS Security Advisory 2013-0003" sent on 07/24/2013 10:05:18. This is the only notification you will receive while this person is awa= y.= --0__=0ABBF121DFFDF7818f9e8a93df938690918c0ABBF121DFFDF781 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 07= /25/2013.

I will be on vacation. Plea= se contact my manager, Paul Crutcher, if you need assistance. Thanks.

Note: Thi= s is an automated response to your message  "[OpenAFS-announce] OpenAFS Security Advi= sory 2013-0003" sent on = 07/24/2013 10:05:18.

This is t= he only notification you will receive while this person is away.= = --0__=0ABBF121DFFDF7818f9e8a93df938690918c0ABBF121DFFDF781-- From l.schimmer@cgv.tugraz.at Thu Jul 25 09:57:33 2013 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Thu, 25 Jul 2013 10:57:33 +0200 Subject: [OpenAFS] OpenAFS 1.7.26 windows and not changed AFS service principle - OK? Message-ID: <51F0E87D.8060009@cgv.tugraz.at> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OXSHPEXDHXCHXPVDFNAK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! Maybe I am not the best reader, but if I do use a win AD as a krb5 auth service and I did not change anything with my keyfiles and everything, should OpenAFS 1.7.26 on Windows work as usual? As I tried on my system it did not work fine. It did show a ticket/token, but it shows \\AFS\cgv.tugraz.at not reachable at all. And it added a strange icon on that drive-icon... So, did I misread anything? MfG, Lars Schimmer --=20 ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ------enig2OXSHPEXDHXCHXPVDFNAK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHw6IIACgkQmWhuE0qbFyP+UQCfVswyLCzRn1AvYDu5Z7MWBCqd WskAni35w7E/KzJja5Yn6BUIi65vgZad =qXlK -----END PGP SIGNATURE----- ------enig2OXSHPEXDHXCHXPVDFNAK-- From ralf.brunckhorst@hp.com Thu Jul 25 12:47:58 2013 From: ralf.brunckhorst@hp.com (Brunckhorst, Ralf) Date: Thu, 25 Jul 2013 11:47:58 +0000 Subject: [OpenAFS] OpenAFS 1.6.5 .src.rpm on RHEL 5.x Fails with cpio: MD5 sum mismatch Message-ID: --_000_E3A882F104F6304D89C62FB119B729800FD0E93AG5W2743americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Similar issue with the src.rpm of the new version 1.6.5 like 1.6.2 Is it possible to fix this by providing a compatible src.rpm 1.6.5 for RHEL= 5? - Ralf --_000_E3A882F104F6304D89C62FB119B729800FD0E93AG5W2743americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Similar issue with the src.rpm of the new version 1.= 6.5 like 1.6.2

Is it possible to fix this by providing a compatible= src.rpm 1.6.5 for RHEL5?

 

-     &= nbsp;    Ralf

 

--_000_E3A882F104F6304D89C62FB119B729800FD0E93AG5W2743americas_-- From stephen@jadevine.org.uk Thu Jul 25 13:03:45 2013 From: stephen@jadevine.org.uk (Stephen Quinney) Date: Thu, 25 Jul 2013 13:03:45 +0100 Subject: [OpenAFS] OpenAFS 1.6.5 .src.rpm on RHEL 5.x Fails with cpio: MD5 sum mismatch In-Reply-To: References: Message-ID: --047d7bdcace466158704e254d199 Content-Type: text/plain; charset=ISO-8859-1 You can grab a signed SRPM for RHEL5 from the /afs/ inf.ed.ac.uk/group/afsbuild/1.6.5/rhel5 directory. That's the source which was used to build the publically available RHEL5 RPMs. Stephen Quinney On 25 July 2013 12:47, Brunckhorst, Ralf wrote: > Hi,**** > > ** ** > > Similar issue with the src.rpm of the new version 1.6.5 like 1.6.2**** > > Is it possible to fix this by providing a compatible src.rpm 1.6.5 for > RHEL5?**** > > ** ** > > **- **Ralf**** > > ** ** > --047d7bdcace466158704e254d199 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You can grab a signed SRPM for RHEL5 from the /afs/inf.ed.ac.uk/group= /afsbuild/1.6.5/rhel5 directory. That's the source which was used t= o build the publically available RHEL5 RPMs.


Stephen Quinney


<= div class=3D"gmail_quote">On 25 July 2013 12:47, Brunckhorst, Ralf <= ralf.brunckhorst@hp.com> wrote:

Hi,

=A0

Similar issue with the src.rpm of the new version 1.= 6.5 like 1.6.2

Is it possible to fix this by providing a compatible= src.rpm 1.6.5 for RHEL5?=

=A0

-=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Ralf

=A0


--047d7bdcace466158704e254d199-- From stephen@physics.unc.edu Thu Jul 25 14:11:38 2013 From: stephen@physics.unc.edu (stephen@physics.unc.edu) Date: Thu, 25 Jul 2013 09:11:38 -0400 (EDT) Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> Message-ID: Hi, In the cell rekeying instructions found at , there is a note for sites using Heimdal KDCs. It mentions a bug present in "certain versions" of the Heimdal KDC software which completely disables DES on the AFS service principal when following the document's instructions. Is more information available about specific versions of the Heimdal KDC software which exhibits this bug? The document mentions experimentally verifying ticket acquisition, which seems wise. But also knowing the KDC versions which have the bug would be beneficial. Anyone have this info? Should I post to a heimdal list instead? Cheers, Stephen From ralf.brunckhorst@hp.com Thu Jul 25 14:52:46 2013 From: ralf.brunckhorst@hp.com (Brunckhorst, Ralf) Date: Thu, 25 Jul 2013 13:52:46 +0000 Subject: [OpenAFS] OpenAFS 1.6.5 .src.rpm on RHEL 5.x Fails with cpio: MD5 sum mismatch In-Reply-To: References: Message-ID: Ok, I will grab it from there. Thanks, Ralf Am 25.07.2013 um 14:03 schrieb Stephen Quinney >: You can grab a signed SRPM for RHEL5 from the /afs/inf.ed.ac.uk/group/afsbu= ild/1.6.5/rhel5 directory. = That's the source which was used to build the publically available RHEL5 RP= Ms. Stephen Quinney On 25 July 2013 12:47, Brunckhorst, Ralf > wrote: Hi, Similar issue with the src.rpm of the new version 1.6.5 like 1.6.2 Is it possible to fix this by providing a compatible src.rpm 1.6.5 for RHEL= 5? - Ralf From adeason@sinenomine.net Thu Jul 25 16:03:18 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 25 Jul 2013 10:03:18 -0500 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> Message-ID: <20130725100318.72d6d8a5.adeason@sinenomine.net> On Thu, 25 Jul 2013 09:11:38 -0400 (EDT) stephen@physics.unc.edu wrote: > In the cell rekeying instructions found at > , there is a note > for sites using Heimdal KDCs. It mentions a bug present in "certain > versions" of the Heimdal KDC software which completely disables DES on > the AFS service principal when following the document's instructions. > > Is more information available about specific versions of the Heimdal > KDC software which exhibits this bug? The document mentions > experimentally verifying ticket acquisition, which seems wise. But > also knowing the KDC versions which have the bug would be beneficial. Sorry about that; this was raised very shortly before the issue became public; I wanted this note to be in there even if we couldn't provide full information, so you would be aware that _something_ was wrong with this. Allegedly it exists in 1.4 and possibly all earlier versions, and is fixed somewhere around 1.5. However, it has apparently been fixed reintroduced a couple of times, so I'm not sure if such a simple versions range is accurate. All I've actually verified so far is that it definitely is a problem on Debian's 1.4.0~git20100726.dfsg.1-2+squeeze1. > Anyone have this info? Should I post to a heimdal list instead? I'm looking around for some kind of reference I can provide for the issue or something. For now, if you want more info, you can ask the heimdal list; I'll probably do that later, but if you get to it before me, it would be helpful :) -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Thu Jul 25 16:07:32 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 25 Jul 2013 10:07:32 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? References: <51F0E87D.8060009@cgv.tugraz.at> Message-ID: <20130725100732.6cd54e24.adeason@sinenomine.net> On Thu, 25 Jul 2013 10:57:33 +0200 Lars Schimmer wrote: > Maybe I am not the best reader, but if I do use a win AD as a krb5 > auth service and I did not change anything with my keyfiles and > everything, should OpenAFS 1.7.26 on Windows work as usual? I didn't have anything to do with the Windows client part of this, but yes, that's my understanding. For any platform, this release should behave the same as the previous one if you don't do anything with changing the keys or enctypes, etc. -- Andrew Deason adeason@sinenomine.net From kaduk@MIT.EDU Thu Jul 25 16:36:52 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 25 Jul 2013 11:36:52 -0400 (EDT) Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <20130725100732.6cd54e24.adeason@sinenomine.net> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> Message-ID: On Thu, 25 Jul 2013, Andrew Deason wrote: > On Thu, 25 Jul 2013 10:57:33 +0200 > Lars Schimmer wrote: > >> Maybe I am not the best reader, but if I do use a win AD as a krb5 >> auth service and I did not change anything with my keyfiles and >> everything, should OpenAFS 1.7.26 on Windows work as usual? > > I didn't have anything to do with the Windows client part of this, but > yes, that's my understanding. For any platform, this release should > behave the same as the previous one if you don't do anything with > changing the keys or enctypes, etc. I think the issue is actually a little more subtle. Prior to yesterday's releases, all (*) places that got tokens from a TGT explicitly requested a single-DES enctype for the session key. In yesterday's releases (including 1.7.26), these places no longer explicitly request single-DES, and use a KDF to convert any non-DES session keys to DES keys for use in the AFS wire protocol. In this new version of things, we rely on the KDC to only supply a DES session key if the AFS server does not support the KDF scheme. In principle, this is fine, since the afs service principal's long-term key must be single-DES for the (old) software to work at all, and in the absence of other information, the KDC should not assume that a service supports an enctype for which it has no long-term key. The short version is: a misconfigured KDC can cause problems for new clients against old servers. -Ben (*) klog.krb5 in 1.4.x did not do so; this was probably just an oversight long ago From adeason@sinenomine.net Thu Jul 25 16:55:02 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 25 Jul 2013 10:55:02 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> Message-ID: <20130725105502.ca630ccd.adeason@sinenomine.net> On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) Benjamin Kaduk wrote: > The short version is: a misconfigured KDC can cause problems for new > clients against old servers. If that's true, we need to say specifically what that misconfiguration is, so people can check for them and avoid it. I'm not aware of any way to create such a configuration (that behavior sounds instead like a KDC bug to me, without knowing any further details). In particular with AD, the AFS service account must already have the USE_DES_KEY_ONLY userAccountControl bit set in order for us to work at all with plain rxkad. Lars, do you know if the "Use Kerberos DES encryption types for this account" account option is checked for the AFS service account? Do you see any errors in wherever the Windows client normally logs errors? Can you access that path if you destroy your tokens? -- Andrew Deason adeason@sinenomine.net From kaduk@MIT.EDU Thu Jul 25 17:00:22 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 25 Jul 2013 12:00:22 -0400 (EDT) Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <20130725105502.ca630ccd.adeason@sinenomine.net> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> Message-ID: On Thu, 25 Jul 2013, Andrew Deason wrote: > On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) > Benjamin Kaduk wrote: > >> The short version is: a misconfigured KDC can cause problems for new >> clients against old servers. > > If that's true, we need to say specifically what that misconfiguration > is, so people can check for them and avoid it. I'm not aware of any way > to create such a configuration (that behavior sounds instead like a KDC > bug to me, without knowing any further details). I almost said "KDC bug", actually. :) As of MIT krb5 1.11, there are KDC knobs to control which enctypes are usable as session keys on a per-principal basis, independent of the long-term key enctypes. I don't know of any other KDCs for which this sort of thing is possible, but I know almost nothing about the AD KDC, and as your "how to rekey" document seems to show, there can be a lot of complicated settings in an AD KDC! -Ben From jaltman@secure-endpoints.com Thu Jul 25 17:07:32 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Thu, 25 Jul 2013 12:07:32 -0400 Subject: [OpenAFS] OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <51F0E87D.8060009@cgv.tugraz.at> References: <51F0E87D.8060009@cgv.tugraz.at> Message-ID: <51F14D44.1090503@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms060409080300060005000102 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/25/2013 4:57 AM, Lars Schimmer wrote: > Hi! >=20 > Maybe I am not the best reader, but if I do use a win AD as a krb5 auth= > service and I did not change anything with my keyfiles and everything, > should OpenAFS 1.7.26 on Windows work as usual? >=20 > As I tried on my system it did not work fine. > It did show a ticket/token, but it shows \\AFS\cgv.tugraz.at not > reachable at all. >=20 > And it added a strange icon on that drive-icon... >=20 > So, did I misread anything? >=20 > MfG, > Lars Schimmer Use Network Identity Manager or klist.exe (not the Windows version) to examine the contents of the credentials cache. In particular, look at the encryption types that are associated with the ticket. The Service EncType is the encryption type used to encrypt the private portion of the ticket which the service shares a key with the KDC. The Session EncType is the encryption type for the key which is distributed by the KDC to both the client and the service. If the session enctype is not DES-*-* then a DES-compatible key will be derived using rxkad-kdf. If the server and client do not agree on the key, there will be a failure. If the session enctype is not DES-*-* and you have not upgraded the server to know about rxkad-kdf, then the ticket will be rejected because the enctype is unknown. Jeffrey Altman --------------ms060409080300060005000102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzI1MTYwNzMyWjAjBgkqhkiG9w0BCQQxFgQUTk3wr5/5I92mRNqg2HDSA2w7wKEwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AFSKh9oAcVXCK/hC8pLS//YyWI0gIuw9JoW8720UsjX6ZdhMlbqftVqiKgwGFjAsNYZPeSgQ eJXWUAFqFJ53StBLavzWILmjAsns5QYAyGW4utuEY4TKeZ1SFC5ELa6dPnD71oiYJOoOpjNC 7sCbqBxk+q9L7p9m6M1QYsgp0mbytEBVNLuGXkA05N7VnuhMyaxG5Ped9eJhZ4d1SrrMDQ1/ laPdFnZeGnENlLc2IBzgaiaRavV6w1AqtYhdOix/rZQlHNbYTXF71YRMpgfDiCgwkd4V6yEs 8SKZ75o01UhalOGLp8Gbw0j2pVK72c2hePwK5ARYz7bZum3j3fw8FEEAAAAAAAA= --------------ms060409080300060005000102-- From adeason@sinenomine.net Thu Jul 25 17:38:46 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 25 Jul 2013 11:38:46 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> Message-ID: <20130725113846.bb44c747.adeason@sinenomine.net> On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) Benjamin Kaduk wrote: > and in the absence of other information, the KDC should not assume > that a service supports an enctype for which it has no long-term key. After thinking about this, it seems like we could make this more robust, if the KDC doesn't do this. The behavior we're desiring is that a KDC just _prefers_ using session key enctypes where it has an associated long-term key, if the client doesn't specify an enctype. Is that mandated by the Kerberos standards or anything? It seems like if the client doesn't specify an enctype, any enctype if possible. After all, if a client specifically requests e.g. a DES session key when the principal only has an AES long term key, we do get the DES session key (unless DES has been disabled kdc-wide or whatever). I know in draft-kaduk-afs3-rxkad-kdf-03 you/we explicitly say that KDCs need to not issue non-DES session keys when we only have a DES long-term key, but do they all actually do that? Is the reasoning there that a KDC that sees just a DES key should infer that the service only understands DES, since DES is a bit of a special case? It seems like we could try to request a DES session key, and if that fails due to a refused enctype, try again without specifically requesting DES. That's not what we do and not what draft-kaduk-afs3-rxkad-kdf-03 recommends, but wouldn't that be more likely to work? (Or do KDCs where this is a problem just not exist, and so this is pointless to think about?) -- Andrew Deason adeason@sinenomine.net From jhutz@cmu.edu Thu Jul 25 18:07:46 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 25 Jul 2013 13:07:46 -0400 Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> Message-ID: <1374772066.1046.107.camel@destiny.pc.cs.cmu.edu> On Thu, 2013-07-25 at 09:11 -0400, stephen@physics.unc.edu wrote: > Hi, > > In the cell rekeying instructions found at > , there is a note for > sites using Heimdal KDCs. It mentions a bug present in "certain versions" > of the Heimdal KDC software which completely disables DES on the AFS > service principal when following the document's instructions. > > Is more information available about specific versions of the Heimdal KDC > software which exhibits this bug? The document mentions experimentally > verifying ticket acquisition, which seems wise. But also knowing the KDC > versions which have the bug would be beneficial. > > Anyone have this info? Should I post to a heimdal list instead? The bug in question essentially means that issued service tickets will always have the same service and session key enctypes, so you must choose between sticking with DES and breaking all existing token-acquiring clients which do not have the new rxkad-kdf code introduced in OpenAFS 1.6.5 and 1.4.15. If I correctly remember my trip through the git repositories on Tuesday evening, the problem was most recently fixed prior to Heimdal 1.5.0, so if you are running that version you should not have a problem. To test, first perform the upgrade as described, but be careful that the new key set includes DES keys. A Heimdal KDC will not issue tickets with DES session keys if the service does not have a DES key in the Kerberos database. Once you've installed the rxkey.keytab files on all of your servers and made the new keys available in the Kerberos database, get fresh tickets and run aklog to get AFS tokens. Then run 'klist -v' and look at the entry for your AFS tickets. If you have an entry like the one below, showing both a non-des "Ticket etype" and a DES "Session key", then everything is working. If it shows only a DES "Ticket etype" and no separate "Session key" line, then your KDC has the bug. Example klist -v output (partial): > Server: afs@CS.CMU.EDU > Client: jhutz@CS.CMU.EDU > Ticket etype: des3-cbc-sha1, kvno 2 > Session key: des-cbc-crc > Ticket length: 237 > Auth time: Jul 25 11:55:20 2013 > Start time: Jul 25 11:55:21 2013 > End time: Jul 26 13:21:41 2013 > Ticket flags: transited-policy-checked, pre-authent, proxiable, forwardable > Addresses: addressless I'm afraid I can't say which all versions are affected. Searching through the tree I was able to find the bug fixed at least twice, once in 1997 and once in 2011. It was first reintroduced sometime in 1998 or 1999, but the comments on the 2011 commit lead me to believe that in the interim, it was at one point fixed and then reintroduced again. So, there are likely at least three ranges of heimdal versions which contain this bug, the most recent of which ends prior to version 1.5.0. [ -- Jeff From Sergio.Gelato@astro.su.se Thu Jul 25 18:12:11 2013 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Thu, 25 Jul 2013 19:12:11 +0200 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130725100318.72d6d8a5.adeason@sinenomine.net> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> Message-ID: <20130725171211.GA9756@hanuman.astro.su.se> * Andrew Deason [2013-07-25 10:03:18 -0500]: > On Thu, 25 Jul 2013 09:11:38 -0400 (EDT) > stephen@physics.unc.edu wrote: > > > In the cell rekeying instructions found at > > , there is a note > > for sites using Heimdal KDCs. It mentions a bug present in "certain > > versions" of the Heimdal KDC software which completely disables DES on > > the AFS service principal when following the document's instructions. > > > > Is more information available about specific versions of the Heimdal > > KDC software which exhibits this bug? The document mentions > > experimentally verifying ticket acquisition, which seems wise. But > > also knowing the KDC versions which have the bug would be beneficial. > > Sorry about that; this was raised very shortly before the issue became > public; I wanted this note to be in there even if we couldn't provide > full information, so you would be aware that _something_ was wrong with > this. > > Allegedly it exists in 1.4 and possibly all earlier versions, and is > fixed somewhere around 1.5. However, it has apparently been fixed > reintroduced a couple of times, so I'm not sure if such a simple > versions range is accurate. All I've actually verified so far is that it > definitely is a problem on Debian's 1.4.0~git20100726.dfsg.1-2+squeeze1. I've been poking a bit into this. First of all, let's make sure I don't misunderstand your expectation here: do you want the KDC to be willing to issue a ticket with a des-cbc-crc session key (as requested by old aklog) even though the afs service principal does not have that enctype? Or are we Heimdal users expected to add that enctype to afs/cell whenever we rekey? The latter works with the Heimdal KDCs I've tried (the pre-1.4.0 from Debian squeeze and the pre-1.6 from Debian wheezy), the former doesn't. The relevant code seems to be in kdc/kerberos5.c:_kdc_find_etype(). It was reworked in 2011, largely by Nico Williams, to use a new session key enctype selection algorithm (controlled by {tgt,svc,preauth}-use-strongest-session-key in krb5.conf, and now on by default) as an alternative to the old one. The old code, which the comments claim conforms to RFC4120, still cannot select an enctype that isn't in the intersection of the principal's and the client's lists. The new code looks like it should (provided that allow_weak_crypto=true for the KDC; the _kdc_is_weak_exception() mechanism won't help here) as a last resort, except it forgets to set ret=0 in the relevant code path (after "enctype = clientbest;"). It looks like the bug might still be there at the tip of the master branch as of this writing. I'll try to test my putative fix later tonight. From jhutz@cmu.edu Thu Jul 25 18:23:54 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Thu, 25 Jul 2013 13:23:54 -0400 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <20130725113846.bb44c747.adeason@sinenomine.net> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725113846.bb44c747.adeason@sinenomine.net> Message-ID: <1374773034.1046.117.camel@destiny.pc.cs.cmu.edu> On Thu, 2013-07-25 at 11:38 -0500, Andrew Deason wrote: > On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) > Benjamin Kaduk wrote: > > > and in the absence of other information, the KDC should not assume > > that a service supports an enctype for which it has no long-term key. > > After thinking about this, it seems like we could make this more robust, > if the KDC doesn't do this. The behavior we're desiring is that a KDC > just _prefers_ using session key enctypes where it has an associated > long-term key, if the client doesn't specify an enctype. Huh? No, the client doesn't specify an enctype; it provides a list of the enctypes it supports. If the list is empty, the authentication will fail. At the API layer, Kerberos libraries generally offer the ability for an application not to specify particular enctypes; what this means is that the library sends a list of everything it supports (or, in some circumstances, perhaps the intersection of "everything it supports" with "everything in this keytab"). The text in RFC4120 is unfortunately scattered and a bit vague, but the intent is that the KDC must select an enctype from the client-provided list. Further, it must select an enctype which is supported by the target service. Both MIT and Heimdal determine this based on the list of enctypes stored for that service in the Kerberos database. So, the selected session key must use an enctype that is both on the client's list _and_ in the service's list of long-term keys. > if a client specifically requests e.g. a DES session key when the > principal only has an AES long term key, we do get the DES session key > (unless DES has been disabled kdc-wide or whatever). This happens only with an MIT Kerberos KDC, which assumes that services support DES-CBC-MD5 even when they have no keys of that type. This is a reasonable assumption because implementation of DES-CBC-MD5 is mandatory. However, this thread is about Windows, not MIT or Heimdal. From rra@stanford.edu Thu Jul 25 19:05:33 2013 From: rra@stanford.edu (Russ Allbery) Date: Thu, 25 Jul 2013 11:05:33 -0700 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130725171211.GA9756@hanuman.astro.su.se> (Sergio Gelato's message of "Thu, 25 Jul 2013 19:12:11 +0200") References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> Message-ID: <87vc3ya51u.fsf@windlord.stanford.edu> Sergio Gelato writes: > I've been poking a bit into this. First of all, let's make sure I don't > misunderstand your expectation here: do you want the KDC to be willing to > issue a ticket with a des-cbc-crc session key (as requested by old aklog) > even though the afs service principal does not have that enctype? That's correct. -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Thu Jul 25 20:11:15 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 25 Jul 2013 14:11:15 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725113846.bb44c747.adeason@sinenomine.net> <1374773034.1046.117.camel@destiny.pc.cs.cmu.edu> Message-ID: <20130725141115.7875d026.adeason@sinenomine.net> On Thu, 25 Jul 2013 13:23:54 -0400 Jeffrey Hutzelman wrote: > > After thinking about this, it seems like we could make this more > > robust, if the KDC doesn't do this. The behavior we're desiring is > > that a KDC just _prefers_ using session key enctypes where it has an > > associated long-term key, if the client doesn't specify an enctype. > > Huh? No, the client doesn't specify an enctype; it provides a list of > the enctypes it supports. Whatever; "if the client application doesn't specify a specific enctype and the client machine sends a list of all the enctypes it understands". > The text in RFC4120 is unfortunately scattered and a bit vague, but > the intent is that the KDC must select an enctype from the > client-provided list. Further, it must select an enctype which is > supported by the target service. Both MIT and Heimdal determine this > based on the list of enctypes stored for that service in the Kerberos > database. So, the selected session key must use an enctype that is > both on the client's list _and_ in the service's list of long-term > keys. Okay, but that's not what happens for MIT in this specific case, as you mention below. > > if a client specifically requests e.g. a DES session key when the > > principal only has an AES long term key, we do get the DES session key > > (unless DES has been disabled kdc-wide or whatever). > > This happens only with an MIT Kerberos KDC, which assumes that > services support DES-CBC-MD5 even when they have no keys of that type. > This is a reasonable assumption because implementation of DES-CBC-MD5 > is mandatory. This answers my question, and indicates that if the client requests e.g. {des-cbc-crc, aes256-cts}, and the service princ only has a DES key, we will not get back an AES session key. My understanding after reading your response is that at the very least, the possibility of getting back an AES session key in that situation is not a practical concern (whether or not it would be considered "incorrect"). > However, this thread is about Windows, not MIT or Heimdal. Yes, well, threads can wander. As far as I can tell, Windows AD doesn't do anything like this, and only Heimdal is possibly a problem, so anything further on this will probably go in the Heimdal thread. -- Andrew Deason adeason@sinenomine.net From kaduk@MIT.EDU Thu Jul 25 20:16:37 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 25 Jul 2013 15:16:37 -0400 (EDT) Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <20130725113846.bb44c747.adeason@sinenomine.net> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725113846.bb44c747.adeason@sinenomine.net> Message-ID: I think jhutz has covered most of the points already, but: On Thu, 25 Jul 2013, Andrew Deason wrote: > On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) > Benjamin Kaduk wrote: > >> and in the absence of other information, the KDC should not assume >> that a service supports an enctype for which it has no long-term key. > > After thinking about this, it seems like we could make this more robust, > if the KDC doesn't do this. The behavior we're desiring is that a KDC > just _prefers_ using session key enctypes where it has an associated > long-term key, if the client doesn't specify an enctype. Is that > mandated by the Kerberos standards or anything? It seems like if the > client doesn't specify an enctype, any enctype if possible. After all, > if a client specifically requests e.g. a DES session key when the > principal only has an AES long term key, we do get the DES session key > (unless DES has been disabled kdc-wide or whatever). > > I know in draft-kaduk-afs3-rxkad-kdf-03 you/we explicitly say that KDCs > need to not issue non-DES session keys when we only have a DES long-term > key, but do they all actually do that? Is the reasoning there that a KDC As jhutz said, MIT and Heimdal do. I assume that AD has some mechanism to cope with application servers that don't speak AES, though I don't know what exactly the mechanism is. > that sees just a DES key should infer that the service only understands > DES, since DES is a bit of a special case? Not a special case, just the standard use of the service principals key list as a proxy for what enctypes it supports. If the list has only one element, then only one enctype is supported. > It seems like we could try to request a DES session key, and if that > fails due to a refused enctype, try again without specifically > requesting DES. That's not what we do and not what > draft-kaduk-afs3-rxkad-kdf-03 recommends, but wouldn't that be more > likely to work? (Or do KDCs where this is a problem just not exist, and > so this is pointless to think about?) Asking for a DES session key first would unnecessarily weaken the session key for some clients. I don't think there are really standard C APIs for getting and parsing the contents of an error packet, so it seems like this would be quite unpleasant to try and implement, and would also introduce delays into normal operation. I don't think it's worth pursuing this route. -Ben From kaduk@MIT.EDU Thu Jul 25 20:22:50 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 25 Jul 2013 15:22:50 -0400 (EDT) Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130725171211.GA9756@hanuman.astro.su.se> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> Message-ID: On Thu, 25 Jul 2013, Sergio Gelato wrote: > I've been poking a bit into this. First of all, let's make sure I don't > misunderstand your expectation here: do you want the KDC to be willing to > issue a ticket with a des-cbc-crc session key (as requested by old aklog) > even though the afs service principal does not have that enctype? Or are > we Heimdal users expected to add that enctype to afs/cell whenever we > rekey? The latter works with the Heimdal KDCs I've tried (the pre-1.4.0 > from Debian squeeze and the pre-1.6 from Debian wheezy), the former doesn't. If the KDC is in a state where it must choose a session key enctype in the intersection of the service principal's keys and the client's list, then the latter should always work. The DES key for the afs/cell principal will need to be entered into the KeyFile or removed from the rxkad.keytab in order for server-to-server authentication to work, though. > The relevant code seems to be in kdc/kerberos5.c:_kdc_find_etype(). It was > reworked in 2011, largely by Nico Williams, to use a new session key enctype > selection algorithm (controlled by {tgt,svc,preauth}-use-strongest-session-key > in krb5.conf, and now on by default) as an alternative to the old one. The > old code, which the comments claim conforms to RFC4120, still cannot select > an enctype that isn't in the intersection of the principal's and the client's > lists. The new code looks like it should (provided that allow_weak_crypto=true > for the KDC; the _kdc_is_weak_exception() mechanism won't help here) as a > last resort, except it forgets to set ret=0 in the relevant code path > (after "enctype = clientbest;"). It looks like the bug might still be there > at the tip of the master branch as of this writing. I'll try to test my > putative fix later tonight. Thanks for looking into this. -Ben From deengert@anl.gov Thu Jul 25 20:35:20 2013 From: deengert@anl.gov (Douglas E. Engert) Date: Thu, 25 Jul 2013 14:35:20 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725113846.bb44c747.adeason@sinenomine.net> Message-ID: <51F17DF8.9040609@anl.gov> On 7/25/2013 2:16 PM, Benjamin Kaduk wrote: > I think jhutz has covered most of the points already, but: > > On Thu, 25 Jul 2013, Andrew Deason wrote: > >> On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) >> Benjamin Kaduk wrote: >> >>> and in the absence of other information, the KDC should not assume >>> that a service supports an enctype for which it has no long-term key. >> >> After thinking about this, it seems like we could make this more robust, >> if the KDC doesn't do this. The behavior we're desiring is that a KDC >> just _prefers_ using session key enctypes where it has an associated >> long-term key, if the client doesn't specify an enctype. Is that >> mandated by the Kerberos standards or anything? It seems like if the >> client doesn't specify an enctype, any enctype if possible. After all, >> if a client specifically requests e.g. a DES session key when the >> principal only has an AES long term key, we do get the DES session key >> (unless DES has been disabled kdc-wide or whatever). >> >> I know in draft-kaduk-afs3-rxkad-kdf-03 you/we explicitly say that KDCs >> need to not issue non-DES session keys when we only have a DES long-term >> key, but do they all actually do that? Is the reasoning there that a KDC > > As jhutz said, MIT and Heimdal do. I assume that AD has some mechanism to cope with application servers that don't speak AES, though I don't know what exactly the mechanism is. > AD has these attributes for an account attributes: http://support.microsoft.com/kb/305144 The userAccountControl USE_DES_KEY_ONLY and with AD 2008: http://msdn.microsoft.com/en-us/library/cc223853.aspx msDS-SupportedEncrtptionTypes msktutil can set this using --enctypes n where n is the decimal value of the msDS-SupportedEncrtptionTypes >> that sees just a DES key should infer that the service only understands >> DES, since DES is a bit of a special case? > > Not a special case, just the standard use of the service principals key list as a proxy for what enctypes it supports. If the list has only one element, then only one enctype is supported. > >> It seems like we could try to request a DES session key, and if that >> fails due to a refused enctype, try again without specifically >> requesting DES. That's not what we do and not what >> draft-kaduk-afs3-rxkad-kdf-03 recommends, but wouldn't that be more >> likely to work? (Or do KDCs where this is a problem just not exist, and >> so this is pointless to think about?) > > Asking for a DES session key first would unnecessarily weaken the session key for some clients. I don't think there are really standard C APIs for getting and parsing the contents of an error packet, > so it seems like this would be quite unpleasant to try and implement, and would also introduce delays into normal operation. I don't think it's worth pursuing this route. > > -Ben > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From adeason@sinenomine.net Thu Jul 25 20:35:58 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 25 Jul 2013 14:35:58 -0500 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> Message-ID: <20130725143558.71bf8936.adeason@sinenomine.net> On Thu, 25 Jul 2013 15:22:50 -0400 (EDT) Benjamin Kaduk wrote: > On Thu, 25 Jul 2013, Sergio Gelato wrote: > > > I've been poking a bit into this. First of all, let's make sure I > > don't misunderstand your expectation here: do you want the KDC to be > > willing to issue a ticket with a des-cbc-crc session key (as > > requested by old aklog) even though the afs service principal does > > not have that enctype? That was the idea. But that doesn't work, as you've seen. Sorry about that; we were trying a lot of different KDC/configuration combinations... > > Or are we Heimdal users expected to add that enctype to afs/cell > > whenever we rekey? That appears to be what you'll need to do, unless you can change the KDC's behavior. If you're expecting to be rekeying the AFS princ regularly or frequently, though... doing that is still usually a disruptive operation, even without this changing-enctype stuff for transitioning to rxkad-k5/rxkad-kdf. That won't change until the Kerberos tools improve. > If the KDC is in a state where it must choose a session key enctype in > the intersection of the service principal's keys and the client's > list, then the latter should always work. The DES key for the > afs/cell principal will need to be entered into the KeyFile or removed > from the rxkad.keytab in order for server-to-server authentication to > work, though. Or just run add_enctype after you extract the keytab. That seems like the easiest way to account for this in the instructions. While I recall it being mentioned that add_enctype may be a relatively new feature, having different enctypes for the service ticket and the session key at all also appears "new", so maybe that is moot. -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Thu Jul 25 20:47:02 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 25 Jul 2013 14:47:02 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725113846.bb44c747.adeason@sinenomine.net> Message-ID: <20130725144702.374d613f.adeason@sinenomine.net> On Thu, 25 Jul 2013 15:16:37 -0400 (EDT) Benjamin Kaduk wrote: > > I know in draft-kaduk-afs3-rxkad-kdf-03 you/we explicitly say that > > KDCs need to not issue non-DES session keys when we only have a DES > > long-term key, but do they all actually do that? Is the reasoning > > there that a KDC > > As jhutz said, MIT and Heimdal do. (except for the exception, which is why I was confused) > I assume that AD has some mechanism to cope with application servers > that don't speak AES, though I don't know what exactly the mechanism > is. While AD doesn't store "keys" like Heimdal and MIT do, it does have a separate setting for "these are the enctypes supported by this princ", which for the current conversation serves the same purpose as the key list for MIT or Heimdal. Like MIT, it appears to only issue session keys with enctypes in that enctype list, with the sole exception of single DES, which is always allowed if DES is turned on for the KDC. (It is turned off by default in Server 2008 or 2008 R2 or somewhere around there.) > Asking for a DES session key first would unnecessarily weaken the > session key for some clients. You're deriving a DES key either way... but yes, the point is moot, I think. -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Thu Jul 25 23:29:26 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Thu, 25 Jul 2013 17:29:26 -0500 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> Message-ID: <20130725172926.fbad6170.adeason@sinenomine.net> On Thu, 25 Jul 2013 19:12:11 +0200 Sergio Gelato wrote: > I've been poking a bit into this. First of all, let's make sure I > don't misunderstand your expectation here: do you want the KDC to be > willing to issue a ticket with a des-cbc-crc session key (as requested > by old aklog) even though the afs service principal does not have that > enctype? Or are we Heimdal users expected to add that enctype to > afs/cell whenever we rekey? The latter works with the Heimdal KDCs > I've tried (the pre-1.4.0 from Debian squeeze and the pre-1.6 from > Debian wheezy), the former doesn't. Again, thanks for looking into this and raising these questions. Even if you find or develop a fix for the Heimdal KDC, most existing Heimdal KDCs will still have this problem, so how-to-rekey.txt needs some changes. If you could look at (the actual diff is currently here: ), I'm sure we would appreciate your input on whether you agree with the updated text. -- Andrew Deason adeason@sinenomine.net From stephen@physics.unc.edu Thu Jul 25 23:34:45 2013 From: stephen@physics.unc.edu (stephen@physics.unc.edu) Date: Thu, 25 Jul 2013 18:34:45 -0400 (EDT) Subject: [OpenAFS] More questions about the re-keying document Message-ID: First, I don't think I said this before, but to whomever wrote the rekeying document and the instructions for 1.4 and 1.6, thanks! It's great that these were available immediately, at the same time as the security vulnerability. I also think that eliminating DES is worth the pain of re-keying a cell and upgrading clients, so a BIG thank you to Derrick Brashear, Alexander Chernyakhovsky, Andrew Deason, Chaskiel M Grundman and Benjamin Kaduk for developing the patches. In going over the re-keying document, a few more questions popped into my mind that weren't clear from my reading of the document. In the "Basic" procedure for MIT, it mentions ensuring that DES should not be one of the encryption types in the rxkad.keytab file. I assume this isn't a technical reason, but that having it there would allow its continued use (so no gain in rekeying). However in the "Basic" procedure for Heimdal, it does not mention any such caution. My site's KDC is Heimdal and does include DES by default. I assume I should similarly ensure DES isn't in the keytab (similar to the advice in the MIT section)? What the best practice for having enctypes availble on a principal on the KDC vs. in the keytab. Obviously the keytab enctypes must be the same as, or a subset of, the principal's enctypes. Does it hurt if DES (or other undesired salts) exist for the afs/cell@REALM principal as long as they're not in the rxkad.keytab file? Cheers, Stephen -- Stephen Joyce Systems Specialist College of Arts and Sciences University of North Carolina at Chapel Hill voice: 919.962.7214 fax: 919.962.0480 From kaduk@MIT.EDU Fri Jul 26 00:12:54 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 25 Jul 2013 19:12:54 -0400 (EDT) Subject: [OpenAFS] More questions about the re-keying document In-Reply-To: References: Message-ID: On Thu, 25 Jul 2013, stephen@physics.unc.edu wrote: > In going over the re-keying document, a few more questions popped into my > mind that weren't clear from my reading of the document. > > In the "Basic" procedure for MIT, it mentions ensuring that DES should not be > one of the encryption types in the rxkad.keytab file. I assume this isn't a > technical reason, but that having it there would allow its continued use (so > no gain in rekeying). This is actually a little subtle. DES keys in the rxkad.keytab will not be used to decrypt incoming tokens (the codepath for tokens whose krb5 tickets are encrypted with a DES enctype looks in the KeyFile, since we kept that codepath largely unchaged). For *outgoing* connections, all keys in the rxkad.keytab are fair game; the key is selected by krb5_kt_get_entry(..., /*kvno*/ 0, /*enctype*/ 0, ...), so the library picks a default entry. For MIT krb5, this should end up being the strongest key (so, aes256); with Heimdal, this is not always the case. I've seen at least one report of Heimdal's krb5_kt_get_entry() picking a DES key, which of course wasn't in the KeyFile on the receiving end and connections failed. There's another MIT-specific reason to not include a DES key in the rxkad.keytab, namely that the MIT KDC does not set requires_preauth on new principals by default. This means that if there's a DES key in the KDB, an unauthenticated attacker can make an AS_REQ with the afs principal as the "client principal", and claim to only support des-cbc-crc. Since preauthentication is not required, the KDC will create an AS_REP and use the DES key from the KDB to encrypt the reply. Now the attacker has a plaintext/ciphertext pair with which to mount an offline brute force attack. The MIT KDC will always (*) assume that any principal supports a single-DES enctype (which is mandatory to implement), so even though the afs service principal does not have a DES key in the KDB, single-DES session keys will still be issued, allowing unpatched clients to work against the patched server. (*) With the MIT krb5 1.11 release, there are ways to disable this "always assume DES is supported" behavior, though the default behavior has not changed. > However in the "Basic" procedure for Heimdal, it does not mention any such > caution. My site's KDC is Heimdal and does include DES by default. I assume I > should similarly ensure DES isn't in the keytab (similar to the advice in the > MIT section)? Heimdal's behavior about session key selection has varied quite a bit over time (there is a pending update to the rekeying document which attempts to cover this in more detail), and in some cases it is necessary to have a DES key in the KDB for the afs service principal in order for a DES session key to be generated (that is, for unpatched clients to continue to work). Heimdal also (I am told) requires preauthentication by default, so the unauthenticated attacker cannot just ask the KDC for a ticket to attack. > What the best practice for having enctypes availble on a principal on the KDC > vs. in the keytab. Obviously the keytab enctypes must be the same as, or a > subset of, the principal's enctypes. Does it hurt if DES (or other undesired > salts) exist for the afs/cell@REALM principal as long as they're not in the > rxkad.keytab file? This does end up depending on the KDC, and the KDC configuration. In some cases it is necessary to have the DES key in the KDB (in order to allow DES session keys), but if preauthentication is required, it is not harmful to do so. If a DES key is in the rxkad.keytab, it must also be in the KeyFile. Some versions of Heimdal have a KDC bug wherein the ticket enctype is always the same as the session key enctype; in these cases the DES key is needed in the rxkad.keytab (and the KeyFile). In all other cases, you should not have the DES key in the rxkad.keytab or KeyFile. You can check whether your Heimdal KDC has this bug by using a DES-only client (with default_tgs_enctypes in krb5.conf, if needed) to request a service ticket (say, with kgetcred) for a service that has a non-DES key in the KDB. If 'klist -v' shows the Ticket etype as being des (as well as the sesion etype), then the KDC is buggy. -Ben From kaduk@MIT.EDU Fri Jul 26 00:35:34 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Thu, 25 Jul 2013 19:35:34 -0400 (EDT) Subject: [OpenAFS] More questions about the re-keying document In-Reply-To: References: Message-ID: On Thu, 25 Jul 2013, Benjamin Kaduk wrote: > There's another MIT-specific reason to not include a DES key in the > rxkad.keytab, namely that the MIT KDC does not set requires_preauth on new > principals by default. This means that if there's a DES key in the KDB, an > unauthenticated attacker can make an AS_REQ with the afs principal as the > "client principal", and claim to only support des-cbc-crc. Since > preauthentication is not required, the KDC will create an AS_REP and use the > DES key from the KDB to encrypt the reply. Now the attacker has a > plaintext/ciphertext pair with which to mount an offline brute force attack. I should note that just setting the requires_preauth flag on the afs service principal to prevent this attack is not a good idea. Unfortunately, the same flag is used to indicate different things when a principal is acting as a client and when it is acting as a server. Here, we want the client behavior, requiring preauthentication before initial credentials are granted. The service behavior is that the flag causes the KDC to require clients to present credentials which were obtained using preauthentication, before the KDC will issue a service ticket for this service principal. If the afs service principal does not have the flag set, it is likely that user principals do not as well, so in effect users will be locked out of accessing AFS. -Ben From jason@rampaginggeek.com Fri Jul 26 00:43:04 2013 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Thu, 25 Jul 2013 19:43:04 -0400 Subject: [OpenAFS] OpenAFS 1.6.5 .src.rpm on RHEL 5.x Fails with cpio: MD5 sum mismatch In-Reply-To: References: Message-ID: <51F1B808.2010201@rampaginggeek.com> On 07/25/2013 07:47 AM, Brunckhorst, Ralf wrote: > Hi, > > Similar issue with the src.rpm of the new version 1.6.5 like 1.6.2 > Is it possible to fix this by providing a compatible src.rpm 1.6.5 for RHEL5? > > > - Ralf > > Run "rpm -i --nomd5 openafs-1.6.5.src.rpm" to install it. RHEL5 doesn't support the checksum used by newer versions of the RPM command. I don't think that the "rpm --rebuild" command works, but you can install then build from the spec file. From l.schimmer@cgv.tugraz.at Fri Jul 26 07:56:44 2013 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Fri, 26 Jul 2013 08:56:44 +0200 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <20130725105502.ca630ccd.adeason@sinenomine.net> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> Message-ID: <51F21DAC.2060409@cgv.tugraz.at> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JAVIBOSXNGRTUOCXKWJQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-25 17:55, Andrew Deason wrote: > On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) > Benjamin Kaduk wrote: >=20 >> The short version is: a misconfigured KDC can cause problems for new >> clients against old servers. >=20 > If that's true, we need to say specifically what that misconfiguration > is, so people can check for them and avoid it. I'm not aware of any way= > to create such a configuration (that behavior sounds instead like a KDC= > bug to me, without knowing any further details). >=20 > In particular with AD, the AFS service account must already have the > USE_DES_KEY_ONLY userAccountControl bit set in order for us to work at > all with plain rxkad. Lars, do you know if the "Use Kerberos DES > encryption types for this account" account option is checked for the AF= S > service account? Do you see any errors in wherever the Windows client > normally logs errors? Can you access that path if you destroy your > tokens? It is a bit more subtile. Yes, the AFS service account has DES only activated. klist -e on liunux shows me: 2013-07-26 08:50:42 2013-07-27 08:51:58 afs/cgv.tugraz.at@CGV.TUGRAZ.AT= Etype (skey, tkt): des-cbc-crc, des-cbc-crc (on a still old client). I updated 3 clients for a test on windows 7 to 1.7.26. One works fine, two show me a valid token on login, but the AfS path is not reachable at all ( \\AFS\.cgv.tugraz.at not reachable). MfG, Lars Schimmer --=20 ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ------enig2JAVIBOSXNGRTUOCXKWJQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHyHawACgkQmWhuE0qbFyOuGQCbBV00HJL+WWMEP0I9LmI3h3OO U+QAniqztK9EPZXrZrnkWBwCWqAKUUzi =IKbe -----END PGP SIGNATURE----- ------enig2JAVIBOSXNGRTUOCXKWJQ-- From Sergio.Gelato@astro.su.se Fri Jul 26 09:57:41 2013 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Fri, 26 Jul 2013 10:57:41 +0200 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130725143558.71bf8936.adeason@sinenomine.net> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> Message-ID: <20130726085741.GA2662@hanuman.astro.su.se> * Andrew Deason [2013-07-25 14:35:58 -0500]: > On Thu, 25 Jul 2013 15:22:50 -0400 (EDT) > Benjamin Kaduk wrote: > > > On Thu, 25 Jul 2013, Sergio Gelato wrote: > > > > > I've been poking a bit into this. First of all, let's make sure I > > > don't misunderstand your expectation here: do you want the KDC to be > > > willing to issue a ticket with a des-cbc-crc session key (as > > > requested by old aklog) even though the afs service principal does > > > not have that enctype? > > That was the idea. But that doesn't work, as you've seen. Sorry about > that; we were trying a lot of different KDC/configuration > combinations... > > > > Or are we Heimdal users expected to add that enctype to afs/cell > > > whenever we rekey? > > That appears to be what you'll need to do, unless you can change the > KDC's behavior. I've now succeeeded in changing the KDC's behavior. First of all, Heimdal's krb5.conf(5) man page states the wrong defaults (I've reported this bug). [kdc]svc-use-strongest-session-key is false by default, toggle it if you want to use the new session key selection algorithm. Secondly, the following patch is required: --- a/kdc/kerberos5.c +++ b/kdc/kerberos5.c @@ -183,9 +183,10 @@ } } if (clientbest != (krb5_enctype)ETYPE_NULL && - enctype == (krb5_enctype)ETYPE_NULL) + enctype == (krb5_enctype)ETYPE_NULL) { enctype = clientbest; - else if (enctype == (krb5_enctype)ETYPE_NULL) + ret = 0; + } else if (enctype == (krb5_enctype)ETYPE_NULL) ret = KRB5KDC_ERR_ETYPE_NOSUPP; if (ret == 0 && ret_enctype != NULL) *ret_enctype = enctype; I'll submit it to heimdal-bugs for consideration. > If you're expecting to be rekeying the AFS princ regularly or > frequently, though... doing that is still usually a disruptive > operation, even without this changing-enctype stuff for transitioning to > rxkad-k5/rxkad-kdf. That won't change until the Kerberos tools improve. Speaking of which, is anyone known to be working on rxkad-kdf support for Heimdal's libkafs? I'd like kinit --afslog to do the right thing. > > If the KDC is in a state where it must choose a session key enctype in > > the intersection of the service principal's keys and the client's > > list, then the latter should always work. The DES key for the > > afs/cell principal will need to be entered into the KeyFile or removed > > from the rxkad.keytab in order for server-to-server authentication to > > work, though. > > Or just run add_enctype after you extract the keytab. That seems like > the easiest way to account for this in the instructions. While I recall > it being mentioned that add_enctype may be a relatively new feature, > having different enctypes for the service ticket and the session key at > all also appears "new", so maybe that is moot. I've glanced at #10110 in Gerrit, will see if I have any constructive comments for you. I'd guess that early adopters of rxkad-k5 are likely to be running a sufficiently recent version of Heimdal (one with DES disabled by default). From ragge@csc.kth.se Fri Jul 26 10:43:57 2013 From: ragge@csc.kth.se (Ragnar Sundblad) Date: Fri, 26 Jul 2013 11:43:57 +0200 Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130726085741.GA2662@hanuman.astro.su.se> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> Message-ID: <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> On 26 jul 2013, at 10:57, Sergio Gelato = wrote: > * Andrew Deason [2013-07-25 14:35:58 -0500]: >> On Thu, 25 Jul 2013 15:22:50 -0400 (EDT) >> Benjamin Kaduk wrote: >>=20 >>> On Thu, 25 Jul 2013, Sergio Gelato wrote: >>>=20 >>>> I've been poking a bit into this. First of all, let's make sure I >>>> don't misunderstand your expectation here: do you want the KDC to = be >>>> willing to issue a ticket with a des-cbc-crc session key (as >>>> requested by old aklog) even though the afs service principal does >>>> not have that enctype? >>=20 >> That was the idea. But that doesn't work, as you've seen. Sorry about >> that; we were trying a lot of different KDC/configuration >> combinations... >>=20 >>>> Or are we Heimdal users expected to add that enctype to afs/cell >>>> whenever we rekey? >>=20 >> That appears to be what you'll need to do, unless you can change the >> KDC's behavior. >=20 > I've now succeeeded in changing the KDC's behavior. >=20 > First of all, Heimdal's krb5.conf(5) man page states the wrong = defaults > (I've reported this bug). [kdc]svc-use-strongest-session-key is false = by > default, toggle it if you want to use the new session key selection > algorithm. >=20 > Secondly, the following patch is required: > --- a/kdc/kerberos5.c > +++ b/kdc/kerberos5.c > @@ -183,9 +183,10 @@ > } > } > if (clientbest !=3D (krb5_enctype)ETYPE_NULL && > - enctype =3D=3D (krb5_enctype)ETYPE_NULL) > + enctype =3D=3D (krb5_enctype)ETYPE_NULL) { > enctype =3D clientbest; > - else if (enctype =3D=3D (krb5_enctype)ETYPE_NULL) > + ret =3D 0; > + } else if (enctype =3D=3D (krb5_enctype)ETYPE_NULL) > ret =3D KRB5KDC_ERR_ETYPE_NOSUPP; > if (ret =3D=3D 0 && ret_enctype !=3D NULL) > *ret_enctype =3D enctype; >=20 > I'll submit it to heimdal-bugs for consideration. I believe you should change the test to also check that ret_key =3D=3D = NULL: if (clientbest !=3D ETYPE_NULL && enctype =3D=3D ETYPE_NUL && = ret_key =3D=3D NULL) { enctype =3D clientbest; ret =3D 0; } since if there is no common key-type, key will be NULL, and the later if (ret =3D=3D 0 && ret_key !=3D NULL) *ret_key =3D key; will return a NULL pointer. Does your change really work as expected? (I am a bit surprised, since in krb5tgs.c:tgs_build_reply() the result of the enctype is ignored and the key is the one used (strangely!). But maybe I read it incorrectly, it is a bit... involved... /ragge From Sergio.Gelato@astro.su.se Fri Jul 26 11:18:07 2013 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Fri, 26 Jul 2013 12:18:07 +0200 Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> Message-ID: <20130726101806.GC4735@ebisu.astro.su.se> * Ragnar Sundblad [2013-07-26 11:43:57 +0200]: > > On 26 jul 2013, at 10:57, Sergio Gelato wrote: > > > Secondly, the following patch is required: > > --- a/kdc/kerberos5.c > > +++ b/kdc/kerberos5.c > > @@ -183,9 +183,10 @@ > > } > > } > > if (clientbest != (krb5_enctype)ETYPE_NULL && > > - enctype == (krb5_enctype)ETYPE_NULL) > > + enctype == (krb5_enctype)ETYPE_NULL) { > > enctype = clientbest; > > - else if (enctype == (krb5_enctype)ETYPE_NULL) > > + ret = 0; > > + } else if (enctype == (krb5_enctype)ETYPE_NULL) > > ret = KRB5KDC_ERR_ETYPE_NOSUPP; > > if (ret == 0 && ret_enctype != NULL) > > *ret_enctype = enctype; > > > > I'll submit it to heimdal-bugs for consideration. > > I believe you should change the test to also check that ret_key == NULL: > if (clientbest != ETYPE_NULL && enctype == ETYPE_NUL && ret_key == NULL) { > enctype = clientbest; > ret = 0; > } > since if there is no common key-type, key will be NULL, and the later > if (ret == 0 && ret_key != NULL) > *ret_key = key; > will return a NULL pointer. Yes, good point. > Does your change really work as expected? (I am a bit surprised, > since in krb5tgs.c:tgs_build_reply() the result of the enctype is > ignored and the key is the one used (strangely!). What version of krb5tgs.c are you looking at? What I see is ret = _kdc_find_etype(context, krb5_principal_is_krbtgt(context, sp) ? config->tgt_use_strongest_session_key : config->svc_use_strongest_session_key, FALSE, server, b->etype.val, b->etype.len, &etype, NULL); so ret_key (the last argument) is NULL. This is also consistent with my understanding that the session key is randomly generated by the KDC at the time of printing the ticket; it should be unrelated to any long-term keys. As for whether my change works, I'll admit that my testing was limited to verifying that I could get a service ticket (with AES for the ticket and DES for the session key) and a token with 1.6.4's aklog. Checking that the token is actually acceptable to AFS servers will come next. > But maybe I read it incorrectly, it is a bit... involved... > > /ragge > From jaltman@secure-endpoints.com Fri Jul 26 11:56:28 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 26 Jul 2013 06:56:28 -0400 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <51F21DAC.2060409@cgv.tugraz.at> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> Message-ID: <51F255DC.6050205@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms060007060305010706040004 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/26/2013 2:56 AM, Lars Schimmer wrote: > On 2013-07-25 17:55, Andrew Deason wrote: >> On Thu, 25 Jul 2013 11:36:52 -0400 (EDT) >> Benjamin Kaduk wrote: >> >>> The short version is: a misconfigured KDC can cause problems for new >>> clients against old servers. >> >> If that's true, we need to say specifically what that misconfiguration= >> is, so people can check for them and avoid it. I'm not aware of any wa= y >> to create such a configuration (that behavior sounds instead like a KD= C >> bug to me, without knowing any further details). >> >> In particular with AD, the AFS service account must already have the >> USE_DES_KEY_ONLY userAccountControl bit set in order for us to work at= >> all with plain rxkad. Lars, do you know if the "Use Kerberos DES >> encryption types for this account" account option is checked for the A= FS >> service account? Do you see any errors in wherever the Windows client >> normally logs errors? Can you access that path if you destroy your >> tokens? >=20 > It is a bit more subtile. > Yes, the AFS service account has DES only activated. klist -e on liunux= > shows me: > 2013-07-26 08:50:42 2013-07-27 08:51:58 afs/cgv.tugraz.at@CGV.TUGRAZ.= AT > Etype (skey, tkt): des-cbc-crc, des-cbc-crc >=20 > (on a still old client). >=20 > I updated 3 clients for a test on windows 7 to 1.7.26. One works fine, > two show me a valid token on login, but the AfS path is not reachable a= t > all ( \\AFS\.cgv.tugraz.at not reachable). What are the enctypes of the service tickets obtained on the Windows systems that do not work? The enctypes from a service ticket on Linux using the old client using the old algorithm are not comparable. --------------ms060007060305010706040004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzI2MTA1NjI4WjAjBgkqhkiG9w0BCQQxFgQUHOo3qs+RYEumo8KXDudjYjarqUcwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AHw6DXO7+GNM1JM2PlTdfrdoqH/6IAlAIA5Baip6iWGboBMRV1QZSCF+qx48y5TPkNsDqfJx bcqADilKoSVWSK8QavGSxu31bjXW3S+2ei+5uWiRLsLwPJzZp5A85IOhWOzMUuqCHy02u3ez V8IKN0XqKowY6q7Lb66by6ZOPPOFcAIbzP14SLn29ctzyV852J8GmZ+Jz4V347ZGGMn7HsS4 ou8bQPKZ+ILSQRhHdJyATb54OoTKtum5QA3YyEIYVxBVH5h+pOuIaFPH/UznerMr3wOTgr+q 8YSY4yaXkP5SyCTSSCjK90ll9Y/j3DfjeC+J52LDRskE9LYSyAGabK0AAAAAAAA= --------------ms060007060305010706040004-- From ragge@csc.kth.se Fri Jul 26 12:01:00 2013 From: ragge@csc.kth.se (Ragnar Sundblad) Date: Fri, 26 Jul 2013 13:01:00 +0200 Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130726101806.GC4735@ebisu.astro.su.se> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> Message-ID: <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> On 26 jul 2013, at 12:18, Sergio Gelato = wrote: > * Ragnar Sundblad [2013-07-26 11:43:57 +0200]: >>=20 >> On 26 jul 2013, at 10:57, Sergio Gelato = wrote: >>=20 >>> Secondly, the following patch is required: >>> --- a/kdc/kerberos5.c >>> +++ b/kdc/kerberos5.c >>> @@ -183,9 +183,10 @@ >>> } >>> } >>> if (clientbest !=3D (krb5_enctype)ETYPE_NULL && >>> - enctype =3D=3D (krb5_enctype)ETYPE_NULL) >>> + enctype =3D=3D (krb5_enctype)ETYPE_NULL) { >>> enctype =3D clientbest; >>> - else if (enctype =3D=3D (krb5_enctype)ETYPE_NULL) >>> + ret =3D 0; >>> + } else if (enctype =3D=3D (krb5_enctype)ETYPE_NULL) >>> ret =3D KRB5KDC_ERR_ETYPE_NOSUPP; >>> if (ret =3D=3D 0 && ret_enctype !=3D NULL) >>> *ret_enctype =3D enctype; >>>=20 >>> I'll submit it to heimdal-bugs for consideration. >>=20 >> I believe you should change the test to also check that ret_key =3D=3D = NULL: >> if (clientbest !=3D ETYPE_NULL && enctype =3D=3D ETYPE_NUL && = ret_key =3D=3D NULL) { >> enctype =3D clientbest; >> ret =3D 0; >> } >> since if there is no common key-type, key will be NULL, and the later >> if (ret =3D=3D 0 && ret_key !=3D NULL) >> *ret_key =3D key; >> will return a NULL pointer. >=20 > Yes, good point. (Please double check that this is correct, I haven't tried it, only read = it. :-) >> Does your change really work as expected? (I am a bit surprised, >> since in krb5tgs.c:tgs_build_reply() the result of the enctype is >> ignored and the key is the one used (strangely!). >=20 > What version of krb5tgs.c are you looking at? What I see is > ret =3D _kdc_find_etype(context, > krb5_principal_is_krbtgt(context, sp) = ? > config->tgt_use_strongest_session_key = : > = config->svc_use_strongest_session_key, FALSE, > server, b->etype.val, b->etype.len, = &etype, > NULL); > so ret_key (the last argument) is NULL. Aha! I am looking at 1.5.2, and there it is: ... server, b->etype.val, b->etype.len, = NULL, &skey); What version are you using? > This is also consistent with my understanding that the session key is > randomly generated by the KDC at the time of printing the ticket; it > should be unrelated to any long-term keys. It does generate a random key in 1.5.2 too, but the enctype of the session key is taken from the enctype of "skey" above, instead of from "etype" in your excerpt. ( krb5tgs.c 1.5.2: ... etype =3D skey->key.keytype; ... ret =3D krb5_generate_random_keyblock(context, etype, = &sessionkey); ... ) > As for whether my change works, I'll admit that my testing was limited = to > verifying that I could get a service ticket (with AES for the ticket = and > DES for the session key) and a token with 1.6.4's aklog. Checking that = the > token is actually acceptable to AFS servers will come next. Ok, that is quite good! (As I read it in 1.5.2 I think you shouldn't have gotten that far at all, I think...) Thanks for your work! /ragge From Sergio.Gelato@astro.su.se Fri Jul 26 12:33:08 2013 From: Sergio.Gelato@astro.su.se (Sergio Gelato) Date: Fri, 26 Jul 2013 13:33:08 +0200 Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> Message-ID: <20130726113307.GD4735@ebisu.astro.su.se> * Ragnar Sundblad [2013-07-26 13:01:00 +0200]: > >> I believe you should change the test to also check that ret_key == NULL: > >> if (clientbest != ETYPE_NULL && enctype == ETYPE_NUL && ret_key == NULL) { > >> enctype = clientbest; > >> ret = 0; > >> } > >> since if there is no common key-type, key will be NULL, and the later > >> if (ret == 0 && ret_key != NULL) > >> *ret_key = key; > >> will return a NULL pointer. > > > > Yes, good point. > > (Please double check that this is correct, I haven't tried it, only read it. :-) I'm compiling my next (and hopefully final) iteration right now. I went for this variant: if (clientbest != (krb5_enctype)ETYPE_NULL && enctype == (krb5_enctype)ETYPE_NULL) { enctype = clientbest; if (ret_key == NULL) ret = 0; } > >> Does your change really work as expected? (I am a bit surprised, > >> since in krb5tgs.c:tgs_build_reply() the result of the enctype is > >> ignored and the key is the one used (strangely!). > > > > What version of krb5tgs.c are you looking at? What I see is > > ret = _kdc_find_etype(context, > > krb5_principal_is_krbtgt(context, sp) ? > > config->tgt_use_strongest_session_key : > > config->svc_use_strongest_session_key, FALSE, > > server, b->etype.val, b->etype.len, &etype, > > NULL); > > so ret_key (the last argument) is NULL. > > Aha! I am looking at 1.5.2, and there it is: > ... > server, b->etype.val, b->etype.len, NULL, > &skey); > > What version are you using? I'm testing with Debian's 1.6~git20120403+dfsg1 but also looked at the tip of the master branch on github. > > This is also consistent with my understanding that the session key is > > randomly generated by the KDC at the time of printing the ticket; it > > should be unrelated to any long-term keys. > > It does generate a random key in 1.5.2 too, but the enctype of the > session key is taken from the enctype of "skey" above, instead of > from "etype" in your excerpt. Yes, that was changed by commits 12cd2c9cbd1ca027a3ef9ac7ab3e79526b1348ae and 4c6976a6bdf8a76c6f3c650ae970d46c931e5c71 (on the master branch). From l.schimmer@cgv.tugraz.at Fri Jul 26 13:07:46 2013 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Fri, 26 Jul 2013 14:07:46 +0200 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <51F255DC.6050205@secure-endpoints.com> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> Message-ID: <51F26692.500@cgv.tugraz.at> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GNSVKJUKKDKKFCSNLDTA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2013-07-26 12:56, Jeffrey Altman wrote: > What are the enctypes of the service tickets obtained on the Windows > systems that do not work? The enctypes from a service ticket on Linux= > using the old client using the old algorithm are not comparable. Ok, now with access to such a machine: krbtgt/CGV.TUGRAZ.AT@CGV.TUGRAZ.AT Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC afs/cgv.tugraz.at/CGV.TUGRAZ.AT Etype /skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with 96-bit SHA-1 HMAC On the working machine the AES-256 CTS is also some kind of DES. Interesting why one of three get 2 DES and non AES.... But yeah, that looks like new client tries to use AES-256 and fail. MfG, Lars Schimmer --=20 ------------------------------------------------------------- TU Graz, Institut f=C3=BCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ------enig2GNSVKJUKKDKKFCSNLDTA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHyZpIACgkQmWhuE0qbFyOpIACeKBZ8CK2q6ucxke2nGylT6bnA ff8Anj+r+XoHUzzakl9hYez9n+mBEgZJ =1ZF4 -----END PGP SIGNATURE----- ------enig2GNSVKJUKKDKKFCSNLDTA-- From stephen@physics.unc.edu Fri Jul 26 15:14:59 2013 From: stephen@physics.unc.edu (stephen@physics.unc.edu) Date: Fri, 26 Jul 2013 10:14:59 -0400 (EDT) Subject: [OpenAFS] More questions about the re-keying document In-Reply-To: References: Message-ID: On Thu, 25 Jul 2013, Benjamin Kaduk wrote: > Some versions of Heimdal have a KDC bug wherein the ticket enctype is always > the same as the session key enctype; in these cases the DES key is needed in > the rxkad.keytab (and the KeyFile). Forgive me if I'm missing an obvious answer, but in this situation, is the cell still vulnerable to the DES attack we're attempting to remediate? > In all other cases, you should not have > the DES key in the rxkad.keytab or KeyFile. You can check whether your > Heimdal KDC has this bug by using a DES-only client (with > default_tgs_enctypes in krb5.conf, if needed) to request a service ticket > (say, with kgetcred) for a service that has a non-DES key in the KDB. If > 'klist -v' shows the Ticket etype as being des (as well as the sesion etype), > then the KDC is buggy. > > -Ben Cheers, Stephen From adeason@sinenomine.net Fri Jul 26 15:45:13 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Jul 2013 09:45:13 -0500 Subject: [OpenAFS] Re: More questions about the re-keying document References: Message-ID: <20130726094513.7f26af09.adeason@sinenomine.net> On Thu, 25 Jul 2013 19:12:54 -0400 (EDT) Benjamin Kaduk wrote: > > In going over the re-keying document, a few more questions popped > > into my mind that weren't clear from my reading of the document. > > > > In the "Basic" procedure for MIT, it mentions ensuring that DES > > should not be one of the encryption types in the rxkad.keytab file. > > I assume this isn't a technical reason, but that having it there > > would allow its continued use (so no gain in rekeying). To summarize: in MIT you do not want any DES keys in rxkad.keytab or in the KDC's db. In Heimdal you do not want any DES keys in rxkad.keytab, but you must have a DES key in the KDC's db due to how it selects session keys. (This is for all versions of Heimdal; there are no version exceptions that I know of, besides a patch that Sergio is developing.) The reason we don't want them in the keytab is so we don't use them for server-to-server communication, and I think it's good to do so we don't accidentally accept a connection using the DES key. (Normally the latter is not a concern, since clients are not supposed to have influence over what service ticket enctype is used.) > Some versions of Heimdal have a KDC bug wherein the ticket enctype is > always the same as the session key enctype; in these cases the DES key > is needed in the rxkad.keytab (and the KeyFile). No, this is not what I'm recommending, since it doesn't solve the security issue at hand. The proposed changes to the document say that if you're running a Heimdal KDC with this bug, you just need to upgrade all clients first. If you have a DES key in the KDB for such a KDC, a client can make the KDC issue a DES service ticket, and so an attacker can crack that ticket, and use the cracked key against the servers (since they contain the relevant key in the KeyFile). The way I was recommending, if you upgrade all clients, they won't ever get a DES session key or service ticket (since they'll all request something stronger). If you access with a non-upgraded client, authenticated access will fail. I was considering saying to remove the DES key for KDCs with this bug, but I thought that may be a bit confusing, and doesn't help the situation much... -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Fri Jul 26 15:51:11 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Jul 2013 09:51:11 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> <51F26692.500@cgv.tugraz.at> Message-ID: <20130726095111.7110c68b.adeason@sinenomine.net> On Fri, 26 Jul 2013 14:07:46 +0200 Lars Schimmer wrote: > Ok, now with access to such a machine: > krbtgt/CGV.TUGRAZ.AT@CGV.TUGRAZ.AT > Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS > mode with 96-bit SHA-1 HMAC > afs/cgv.tugraz.at/CGV.TUGRAZ.AT > Etype /skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with > 96-bit SHA-1 HMAC > > On the working machine the AES-256 CTS is also some kind of DES. > Interesting why one of three get 2 DES and non AES.... Are you sure you have the "DES-only" account option set? Can you show what the userAccountControl and msDS-SupportedEncryptionTypes fields are for that account in LDAP? (You can see this either using ldapsearch from a unix machine if you don't know how in windows) Do you know what version of Windows Server this is? If the "des-only" attribute is set for the account, it looks like it's not being honored. -- Andrew Deason adeason@sinenomine.net From kaduk@MIT.EDU Fri Jul 26 16:03:12 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Fri, 26 Jul 2013 11:03:12 -0400 (EDT) Subject: [OpenAFS] Re: More questions about the re-keying document In-Reply-To: <20130726094513.7f26af09.adeason@sinenomine.net> References: <20130726094513.7f26af09.adeason@sinenomine.net> Message-ID: On Fri, 26 Jul 2013, Andrew Deason wrote: > On Thu, 25 Jul 2013 19:12:54 -0400 (EDT) > Benjamin Kaduk wrote: > >>> In going over the re-keying document, a few more questions popped >>> into my mind that weren't clear from my reading of the document. >>> >>> In the "Basic" procedure for MIT, it mentions ensuring that DES >>> should not be one of the encryption types in the rxkad.keytab file. >>> I assume this isn't a technical reason, but that having it there >>> would allow its continued use (so no gain in rekeying). > > To summarize: in MIT you do not want any DES keys in rxkad.keytab or in > the KDC's db. In Heimdal you do not want any DES keys in rxkad.keytab, > but you must have a DES key in the KDC's db due to how it selects > session keys. (This is for all versions of Heimdal; there are no version > exceptions that I know of, besides a patch that Sergio is developing.) > > The reason we don't want them in the keytab is so we don't use them for > server-to-server communication, and I think it's good to do so we don't > accidentally accept a connection using the DES key. (Normally the latter > is not a concern, since clients are not supposed to have influence over > what service ticket enctype is used.) > >> Some versions of Heimdal have a KDC bug wherein the ticket enctype is >> always the same as the session key enctype; in these cases the DES key >> is needed in the rxkad.keytab (and the KeyFile). > > No, this is not what I'm recommending, since it doesn't solve the > security issue at hand. The proposed changes to the document say that if > you're running a Heimdal KDC with this bug, you just need to upgrade all > clients first. Well, or upgrade/patch the KDC. Which might be preferable anyway -- giving the client control over the ticket enctype seems risky. > If you have a DES key in the KDB for such a KDC, a client can make the > KDC issue a DES service ticket, and so an attacker can crack that > ticket, and use the cracked key against the servers (since they contain > the relevant key in the KeyFile). This answers Stephen's follow-up question: "yes". -Ben From jhutz@cmu.edu Fri Jul 26 16:58:20 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Fri, 26 Jul 2013 11:58:20 -0400 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130726085741.GA2662@hanuman.astro.su.se> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> Message-ID: <1374854300.7322.40.camel@destiny.pc.cs.cmu.edu> On Fri, 2013-07-26 at 10:57 +0200, Sergio Gelato wrote: > Speaking of which, is anyone known to be working on rxkad-kdf support for > Heimdal's libkafs? I'd like kinit --afslog to do the right thing. It's on my todo list, but I won't complain if someone else gets there first. -- Jeff From adeason@sinenomine.net Fri Jul 26 17:15:32 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Jul 2013 11:15:32 -0500 Subject: [OpenAFS] Re: More questions about the re-keying document References: <20130726094513.7f26af09.adeason@sinenomine.net> Message-ID: <20130726111532.08bd2bf8.adeason@sinenomine.net> On Fri, 26 Jul 2013 09:45:13 -0500 Andrew Deason wrote: > To summarize: in MIT you do not want any DES keys in rxkad.keytab or > in the KDC's db. In Heimdal you do not want any DES keys in > rxkad.keytab, but you must have a DES key in the KDC's db due to how > it selects session keys. (This is for all versions of Heimdal; there > are no version exceptions that I know of, besides a patch that Sergio > is developing.) As someone else brought up with me, the above only applies if you care about supporting old clients. If you control all of the clients and upgrade all of them first, you don't need a DES key in Heimdal, and so you don't need to worry about a lot of this stuff. (This needs to be clarified in how-to-rekey.txt, too...) -- Andrew Deason adeason@sinenomine.net From shadow@gmail.com Fri Jul 26 21:15:14 2013 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 26 Jul 2013 16:15:14 -0400 Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130726113307.GD4735@ebisu.astro.su.se> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> <20130726113307.GD4735@ebisu.astro.su.se> Message-ID: --001a11c2f670f2ff0e04e26fccff Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 26, 2013 at 7:33 AM, Sergio Gelato wrote: > * Ragnar Sundblad [2013-07-26 13:01:00 +0200]: > > >> I believe you should change the test to also check that ret_key == > NULL: > > >> if (clientbest != ETYPE_NULL && enctype == ETYPE_NUL && > ret_key == NULL) { > > >> enctype = clientbest; > > >> ret = 0; > > >> } > > >> since if there is no common key-type, key will be NULL, and the later > > >> if (ret == 0 && ret_key != NULL) > > >> *ret_key = key; > > >> will return a NULL pointer. > > > > > > Yes, good point. > > > > (Please double check that this is correct, I haven't tried it, only read > it. :-) > > I'm compiling my next (and hopefully final) iteration right now. > I went for this variant: > if (clientbest != (krb5_enctype)ETYPE_NULL && > enctype == (krb5_enctype)ETYPE_NULL) { > enctype = clientbest; > if (ret_key == NULL) > ret = 0; > } > > This plus [kdc]svc-use-strongest- session-key=true Works. -- Derrick --001a11c2f670f2ff0e04e26fccff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 26, 2013 at 7:33 AM, Sergio Gelato &l= t;Sergio.Gel= ato@astro.su.se> wrote:
* Ragnar Sundblad [2013-0= 7-26 13:01:00 +0200]:
> >> I believe you should change the test to als= o check that ret_key =3D=3D NULL:
> >> =A0 =A0 =A0 =A0if (clientbest !=3D ETYPE_NULL && enct= ype =3D=3D ETYPE_NUL && ret_key =3D=3D NULL) {
> >> =A0 =A0 =A0 =A0 =A0 =A0enctype =3D clientbest;
> >> =A0 =A0 =A0 =A0 =A0 =A0ret =3D 0;
> >> =A0 =A0}
> >> since if there is no common key-type, key will be NULL, and t= he later
> >> =A0 =A0 =A0 =A0if (ret =3D=3D 0 && ret_key !=3D NULL)=
> >> =A0 =A0 =A0 =A0 =A0 =A0*ret_key =3D key;
> >> will return a NULL pointer.
> >
> > Yes, good point.
>
> (Please double check that this is correct, I haven't tried it, onl= y read it. :-)

I'm compiling my next (and hopefully final) iteration right now.<= br> I went for this variant:
=A0 =A0 =A0 =A0 if (clientbest !=3D (krb5_enctype)ETYPE_N= ULL &&
=A0 =A0 =A0 =A0 =A0 =A0 enctype =3D=3D (krb5_enctyp= e)ETYPE_NULL) {
=A0 =A0 =A0 =A0 =A0 =A0 enctype =3D clientbest;
=A0 =A0 =A0 =A0 =A0 =A0 if (ret_key =3D=3D NULL)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D 0;
=A0 =A0 =A0 =A0 }

This plus
[kdc]svc-use-strongest-
session-key=3Dtrue

Works.
=
--
Derrick
--001a11c2f670f2ff0e04e26fccff-- From adeason@sinenomine.net Fri Jul 26 21:30:06 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Jul 2013 15:30:06 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> <51F26692.500@cgv.tugraz.at> Message-ID: <20130726153006.16204d6a.adeason@sinenomine.net> On Fri, 26 Jul 2013 14:07:46 +0200 Lars Schimmer wrote: > Ok, now with access to such a machine: > krbtgt/CGV.TUGRAZ.AT@CGV.TUGRAZ.AT > Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS > mode with 96-bit SHA-1 HMAC > afs/cgv.tugraz.at/CGV.TUGRAZ.AT > Etype /skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with > 96-bit SHA-1 HMAC By any chance, do you happen to have the registry entry HKLM\SYSTEM\CurrentControlSet\services\kdc\KdcUseRequestedEtypesForTickets set to 1? That seems like it may cause that behavior, from a quck test I just did. I'm having trouble seeing what on earth that option is for. From what I can find on various sites, that makes the KDC use the client-specified enctype list for the service ticket enctype, ignoring the principal enctype settings (but still honoring the principal enctypes for the session key?). I'm having trouble seeing any scenario where that is not completely inappropriate (and a security issue!), let alone for AFS usage. I've seen this mentioned in a few AFS/Active Directory howtos, and I have no idea why. If anyone has some info to share... -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Fri Jul 26 21:39:22 2013 From: rra@stanford.edu (Russ Allbery) Date: Fri, 26 Jul 2013 13:39:22 -0700 Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: (Derrick Brashear's message of "Fri, 26 Jul 2013 16:15:14 -0400") References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> <20130726113307.GD4735@ebisu.astro.su.se> Message-ID: <87zjt9kqdh.fsf@windlord.stanford.edu> Derrick Brashear writes: > Sergio Gelato wrote: >> I'm compiling my next (and hopefully final) iteration right now. >> I went for this variant: >> if (clientbest != (krb5_enctype)ETYPE_NULL && >> enctype == (krb5_enctype)ETYPE_NULL) { >> enctype = clientbest; >> if (ret_key == NULL) >> ret = 0; >> } >> > This plus > [kdc]svc-use-strongest-session-key=true > Works. svc-use-strongest-session-key looks like it still tries to find something in the common subset of supported keys between the client and server, and legacy aklog sends only des-cbc-crc as its supported keys. So how could this work? Isn't there still no common subset with a principal that has no DES keys? And, in 1.5.2, since the server key is forced to the service key (per later discussion), if there *is* a DES key for the afs/* principal, doesn't that result in using a DES long-term key, thus making the update mostly pointless? -- Russ Allbery (rra@stanford.edu) From adeason@sinenomine.net Fri Jul 26 22:09:44 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Jul 2013 16:09:44 -0500 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> <20130726113307.GD4735@ebisu.astro.su.se> <87zjt9kqdh.fsf@windlord.stanford.edu> Message-ID: <20130726160944.a0e6fd1e.adeason@sinenomine.net> On Fri, 26 Jul 2013 13:39:22 -0700 Russ Allbery wrote: > > This plus > > [kdc]svc-use-strongest-session-key=true > > > Works. > > svc-use-strongest-session-key looks like it still tries to find > something in the common subset of supported keys between the client > and server, and legacy aklog sends only des-cbc-crc as its supported > keys. So how could this work? Isn't there still no common subset > with a principal that has no DES keys? That's what Sergio's patch above is supposed to fix, is my understanding (not that I've verified it). That is, with that patch in play, the KDC can now choose a session key enctype that is not one of the principal key enctypes. So, legacy aklog will get a des-cbc-crc session key when the service princ has no des-cbc-crc key. However, my reading of that patch says that the KDC, as a last resort, gives the client a session key no matching any principal key enctype. This is _not_ the same as the behavior in MIT Kerberos and AD; they only do this for the special case of single DES, not for just any enctype. I don't know if that's intentional or not, but it is different, and I'm not sure if that's desirable. I'm also not sure if it's intended/desirable for this to only be in the svc-use-strongest-session-key code path, but I may need to take a little more time to look at this... > And, in 1.5.2, since the server key is forced to the service key (per > later discussion), if there *is* a DES key for the afs/* principal, > doesn't that result in using a DES long-term key, thus making the > update mostly pointless? I thought we said that was fixed for 1.5 and beyond. But yes, if the session key and the service ticket must use the same enctype (1.4 Heimdal and earlier), yes that's a problem, and that's why I'm recommending _not_ extracting a DES key in any of these scenarios. That's why you need to upgrade all clients if you have a 1.4 Heimdal KDC, and don't want to upgrade it or patch it. -- Andrew Deason adeason@sinenomine.net From rra@stanford.edu Fri Jul 26 22:21:02 2013 From: rra@stanford.edu (Russ Allbery) Date: Fri, 26 Jul 2013 14:21:02 -0700 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130726160944.a0e6fd1e.adeason@sinenomine.net> (Andrew Deason's message of "Fri, 26 Jul 2013 16:09:44 -0500") References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> <20130726113307.GD4735@ebisu.astro.su.se> <87zjt9kqdh.fsf@windlord.stanford.edu> <20130726160944.a0e6fd1e.adeason@sinenomine.net> Message-ID: <87txjhj9vl.fsf@windlord.stanford.edu> Andrew Deason writes: > Russ Allbery wrote: >> svc-use-strongest-session-key looks like it still tries to find >> something in the common subset of supported keys between the client and >> server, and legacy aklog sends only des-cbc-crc as its supported keys. >> So how could this work? Isn't there still no common subset with a >> principal that has no DES keys? > That's what Sergio's patch above is supposed to fix, is my understanding > (not that I've verified it). That is, with that patch in play, the KDC > can now choose a session key enctype that is not one of the principal > key enctypes. So, legacy aklog will get a des-cbc-crc session key when > the service princ has no des-cbc-crc key. Oh! Oh, I understand now. (But *only* in the svc-use-strongest-session-key path? That's kind of weird. I would have expected that to be the behavior in either all paths or in only the path that's !svc-use-strongest-session-key. Oh, I see you say that below.) > However, my reading of that patch says that the KDC, as a last resort, > gives the client a session key no matching any principal key enctype. > This is _not_ the same as the behavior in MIT Kerberos and AD; they only > do this for the special case of single DES, not for just any enctype. I > don't know if that's intentional or not, but it is different, and I'm > not sure if that's desirable. Indeed. Although we're replacing one type of error with another type of error in the worst case, so it doesn't seem like a serious problem. > I'm also not sure if it's intended/desirable for this to only be in the > svc-use-strongest-session-key code path, but I may need to take a little > more time to look at this... Yeah, indeed. >> And, in 1.5.2, since the server key is forced to the service key (per >> later discussion), if there *is* a DES key for the afs/* principal, >> doesn't that result in using a DES long-term key, thus making the >> update mostly pointless? > I thought we said that was fixed for 1.5 and beyond. 1.5.2 still has the code pattern that was mentioned elsewhere in this thread, and, if the afs/* principal has DES keys, I'm seeing 1.5.2 return a ticket in which both the session and server key are des-cbc-crc. Sergio said that was fixed on the master branch. -- Russ Allbery (rra@stanford.edu) From shadow@gmail.com Fri Jul 26 22:25:09 2013 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 26 Jul 2013 17:25:09 -0400 Subject: [OpenAFS] Heimdal KDC bug mentioned in rekeying document In-Reply-To: <87zjt9kqdh.fsf@windlord.stanford.edu> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> <20130726113307.GD4735@ebisu.astro.su.se> <87zjt9kqdh.fsf@windlord.stanford.edu> Message-ID: --089e0116088401bf0004e270c740 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 26, 2013 at 4:39 PM, Russ Allbery wrote: > Derrick Brashear writes: > > Sergio Gelato wrote: > > >> I'm compiling my next (and hopefully final) iteration right now. > >> I went for this variant: > >> if (clientbest != (krb5_enctype)ETYPE_NULL && > >> enctype == (krb5_enctype)ETYPE_NULL) { > >> enctype = clientbest; > >> if (ret_key == NULL) > >> ret = 0; > >> } > >> > > > This plus > > [kdc]svc-use-strongest-session-key=true > > > Works. > > svc-use-strongest-session-key looks like it still tries to find something > in the common subset of supported keys between the client and server, and > legacy aklog sends only des-cbc-crc as its supported keys. So how could > this work? Isn't there still no common subset with a principal that has > no DES keys? > > There is exactly zero des key for afs in the dementia KDC, and I have the aklog from 1.6.4. what ~/aklog.old /Users/shadow/aklog.old OpenAFS 1.6.4 built 2013-07-26 and a KDC built from the tip of heimdal git. Now, there are possibly side effects elsewhere from this given what appears to happen in the svc-use-strongest-session-key code path but for the limited testing I have done thus far they don't seem to cause any problems. And, in 1.5.2, since the server key is forced to the service key (per > later discussion), if there *is* a DES key for the afs/* principal, > doesn't that result in using a DES long-term key, thus making the update > mostly pointless? > > -- > Russ Allbery (rra@stanford.edu) > -- Derrick --089e0116088401bf0004e270c740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 26, 2013 at 4:39 PM, Russ Allbery <= ;rra@stanford.edu= > wrote:
Derrick Brashear <shadow@gmail.com> writes:
> Sergio Gelato <Sergio.= Gelato@astro.su.se>wrote:

>> I'm compiling my next (and hopefully final) iteration right no= w.
>> I went for this variant:
>> =A0 =A0 =A0 =A0 if (clientbest !=3D (krb5_enctype)ETYPE_NULL &= &
>> =A0 =A0 =A0 =A0 =A0 =A0 enctype =3D=3D (krb5_enctype)ETYPE_NULL) {=
>> =A0 =A0 =A0 =A0 =A0 =A0 enctype =3D clientbest;
>> =A0 =A0 =A0 =A0 =A0 =A0 if (ret_key =3D=3D NULL)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D 0;
>> =A0 =A0 =A0 =A0 }
>>

> This plus
> [kdc]svc-use-strongest-session-key=3Dtrue

> Works.

svc-use-strongest-session-key looks like it still tries to find somet= hing
in the common subset of supported keys between the client and server, and legacy aklog sends only des-cbc-crc as its supported keys. =A0So how could<= br> this work? =A0Isn't there still no common subset with a principal that = has
no DES keys?

There is exactly zero des key for afs in the dementia= KDC, and I have the aklog from 1.6.4.
=A0what ~/aklog.old
/Users/sha= dow/aklog.old
=A0=A0=A0=A0=A0=A0=A0=A0 OpenAFS 1.6.4 built=A0 2013-07-26=
and a KDC built from the tip of heimdal git.

Now, there = are possibly side effects elsewhere from this given what appears to happen = in the
svc-use-strongest-session-key code path but for the limited test= ing I have done thus far they
don't seem to cause any problems.

And, in 1.5.2, since the server key is forced to the service key (per
later discussion), if there *is* a DES key for the afs/* principal,
doesn't that result in using a DES long-term key, thus making the updat= e
mostly pointless?

--
Russ Allbery (rra@stanford.edu) =A0= =A0 =A0 =A0 =A0 =A0 <http://www.eyrie.org/~eagle/>



--
Derrick
--089e0116088401bf0004e270c740-- From shadow@gmail.com Fri Jul 26 22:26:24 2013 From: shadow@gmail.com (Derrick Brashear) Date: Fri, 26 Jul 2013 17:26:24 -0400 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130726160944.a0e6fd1e.adeason@sinenomine.net> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> <20130726113307.GD4735@ebisu.astro.su.se> <87zjt9kqdh.fsf@windlord.stanford.edu> <20130726160944.a0e6fd1e.adeason@sinenomine.net> Message-ID: --e89a8ff24855787f3004e270cb1e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 26, 2013 at 5:09 PM, Andrew Deason wrote: > On Fri, 26 Jul 2013 13:39:22 -0700 > Russ Allbery wrote: > > > > This plus > > > [kdc]svc-use-strongest-session-key=true > > > > > Works. > > > > svc-use-strongest-session-key looks like it still tries to find > > something in the common subset of supported keys between the client > > and server, and legacy aklog sends only des-cbc-crc as its supported > > keys. So how could this work? Isn't there still no common subset > > with a principal that has no DES keys? > > That's what Sergio's patch above is supposed to fix, is my understanding > (not that I've verified it). That is, with that patch in play, the KDC > can now choose a session key enctype that is not one of the principal > key enctypes. So, legacy aklog will get a des-cbc-crc session key when > the service princ has no des-cbc-crc key. > > However, my reading of that patch says that the KDC, as a last resort, > gives the client a session key no matching any principal key enctype. > This is _not_ the same as the behavior in MIT Kerberos and AD; they only > do this for the special case of single DES, not for just any enctype. I > don't know if that's intentional or not, but it is different, and I'm > not sure if that's desirable. > > I couldn't come up with any situation here where it did, but I didn't do an in-depth check of things. -- Derrick --e89a8ff24855787f3004e270cb1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 26, 2013 at 5:09 PM, Andrew Deason &l= t;adeason@sinen= omine.net> wrote:
On Fri, 26 Jul 2013 13:39:= 22 -0700
Russ Allbery <rra@stanford.edu&g= t; wrote:

> > This plus
> > [kdc]svc-use-strongest-session-key=3Dtrue
>
> > Works.
>
> svc-use-strongest-session-key looks like it still tries to find
> something in the common subset of supported keys between the client > and server, and legacy aklog sends only des-cbc-crc as its supported > keys. =A0So how could this work? =A0Isn't there still no common su= bset
> with a principal that has no DES keys?

That's what Sergio's patch above is supposed to fix, is my un= derstanding
(not that I've verified it). That is, with that patch in play, the KDC<= br> can now choose a session key enctype that is not one of the principal
key enctypes. So, legacy aklog will get a des-cbc-crc session key when
the service princ has no des-cbc-crc key.

However, my reading of that patch says that the KDC, as a last resort,
gives the client a session key no matching any principal key enctype.
This is _not_ the same as the behavior in MIT Kerberos and AD; they only do this for the special case of single DES, not for just any enctype. I
don't know if that's intentional or not, but it is different, and I= 'm
not sure if that's desirable.

I couldn't come up with any situation here where = it did, but I didn't do an
in-depth check of things.
--
Derrick
--e89a8ff24855787f3004e270cb1e-- From jaltman@secure-endpoints.com Fri Jul 26 22:42:03 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Fri, 26 Jul 2013 17:42:03 -0400 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <20130726153006.16204d6a.adeason@sinenomine.net> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> <51F26692.500@cgv.tugraz.at> <20130726153006.16204d6a.adeason@sinenomine.net> Message-ID: <51F2ED2B.3020104@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms070802070101090900020702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/26/2013 4:30 PM, Andrew Deason wrote: > On Fri, 26 Jul 2013 14:07:46 +0200 > Lars Schimmer wrote: >=20 >> Ok, now with access to such a machine: >> krbtgt/CGV.TUGRAZ.AT@CGV.TUGRAZ.AT >> Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CT= S >> mode with 96-bit SHA-1 HMAC >> afs/cgv.tugraz.at/CGV.TUGRAZ.AT >> Etype /skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with >> 96-bit SHA-1 HMAC >=20 > By any chance, do you happen to have the registry entry >=20 > HKLM\SYSTEM\CurrentControlSet\services\kdc\KdcUseRequestedEtypesForTick= ets >=20 > set to 1? That seems like it may cause that behavior, from a quck test = I > just did. >=20 > I'm having trouble seeing what on earth that option is for. From what I= > can find on various sites, that makes the KDC use the client-specified > enctype list for the service ticket enctype, ignoring the principal > enctype settings (but still honoring the principal enctypes for the > session key?). I'm having trouble seeing any scenario where that is not= > completely inappropriate (and a security issue!), let alone for AFS > usage. >=20 > I've seen this mentioned in a few AFS/Active Directory howtos, and I > have no idea why. If anyone has some info to share... That was added as a hotfix to Server 2003. In Server 2000 the KDC always issued tickets with the session key and service ticket key configured based upon the client specified enctype list. This was a bug that was fixed in Server 2003. At the time there were a number of Kerberos implementations which would crash if any of the enctypes in the ticket were not recognized even if the Kerberos implementation had no business attempting to decrypt the service ticket portion. To avoid crashing these implementations the above hotfix was added. If this is in fact the problem, a bug report needs to be filed with Microsoft to address the conflict between the DES_ONLY flag and the KdcUseRequestedEtypesForTickets option. Jeffrey Altman --------------ms070802070101090900020702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzI2MjE0MjAzWjAjBgkqhkiG9w0BCQQxFgQU9bmNurxKrcPLlog3NU90AB/JuAIwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AHDfye5bNp5Q1V69YTyDX4MsV9FaFkaeRp7o/SSLXjPZhYL8R+l9rK6w50DS8VZei9vyncjb HcN51YYg8UpnDD7HhYS7lVPSCnmL553ruUJcDf3x06ziIHvfpAtqwHzKkvVTNsbeFjN85UR/ NcmfDzSlJnH1KvXjy2cR2sjAOaEbeFCCb6rwQa5mVLRTFpZAn3dcDjRNWOWG1bxHOvDRx2gH Cvlqw8l5s1RK9kvgSOSRw2eYW6yM4CPmUP3gQZSOvHWv5U8kOY6GRoo7GGsv6xeL51azHp/E Zq8unIpHh9WnDUZHVZsqEHX2PcUmf4qqZagZwtXXr0M5KHa9QXzjFaEAAAAAAAA= --------------ms070802070101090900020702-- From adeason@sinenomine.net Fri Jul 26 23:02:25 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Fri, 26 Jul 2013 17:02:25 -0500 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> <51F26692.500@cgv.tugraz.at> <20130726153006.16204d6a.adeason@sinenomine.net> <51F2ED2B.3020104@secure-endpoints.com> Message-ID: <20130726170225.82669598.adeason@sinenomine.net> On Fri, 26 Jul 2013 17:42:03 -0400 Jeffrey Altman wrote: > That was added as a hotfix to Server 2003. In Server 2000 the KDC > always issued tickets with the session key and service ticket key > configured based upon the client specified enctype list. This was a > bug that was fixed in Server 2003. At the time there were a number of > Kerberos implementations which would crash if any of the enctypes in > the ticket were not recognized even if the Kerberos implementation had > no business attempting to decrypt the service ticket portion. To > avoid crashing these implementations the above hotfix was added. Thank you for this explanation. > If this is in fact the problem, a bug report needs to be filed with > Microsoft to address the conflict between the DES_ONLY flag and the > KdcUseRequestedEtypesForTickets option. And for Lars and others, if you only turned on this option because of AFS, you may be able to turn it off, since AFS doesn't need it turned on. Of course, if you are affected by any buggy kerberos client implementations as mentioned above, you may need it on for other reasons. -- Andrew Deason adeason@sinenomine.net From lass@mail.upb.de Sat Jul 27 09:04:50 2013 From: lass@mail.upb.de (Michael =?ISO-8859-1?Q?La=DF?=) Date: Sat, 27 Jul 2013 10:04:50 +0200 Subject: [OpenAFS] Default for encryption of file transfers Message-ID: <1374912290.18607.214.camel@localhost.localdomain> Hi, I heard from a user about an inconsistency between documentation and the actual behavior of the openafs client (1.6.5): The manpage for "fs setcrypt" states: "The default encryption status is enabled." But in fact this seems to be not the case. Start scripts for Debian and FreeBSD enable it after starting the client. The service file for Fedora does not. This leads to the fact that encryption is disabled by default on Fedora. What is the intended behavior here? Should encryption be enabled by default or is the documentation misleading and start scripts are responsible for enabling encryption? Michael From l.schimmer@cgv.tugraz.at Sat Jul 27 09:51:04 2013 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Sat, 27 Jul 2013 10:51:04 +0200 Subject: [OpenAFS] Re: OpenAFS 1.7.26 windows and not changed AFS service principle - OK? In-Reply-To: <20130726153006.16204d6a.adeason@sinenomine.net> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> <51F26692.500@cgv.tugraz.at> <20130726153006.16204d6a.adeason@sinenomine.net> Message-ID: <51F389F8.70302@cgv.tugraz.at> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2VHTMFORNDEAUOVDFQIVK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-26 22:30, Andrew Deason wrote: > On Fri, 26 Jul 2013 14:07:46 +0200 > Lars Schimmer wrote: >=20 >> Ok, now with access to such a machine: >> krbtgt/CGV.TUGRAZ.AT@CGV.TUGRAZ.AT >> Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CT= S >> mode with 96-bit SHA-1 HMAC >> afs/cgv.tugraz.at/CGV.TUGRAZ.AT >> Etype /skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with >> 96-bit SHA-1 HMAC >=20 > By any chance, do you happen to have the registry entry >=20 > HKLM\SYSTEM\CurrentControlSet\services\kdc\KdcUseRequestedEtypesForTick= ets >=20 > set to 1? That seems like it may cause that behavior, from a quck test = I > just did. Yes, I did set it. Lets see what happens if I set it to 0. MfG, Lars Schimmer --=20 ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ------enig2VHTMFORNDEAUOVDFQIVK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHzifwACgkQmWhuE0qbFyNS7gCfZEGdyO29HzP6MYaxcrwrQJYL dI0AnivE2xMSvoscShCnCRuQv3nZQJOZ =tRHt -----END PGP SIGNATURE----- ------enig2VHTMFORNDEAUOVDFQIVK-- From l.schimmer@cgv.tugraz.at Sat Jul 27 12:53:37 2013 From: l.schimmer@cgv.tugraz.at (Lars Schimmer) Date: Sat, 27 Jul 2013 13:53:37 +0200 Subject: [OpenAFS] KdcUseReqEtype changed another problem occured... In-Reply-To: <51F389F8.70302@cgv.tugraz.at> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> <51F26692.500@cgv.tugraz.at> <20130726153006.16204d6a.adeason@sinenomine.net> <51F389F8.70302@cgv.tugraz.at> Message-ID: <51F3B4C1.8090406@cgv.tugraz.at> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ADkhekmMeAhf4NKrVkxRNaKs4XINgO5hU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27.07.2013 10:51, Lars Schimmer wrote: > On 2013-07-26 22:30, Andrew Deason wrote: >> On Fri, 26 Jul 2013 14:07:46 +0200 >> Lars Schimmer wrote: >> >>> Ok, now with access to such a machine: >>> krbtgt/CGV.TUGRAZ.AT@CGV.TUGRAZ.AT >>> Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 C= TS >>> mode with 96-bit SHA-1 HMAC >>> afs/cgv.tugraz.at/CGV.TUGRAZ.AT >>> Etype /skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with >>> 96-bit SHA-1 HMAC >> >> By any chance, do you happen to have the registry entry >> >> HKLM\SYSTEM\CurrentControlSet\services\kdc\KdcUseRequestedEtypesForTic= kets >> >> set to 1? That seems like it may cause that behavior, from a quck test= I >> just did. >=20 > Yes, I did set it. >=20 > Lets see what happens if I set it to 0. Ok, the windows machines (I tested now with 1.7.2601 OpenAFS windows) get a token on login and can access the OpenAFS filespace as usual. That entry really did a change. BUT on my laptop I get now this error: PS C:\Program Files (x86)\MIT\Kerberos\bin> kinit lschimmer Password for lschimmer@CGV.TUGRAZ.AT: kinit.exe(v5): Ccache function not supported: read-only ccache type while storing credentials PS C:\Program Files (x86)\MIT\Kerberos\bin> Even networkID manager does not show a ticket and klist -e does not show anything, as I could not get a token with kinit/network ID manager.. What goes wrong now? (it did well on the machine I tested first and which worked all the time with 1.7.26...) MfG, Lars Schimmer --=20 ------------------------------------------------------------- TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 --ADkhekmMeAhf4NKrVkxRNaKs4XINgO5hU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHztMgACgkQmWhuE0qbFyPtvACeMmTBrZU8Xc4k5Bux6wmM/+19 UMsAn0jmnMmOu/H3+1ICwzzXCPEw/vhb =2SBr -----END PGP SIGNATURE----- --ADkhekmMeAhf4NKrVkxRNaKs4XINgO5hU-- From jaltman@secure-endpoints.com Sat Jul 27 16:10:28 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Sat, 27 Jul 2013 11:10:28 -0400 Subject: [OpenAFS] KdcUseReqEtype changed another problem occured... In-Reply-To: <51F3B4C1.8090406@cgv.tugraz.at> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> <51F26692.500@cgv.tugraz.at> <20130726153006.16204d6a.adeason@sinenomine.net> <51F389F8.70302@cgv.tugraz.at> <51F3B4C1.8090406@cgv.tugraz.at> Message-ID: <51F3E2E4.9070504@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms010801080100090909050104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/27/2013 7:53 AM, Lars Schimmer wrote: > BUT on my laptop I get now this error: > PS C:\Program Files (x86)\MIT\Kerberos\bin> kinit lschimmer > Password for lschimmer@CGV.TUGRAZ.AT: > kinit.exe(v5): Ccache function not supported: read-only ccache type > while storing credentials > PS C:\Program Files (x86)\MIT\Kerberos\bin> You cannot use kinit with a MSLSA: cache. Ticket granting tickets are obtained by Windows. You cannot replace them. --------------ms010801080100090909050104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzI3MTUxMDI4WjAjBgkqhkiG9w0BCQQxFgQUG3ltQzcGlwvSMs5z013etTGQc8AwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB ACwCj5vPc69MiefpxKEBdKN+6u9sQUplOMxNFuFpaqxhfdb5yRLwv1bBt9h0Sn0VWHoObiKS LN+QDb1DGm3m3MaiCDm+oN39GXzGRcr6i59zqgIPfiGZQhbZ0LUv26eSOaEx+9NegAuBiH2K DVzoiHtx7bqHEAt/XYHC1MnRYLs9aPHsTMwIeXQiXEdEMQTE/HsOmhV38p/o0X7/G5I7hjTo C08qv0IolHUqrCFcJXeRM1iGNzGaVPJqP+nyuO9FDmUuMZvc0HPfj3oJBWvA3JjdhLP3Ud7H wsZIgew+cr/KkwSvfupvYGLvvIBZ6kfQfaB7LG9XoD6byte18Tm41UoAAAAAAAA= --------------ms010801080100090909050104-- From jaltman@your-file-system.com Sat Jul 27 16:12:36 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Sat, 27 Jul 2013 11:12:36 -0400 Subject: [OpenAFS] Default for encryption of file transfers In-Reply-To: <1374912290.18607.214.camel@localhost.localdomain> References: <1374912290.18607.214.camel@localhost.localdomain> Message-ID: <51F3E364.3040401@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms070502060606040301060900 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/27/2013 4:04 AM, Michael La=C3=9F wrote: > Hi, >=20 > I heard from a user about an inconsistency between documentation and th= e > actual behavior of the openafs client (1.6.5): >=20 > The manpage for "fs setcrypt" states: "The default encryption status is= > enabled." But in fact this seems to be not the case. >=20 The default is enabled on Windows; disabled on everything else. --------------ms070502060606040301060900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzI3MTUxMjM2WjAjBgkqhkiG9w0BCQQxFgQUdWR9gqHEi43TykFn/hs5Jlh/cdUwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AJCMlEI47pt7O9yL5WjEVrbqyXR3uQ9IZtHZNFgXDM2EIe/LLgiTYyUGK4A7X9kkSxG8j9pn +xgXf3ez/PMsI8xeOsYAsD78J2cbTS7rK7Rwb2K8T4xf/BG7MlS+jDzdKGPVilqGuFEQt/Bi rdfGcTLgRXyHN7cyIe5Zyy3bglEriQtIKqtWhaewymiZ3m3Pyq8gavkK7fG9olClPO2JOLVO 4EHHnfujotuih4z2Jf5iU/cHC4ABXsIqYWaRwugdNdFc/u9V2d+2ZdnE+l9SR5L3NgomSdcI 2mF3teFZ/1cyEZHm3VkLeXXkwr72i6jssNnu5XExEbrQx3L0FWahidUAAAAAAAA= --------------ms070502060606040301060900-- From ktdreyer@ktdreyer.com Sat Jul 27 16:30:38 2013 From: ktdreyer@ktdreyer.com (Ken Dreyer) Date: Sat, 27 Jul 2013 09:30:38 -0600 Subject: [OpenAFS] Default for encryption of file transfers In-Reply-To: <51F3E364.3040401@your-file-system.com> References: <1374912290.18607.214.camel@localhost.localdomain> <51F3E364.3040401@your-file-system.com> Message-ID: On Sat, Jul 27, 2013 at 9:12 AM, Jeffrey Altman wrote: > On 7/27/2013 4:04 AM, Michael La=C3=9F wrote: >> I heard from a user about an inconsistency between documentation and the >> actual behavior of the openafs client (1.6.5): >> >> The manpage for "fs setcrypt" states: "The default encryption status is >> enabled." But in fact this seems to be not the case. >> > > The default is enabled on Windows; disabled on everything else. > Proposed manpage fix at http://gerrit.openafs.org/10111 - Ken From kaduk@MIT.EDU Sun Jul 28 23:20:09 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Sun, 28 Jul 2013 18:20:09 -0400 (EDT) Subject: [OpenAFS] KdcUseReqEtype changed another problem occured... In-Reply-To: <51F3E2E4.9070504@secure-endpoints.com> References: <51F0E87D.8060009@cgv.tugraz.at> <20130725100732.6cd54e24.adeason@sinenomine.net> <20130725105502.ca630ccd.adeason@sinenomine.net> <51F21DAC.2060409@cgv.tugraz.at> <51F255DC.6050205@secure-endpoints.com> <51F26692.500@cgv.tugraz.at> <20130726153006.16204d6a.adeason@sinenomine.net> <51F389F8.70302@cgv.tugraz.at> <51F3B4C1.8090406@cgv.tugraz.at> <51F3E2E4.9070504@secure-endpoints.com> Message-ID: On Sat, 27 Jul 2013, Jeffrey Altman wrote: > On 7/27/2013 7:53 AM, Lars Schimmer wrote: >> BUT on my laptop I get now this error: >> PS C:\Program Files (x86)\MIT\Kerberos\bin> kinit lschimmer >> Password for lschimmer@CGV.TUGRAZ.AT: >> kinit.exe(v5): Ccache function not supported: read-only ccache type >> while storing credentials >> PS C:\Program Files (x86)\MIT\Kerberos\bin> > > You cannot use kinit with a MSLSA: cache. Ticket granting tickets are This is no longer the case with KfW 4.x. However, there are lots of edge cases and I would not recommend using KfW to write to the MSLSA: cache unless you have a good reason to do so. -Ben > obtained by Windows. You cannot replace them. From jaltman@secure-endpoints.com Mon Jul 29 23:12:30 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Mon, 29 Jul 2013 18:12:30 -0400 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <87txjhj9vl.fsf@windlord.stanford.edu> References: <98EA4653-A452-421B-9E8E-69F8C6F73DFC@sxw.org.uk> <20130725100318.72d6d8a5.adeason@sinenomine.net> <20130725171211.GA9756@hanuman.astro.su.se> <20130725143558.71bf8936.adeason@sinenomine.net> <20130726085741.GA2662@hanuman.astro.su.se> <4FAFFFB8-4F52-4A6E-AFAF-B4D4272208F0@csc.kth.se> <20130726101806.GC4735@ebisu.astro.su.se> <44E18915-2D78-4756-859A-536CA74F2B7D@csc.kth.se> <20130726113307.GD4735@ebisu.astro.su.se> <87zjt9kqdh.fsf@windlord.stanford.edu> <20130726160944.a0e6fd1e.adeason@sinenomine.net> <87txjhj9vl.fsf@windlord.stanford.edu> Message-ID: <51F6E8CE.7070405@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms020006000501070201060400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Secure Endpoints has pushed fixes to https://github.com/heimdal/heimdal for both the 'master' (aka pre-1.6) and 'heimdal-1-5-branch' branches. With the HEAD of each branch the following is now true: 1. The svc_use_strongest_session_key option does not need to be enabled. If you choose to enable it you can. 2. If the afs/* service principal does not have a 1des key and the client requests a 1des key, a 1des session key can be issued. 3. a 1des session key or service ticket key can be issued for afs/* service principals even if 'allow_weak_crypto' is not enabled. Thanks to Stanford University and KTH for testing. Jeffrey Altman --------------ms020006000501070201060400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzI5MjIxMjMwWjAjBgkqhkiG9w0BCQQxFgQUCeNmeVPtwF0ZBv2MG4bYUDaIHNUwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB ADmjeE4yPc4alfAW4OMnKAIKFRFLZ4xAzzL1ELQiloDcMPvtAwcmLGFC/OUynl3lHLeYFiZS GddrHo4tKLj9a8nZQFZNA4sFAbjYt9+3fHjbF7nhLgjtWXzeBZ36Nhf22WkWqB2R8U9LY2PN h1Ng5/dFiEtqY5RwrdynWsdTx935Y9j6+vTvpXo6FQobCSPIhjoaXqw00TNs3wYodK6weE6b GHk6Bu9f0wBGr4TOvYPxqG/T+9I1ecIlEursXWl3/5Kd5Y0/CTnW4zcw3kOs8lC/pneK5q4S MsFoM7EBFoE3BA81i6mY0biuPs7gJEm1IQ48OupatexdrLh1Qt/FUNIAAAAAAAA= --------------ms020006000501070201060400-- From jason@rampaginggeek.com Tue Jul 30 02:21:23 2013 From: jason@rampaginggeek.com (Jason Edgecombe) Date: Mon, 29 Jul 2013 21:21:23 -0400 Subject: [OpenAFS] Need a RHEL5 buildslave machine Message-ID: <51F71513.4030209@rampaginggeek.com> Hi everyone, I've been notified that the machine that hosts our buildslave for RHEL5 x86_64 is being decommissioned at the end of August. Without a RHEL5 builder, RHEL5 support may suffer and problems on RHEL5 may not be found as quickly. To host a RHEL5 buildslave, the following is needed: * A virtual or real machine * 1GB RAM * 2GB of free disk space in /home * ssh access from the internet or through a gateway root access is not needed. I can manage the buildslave software if I have remote ssh access. The host can be behind a NAT firewall, so long as there is ssh access somehow. If you are interested in hosting a buildslave for RHEL5 o some other platform, please contact me privately. Thanks, Jason From haba@kth.se Tue Jul 30 11:57:04 2013 From: haba@kth.se (Harald Barth) Date: Tue, 30 Jul 2013 12:57:04 +0200 (CEST) Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <51F6E8CE.7070405@secure-endpoints.com> References: <20130726160944.a0e6fd1e.adeason@sinenomine.net> <87txjhj9vl.fsf@windlord.stanford.edu> <51F6E8CE.7070405@secure-endpoints.com> Message-ID: <20130730.125704.1060864531730322078.haba@habanero> > Secure Endpoints has pushed fixes to https://github.com/heimdal/heimdal > for both the 'master' (aka pre-1.6) and 'heimdal-1-5-branch' branches. Warning: Real-life results show that the code path for preauth always seems to go through the strongest enctype configured (for example aes256), even if the users principal does not have a key of that enctype. So these users (*) will not be able to obtain tickets any more (at least not without password change to get those new keys). A more detailed report will probably follow from the testers. Harald. (*) for example users with enctypes up to aes128 who have not changed their password since the newest enctype aes256 has been available. From jwedgeco@uncc.edu Tue Jul 30 14:01:44 2013 From: jwedgeco@uncc.edu (Edgecombe, Jason) Date: Tue, 30 Jul 2013 13:01:44 +0000 Subject: [OpenAFS] anonymous AFS access from pre-1.6.5 clients after DES is disabled Message-ID: <4DE25DED585CD840A23808AFDE3DA2060126AFF0@RPITSEXMS4.its.uncc.edu> Hi everyone, After all of the cell's AFS servers are upgraded to 1.6.5 and DES is disabl= ed, will pre-1.6.5 clients still retain anonymous AFS access via system:any= user access and IP ACLs? I understand that authenticated access will not be= possible, but I want to clarify the anonymous access case. Thanks, Jason --------------------------------------------------------------------------- Jason Edgecombe | Linux and Solaris Administrator UNC Charlotte | The William States Lee College of Engineering 9201 University City Blvd. | Charlotte, NC 28223-0001 Phone: 704-687-1943 jwedgeco@uncc.edu | http://engr.uncc.edu | =A0Facebook --------------------------------------------------------------------------- If you are not the intended recipient of this transmission or a person resp= onsible for delivering it to the intended recipient, any disclosure, copyin= g, distribution, or other use of any of the information in this transmissio= n is strictly prohibited. If you have received this transmission in error, = please notify me immediately by reply e-mail or by telephone at 704-687-194= 3.=A0 Thank you. From jaltman@your-file-system.com Tue Jul 30 14:19:10 2013 From: jaltman@your-file-system.com (Jeffrey Altman) Date: Tue, 30 Jul 2013 09:19:10 -0400 Subject: [OpenAFS] anonymous AFS access from pre-1.6.5 clients after DES is disabled In-Reply-To: <4DE25DED585CD840A23808AFDE3DA2060126AFF0@RPITSEXMS4.its.uncc.edu> References: <4DE25DED585CD840A23808AFDE3DA2060126AFF0@RPITSEXMS4.its.uncc.edu> Message-ID: <51F7BD4E.2030903@your-file-system.com> This is a cryptographically signed message in MIME format. --------------ms000206090909070509030300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "anonymous" access is unaffected. However, a user with a token that is no longer accepted is not "anonymous= " On 7/30/2013 9:01 AM, Edgecombe, Jason wrote: > Hi everyone, >=20 > After all of the cell's AFS servers are upgraded to 1.6.5 and DES is di= sabled, will pre-1.6.5 clients still retain anonymous AFS access via syst= em:anyuser access and IP ACLs? I understand that authenticated access wil= l not be possible, but I want to clarify the anonymous access case. >=20 > Thanks, > Jason >=20 > -----------------------------------------------------------------------= ---- > Jason Edgecombe | Linux and Solaris Administrator > UNC Charlotte | The William States Lee College of Engineering > 9201 University City Blvd. | Charlotte, NC 28223-0001 > Phone: 704-687-1943 > jwedgeco@uncc.edu | http://engr.uncc.edu | Facebook > -----------------------------------------------------------------------= ---- > If you are not the intended recipient of this transmission or a person = responsible for delivering it to the intended recipient, any disclosure, = copying, distribution, or other use of any of the information in this tra= nsmission is strictly prohibited. If you have received this transmission = in error, please notify me immediately by reply e-mail or by telephone at= 704-687-1943. Thank you. >=20 > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info >=20 --------------ms000206090909070509030300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhAl sq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc2MTA4NjMxMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHlvdXItZmlsZS1zeXN0ZW0u Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChjpVdVk6XeKFff4To xGglVcP3FVY95LfwfBUKbQKppRYgfKBFW1RIEG+KXpc3IGOOTUX0Lg1xaukRwuoqv/pqRMNK JabXcr1RFuCFg9xfcmP5Z+65qQ+IRxYCKdcNfu3GdS7rMOY57+VLU7aZnnMgnt0oE42awze8 gYQSJsdjZKKZS9DBnzxJYfzqhIw7txoMdV7rwPAZm5yujsqI/eWuZPZ+qZ+8GTsnHJzZNvc6 KrDGU6aVfknM+qf92hXA2VXvmtf1B17BBbGX6Hgat71Ufw5oXFly6/Vt+e5mKIozXytw8qPX NllsG89ITVzn0OovcpcSRFBrXanzVn7JVj33AgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFMC1SMuRefXyNAwkZM+Lgu7iJ6nFMCcGA1UdEQQgMB6BHGphbHRtYW5AeW91ci1m aWxlLXN5c3RlbS5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHVBsY+l21fY0twxzNnO0QbadbRT4n7k3rYfOMbP noBDkYQx5lcrYn19f7e+ADMPdW/MY2ZjFM76aiRgiTo2IjMB7z4vyX6hfGJKTIHX9loDW0H2 z2o0jYqXDQtXx9A/gfMtVh9J+8O5IuCPsVtXgI4p6kRQHN+Er2Rzu1I4BILxE9HsDb/ruX6p NXZSUQ2AcMP87ZVfz+reumMpJgWWAoiQWJCgp+qZ2c2AG+yV+FstiMpxIj/qB9+BrFRuam8d IGbH0tIS2tyc7pgit8Pid2Zv7HGT2NFu69INsKIyqGImhMVuOUaCq/kNi3Z+6R5Hm3ljift8 ZF52Kiq4whe8KlcxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCECWyrbsULgHrdnyrUnPHH4IwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzMwMTMxOTEwWjAjBgkqhkiG9w0BCQQxFgQUcLBrxzjdlYHYoMp3wqfrDfeUYUowbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQJbKtuxQuAet2fKtSc8cfgjCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAlsq27FC4B63Z8q1Jzxx+CMA0GCSqGSIb3DQEBAQUABIIB AA91Yqza70TVy+n/t9ffp/65BewNfoYOjHu1ZEXR7FIzaCPPvoGnvPFJlsaD3AdBgPoTmLDG sBKQ6sgdo960PwUOsg0PBPJf30QYu/UgmgorKmUzwWlcsd+hf7Sl4kmKzc1ObNaLYHWI/dap DOL5w80u442PB9wQYwC2PL6uZ16hwV4zHUKqVfdgOip2Z09HtraFLmKkQ8vHCFDRicIhEANo uwWfNlRQxESet4oAya6iM/TokK742ypqEg7Te5fQ4zmOvxTsM3DYA7HuuSGJLsdbQD0HRNng OXR35ZgWE0+ayPnaFedloaz1U3b3MOfczYjYHy2/xdhtKsPgVVvXWScAAAAAAAA= --------------ms000206090909070509030300-- From jaltman@secure-endpoints.com Tue Jul 30 16:39:17 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 30 Jul 2013 11:39:17 -0400 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <20130730.125704.1060864531730322078.haba@habanero> References: <20130726160944.a0e6fd1e.adeason@sinenomine.net> <87txjhj9vl.fsf@windlord.stanford.edu> <51F6E8CE.7070405@secure-endpoints.com> <20130730.125704.1060864531730322078.haba@habanero> Message-ID: <51F7DE25.80909@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080908020309060308050708 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/30/2013 6:57 AM, Harald Barth wrote: >=20 >> Secure Endpoints has pushed fixes to https://github.com/heimdal/heimda= l >> for both the 'master' (aka pre-1.6) and 'heimdal-1-5-branch' branches.= >=20 > Warning: Real-life results show that the code path for preauth always > seems to go through the strongest enctype configured (for example > aes256), even if the users principal does not have a key of that > enctype. So these users (*) will not be able to obtain tickets any > more (at least not without password change to get those new keys). This is an incorrect description. The explicit problem occurs when the following combination is true: 1. user has one or more strong enctype keys with non-default password salts 2. the only keys with default password salts are weak enctypes 3. preauth is required In this combination, the strong enctype with the non-default password salt will not be recommended to the client in the pa-etype-info or pa-etype-info2 data sent with the preauth required error reply. Since no pa-etype hint was provided the client chooses its preferred enctype which is aes256. A correction has been prepared and will be submitted after testing. Jeffrey Altman --------------ms080908020309060308050708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzMwMTUzOTE3WjAjBgkqhkiG9w0BCQQxFgQUO2yq+Y6OOQyHfdQAOKyIzVuIPWEwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AK7F4IkarX0Q59zxSp6D8VDY4TreRKaG2IQWYVmcjCRblk6WmKMxocMMcyOiutVPHJ9SmD5u E/XXTrMzOSJXiR37LQ+DgBlGAWyMy4DABOY/O/e6aCoTugFyJbSsC5RTEOlsmcAu/NG/czqz 2yYgAh67XwJdFCIJ1H0mzGA4yyx3mfAOBnNCAgpzOakStIMT5rK/7Owf/jBZTmV43jZFEGRd gOrXwOWwD7GdIQSowu/eTvaT3siRmsbJFDUO7UwMKNARNK8Q85y8N48FZIsHJ76WIqwVdz87 hG6mam3zbh+GVB8xDbkNtS6IQQA3Sz4ZybihM/5d3ZrIGakmedCJ3ZgAAAAAAAA= --------------ms080908020309060308050708-- From jwinius@umrk.nl Tue Jul 30 17:01:54 2013 From: jwinius@umrk.nl (Jaap Winius) Date: Tue, 30 Jul 2013 18:01:54 +0200 Subject: [OpenAFS] Removing stuff from /afs Message-ID: <20130730180154.81591lnb0r529gsg@bitis.umrk.nl> Hi folks, Could someone please remind me how to remove stuff from the /afs directory? I recently discovered an empty directory there, called: /afs/.:mount Obviously it was created there by accident, probably by me. However, when I try to remove it I get: rmdir: failed to remove `/afs/.:mount/': Read-only file system Can anyone help? Thanks, Jaap From kaduk@MIT.EDU Tue Jul 30 17:06:46 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Tue, 30 Jul 2013 12:06:46 -0400 (EDT) Subject: [OpenAFS] Removing stuff from /afs In-Reply-To: <20130730180154.81591lnb0r529gsg@bitis.umrk.nl> References: <20130730180154.81591lnb0r529gsg@bitis.umrk.nl> Message-ID: On Tue, 30 Jul 2013, Jaap Winius wrote: > Hi folks, > > Could someone please remind me how to remove stuff from the /afs directory? I > recently discovered an empty directory there, called: > > /afs/.:mount > > Obviously it was created there by accident, probably by me. However, when I > try to remove it I get: > > rmdir: failed to remove `/afs/.:mount/': Read-only file system > > Can anyone help? I assume that you are not using dynroot? The standard way to do such things is to make an additional mount of the root.afs volume somewhere else in the local cell, and use a read-write path to access it. -Ben Kaduk From ballbery@sinenomine.net Tue Jul 30 17:15:33 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Tue, 30 Jul 2013 16:15:33 +0000 Subject: [OpenAFS] Removing stuff from /afs In-Reply-To: <20130730180154.81591lnb0r529gsg@bitis.umrk.nl> Message-ID: T24gNy8zMC8xMyAxMjowMSwgIkphYXAgV2luaXVzIiA8andpbml1c0B1bXJrLm5sPiB3cm90ZToN Cg0KPkhpIGZvbGtzLA0KPg0KPkNvdWxkIHNvbWVvbmUgcGxlYXNlIHJlbWluZCBtZSBob3cgdG8g cmVtb3ZlIHN0dWZmIGZyb20gdGhlIC9hZnMNCj5kaXJlY3Rvcnk/IEkgcmVjZW50bHkgZGlzY292 ZXJlZCBhbiBlbXB0eSBkaXJlY3RvcnkgdGhlcmUsIGNhbGxlZDoNCj4NCj4gICAvYWZzLy46bW91 bnQNCg0KSWYgeW91J3JlIHVzaW5nIGR5bnJvb3QsIHRoYXQncyBhbiBhdXRvY3JlYXRlZCBkaXJl Y3Rvcnkgd2hpY2ggY2FuIGJlIHVzZWQNCnRvIGFjY2VzcyBhbnkgdm9sdW1lIGRpcmVjdGx5OiB0 cnkgL2Fmcy8uOm1vdW50L2xvY2FsLmNlbGw6cm9vdC5jZWxsDQoocmVwbGFjaW5nICJsb2NhbC5j ZWxsIiB3aXRoIHRoZSBuYW1lIG9mIHRoZSBsb2NhbCBjZWxsKS4NCg0KLS0gDQpicmFuZG9uIHMg YWxsYmVyeSBrZjhuaCAgICBzaW5lIG5vbWluZSBhc3NvY2lhdGVzDQphbGxiZXJ5LmJAZ21haWwu Y29tICAgICAgIGJhbGxiZXJ5QHNpbmVub21pbmUubmV0DQp1bml4LCBvcGVuYWZzLCBrZXJiZXJv cywgaW5mcmFzdHJ1Y3R1cmUsIHhtb25hZA0KDQoNCg0K From adeason@sinenomine.net Tue Jul 30 17:25:05 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 30 Jul 2013 11:25:05 -0500 Subject: [OpenAFS] Re: Removing stuff from /afs References: <20130730180154.81591lnb0r529gsg@bitis.umrk.nl> Message-ID: <20130730112505.a5bcb40e.adeason@sinenomine.net> On Tue, 30 Jul 2013 18:01:54 +0200 Jaap Winius wrote: > Could someone please remind me how to remove stuff from the /afs > directory? I recently discovered an empty directory there, called: > > /afs/.:mount > > Obviously it was created there by accident, probably by me. However, > when I try to remove it I get: /afs/.:mount is a special magic directory that can be used to refer to specific volumes via a short path; it's briefly mentioned in the afsd(8) manpage. You can't get rid of it. Of course, it's possible you're on a platform or version, etc, where that magic directory doesn't exist, and you did actually create such a directory, but that would be quite a coincidence :) -- Andrew Deason adeason@sinenomine.net From jwinius@umrk.nl Tue Jul 30 18:09:35 2013 From: jwinius@umrk.nl (Jaap Winius) Date: Tue, 30 Jul 2013 19:09:35 +0200 Subject: [OpenAFS] Removing stuff from /afs In-Reply-To: References: Message-ID: <20130730190935.20006xl4vzd4d1ss@bitis.umrk.nl> Quoting Brandon Allbery : > If you're using dynroot, that's an autocreated directory which can be used > to access any volume directly: try /afs/.:mount/local.cell:root.cell > (replacing "local.cell" with the name of the local cell). Well, whaddya know: it's not a mistake, it's a feature! Must be new in v1.6. Sure did take me a while to notice (doh!). And, yes, I have dynroot enabled in the client configuration. Thanks! Jaap From jwinius@umrk.nl Tue Jul 30 18:09:33 2013 From: jwinius@umrk.nl (Jaap Winius) Date: Tue, 30 Jul 2013 19:09:33 +0200 Subject: [OpenAFS] Removing stuff from /afs In-Reply-To: References: <20130730180154.81591lnb0r529gsg@bitis.umrk.nl> Message-ID: <20130730190933.12525ge74ld2z9wc@bitis.umrk.nl> Quoting Benjamin Kaduk : > I assume that you are not using dynroot? Actually, I am using it. In /etc/openafs/afs.conf.client I have: AFS_DYNROOT=true > The standard way to do such things is to make an additional mount of > the root.afs volume somewhere else in the local cell, and use a > read-write path to access it. Yes, that seems like the way to do that. For example: ~# fs mkmount -dir temp -vol root.afs Thanks! Jaap From stephan.wiesand@desy.de Tue Jul 30 18:23:56 2013 From: stephan.wiesand@desy.de (Stephan Wiesand) Date: Tue, 30 Jul 2013 19:23:56 +0200 Subject: [OpenAFS] Removing stuff from /afs In-Reply-To: <20130730190933.12525ge74ld2z9wc@bitis.umrk.nl> References: <20130730180154.81591lnb0r529gsg@bitis.umrk.nl> <20130730190933.12525ge74ld2z9wc@bitis.umrk.nl> Message-ID: <36B4191D-D815-48D8-B57C-EAF51E68B7B8@desy.de> On Jul 30, 2013, at 19:09 , Jaap Winius wrote: > Quoting Benjamin Kaduk : >=20 >> I assume that you are not using dynroot? >=20 > Actually, I am using it. In /etc/openafs/afs.conf.client I have: >=20 > AFS_DYNROOT=3Dtrue >=20 >> The standard way to do such things is to make an additional mount of = the root.afs volume somewhere else in the local cell, and use a = read-write path to access it. >=20 > Yes, that seems like the way to do that. For example: >=20 > ~# fs mkmount -dir temp -vol root.afs Or simply "rm /afs/.:mount/your.cell:root.afs/something" instead ;-) From mmeffie@sinenomine.net Tue Jul 30 18:52:31 2013 From: mmeffie@sinenomine.net (Michael Meffie) Date: Tue, 30 Jul 2013 13:52:31 -0400 Subject: [OpenAFS] Re: Removing stuff from /afs In-Reply-To: <20130730112505.a5bcb40e.adeason@sinenomine.net> References: <20130730180154.81591lnb0r529gsg@bitis.umrk.nl> <20130730112505.a5bcb40e.adeason@sinenomine.net> Message-ID: <20130730135231.5463da25.mmeffie@sinenomine.net> On Tue, 30 Jul 2013 11:25:05 -0500 Andrew Deason wrote: > On Tue, 30 Jul 2013 18:01:54 +0200 > Jaap Winius wrote: > > > Could someone please remind me how to remove stuff from the /afs > > directory? I recently discovered an empty directory there, called: > > > > /afs/.:mount > > > > Obviously it was created there by accident, probably by me. However, > > when I try to remove it I get: > > /afs/.:mount is a special magic directory that can be used to refer to > specific volumes via a short path; it's briefly mentioned in the afsd(8) > manpage. You can't get rid of it. There is also a brief mention in the Admin Guide, under "Managing Fileserver Machines", "Mounting Volumes", "To access volumes directly by volume id". -- Michael Meffie From sopko@cs.unc.edu Tue Jul 30 19:39:56 2013 From: sopko@cs.unc.edu (John Sopko) Date: Tue, 30 Jul 2013 14:39:56 -0400 Subject: [OpenAFS] MIT Kerberos des session key Message-ID: Where is the session key for the afs/cell@REALM service principal derived from? If I remove the des-cbc-crc encryption type from both the afs/cell@REALM and the user principals will things still work without having to upgrade all clients to openafs 1.6.5? I would like to get rid of the single des key for the afs/cell@REALM service principal as described in the security advisory. I am running Red Hat 6.4 and MIT kerberos 1.10.3 that comes with rhel6. I have upgraded all my db and file servers to openafs 1.6.5 and things are working nicely, ( thanks everyone involved). Here is my config information. My /var/kerberos/krb5kdc/kdc.conf file has the following in it, this is the default from Red Hat: supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal But when I create a user or a user changes their passwd they do not get the "des-cbc-crc" encryption type, for example kadmin for a user shows: Principal: sopko@CSX.UNC.EDU Number of keys: 6 Key: vno 38, aes256-cts-hmac-sha1-96, no salt Key: vno 38, aes128-cts-hmac-sha1-96, no salt Key: vno 38, des3-cbc-sha1, no salt Key: vno 38, arcfour-hmac, no salt Key: vno 38, des-hmac-sha1, no salt Key: vno 38, des-cbc-md5, no salt Notice there is no des-cbc-crc encryption type for a user principal, I believe this is done on purpose. Note I also I have the following set in the /etc/krb5.conf file. [libdefaults] allow_weak_crypto = true You can explicitly set des-cbc-crc in kadmin and of course I had to do that for the afs principal: Principal: afs/cs.unc.edu@CSX.UNC.EDU Key: vno 10, des-cbc-crc, no salt Using MIT "klist -e" command to show the encryption types while logged in shows: Valid starting Expires Service principal 07/30/13 14:16:12 07/31/13 14:16:12 krbtgt/CSX.UNC.EDU@CSX.UNC.EDU renew until 07/31/13 14:16:12, Etype (skey, tkt): des3-cbc-sha1, des3-cbc-sha1 07/30/13 14:16:12 07/31/13 14:16:12 afs/cs.unc.edu@CSX.UNC.EDU renew until 07/31/13 14:16:12, Etype (skey, tkt): des-cbc-crc, des-cbc-crc So currently the skey (session key) and tkt key for afs/cs.unc.edu is des-cbc-crc. So if I re-key afs/cs.unc.edu service principal to NOT USE des-cbc-crc my understanding is you still need a des-cbc-crc session key unless you upgrade all clients which is not feasible at this time. Will I be ok without a des-cbs-crc key for the user and the service principal? Can I also remove the des-cbc-md5:normal des-hmac-sha1:normal assuming no other service is using it, (my guess is yes)? Thanks for your input. -- John W. Sopko Jr. University of North Carolina email: sopko AT cs.unc.edu Computer Science Dept., CB 3175 Phone: 919-590-6144 Fred Brooks Building; Room 140 Chapel Hill, NC 27599-3175 From ballbery@sinenomine.net Tue Jul 30 20:16:05 2013 From: ballbery@sinenomine.net (Brandon Allbery) Date: Tue, 30 Jul 2013 19:16:05 +0000 Subject: [OpenAFS] MIT Kerberos des session key In-Reply-To: Message-ID: T24gNy8zMC8xMyAxNDozOSwgIkpvaG4gU29wa28iIDxzb3Brb0Bjcy51bmMuZWR1PiB3cm90ZToN Cg0KPldoZXJlIGlzIHRoZSBzZXNzaW9uIGtleSBmb3IgdGhlIGFmcy9jZWxsQFJFQUxNIHNlcnZp Y2UgcHJpbmNpcGFsDQo+ZGVyaXZlZCBmcm9tPyBJZiBJIHJlbW92ZSB0aGUgZGVzLWNiYy1jcmMg ZW5jcnlwdGlvbiB0eXBlIGZyb20gYm90aCB0aGUNCj5hZnMvY2VsbEBSRUFMTSBhbmQgdGhlIHVz ZXIgcHJpbmNpcGFscyB3aWxsIHRoaW5ncyBzdGlsbCB3b3JrIHdpdGhvdXQNCj5oYXZpbmcgdG8g dXBncmFkZSBhbGwgY2xpZW50cyB0byBvcGVuYWZzIDEuNi41Pw0KDQpVc2VyIHByaW5jaXBhbHMg b25seSByZXF1aXJlIGRlcy1jYmMtY3JjIGlmIHlvdSBhcmUgdXNpbmcga2xvZyB2aWENCmthLWZv cndhcmRlciBvciBIZWltZGFsJ3MgImtkYyAtLWthc2VydmVyIjsgYWtsb2cgY2FuIGhhbmRsZSBu b24tZGVzIHVzZXINCnByaW5jaXBhbHMgZmluZS4gSW4gYW55IEFGUyByZWxlYXNlIGJlZm9yZSAx LjYuNSwgYW5kIGV2ZW4gaW4gMS42LjUgaWYgeW91DQpoYXZlIG5vdCBzZXQgdXAgcnhrYWQua2V5 dGFiLCB0aGUgYWZzL2NlbGwgcHJpbmNpcGFsICptdXN0KiBoYXZlDQpkZXMtY2JjLWNyYy4NCg0K PkJ1dCB3aGVuIEkgY3JlYXRlIGEgdXNlciBvciBhIHVzZXIgY2hhbmdlcyB0aGVpciBwYXNzd2Qg dGhleSBkbyBub3QgZ2V0DQo+dGhlICJkZXMtY2JjLWNyYyIgZW5jcnlwdGlvbiB0eXBlLCBmb3Ig ZXhhbXBsZSBrYWRtaW4gZm9yIGEgdXNlciBzaG93czoNCg0KQ2hlY2sga3JiNS5jb25mIGFzIHdl bGwgYXMga2RjLmNvbmYuIEFsc28gSSB3b3VsZCBkaXNhYmxlIG9yIHByZWZlcmFibHkNCnJlbW92 ZSAqYWxsKiBvZiB0aGUgZGVzIGtleXMgZm9yIHByaW5jaXBhbHMgb3RoZXIgdGhhbiBhZnMvY2Vs bCwgbm90IGp1c3QNCmRlcy1jYmMtY3JjLg0KDQotLSANCmJyYW5kb24gcyBhbGxiZXJ5IGtmOG5o ICAgIHNpbmUgbm9taW5lIGFzc29jaWF0ZXMNCmFsbGJlcnkuYkBnbWFpbC5jb20gICAgICAgYmFs bGJlcnlAc2luZW5vbWluZS5uZXQNCnVuaXgsIG9wZW5hZnMsIGtlcmJlcm9zLCBpbmZyYXN0cnVj dHVyZSwgeG1vbmFkDQoNCg0KDQo= From adeason@sinenomine.net Tue Jul 30 20:33:04 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Tue, 30 Jul 2013 14:33:04 -0500 Subject: [OpenAFS] Re: MIT Kerberos des session key References: Message-ID: <20130730143304.2cd703f6.adeason@sinenomine.net> On Tue, 30 Jul 2013 14:39:56 -0400 John Sopko wrote: > Where is the session key for the afs/cell@REALM service principal > derived from? Session keys aren't usually derived from anything in the principal; they're chosen randomly. There is a situation for OpenAFS specifically where we derive a DES key from other things, but that only happens if you disable DES for the entire KDC. That is, for an MIT KDC, it doesn't have anything to do with changing the enctypes on the service principal, but rather if you disable DES entirely in the KDC configuration. (As you may have seen on the list, things here are different for various Heimdal versions, but for MIT krb5 you don't need to deal with that.) > If I remove the des-cbc-crc encryption type from both the > afs/cell@REALM and the user principals will things still work without > having to upgrade all clients to openafs 1.6.5? Yes, probably. You should really try testing with a test environment or test principal if you're unsure about what's going on, though. (You also do need to upgrade and configure the _servers_ if that's not clear.) > But when I create a user or a user changes their passwd they do not > get the "des-cbc-crc" encryption type, for example kadmin for a user > shows: > > Principal: sopko@CSX.UNC.EDU > Number of keys: 6 > Key: vno 38, aes256-cts-hmac-sha1-96, no salt > Key: vno 38, aes128-cts-hmac-sha1-96, no salt > Key: vno 38, des3-cbc-sha1, no salt > Key: vno 38, arcfour-hmac, no salt > Key: vno 38, des-hmac-sha1, no salt > Key: vno 38, des-cbc-md5, no salt > > Notice there is no des-cbc-crc encryption type for a user principal, I > believe this is done on purpose. You have other des-* enctypes in there, though, just by the way. > Using MIT "klist -e" command to show the encryption types while logged > in shows: > > Valid starting Expires Service principal > 07/30/13 14:16:12 07/31/13 14:16:12 krbtgt/CSX.UNC.EDU@CSX.UNC.EDU > renew until 07/31/13 14:16:12, Etype (skey, tkt): > des3-cbc-sha1, des3-cbc-sha1 > 07/30/13 14:16:12 07/31/13 14:16:12 afs/cs.unc.edu@CSX.UNC.EDU > renew until 07/31/13 14:16:12, Etype (skey, tkt): des-cbc-crc, > des-cbc-crc > > So currently the skey (session key) and tkt key for afs/cs.unc.edu > is des-cbc-crc. > > So if I re-key afs/cs.unc.edu service principal to NOT USE des-cbc-crc > my understanding is you still need a des-cbc-crc session key unless > you upgrade all clients which is not feasible at this time. Will I be > ok without a des-cbs-crc key for the user and the service principal? You should be fine without a des-cbc-crc key. The session key is not something stored in the database or anything like that; it is generated every time someone gets an AFS token. MIT krb5 always permits single DES session keys, unless the KDC has turned off single DES entirely, or unless you twiddle with some really new options that I think don't exist in 1.10. If you want to see an example after the AFS service princ no longer has a DES key: kadmin.local: getprinc afs/localcell Principal: afs/localcell@LOCALCELL [...] Number of keys: 4 Key: vno 7, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt Key: vno 7, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt Key: vno 7, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 7, ArcFour with HMAC/md5, no salt $ kinit adeason Password for adeason@LOCALCELL: $ aklog $ klist -e Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: adeason@LOCALCELL Valid starting Expires Service principal 07/30/13 14:13:37 07/31/13 14:13:37 krbtgt/LOCALCELL@LOCALCELL Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1 07/30/13 14:13:43 07/31/13 14:13:37 afs/localcell@LOCALCELL Etype (skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with 96-bit SHA-1 HMAC You can also test out some of this service principal and enctype stuff without any AFS infrastructure, if you want. If you run: $ kvno -e des-cbc-crc afs/cellname@REALMNAME You'll be doing pretty much the same thing that any old aklog does, in terms of interacting with the krb5 KDC. You can try that out and test other service principals if you want, to see what happens with them. -- Andrew Deason adeason@sinenomine.net From kaduk@MIT.EDU Wed Jul 31 00:32:51 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Tue, 30 Jul 2013 19:32:51 -0400 (EDT) Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <51F7DE25.80909@secure-endpoints.com> References: <20130726160944.a0e6fd1e.adeason@sinenomine.net> <87txjhj9vl.fsf@windlord.stanford.edu> <51F6E8CE.7070405@secure-endpoints.com> <20130730.125704.1060864531730322078.haba@habanero> <51F7DE25.80909@secure-endpoints.com> Message-ID: On Tue, 30 Jul 2013, Jeffrey Altman wrote: > This is an incorrect description. The explicit problem occurs when the > following combination is true: > > 1. user has one or more strong enctype keys with non-default > password salts > > 2. the only keys with default password salts are weak enctypes > > 3. preauth is required A bit off-topic (and feel free to go off-list), but I'm curious if there is anything that can be said in general to be a cause for the presence of non-default salts. Thanks, Ben From jaltman@secure-endpoints.com Wed Jul 31 00:44:52 2013 From: jaltman@secure-endpoints.com (Jeffrey Altman) Date: Tue, 30 Jul 2013 19:44:52 -0400 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: References: <20130726160944.a0e6fd1e.adeason@sinenomine.net> <87txjhj9vl.fsf@windlord.stanford.edu> <51F6E8CE.7070405@secure-endpoints.com> <20130730.125704.1060864531730322078.haba@habanero> <51F7DE25.80909@secure-endpoints.com> Message-ID: <51F84FF4.5050003@secure-endpoints.com> This is a cryptographically signed message in MIME format. --------------ms080600010606050407010203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/30/2013 7:32 PM, Benjamin Kaduk wrote: > On Tue, 30 Jul 2013, Jeffrey Altman wrote: >=20 >> This is an incorrect description. The explicit problem occurs when th= e >> following combination is true: >> >> 1. user has one or more strong enctype keys with non-default >> password salts >> >> 2. the only keys with default password salts are weak enctypes >> >> 3. preauth is required >=20 > A bit off-topic (and feel free to go off-list), but I'm curious if ther= e > is anything that can be said in general to be a cause for the presence > of non-default salts. >=20 > Thanks, >=20 > Ben Realm or principal renaming without updating the keys. This is not specific to Heimdal. --------------ms080600010606050407010203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINITCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggbXMIIFv6ADAgECAhBD 9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzAxMTUwMDAwMDBa Fw0xNDAxMTYyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzU4Mjc1NTk5Njg2MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDGK4TaaHgHBkEIqx9 xgS06g4a1HdPcm5Lspe5OkYgSdxRiX84qp6msq+DWu1yQqmAxoS0a70Ctp99UgojGzKn2F8g nIEEFe0bOMbye736C4LWashMhB8iRXbNmfQHJU5mrLoeghHUnTsmRZsFOagpwZgHAC4ZKITq 87yJvVGGfIAS77EuoZx3PlQCTeq6xdmas4BzLxb+DF3vYkRvtLOnh3ixsEu1Js1QjIcrBIA8 bZp0fU9SZWTU1MSHheYykKhBDBNurQpYEJ1VkJGvgITfcRUUfifxe7HbMlyDHJQtzn9mpocE xiF1Vtzthcw6BhdqDhw4IvhWin+CY1Q6XOoHAgMBAAGjggLVMIIC0TAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFLNBzIZb/xB6K+oeDwfBVLaB3qbUMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCoGCmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYF MTA5MjIwDQYJKoZIhvcNAQEFBQADggEBAHgy34Smu5krf/eRWcjkEwnLYWZSXqo8T6/FBeSS TUE/E7DB6k27NUate7u5keQnrWmohWErxU/ona1WVHIdvSmK1Ow4IbUM9Pl4TKsDmBezDd8U eQU6q7KtkQuooeO/OgaJ49NXq/UgqoTXi72sAVpiPtOqgRJ4m+oO6Hv9OF5co49z5zMRFI6A SHEVi/41s8iYxlv++2ghtDDIA6vLS3MhGogh0wXFszn/dcWeluOkQZR9glfLr7Y853v3OBoh u1k40Q3NpnTl9ZgODP6Gh/hD08fXmBka0/p9rFRhR1NQBQg0WQbwS0ScFiECviWt9TbN2k/e GLwmOQD4a4Md7uoxggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEP2DS/S5ZSBTt+yrappszwwCQYF Kw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMwNzMwMjM0NDUyWjAjBgkqhkiG9w0BCQQxFgQUMzTfpXFvBf5Vj11DFttfyXk/C1EwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB zAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQ/YNL9LllIFO37KtqmmzPDCBzgYLKoZIhvcN AQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhBD9g0v0uWUgU7fsq2qabM8MA0GCSqGSIb3DQEBAQUABIIB AAmmrJ4dA/Ikw7pG5atHGMEJAjwdAWkQ+V+m0IP5+erSJvZ6yuEcOGHRrts1MX1JTw2R0t4h VKn0OxTJUnaBj7UOE9T0S9vw9C2EXyIctPiDRhvpRoRM3FYIwxrz8vxqkWAODOHjIEb0M407 mCcS16O60kLfulNU6qGcb+a+JbLGC3wc0kblNGj9jNS5TvC+baSx970Vie4G2T+M3+0UkrLY 3GNS6M/6Uz24QJi+Nn6W3yUfh/HLB7VWIXnnFAAb30brsbvPJHHCqXrmBPllfHTBNg1rxcBi r0+P+O7LZcvx+5fUGGZ10FV4sy3wX/rxsrP79BgfHPLk2WgFQyEBMRsAAAAAAAA= --------------ms080600010606050407010203-- From kaduk@MIT.EDU Wed Jul 31 00:55:54 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Tue, 30 Jul 2013 19:55:54 -0400 (EDT) Subject: [OpenAFS] Re: MIT Kerberos des session key In-Reply-To: <20130730143304.2cd703f6.adeason@sinenomine.net> References: <20130730143304.2cd703f6.adeason@sinenomine.net> Message-ID: Andrew is spot-on, just two minor clarifications (inline) On Tue, 30 Jul 2013, Andrew Deason wrote: > On Tue, 30 Jul 2013 14:39:56 -0400 > John Sopko wrote: > >> Where is the session key for the afs/cell@REALM service principal >> derived from? > > Session keys aren't usually derived from anything in the principal; > they're chosen randomly. There is a situation for OpenAFS specifically > where we derive a DES key from other things, but that only happens if > you disable DES for the entire KDC. That is, for an MIT KDC, it doesn't > have anything to do with changing the enctypes on the service principal, > but rather if you disable DES entirely in the KDC configuration. (As you > may have seen on the list, things here are different for various Heimdal > versions, but for MIT krb5 you don't need to deal with that.) > >> If I remove the des-cbc-crc encryption type from both the >> afs/cell@REALM and the user principals will things still work without >> having to upgrade all clients to openafs 1.6.5? > > Yes, probably. You should really try testing with a test environment or > test principal if you're unsure about what's going on, though. (You also > do need to upgrade and configure the _servers_ if that's not clear.) The MIT KDC is happy to generate a DES session key even if a service does not have a DES enctype in the KDB, for KDC's prior to the 1.11 release. The 1.11 release gives more control over this feature. >> But when I create a user or a user changes their passwd they do not >> get the "des-cbc-crc" encryption type, for example kadmin for a user >> shows: >> >> Principal: sopko@CSX.UNC.EDU >> Number of keys: 6 >> Key: vno 38, aes256-cts-hmac-sha1-96, no salt >> Key: vno 38, aes128-cts-hmac-sha1-96, no salt >> Key: vno 38, des3-cbc-sha1, no salt >> Key: vno 38, arcfour-hmac, no salt >> Key: vno 38, des-hmac-sha1, no salt >> Key: vno 38, des-cbc-md5, no salt >> >> Notice there is no des-cbc-crc encryption type for a user principal, I >> believe this is done on purpose. > > You have other des-* enctypes in there, though, just by the way. > >> Using MIT "klist -e" command to show the encryption types while logged >> in shows: >> >> Valid starting Expires Service principal >> 07/30/13 14:16:12 07/31/13 14:16:12 krbtgt/CSX.UNC.EDU@CSX.UNC.EDU >> renew until 07/31/13 14:16:12, Etype (skey, tkt): >> des3-cbc-sha1, des3-cbc-sha1 >> 07/30/13 14:16:12 07/31/13 14:16:12 afs/cs.unc.edu@CSX.UNC.EDU >> renew until 07/31/13 14:16:12, Etype (skey, tkt): des-cbc-crc, >> des-cbc-crc >> >> So currently the skey (session key) and tkt key for afs/cs.unc.edu >> is des-cbc-crc. >> >> So if I re-key afs/cs.unc.edu service principal to NOT USE des-cbc-crc >> my understanding is you still need a des-cbc-crc session key unless >> you upgrade all clients which is not feasible at this time. Will I be >> ok without a des-cbs-crc key for the user and the service principal? AFS doesn't care whether it's des-cbc-crc or des-cbc-md5; any DES enctype will do. -Ben Kaduk > You should be fine without a des-cbc-crc key. The session key is not > something stored in the database or anything like that; it is generated > every time someone gets an AFS token. MIT krb5 always permits single DES > session keys, unless the KDC has turned off single DES entirely, or > unless you twiddle with some really new options that I think don't exist > in 1.10. > > If you want to see an example after the AFS service princ no longer has > a DES key: > > kadmin.local: getprinc afs/localcell > Principal: afs/localcell@LOCALCELL > [...] > Number of keys: 4 > Key: vno 7, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt > Key: vno 7, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt > Key: vno 7, Triple DES cbc mode with HMAC/sha1, no salt > Key: vno 7, ArcFour with HMAC/md5, no salt > > $ kinit adeason > Password for adeason@LOCALCELL: > $ aklog > $ klist -e > Ticket cache: FILE:/tmp/krb5cc_1000 > Default principal: adeason@LOCALCELL > > Valid starting Expires Service principal > 07/30/13 14:13:37 07/31/13 14:13:37 krbtgt/LOCALCELL@LOCALCELL > Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1 > 07/30/13 14:13:43 07/31/13 14:13:37 afs/localcell@LOCALCELL > Etype (skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with 96-bit SHA-1 HMAC > > > You can also test out some of this service principal and enctype stuff > without any AFS infrastructure, if you want. If you run: > > $ kvno -e des-cbc-crc afs/cellname@REALMNAME > > You'll be doing pretty much the same thing that any old aklog does, in > terms of interacting with the krb5 KDC. You can try that out and test > other service principals if you want, to see what happens with them. > > -- > Andrew Deason > adeason@sinenomine.net > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > From jhutz@cmu.edu Wed Jul 31 02:17:23 2013 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Tue, 30 Jul 2013 21:17:23 -0400 Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <51F84FF4.5050003@secure-endpoints.com> References: <20130726160944.a0e6fd1e.adeason@sinenomine.net> <87txjhj9vl.fsf@windlord.stanford.edu> <51F6E8CE.7070405@secure-endpoints.com> <20130730.125704.1060864531730322078.haba@habanero> <51F7DE25.80909@secure-endpoints.com> <51F84FF4.5050003@secure-endpoints.com> Message-ID: <1375233443.23365.486.camel@minbar.fac.cs.cmu.edu> On Tue, 2013-07-30 at 19:44 -0400, Jeffrey Altman wrote: > On 7/30/2013 7:32 PM, Benjamin Kaduk wrote: > > On Tue, 30 Jul 2013, Jeffrey Altman wrote: > > > >> This is an incorrect description. The explicit problem occurs when the > >> following combination is true: > >> > >> 1. user has one or more strong enctype keys with non-default > >> password salts > >> > >> 2. the only keys with default password salts are weak enctypes > >> > >> 3. preauth is required > > > > A bit off-topic (and feel free to go off-list), but I'm curious if there > > is anything that can be said in general to be a cause for the presence > > of non-default salts. > > > > Thanks, > > > > Ben > > Realm or principal renaming without updating the keys. This is not > specific to Heimdal. Also, some realms contain keys that date back to when they were running krb4; these have non-default salts, according to krb5's way of thinking. From haba@kth.se Wed Jul 31 06:28:50 2013 From: haba@kth.se (Harald Barth) Date: Wed, 31 Jul 2013 07:28:50 +0200 (CEST) Subject: [OpenAFS] Re: Heimdal KDC bug mentioned in rekeying document In-Reply-To: <51F7DE25.80909@secure-endpoints.com> References: <51F6E8CE.7070405@secure-endpoints.com> <20130730.125704.1060864531730322078.haba@habanero> <51F7DE25.80909@secure-endpoints.com> Message-ID: <20130731.072850.385152963173197418.haba@habanero> > This is an incorrect description. That might very well be, but I thought it was better than nothing because others who are in trouble might want to know that they are not alone ;-/ > The explicit problem occurs when the > following combination is true: > > 1. user has one or more strong enctype keys with non-default > password salts > > 2. the only keys with default password salts are weak enctypes I don't know how the user would have ended up with that combination and I don't know how the enctype list looked before the user was told to change password. > 3. preauth is required As 1.5.x seems to have the bug that you can't turn it off, yes of course. > In this combination, the strong enctype with the non-default password > salt will not be recommended to the client in the pa-etype-info or > pa-etype-info2 data sent with the preauth required error reply. And what would happen if there is no strong enctype at all? > Since no pa-etype hint was provided the client chooses its preferred > enctype which is aes256. > A correction has been prepared and will be submitted after testing. :-) Harald. From sopko@cs.unc.edu Wed Jul 31 13:25:54 2013 From: sopko@cs.unc.edu (John Sopko) Date: Wed, 31 Jul 2013 08:25:54 -0400 Subject: [OpenAFS] Re: MIT Kerberos des session key In-Reply-To: References: <20130730143304.2cd703f6.adeason@sinenomine.net> Message-ID: Ok thanks for all the input. Seems pretty straight forward for MIT kerberos. Note I updated my /var/kerberos/krb5kdc/kdc.conf encryption types: supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal I had to restart the kadmin server, (a reload did not work), to get the new encryption types while changing a password. I tested ktadd on a test user and the only the above keys get created. Summary: upgrade all servers to openafs 1.6.5 ktadd -k /tmp/rxkad.keytab afs/cell cp rxkad.keytab to /usr/afs/etc/rxkad.keytab on all servers restart all servers keep KeyFile in place for a day or more then rename and touch CellServDB On Tue, Jul 30, 2013 at 7:55 PM, Benjamin Kaduk wrote: > Andrew is spot-on, just two minor clarifications (inline) > > > On Tue, 30 Jul 2013, Andrew Deason wrote: > >> On Tue, 30 Jul 2013 14:39:56 -0400 >> John Sopko wrote: >> >>> Where is the session key for the afs/cell@REALM service principal >>> derived from? >> >> >> Session keys aren't usually derived from anything in the principal; >> they're chosen randomly. There is a situation for OpenAFS specifically >> where we derive a DES key from other things, but that only happens if >> you disable DES for the entire KDC. That is, for an MIT KDC, it doesn't >> have anything to do with changing the enctypes on the service principal, >> but rather if you disable DES entirely in the KDC configuration. (As you >> may have seen on the list, things here are different for various Heimdal >> versions, but for MIT krb5 you don't need to deal with that.) >> >>> If I remove the des-cbc-crc encryption type from both the >>> afs/cell@REALM and the user principals will things still work without >>> having to upgrade all clients to openafs 1.6.5? >> >> >> Yes, probably. You should really try testing with a test environment or >> test principal if you're unsure about what's going on, though. (You also >> do need to upgrade and configure the _servers_ if that's not clear.) > > > The MIT KDC is happy to generate a DES session key even if a service does > not have a DES enctype in the KDB, for KDC's prior to the 1.11 release. The > 1.11 release gives more control over this feature. > > >>> But when I create a user or a user changes their passwd they do not >>> get the "des-cbc-crc" encryption type, for example kadmin for a user >>> shows: >>> >>> Principal: sopko@CSX.UNC.EDU >>> Number of keys: 6 >>> Key: vno 38, aes256-cts-hmac-sha1-96, no salt >>> Key: vno 38, aes128-cts-hmac-sha1-96, no salt >>> Key: vno 38, des3-cbc-sha1, no salt >>> Key: vno 38, arcfour-hmac, no salt >>> Key: vno 38, des-hmac-sha1, no salt >>> Key: vno 38, des-cbc-md5, no salt >>> >>> Notice there is no des-cbc-crc encryption type for a user principal, I >>> believe this is done on purpose. >> >> >> You have other des-* enctypes in there, though, just by the way. >> >>> Using MIT "klist -e" command to show the encryption types while logged >>> in shows: >>> >>> Valid starting Expires Service principal >>> 07/30/13 14:16:12 07/31/13 14:16:12 krbtgt/CSX.UNC.EDU@CSX.UNC.EDU >>> renew until 07/31/13 14:16:12, Etype (skey, tkt): >>> des3-cbc-sha1, des3-cbc-sha1 >>> 07/30/13 14:16:12 07/31/13 14:16:12 afs/cs.unc.edu@CSX.UNC.EDU >>> renew until 07/31/13 14:16:12, Etype (skey, tkt): des-cbc-crc, >>> des-cbc-crc >>> >>> So currently the skey (session key) and tkt key for afs/cs.unc.edu >>> is des-cbc-crc. >>> >>> So if I re-key afs/cs.unc.edu service principal to NOT USE des-cbc-crc >>> my understanding is you still need a des-cbc-crc session key unless >>> you upgrade all clients which is not feasible at this time. Will I be >>> ok without a des-cbs-crc key for the user and the service principal? > > > AFS doesn't care whether it's des-cbc-crc or des-cbc-md5; any DES enctype > will do. > > -Ben Kaduk > > >> You should be fine without a des-cbc-crc key. The session key is not >> something stored in the database or anything like that; it is generated >> every time someone gets an AFS token. MIT krb5 always permits single DES >> session keys, unless the KDC has turned off single DES entirely, or >> unless you twiddle with some really new options that I think don't exist >> in 1.10. >> >> If you want to see an example after the AFS service princ no longer has >> a DES key: >> >> kadmin.local: getprinc afs/localcell >> Principal: afs/localcell@LOCALCELL >> [...] >> Number of keys: 4 >> Key: vno 7, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt >> Key: vno 7, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt >> Key: vno 7, Triple DES cbc mode with HMAC/sha1, no salt >> Key: vno 7, ArcFour with HMAC/md5, no salt >> >> $ kinit adeason >> Password for adeason@LOCALCELL: >> $ aklog >> $ klist -e >> Ticket cache: FILE:/tmp/krb5cc_1000 >> Default principal: adeason@LOCALCELL >> >> Valid starting Expires Service principal >> 07/30/13 14:13:37 07/31/13 14:13:37 krbtgt/LOCALCELL@LOCALCELL >> Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES >> cbc mode with HMAC/sha1 >> 07/30/13 14:13:43 07/31/13 14:13:37 afs/localcell@LOCALCELL >> Etype (skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with >> 96-bit SHA-1 HMAC >> >> >> You can also test out some of this service principal and enctype stuff >> without any AFS infrastructure, if you want. If you run: >> >> $ kvno -e des-cbc-crc afs/cellname@REALMNAME >> >> You'll be doing pretty much the same thing that any old aklog does, in >> terms of interacting with the krb5 KDC. You can try that out and test >> other service principals if you want, to see what happens with them. >> >> -- >> Andrew Deason >> adeason@sinenomine.net >> >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > -- John W. Sopko Jr. University of North Carolina email: sopko AT cs.unc.edu Computer Science Dept., CB 3175 Phone: 919-590-6144 Fred Brooks Building; Room 140 Chapel Hill, NC 27599-3175 From kendrick.hernandez@umbc.edu Wed Jul 31 20:00:32 2013 From: kendrick.hernandez@umbc.edu (Kendrick Hernandez) Date: Wed, 31 Jul 2013 15:00:32 -0400 Subject: [OpenAFS] Building 1.4.15 on Solaris 10 Message-ID: --089e0168134402277404e2d357ba Content-Type: text/plain; charset=UTF-8 Hi all, I'm curious if anyone has run into problems building OpenAFS 1.4.15 on Solaris 10 x86? I'm building on Solaris 10 1/13 with Solaris Studio 12.3, and using the following configure options: ./configure --enable-debug --enable-transarc-paths --enable-namei-fileserver --enable-supergroups --with-afs-sysname=sunx86_510 and the build fails in src/afs/SOLARIS/osi_vnodeops.c[1]. I've also tried building on an older release of Solaris 10 with a much older version of Sun Studio and get similar results. k- ------- [1] ------- /opt/SUNWspro/bin/cc -I. -I.. -I../nfs -I/local/afs/builds/sunx86_510/openafs-1.4.15/src -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/config -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/rx/SOLARIS -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/rxkad -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/rxkad/domestic -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/util -I/local/afs/builds/sunx86_510/openafs-1.4.15/src -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/util -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/rxkad -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/config -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/fsint -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/vlserver -I/local/afs/builds/sunx86_510/openafs-1.4.15/include -I/local/afs/builds/sunx86_510/openafs-1.4.15/include/afs -I. -I.. -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/config -DAFSDEBUG -DKERNEL -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOUNT -D_KERNEL -DSYSV -dn -o osi_vnodeops.o -c /local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1085: warning: old-style declaration or incorrect type for: afs_map "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1142: warning: implicit function declaration: map_addr "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1183: warning: old-style declaration or incorrect type for: afs_pathconf "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1219: warning: old-style declaration or incorrect type for: afs_ioctl "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1247: warning: old-style declaration or incorrect type for: afs_seek "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1367: warning: old-style declaration or incorrect type for: afs_cmp "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1544: warning: initialization type mismatch "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1546: warning: initialization type mismatch "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1547: warning: initialization type mismatch "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1558: warning: initialization type mismatch "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1563: warning: initialization type mismatch "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1625: warning: old-style declaration or incorrect type for: gafs_open "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1639: warning: old-style declaration or incorrect type for: gafs_close "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1655: warning: old-style declaration or incorrect type for: gafs_getattr "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1670: warning: old-style declaration or incorrect type for: gafs_setattr "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1685: warning: old-style declaration or incorrect type for: gafs_access "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1700: warning: old-style declaration or incorrect type for: gafs_lookup "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1717: warning: old-style declaration or incorrect type for: gafs_create "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1734: warning: old-style declaration or incorrect type for: gafs_remove "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1747: warning: old-style declaration or incorrect type for: gafs_link "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1761: warning: old-style declaration or incorrect type for: gafs_rename "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1784: warning: argument #1 is incompatible with prototype: prototype: pointer to struct vnode {struct mutex {..} v_lock, unsigned int v_flag, unsigned int v_count, pointer to void v_data, pointer to struct vfs {..} v_vfsp, pointer to struct stdata {..} v_stream, enum vtype {VBAD(11), VPORT(10), VSOCK(9), VPROC(8), VDOOR(7), VFIFO(6), VLNK(5), VCHR(4), VBLK(3), VDIR(2), VREG(1), VNON(0)} v_type, unsigned long v_rdev, pointer to struct vfs {..} v_vfsmountedhere, pointer to struct vnodeops {..} v_op, pointer to struct page {..} v_pages, unsigned long v_npages, unsigned long v_msnpages, pointer to struct page {..} v_scanfront, pointer to struct page {..} v_scanback, pointer to struct filock {..} v_filocks, pointer to struct shrlocklist {..} v_shrlocks, struct _krwlock {..} v_nbllock, struct _kcondvar {..} v_cv, pointer to void v_locality, pointer to struct fem_head {..} v_femhead, pointer to char v_path, unsigned int v_rdcnt, unsigned int v_wrcnt, unsigned long long v_mmap_read, unsigned long long v_mmap_write, pointer to void v_mpssdata, long long v_scantime, unsigned short v_mset, unsigned int v_msflags, pointer to struct vnode {..} v_msnext, pointer to struct vnode {..} v_msprev, struct _krwlock {..} v_mslock} : "../sys/vnode.h", line 939 argument : pointer to struct vcache {struct vnode {..} v, struct afs_q {..} vlruq, pointer to struct vcache {..} nextfree, pointer to struct vcache {..} hnext, struct afs_q {..} vhashq, struct VenusFid {..} fid, struct mstat {..} m, struct afs_lock {..} lock, struct afs_lock {..} vlock, struct _krwlock {..} rwlock, pointer to struct cred {..} credp, struct mutex {..} pvnLock, int parentVnode, int parentUnique, pointer to struct VenusFid {..} mvid, pointer to char linkData, struct afs_hyper_t {..} flushDV, struct afs_hyper_t {..} mapDV, long long truncPos, pointer to struct server {..} callback, unsigned int cbExpires, struct afs_q {..} callsort, pointer to struct axscache {..} Access, int anyAccess, int last_looker, int activeV, pointer to struct SimpleLocks {..} slocks, short opens, short execsOrWriters, short flockCount, char mvstat, unsigned int states, unsigned int vstates, pointer to struct dcache {..} dchint, int vc_error, int xlatordv, pointer to struct cred {..} uncred, int asynchrony, short multiPage} "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1784: prototype mismatch: 5 args passed, 6 expected "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1786: warning: argument #1 is incompatible with prototype: prototype: pointer to struct vnode {struct mutex {..} v_lock, unsigned int v_flag, unsigned int v_count, pointer to void v_data, pointer to struct vfs {..} v_vfsp, pointer to struct stdata {..} v_stream, enum vtype {VBAD(11), VPORT(10), VSOCK(9), VPROC(8), VDOOR(7), VFIFO(6), VLNK(5), VCHR(4), VBLK(3), VDIR(2), VREG(1), VNON(0)} v_type, unsigned long v_rdev, pointer to struct vfs {..} v_vfsmountedhere, pointer to struct vnodeops {..} v_op, pointer to struct page {..} v_pages, unsigned long v_npages, unsigned long v_msnpages, pointer to struct page {..} v_scanfront, pointer to struct page {..} v_scanback, pointer to struct filock {..} v_filocks, pointer to struct shrlocklist {..} v_shrlocks, struct _krwlock {..} v_nbllock, struct _kcondvar {..} v_cv, pointer to void v_locality, pointer to struct fem_head {..} v_femhead, pointer to char v_path, unsigned int v_rdcnt, unsigned int v_wrcnt, unsigned long long v_mmap_read, unsigned long long v_mmap_write, pointer to void v_mpssdata, long long v_scantime, unsigned short v_mset, unsigned int v_msflags, pointer to struct vnode {..} v_msnext, pointer to struct vnode {..} v_msprev, struct _krwlock {..} v_mslock} : "../sys/vnode.h", line 914 argument : pointer to struct vcache {struct vnode {..} v, struct afs_q {..} vlruq, pointer to struct vcache {..} nextfree, pointer to struct vcache {..} hnext, struct afs_q {..} vhashq, struct VenusFid {..} fid, struct mstat {..} m, struct afs_lock {..} lock, struct afs_lock {..} vlock, struct _krwlock {..} rwlock, pointer to struct cred {..} credp, struct mutex {..} pvnLock, int parentVnode, int parentUnique, pointer to struct VenusFid {..} mvid, pointer to char linkData, struct afs_hyper_t {..} flushDV, struct afs_hyper_t {..} mapDV, long long truncPos, pointer to struct server {..} callback, unsigned int cbExpires, struct afs_q {..} callsort, pointer to struct axscache {..} Access, int anyAccess, int last_looker, int activeV, pointer to struct SimpleLocks {..} slocks, short opens, short execsOrWriters, short flockCount, char mvstat, unsigned int states, unsigned int vstates, pointer to struct dcache {..} dchint, int vc_error, int xlatordv, pointer to struct cred {..} uncred, int asynchrony, short multiPage} "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1794: warning: old-style declaration or incorrect type for: gafs_mkdir "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1810: warning: old-style declaration or incorrect type for: gafs_rmdir "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1825: warning: old-style declaration or incorrect type for: gafs_readdir "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1839: warning: old-style declaration or incorrect type for: gafs_symlink "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1855: warning: old-style declaration or incorrect type for: gafs_readlink "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1869: warning: old-style declaration or incorrect type for: gafs_fsync "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1939: warning: old-style declaration or incorrect type for: gafs_fid "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1946: warning: implicit function declaration: afs_fid cc: acomp failed for /local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c *** Error code 2 make: Fatal error: Command failed for target `osi_vnodeops.o' Current working directory /local/afs/builds/sunx86_510/openafs-1.4.15/src/libafs/MODLOAD32 *** Error code 1 make: Fatal error: Command failed for target `solaris_compdirs' Current working directory /local/afs/builds/sunx86_510/openafs-1.4.15/src/libafs *** Error code 1 make: Fatal error: Command failed for target `libafs' Current working directory /local/afs/builds/sunx86_510/openafs-1.4.15 *** Error code 1 make: Fatal error: Command failed for target `build' Current working directory /local/afs/builds/sunx86_510/openafs-1.4.15 *** Error code 1 make: Fatal error: Command failed for target `all' FATAL: Looks like the compilation failed somewhere... -- : Kendrick Hernandez : UNIX Systems Administrator : UNIX Systems and Infrastructure : Division of Information Technology : University of Maryland, Baltimore County --089e0168134402277404e2d357ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm curious if anyone has r= un into problems building OpenAFS 1.4.15 on Solaris 10 x86?

<= div>I'm building on Solaris 10 1/13 with Solaris Studio 12.3, and using= the following configure options:

=C2=A0 =C2=A0 =C2=A0./configure --enable-debug --enable= -transarc-paths --enable-namei-fileserver --enable-supergroups --with-afs-s= ysname=3Dsunx86_510

and the build fails = in src/afs/SOLARIS/osi_vnodeops.c[1]. I've also tried building on an ol= der release of Solaris 10 with a much older version of Sun Studio and get s= imilar results.

k-

------- [1] -------
/opt/SUNWspro/bin/cc -I. -I.. -I../nfs =C2= =A0-I/local/afs/builds/sunx86_510/openafs-1.4.15/src =C2=A0-I/local/afs/bui= lds/sunx86_510/openafs-1.4.15/src/afs =C2=A0-I/local/afs/builds/sunx86_510/= openafs-1.4.15/src/afs/SOLARIS =C2=A0-I/local/afs/builds/sunx86_510/openafs= -1.4.15/src/config =C2=A0-I/local/afs/builds/sunx86_510/openafs-1.4.15/src/= rx/SOLARIS =C2=A0-I/local/afs/builds/sunx86_510/openafs-1.4.15/src/rxkad = =C2=A0-I/local/afs/builds/sunx86_510/openafs-1.4.15/src/rxkad/domestic =C2= =A0-I/local/afs/builds/sunx86_510/openafs-1.4.15/src/util =C2=A0-I/local/af= s/builds/sunx86_510/openafs-1.4.15/src =C2=A0-I/local/afs/builds/sunx86_510= /openafs-1.4.15/src/afs =C2=A0-I/local/afs/builds/sunx86_510/openafs-1.4.15= /src/afs/SOLARIS =C2=A0-I/local/afs/builds/sunx86_510/openafs-1.4.15/src/ut= il =C2=A0-I/local/afs/builds/sunx86_510/openafs-1.4.15/src/rxkad =C2=A0-I/l= ocal/afs/builds/sunx86_510/openafs-1.4.15/src/config =C2=A0-I/local/afs/bui= lds/sunx86_510/openafs-1.4.15/src/fsint =C2=A0-I/local/afs/builds/sunx86_51= 0/openafs-1.4.15/src/vlserver =C2=A0-I/local/afs/builds/sunx86_510/openafs-= 1.4.15/include =C2=A0-I/local/afs/builds/sunx86_510/openafs-1.4.15/include/= afs =C2=A0-I. -I.. -I/local/afs/builds/sunx86_510/openafs-1.4.15/src/config= =C2=A0-DAFSDEBUG -DKERNEL -DAFS -DVICE -DNFS -DUFS -DINET -DQUOTA -DGETMOU= NT -D_KERNEL -DSYSV -dn =C2=A0 =C2=A0 -o osi_vnodeops.o -c /local/afs/build= s/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/S= OLARIS/osi_vnodeops.c", line 1085: warning: old-style declaration or i= ncorrect type for: afs_map
"/local/afs/builds/sunx86_510/ope= nafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1142: warning: impli= cit function declaration: map_addr
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1183: warning: old-style declaration or incorrect ty= pe for: afs_pathconf
"/local/afs/builds/sunx86_510/openafs-1= .4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1219: warning: old-style d= eclaration or incorrect type for: afs_ioctl
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1247: warning: old-style declaration or incorrect ty= pe for: afs_seek
"/local/afs/builds/sunx86_510/openafs-1.4.1= 5/src/afs/SOLARIS/osi_vnodeops.c", line 1367: warning: old-style decla= ration or incorrect type for: afs_cmp
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1544: warning: initialization type mismatch
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vno= deops.c", line 1546: warning: initialization type mismatch
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1547: warning: initialization type mismatch
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vno= deops.c", line 1558: warning: initialization type mismatch
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1563: warning: initialization type mismatch
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vno= deops.c", line 1625: warning: old-style declaration or incorrect type = for: gafs_open
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1639: warning: old-style declaration or incorrect ty= pe for: gafs_close
"/local/afs/builds/sunx86_510/openafs-1.4= .15/src/afs/SOLARIS/osi_vnodeops.c", line 1655: warning: old-style dec= laration or incorrect type for: gafs_getattr
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1670: warning: old-style declaration or incorrect ty= pe for: gafs_setattr
"/local/afs/builds/sunx86_510/openafs-1= .4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1685: warning: old-style d= eclaration or incorrect type for: gafs_access
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1700: warning: old-style declaration or incorrect ty= pe for: gafs_lookup
"/local/afs/builds/sunx86_510/openafs-1.= 4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1717: warning: old-style de= claration or incorrect type for: gafs_create
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1734: warning: old-style declaration or incorrect ty= pe for: gafs_remove
"/local/afs/builds/sunx86_510/openafs-1.= 4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1747: warning: old-style de= claration or incorrect type for: gafs_link
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1761: warning: old-style declaration or incorrect ty= pe for: gafs_rename
"/local/afs/builds/sunx86_510/openafs-1.= 4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1784: warning: argument #1 = is incompatible with prototype:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prototype: pointer to struct vnode {struct= mutex {..} v_lock, unsigned int v_flag, unsigned int v_count, pointer to v= oid v_data, pointer to struct vfs {..} v_vfsp, pointer to struct stdata {..= } v_stream, enum vtype {VBAD(11), VPORT(10), VSOCK(9), VPROC(8), VDOOR(7), = VFIFO(6), VLNK(5), VCHR(4), VBLK(3), VDIR(2), VREG(1), VNON(0)} v_type, uns= igned long v_rdev, pointer to struct vfs {..} v_vfsmountedhere, pointer to = struct vnodeops {..} v_op, pointer to struct page {..} v_pages, unsigned lo= ng v_npages, unsigned long v_msnpages, pointer to struct page {..} v_scanfr= ont, pointer to struct page {..} v_scanback, pointer to struct filock {..} = v_filocks, pointer to struct shrlocklist {..} v_shrlocks, struct _krwlock {= ..} v_nbllock, struct _kcondvar {..} v_cv, pointer to void v_locality, poin= ter to struct fem_head {..} v_femhead, pointer to char v_path, unsigned int= v_rdcnt, unsigned int v_wrcnt, unsigned long long v_mmap_read, unsigned lo= ng long v_mmap_write, pointer to void v_mpssdata, long long v_scantime, uns= igned short v_mset, unsigned int v_msflags, pointer to struct vnode {..} v_= msnext, pointer to struct vnode {..} v_msprev, struct _krwlock {..} v_msloc= k} : "../sys/vnode.h", line 939
=C2=A0 =C2=A0 =C2=A0 =C2=A0 argument : pointer to struct vcache {struc= t vnode {..} v, struct afs_q {..} vlruq, pointer to struct vcache {..} next= free, pointer to struct vcache {..} hnext, struct afs_q {..} vhashq, struct= VenusFid {..} fid, struct mstat {..} m, struct afs_lock {..} lock, struct = afs_lock {..} vlock, struct _krwlock {..} rwlock, pointer to struct cred {.= .} credp, struct mutex {..} pvnLock, int parentVnode, int parentUnique, poi= nter to struct VenusFid {..} mvid, pointer to char linkData, struct afs_hyp= er_t {..} flushDV, struct afs_hyper_t {..} mapDV, long long truncPos, point= er to struct server {..} callback, unsigned int cbExpires, struct afs_q {..= } callsort, pointer to struct axscache {..} Access, int anyAccess, int last= _looker, int activeV, pointer to struct SimpleLocks {..} slocks, short open= s, short execsOrWriters, short flockCount, char mvstat, unsigned int states= , unsigned int vstates, pointer to struct dcache {..} dchint, int vc_error,= int xlatordv, pointer to struct cred {..} uncred, int asynchrony, short mu= ltiPage}
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1784: prototype mismatch: 5 args passed, 6 expected<= /div>
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS= /osi_vnodeops.c", line 1786: warning: argument #1 is incompatible with= prototype:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prototype: pointer to struct vnode {struct= mutex {..} v_lock, unsigned int v_flag, unsigned int v_count, pointer to v= oid v_data, pointer to struct vfs {..} v_vfsp, pointer to struct stdata {..= } v_stream, enum vtype {VBAD(11), VPORT(10), VSOCK(9), VPROC(8), VDOOR(7), = VFIFO(6), VLNK(5), VCHR(4), VBLK(3), VDIR(2), VREG(1), VNON(0)} v_type, uns= igned long v_rdev, pointer to struct vfs {..} v_vfsmountedhere, pointer to = struct vnodeops {..} v_op, pointer to struct page {..} v_pages, unsigned lo= ng v_npages, unsigned long v_msnpages, pointer to struct page {..} v_scanfr= ont, pointer to struct page {..} v_scanback, pointer to struct filock {..} = v_filocks, pointer to struct shrlocklist {..} v_shrlocks, struct _krwlock {= ..} v_nbllock, struct _kcondvar {..} v_cv, pointer to void v_locality, poin= ter to struct fem_head {..} v_femhead, pointer to char v_path, unsigned int= v_rdcnt, unsigned int v_wrcnt, unsigned long long v_mmap_read, unsigned lo= ng long v_mmap_write, pointer to void v_mpssdata, long long v_scantime, uns= igned short v_mset, unsigned int v_msflags, pointer to struct vnode {..} v_= msnext, pointer to struct vnode {..} v_msprev, struct _krwlock {..} v_msloc= k} : "../sys/vnode.h", line 914
=C2=A0 =C2=A0 =C2=A0 =C2=A0 argument : pointer to struct vcache {struc= t vnode {..} v, struct afs_q {..} vlruq, pointer to struct vcache {..} next= free, pointer to struct vcache {..} hnext, struct afs_q {..} vhashq, struct= VenusFid {..} fid, struct mstat {..} m, struct afs_lock {..} lock, struct = afs_lock {..} vlock, struct _krwlock {..} rwlock, pointer to struct cred {.= .} credp, struct mutex {..} pvnLock, int parentVnode, int parentUnique, poi= nter to struct VenusFid {..} mvid, pointer to char linkData, struct afs_hyp= er_t {..} flushDV, struct afs_hyper_t {..} mapDV, long long truncPos, point= er to struct server {..} callback, unsigned int cbExpires, struct afs_q {..= } callsort, pointer to struct axscache {..} Access, int anyAccess, int last= _looker, int activeV, pointer to struct SimpleLocks {..} slocks, short open= s, short execsOrWriters, short flockCount, char mvstat, unsigned int states= , unsigned int vstates, pointer to struct dcache {..} dchint, int vc_error,= int xlatordv, pointer to struct cred {..} uncred, int asynchrony, short mu= ltiPage}
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1794: warning: old-style declaration or incorrect ty= pe for: gafs_mkdir
"/local/afs/builds/sunx86_510/openafs-1.4= .15/src/afs/SOLARIS/osi_vnodeops.c", line 1810: warning: old-style dec= laration or incorrect type for: gafs_rmdir
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1825: warning: old-style declaration or incorrect ty= pe for: gafs_readdir
"/local/afs/builds/sunx86_510/openafs-1= .4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1839: warning: old-style d= eclaration or incorrect type for: gafs_symlink
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1855: warning: old-style declaration or incorrect ty= pe for: gafs_readlink
"/local/afs/builds/sunx86_510/openafs-= 1.4.15/src/afs/SOLARIS/osi_vnodeops.c", line 1869: warning: old-style = declaration or incorrect type for: gafs_fsync
"/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_= vnodeops.c", line 1939: warning: old-style declaration or incorrect ty= pe for: gafs_fid
"/local/afs/builds/sunx86_510/openafs-1.4.1= 5/src/afs/SOLARIS/osi_vnodeops.c", line 1946: warning: implicit functi= on declaration: afs_fid
cc: acomp failed for /local/afs/builds/sunx86_510/openafs-1.4.15/src/a= fs/SOLARIS/osi_vnodeops.c
*** Error code 2
make: Fatal = error: Command failed for target `osi_vnodeops.o'
Current wor= king directory /local/afs/builds/sunx86_510/openafs-1.4.15/src/libafs/MODLO= AD32
*** Error code 1
make: Fatal error: Command failed for targe= t `solaris_compdirs'
Current working directory /local/afs/bui= lds/sunx86_510/openafs-1.4.15/src/libafs
*** Error code 1
make: Fatal error: Command failed for target `libafs'
Cu= rrent working directory /local/afs/builds/sunx86_510/openafs-1.4.15
*** Error code 1
make: Fatal error: Command failed for target = `build'
Current working directory /local/afs/builds/sunx86_510/openafs-1.4.15<= /div>
*** Error code 1
make: Fatal error: Command failed for = target `all'
FATAL: Looks like the compilation failed somewhe= re...

--

: Kendrick Hernandez
: UNIX Systems Administra= tor
: UNIX Systems and Infrastructure
: Division of Information Techn= ology
: University of Maryland, Baltimore County
--089e0168134402277404e2d357ba-- From adeason@sinenomine.net Wed Jul 31 20:26:36 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 31 Jul 2013 14:26:36 -0500 Subject: [OpenAFS] Re: Building 1.4.15 on Solaris 10 References: Message-ID: <20130731142636.027215a3.adeason@sinenomine.net> On Wed, 31 Jul 2013 15:00:32 -0400 Kendrick Hernandez wrote: > I'm building on Solaris 10 1/13 with Solaris Studio 12.3, and using the > following configure options: 1.4.15 included only security fixes, not platform support. The 1.4 tree hasn't improved platform support in quite some time, so the client kernel module won't build on newer Solaris. I can give you a patch for this specific failure if you really want, but if you want to build on newer Solaris, you should be building newer openafs (that is, 1.6). If you don't care about the client, you can build with something like 'make dest_nolibafs', and it would be more likely to work. [...] > and the build fails in src/afs/SOLARIS/osi_vnodeops.c[1]. I've also > tried building on an older release of Solaris 10 with a much older > version of Sun Studio and get similar results. Which older Solaris 10? Is it newer than the release of 1.4.14.1 (May 2011)? -- Andrew Deason adeason@sinenomine.net From adeason@sinenomine.net Wed Jul 31 20:32:46 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 31 Jul 2013 14:32:46 -0500 Subject: [OpenAFS] Re: Building 1.4.15 on Solaris 10 References: Message-ID: <20130731143246.35e1f976.adeason@sinenomine.net> On Wed, 31 Jul 2013 15:00:32 -0400 Kendrick Hernandez wrote: > "/local/afs/builds/sunx86_510/openafs-1.4.15/src/afs/SOLARIS/osi_vnodeops.c", > line 1784: prototype mismatch: 5 args passed, 6 expected And if you or anyone was curious or just wanted to know what the actual error is in all that mess, it's this. This is because vn_setpath gained an argument; we fixed this by switching to vn_renamepath by 1.6.2. (gerrit 8894, 8920) -- Andrew Deason adeason@sinenomine.net From kendrick.hernandez@umbc.edu Wed Jul 31 21:20:34 2013 From: kendrick.hernandez@umbc.edu (Kendrick Hernandez) Date: Wed, 31 Jul 2013 16:20:34 -0400 Subject: [OpenAFS] Re: Building 1.4.15 on Solaris 10 In-Reply-To: <20130731142636.027215a3.adeason@sinenomine.net> References: <20130731142636.027215a3.adeason@sinenomine.net> Message-ID: --089e0160c1ba3d197304e2d47554 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 31, 2013 at 3:26 PM, Andrew Deason wrote: > On Wed, 31 Jul 2013 15:00:32 -0400 > Kendrick Hernandez wrote: > > > I'm building on Solaris 10 1/13 with Solaris Studio 12.3, and using the > > following configure options: > > 1.4.15 included only security fixes, not platform support. The 1.4 tree > hasn't improved platform support in quite some time, so the client > kernel module won't build on newer Solaris. I can give you a patch for > this specific failure if you really want, but if you want to build on > newer Solaris, you should be building newer openafs (that is, 1.6). > Ah, I see. I'll be taking a look at building 1.6 next for our Solaris clients, but my current priority is to upgrade our DB servers which unfortunately, are still running 1.4. > > If you don't care about the client, you can build with something like > 'make dest_nolibafs', and it would be more likely to work. > Thanks, I'll take a look at this too. > > [...] > > and the build fails in src/afs/SOLARIS/osi_vnodeops.c[1]. I've also > > tried building on an older release of Solaris 10 with a much older > > version of Sun Studio and get similar results. > > Which older Solaris 10? Is it newer than the release of 1.4.14.1 (May > 2011)? > Yep, it's Solaris 10 8/11. I do have some x86 boxen with older installs (pre-"U10"); I've give one of those a shot. Thanks for the suggestions. k- -- : Kendrick Hernandez : UNIX Systems Administrator : UNIX Systems and Infrastructure : Division of Information Technology : University of Maryland, Baltimore County --089e0160c1ba3d197304e2d47554 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 31, 2013 at 3:26 PM, Andrew Deason &l= t;adeason@sinen= omine.net> wrote:
On Wed, 31 Jul 2013 15:00:= 32 -0400
Kendrick Hernandez <kendr= ick.hernandez@umbc.edu> wrote:

> I'm building on Solaris 10 1/13 with Solaris Studio 12.3, and usin= g the
> following configure options:

1.4.15 included only security fixes, not platform support. The 1.4 tr= ee
hasn't improved platform support in quite some time, so the client
kernel module won't build on newer Solaris. I can give you a patch for<= br> this specific failure if you really want, but if you want to build on
newer Solaris, you should be building newer openafs (that is, 1.6).

Ah, I see. I'll be taking a look at = building 1.6 next for our Solaris clients, but my current priority is to up= grade our DB servers which unfortunately, are still running 1.4.=C2=A0
=C2=A0

If you don't care about the client, you can build with something like 'make dest_nolibafs', and it would be more likely to work.

Thanks, I'll take a look at this too.=
=C2=A0

[...]
> and the build fails in src/afs/SOLARIS/osi_vnodeops.= c[1]. I've also
> tried building on an older release of Solaris 10 with a much older
> version of Sun Studio and get similar results.

Which older Solaris 10? Is it newer than the release of 1.4.14.1 (May=
2011)?

Yep, it's Solaris 10 8= /11. I do have some x86 boxen with older installs (pre-"U10"); I&= #39;ve give one of those a shot. Thanks for the suggestions.

k-
=C2=A0

=
--

: Kendrick Hernandez
: UNIX Systems Administrator: UNIX Systems and Infrastructure
: Division of Information Technology=
: University of Maryland, Baltimore County
--089e0160c1ba3d197304e2d47554-- From adeason@sinenomine.net Wed Jul 31 23:11:40 2013 From: adeason@sinenomine.net (Andrew Deason) Date: Wed, 31 Jul 2013 17:11:40 -0500 Subject: [OpenAFS] Re: Building 1.4.15 on Solaris 10 References: <20130731142636.027215a3.adeason@sinenomine.net> Message-ID: <20130731171140.f8adc9a3.adeason@sinenomine.net> On Wed, 31 Jul 2013 16:20:34 -0400 Kendrick Hernandez wrote: > > If you don't care about the client, you can build with something > > like 'make dest_nolibafs', and it would be more likely to work. > > Thanks, I'll take a look at this too. Actually, I realized it's probably 'better' to use ./configure --disable-kernel-module. I'm not sure if our make targets will change, but they are probably more likely to change than configure arguments. So, pretend I said that instead. -- Andrew Deason adeason@sinenomine.net