[OpenAFS-devel] Anyone supporting multiple realms in a "all realms are equal" type of setup?

[Jeffrey Altman]

This is a cryptographically signed message in MIME format.

--------------ms040008050002050803070209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Douglas E. Engert wrote:

> But I think part of this is not the user's problem but KfW/OpenAFS's
> problem. The assumption appears to be "mappings? we do't need no
> stinking mappings" so bypass krb524 because all it was doing was
> converting a k5 ticket to a token.  That is a good goal but I think
> you jumped ahead.

Some history here.  krb524 was only supported in KFW 2.6 through
2.6.2(?).  It was only supported in OpenAFS in 1.3.60 through 1.3.64.
The implementations used krb524 to obtain a Kerberos 4 TGT from a
Kerberos 5 TGT and then use Kerberos 4 to obtain an afs service ticket.
The time period of this support was approximately six months.
I removed this support because it was causing more headaches then it was
worth.

We discovered that krb524 could not be used without resulting in large
numbers of complaints to help desks from home users when krb524d could
not be reached.  Sometimes it could not be reached because the Kerberos
realm does not support it.  Other times it could not be reached because
several of the large ISPs blocked port 4444/udp due to a worm that
attacked Windows systems.

As soon as it became clear that Kerberos 5 tickets could be used
directly by all current versions of OpenAFS servers and that all OpenAFS
servers had to be upgraded to at least that version due to fatal bugs I
implemented support for Kerberos 5 tickets as tokens in OpenAFS and KFW.
If Kerberos 5 tickets could not be used, then users should either not
install KFW or should disable the use of KFW.  Organizations would need
to provide their own tools for obtaining afs tokens.

Previous to the brief attempt to support krb524, OpenAFS and KFW only
supported the use of Kerberos 4 service tickets which were obtained by
directly obtaining a Kerberos 4 TGT from the password.  There was no
mapping being done by krb524d for afs whenever an afs service ticket was
obtained using Kerberos 4 instead of Kerberos 5.


> Many sites may not have planed ahead to have a K5 realm match the
> AFS cell, with a one-to-one user mapping. Some may have only
> use the kaserver and now have AD and had no coordination of
> userids across both, now that they need to use both together
> and need some mappings.

I agree.  Most sites do not plan ahead and did not think through the
potential consequences of their actions.  All they did was follow the
directions that were recommended in the afs-krb5 migration kit.  Since 
the afs krb.conf file was not mentioned in that document, krb524d based 
mapping was implemented instead when the realm and cell names failed to 
match.

jhutz's proposal solves this problem in a general way.

> As you pointed out it is complicated by the fact that the same
> principal name of afs/cell is used with and without the mapping.
> And by the fact that the client can not determine if no mapping is
> needed, since the KDC can issue a ticket for afs/cell@realm and
> the client can not determine if this needs be run by krb524d.

Since the same principal name is used for Kerberos 4 to afs
as for Kerberos 5 to afs, I believe it is the need to perform
a mapping which is what needs to be detected.

> (BTW our ak5log and krb524d mods used afsx/cell@realm to map to
> afs/cell@cell, The DCE server never had a principal for
> afs/cell@realm The DCE AFS/DFS translator reserver the afs/cell@realm
> for itself with DFS.)

But did you offer afs/cell@realm as well?  If so, you have defeated
the purpose.

> Maybe what should have happened was that the AFS servers
> should have been modified to use a different name for direct access,
> like afsk5/cell@realm ticket, but expected afs/cell@realm to be mapped
> by krb524d. Then the client could try for one or the other and know
> what to do.

maybe but since krb524d was never shipped as part of OpenAFS or
Transarc AFS I don't think that it should be considered a standard
feature of AFS.  It is also true that all implementations of krb524d
do not perform this mapping.  So it is not possible to even say that
if krb524d is available it should be used.

The problem is not the use of krb524d to convert a Kerberos
ticket from Kerberos 5 to Kerberos 4.  It is the hacks that were added
to transform the principal name which is causing the problem.
As such it is this special mapping that must be detected not the
potential to use krb524d.


Jeffrey Altman



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC
AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4
WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT
SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l
ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2
+nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp
z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9
WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02
lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r
1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s
dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0
eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe
L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M
CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1
MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx
HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A
Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M
3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs
Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A
B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD
GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf
u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq
YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH
lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b
rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU
njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT
ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB
MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx
NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK
mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/
cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8
YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4
oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j
cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy
LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4
Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB
MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw
CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDQwOTIyMjEwMjE1WjAjBgkqhkiG9w0BCQQxFgQUJtBtaDdHXhMc9rPi0S4wCUmSpr0w
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B
CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB
AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAziS+tCJoweiBxfYAxnewxdOO0ITkz8kKehHstaYQ
2UTOKa6okHWc1MDcnZl1i8is5wT0qEJoXEfJWLuhcITcMXvWLTAdx85q9zapo7gm/SW9npSb
efJnoy4vuR332asAs+ByYfnizz3Y169wY5z0SR6CVLjoRmTLOAAvGvZVEVrs71mQNichXCFV
4WC2WY5HxgXfpv1co4s0QkDsGeLeW8z9Hu1IMB0F2GL/5kd6Xk9Rs8pTKfy/oSke1+L7r/A7
iEmsk7Q4ZevQghGWjA409cP8haSVDUKJzByu+wcIQkLYpPxKAbVge3rP/qbhrX0r5EW9X124
olg7eGs9B317CQAAAAAAAA==
--------------ms040008050002050803070209--