[OpenAFS] 1.3.70 and aklog
Jeffrey Altman
jaltman@columbia.edu
Tue, 17 Aug 2004 02:39:11 -0400
This is a cryptographically signed message in MIME format.
--------------ms010003010707070505070907
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Christopher D. Clausen wrote:
> Jeffrey Altman wrote:
> My servers are 1.2.11 and they have not been patched for MD5 support. I
> don't understand why I need this patch. I do not have an AFS service
> ticket in Active Directory. The only AFS service ticket is the one on
> the MIT KDC: afs/acm.uiuc.edu@ACM.UIUC.EDU
What enctype is this ticket?
>>> C:\> "C:\Program Files\OpenAFS\Client\Program\aklog.exe" -5 -d
>>> Authenticating to cell acm.uiuc.edu.
>>> Getting v5 tickets: afs/acm.uiuc.edu@ACM.UIUC.EDU
>>> About to resolve name cclausen@AD.UIUC.EDU to id
>>> Id 32766
>>> doing first-time registration of cclausen@ad.uiuc.edu at acm.uiuc.edu
>>> libprot: funny kvno (256) in ticket, proceeding
>>> aklog.exe: unable to create remote PTS user cclausen@ad.uiuc.edu in
>>> cell acm.uiuc.edu (status: 19270403).
>>> Set username to cclausen@ad.uiuc.edu
>>> Getting tokens.
>
>
> Why is it trying to create a remote user? I am not a remote user, I'm
> just using Kerberos trusts to obtain the ticket/token. Is this not
> possible or am I completely misunderstanding cross-realm trusts?
You are a remote user as long as you are obtaining the token via
a cross-realm trust. If you were to obtain a TGT directly from
ACM.UIUC.EDU you would be a local user.
>> names are local identifiers in tokens. they have no impact on how
>> the server treats the tickets. You are using Kerberos 5 cross realm
>> to obtains a ticket for afs/acm.uiuc.edu@ACM.UIUC.EDU. The Kerberos
>> 5 ticket is going to have the principal name cclausen@AD.UIUC.EDU
>> in it. This should be translated to cclausen@ad.uiuc.edu by the
>> AFS server.
>
>
> gssklog correctly gives me a token in the acm.uiuc.edu cell. (See below)
gssklog does not store the cross-realm trust into the token. It uses
the cross-realm trust to determine whether or not a local token blob
should be issued. The token which is generated by gssklogd is a
kaserver style token with local scope for the cell in which gssklogd
is configured.
>> Does "cclausen@ad.uiuc.edu" appear in your acl list
>> for the acm.uiuc.edu cell? If not, that is where your problem lies.
>
>
> That ACL does not exist.
> But I cannot add it either:
> H:\>fs sa . cclausen@ad.uiuc.edu rl
> fs:'.': code 0x19
You can't add an ACL if you do not have privileges.
> I thought that the user @ domain syntax was only used for foreign users.
> Shouldn't I be able to use my AD.UIUC.EDU tickets to get tokens in the
> ACM.UIUC.EDU realm via the Kerberos trust? Or am I again completely
> missing something obvious?
You have obtained a token for acm.uiuc.edu. The name of the principal
associated with the token is cclausen@ad.uiuc.edu. Therefore, you
are a foreign user.
>> What does "klist -e" report for the enctype of
>> "afs/acm.uiuc.edu@ACM.UICU.EDU"? You want it to read:
>>
>> Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32
>
>
> cclausen@KBS-CDC C:\>klist -ef
> Ticket cache: API:krb5cc.cclausen
> Default principal: cclausen@AD.UIUC.EDU
>
> Valid starting Expires Service principal
> 08/16/04 23:03:10 08/17/04 09:03:10 krbtgt/AD.UIUC.EDU@AD.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FRIA
> Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
> 08/16/04 23:03:10 08/17/04 09:03:10 host/kbs-cdc.ad.uiuc.edu@AD.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FRA
> Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
> 08/16/04 23:03:10 08/17/04 09:03:10 krbtgt/ACM.UIUC.EDU@AD.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FRA
> Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with
> RSA-MD5
> 08/17/04 00:17:44 08/17/04 09:03:10 afs/acm.uiuc.edu@ACM.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FRA
> Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with
> CRC-32
>
> It looks to be DES to me. The realm trust was used to obtain the
> afs/acm.uiuc.edu ticket.
This looks fine.
>>> C:\>tokens
>>> Tokens held by the Cache Manager:
>>> User cclausen@ad.uiuc.edu's tokens for afs@acm.uiuc.edu [Expires Aug
>>> 17 09:03]
>>> --End of list --
>>
>>
>> This looks correct.
>
>
> It doesn't look correct to me.
Because you don't understand cross realm.
> Things work the way I think they should when I use gssklog:
>
> C:\>unlog
> C:\>kdestroy
> C:\>ms2mit
> C:\>klist
> Ticket cache: API:krb5cc.cclausen
> Default principal: cclausen@AD.UIUC.EDU
>
> Valid starting Expires Service principal
> 08/17/04 00:47:52 08/17/04 09:03:10 krbtgt/AD.UIUC.EDU@AD.UIUC.EDU
> renew until 08/23/04 23:03:10
> 08/16/04 23:03:10 08/17/04 09:03:10 krbtgt/AD.UIUC.EDU@AD.UIUC.EDU
> renew until 08/23/04 23:03:10
> 08/17/04 00:31:12 08/17/04 09:03:10 ldap/ad-dc-p1.ad.uiuc.edu@AD.UIUC.EDU
> renew until 08/23/04 23:03:10
> 08/17/04 00:24:22 08/17/04 09:03:10 cifs/ad-dc-p1.ad.uiuc.edu@AD.UIUC.EDU
> renew until 08/23/04 23:03:10
> 08/17/04 00:24:22 08/17/04 09:03:10
> ldap/AD-DC-P2.ad.uiuc.edu/ad.uiuc.edu@AD.UIUC.EDU
> renew until 08/23/04 23:03:10
> 08/17/04 00:24:22 08/17/04 09:03:10 LDAP/AD-DC-P2.ad.uiuc.edu@AD.UIUC.EDU
> renew until 08/23/04 23:03:10
> 08/16/04 23:03:10 08/17/04 09:03:10 host/kbs-cdc.ad.uiuc.edu@AD.UIUC.EDU
> renew until 08/23/04 23:03:10
>
> C:\>gssklog
> C:\>tokens
>
> Tokens held by the Cache Manager:
>
> User cclausen's tokens for afs@acm.uiuc.edu [Expires Aug 17 09:03]
> --End of list --
>
> C:\>klist -ef
> Ticket cache: API:krb5cc.cclausen
> Default principal: cclausen@AD.UIUC.EDU
>
> Valid starting Expires Service principal
> 08/17/04 00:47:52 08/17/04 09:03:10 krbtgt/AD.UIUC.EDU@AD.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FfRA
> Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
> 08/16/04 23:03:10 08/17/04 09:03:10 krbtgt/AD.UIUC.EDU@AD.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FRIA
> Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
> 08/16/04 23:03:10 08/17/04 09:03:10 host/kbs-cdc.ad.uiuc.edu@AD.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FRA
> Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
> 08/17/04 00:47:52 08/17/04 09:03:10 krbtgt/ACM.UIUC.EDU@AD.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FfRA
> Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with
> RSA-MD5
> 08/17/04 00:48:17 08/17/04 09:03:10
> gssklog/mintaka.acm.uiuc.edu@ACM.UIUC.EDU
> renew until 08/23/04 23:03:10, Flags: FfRA
> Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES
> cbc mode with HMAC/sha1
>
> I have tokens for cclausen and I can correctly access my files.
yes. but gssklogd exists solely within the realm ACM.UIUC.EDU and it
has been configured to use the first component of the principal name
as the AFS username. The token which is generated contains the user
principal name "cclausen@ACM.UIUC.EDU"; it does not contain the
cross-realm principal name "cclausen@AD.UIUC.EDU". gssklogd throws
away the foreign realm and substitutes the local realm.
> Are aklog and gssklog acting differently wrt to the cross realm trust? I
> mean, they both do the same thing, set AFS tokens. Why would one set
> tokens for cclausen and one for cclausen@ad.uiuc.edu.
See above.
Are you able to access your home directory when you destroy your tokens
with unlog.exe?
I'm concerned that you unable to access the volume at all.
Jeffrey Altman
--------------ms010003010707070505070907
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
DxcNMDQwODE3MDYzOTExWjAjBgkqhkiG9w0BCQQxFgQURBvsdwbNn4vSWn0HdB1r5MrjfuMw
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B
CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB
AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAjMaXqWgfMOZfhQKzVaWL2oVEgpE7IQ1XOz7pmSji
NL3aLLcpq27DfS0IxTAieLGI8gjXLeIk9qYn2rmPK1yaM4bpmVSKMFprWaqtM3cQMnQlvIGw
ugqDi0zu533PIopW0fBDsatNoq3WMU59/QFTnCSwlsFK0dvK6beGxG4kvrIeR9rN/RkAno64
MOU4aDZ7oXNKeS/rSud77lZ/BIXD31CNj/4Mm1Mfb9FX59zJe6w7q2dKQXr7yYIihcuyUx7S
KKZ2b011r/84H6+6AToDPJusVdMv2Y9OZ/Y07ICqi1dUSflr1oeRQkLi1CjnPPpV7EbLW1ls
U8sebxPGS6tUoAAAAAAAAA==
--------------ms010003010707070505070907--