[OpenAFS] 1.3.70 and aklog

[Jeffrey Altman]

This is a cryptographically signed message in MIME format.

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

Christopher D. Clausen wrote:
> Couldn't I just create a afs/acm.uiuc.edu@AD.UIUC.EDU AFS service 
> principal using ktpass.exe, add it my AFS servers and use that to 
> authenticate from the AD.UIUC.EDU realm / domain instead of trying to 
> setup this foreign user stuff?
> 
> So I would need to set up:
> 1) pts creategroup system:authuser@ad.uiuc.edu system:administrators 
> -cell acm.uiuc.edu
> 2) create a pts user cclausen@ad.uiuc.edu (is this needed)?
> 3) add cclausen@ad.uiuc.edu to ACLs.
> 4) try aklog (which works once the above are done.)

It should not matter whether the token for acm.uiuc.edu is obtained
via a service ticket for afs/acm.uiuc.edu@AD.UIUC.EDU or via a service
ticket for afs/acm.uiuc.edu@ACM.UIUC.EDU.  In both cases, the client
principal name is going to be cclausen@AD.UIUC.EDU.

Where you will find yourself having problems when you do this is that
the Windows 2003 KDC is going to issue tickets which are both very
large in size and which use DES-CBC-MD5 as the enctype.  This will
require that your servers are running OpenAFS 1.3.65 or higher.


> Will this work if the Kerberos trust is only one way?
> ACM.UIUC.EDU trusts AD.UIUC.EDU
> AD.UIUC.EDU DOES NOT trust ACM.UIUC.EDU

Yes.  A one way trust from the AD to ACM is all that is required.
You would only need the AD to trust ACM if you wanted to allow
ACM principals to be used to login into Windows or access Windows
based services.

> Also, the ACM.UIUC.EDU realm is running MIT krb5-1.2.4-5 (Debian woody). 

You want to upgrade this so that you can establish your cross realm
trusts using RC4-HMAC instead of DES-CBC-CRC or DES-CBC-MD5.  Once
you are running MIT 1.3.4 and 2003 SP1 there should not be a reason
to use single DES except for AFS.  Hopefully that will be changing
real soon now too.

> Would the KDCs need to be upgraded for this cross-realm stuff to work?

No.  You already have cross realm working.  If you didn't, you would not
have been able to obtain the afs/acm.uiuc.edu@ACM.UIUC.EDU service
ticket using the cclausen@AD.UIUC.EDU client principal.

> I assume that I still need to have newer servers, or otherwise patch 
> them to support the MD5 enctype:
> C:\>vos examine user.cclausen
> vsu_ClientInit: funny kvno (256) in ticket, proceeding
> rxk: Ticket length too long or too short

Now this is interesting.  I can not think of a reason why you should
be seeing this error.

> The above is the result of me acutally having a cclausen@ad.uiuc.edu 
> token and not having upgraded AFS servers, correct?  As it works just 
> fine if I unlog.

The token you have is a Kerberos 5 ticket issued by an MIT 1.2.4 KDC.
I do not remember whether or not the Microsoft PAC data is going to
be propagated to the service ticket or not.  It sounds like it is
being propagated and the server cannot handle the ticket being larger
then 388 bytes.

If this is the case then the servers will need to be updated to support
the larger ticket sizes.  The new maximum is at least 12,000 bytes.

> Indeed.  I'm trying to fix that, which is why I am asking questions.

and I appreciate that.  therefore I am answering them.

> I can access it just fine either when I kinit to cclausen@ACM.UIUC.EDU 
> or use gssklog to obtain tokens.

Both of these methods will produce small tokens.

> I do however seem to have problems accessing anything in AFS when I have 
> cclausen@ad.uiuc.edu tokens (after setting up some of the foreign user 
> stuff listed above.)  If I unlog, things go back to normal.  (I assume 
> this is either b/c of the older AFS servers or some configuration option 
> I've overlooked.)

Its most likely because of the large ticket sizes.  Unfortunately,
klist does not have an option to report the ticket size.  That would
be useful in this case.

> Please don't reply to the list AND to me.  I am on the list, even if I 
> don't understand everything.

I would prefer if the list was configured to force all replies to the 
list.  Unfortunately, since that is not the case the default means of
replying to the list is to "Reply-all".  This has the side effect that
unless someone manually edits the addressee list two copies are sent
to the original author(s).  I receive dozens of duplicate e-mails a
day from the various lists I post to.  Deleting an extra e-mail really
isn't all that hard.

What I find annoying are the folks who decide that sending private
e-mail without copying the list is a better means of getting me to
answer their questions; it is not.

Jeffrey Altman


--------------ms030300050002040202030504
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
DxcNMDQwODE3MDkyNzMyWjAjBgkqhkiG9w0BCQQxFgQUEOoGTo6aZJXDfP7dpegwRoTQEb4w
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B
CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB
AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAIX8GvFbTPQzd3iHhlSRfel+E5oLNNczEQG+gczye
f2xlQdgqvgMvGtPnpseQC7tKpQfrj4Vdw7hcXDN4xd6BXSe2EwiVc/fA9rzls8t0VjA+Elgi
2ZaJcM1XWWXyPstXO8KQASZYXdy7jAk9OiGHMRVJwkGCLyD/XbrxMteABMYhFe0sRcxDhlY2
bITSB3RvvrXtXQAi05dAVYa/3tiG6KZyEPbNtKxXyoMWb0T1fyGx+R8MS+uWpYPCPRDAtYMV
tw/UrjKG6zGsJQRPzc2pKPcE1KJ/oj0O/8DnqS1aAXlFIeK0UJ5FC47j+cycywmLVb1StKxH
6Vd+VuDvrm7RmwAAAAAAAA==
--------------ms030300050002040202030504--