[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad
error=19270407, arghhhh
Jeffrey Altman
jaltman@secure-endpoints.com
Fri, 05 Jan 2007 10:51:44 -0500
This is a cryptographically signed message in MIME format.
--------------ms090305010002080902090908
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
John:
unless you plan to get rid of the MIT realm and move all of your
principals to active directory, you are going to have to rename
one of the Kerberos realms.
In my family there are two first cousins named "Jeffrey" who were
born two weeks apart. Our Mothers both loved the name and refused
to let the other use it, and so, we both got the name and our parents
did not speak to each other for months. We lived blocks away from
each other and went to the same schools and of course once our parents
got over the theft of their child's name, they started to baby sit
for each other. You can imagine what life was like. Any one parent
would call out "Jeffrey" and never know which kid they were going to
get. In the end, there was mutual agreement that when both of the
Jeffreys were present that we would be called by our middle names.
Hence, I became Eric and he became Alan. (This worked just fine
except when our second cousin Alan came to visit but that is a different
story.)
The point is that your clients and services are always going to be
confused if you have two realms with the same name and no other
mechanism by which they can be identified. Now, because of the desire
to have peer-to-peer realms, there is some discussion about developing
a public key identifier that would turn the realm name into a display
name. However, its not even specified yet let alone a standard and you
wouldn't see it deployed in a Microsoft OS for ten years so there is
little point in considering it.
Microsoft knows that many Windows 2000 domains were installed using
the same name as MIT Kerberos realms but at the time Windows domains
really did not handle having a name different from the DNS domain.
With the release of Windows 2003, Microsoft fixed the issues with Domain
names vs DNS names and also provided a tool that can be used to rename
the Windows domain. The procedure is painful but it is better than
running two realms with the same name.
Once the Windows domain has been renamed you can:
* Create a Windows domain account called "AFS.CS.UNC.EDU"
* Use setspn to assign a service principal name to the account
setspn -A afs/cs.unc.edu AFS.CS.UNC.EDU
* Use a working (non-2003 SP1) version of ktpass to export the key
The 2003 SP1 Support Tools version is 5.2.3790.1830. Do not use it.
The Vista version has not been released yet. It is supposed to be
published under KB926036. I suspect we will see it on Jan 30.
ktpass -out <keytab> -princ afs/cs.unc.edu@WIN.CS.UNC.EDU \
-crypto DES-CBC-CRC +rndPass -DesOnly
The vista version of ktpass will allow you to:
-DumpSalt to have it display the salt that was used
-RawSalt <salt> to specify a specific salt
-SetUPN to set the user principal name in addition to the Service
Principal Name
-SetPass to set a user account password
as well as supporting the new AES crypto types.
* copy the keytab to your AFS servers and import the key with asetkey
The reason that ktutil could be used to generate the keytab was that
the password for the service principal was known. Therefore, ktutil
didn't have to query the Kerberos database.
Jeffrey Altman
John W. Sopko Jr. wrote:
> I have been following this thread. I also want to test our Windows AD for
> authentication. I have tested a krb5 server on linux and am familiar with
> generating a keytab/KeyFile for the afs/cell.name service principal using
> kadmin and asetkey. I got a bit confused with your Windows AD procedure.
> Could you please summarize and post the steps you used including command
> line options.
>
> For example, one thread says you ran ktutil on linux not Windows but as
> far as I know ktutil on linux is used to manipulate keytabs files not
> export keys from the krb5 principal database. Looks like you basically
> did this:
>
> - Create Windows AD user afs/cell.name user with "DES" key only
> - Used Microsoft 2003 SP1 ktpass.exe to export the afs/cell.name to a
> keytab
> - Used OpenAFS asetkey to import keytab to /usr/afs/etc/KeyFile
> - This did not work
> - You then used ktutil.exe on Windows to to export the afs/cell.name to
> a keytab
> - Used OpenAFS asetkey to import keytab to /usr/afs/etc/KeyFile
> - Success
> - Appears to be some issue with Microsoft 2003 SP1 ktpass.exe
>
> Which ktutil command did you run, on Windows or L/Uinux?
> Where did you get the ktutil command for Windows?
> Did you upgrade to a Microsoft ktpass.exe that worked?
>
> Appreciate the info and the time you saved us!
>
> I would prefer to run the MIT K5 server on linux for OpenAFS but I bet
> others have the same issue I have. Our Windows machines run in the same
> DNS domain as our L/Unix machines. The Windows folks have been running
> AD under our DNS/cell.name/realm name for sometime. Our afs cellname
> is the same as our DNS name. I have tested using a different KRB realm
> name and using the "domain_realm" mapping, it gets confusing to have 2
> kerberos realm names in the same DNS domain. It does not make sense to
> run 2 different krb5 servers for authentication.
>
>
>> Date: Wed, 3 Jan 2007 16:40:33 +0100
>> From: =?iso-8859-1?Q?L=F6nroth_Erik?= <erik.lonroth@scania.com>
>> To: =?iso-8859-1?Q?L=F6nroth_Erik?= <erik.lonroth@scania.com>,
>> "Jeffrey Altman" <jaltman@secure-endpoints.com>
>> Cc: <openafs-info@openafs.org>
>> Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS -
>> rxkad error=19270407, arghhhh
>>
>> This is a multi-part message in MIME format.
>>
>> ------_=_NextPart_001_01C72F4D.B4C63582
>> Content-Type: text/plain;
>> charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>>
>> Correction on that:
>>
>> The "ktutil" was run on the linux host! (not windows)
>>
>> But still... the ktpass.exe gives me bogus keyfiles.
>>
>> /Erik
>>
>>
>> -----Original Message-----
>> From: openafs-info-admin@openafs.org on behalf of L=F6nroth Erik
>> Sent: Wed 1/3/2007 4:34 PM
>> To: Jeffrey Altman
>> Cc: openafs-info@openafs.org
>> Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - =
>> rxkad error=3D19270407, arghhhh
>> =20
>> OK, I believe have resolved the problem now after 5 whole days of trial =
>> and error.
>>
>> It turns out that using the "KTPASS" native from Active Directory =
>> generates keys that is not liked by AFS.
>>
>> I instead used ktutil.exe (for windows) to generate my key that I then =
>> imported as usual into AFS. =20
>>
>> On Microsoft AD side:
>>
>>> ktutil
>> ktutil: addent -password -p afs/sss.se.scania.com@LAB.SCANIA.COM -k 9
>> -e =
>> des-cbc-crc
>> ktutil: wkt ./keytab.file
>> ktutil: quit=20
>>
>> This file is then copied to linux and imported exactly as I would =
>> normally:
>>
>> asetkey add 9 keytab.file afs/sss.se.scania.com
>>
>> Now - everything works=20
>>
>> kinit sssler
>> aklog
>> touch /afs/sss.se.scania.com/home/sssler/somefile
>> ls /afs/sss.se.scania.com/home/sssler/somefile
>> /afs/sss.se.scania.com/home/sssler/somefile
>>
>> Success!
>>
>> I verified this by behaviour - AGAIN - by using the "KTPASS.EXE" =
>> (without changing anything else) and importing the key with "asetkey"
>> as =
>> normal.
>>
>> C:\ktpass -out afs-keytab-md5-verify -princ =
>> afs/sss.se.scania.com@LAB.SCANIA.COM -mapuser afs -crypto DES-CBC-CRC =
>> -pass *
>> Targeting domain controller: SeSoCoLab11.scania.se
>> Successfully mapped afs/sss.se.scania.com to afs.
>> Type the password for afs/sss.se.scania.com:
>> Type the password again to confirm:
>> WARNING: pType and account type do not match. This might cause =
>> problems.
>> Key created.
>> Output keytab to afs-keytab-md5-verify:
>> Keytab version: 0x502
>> keysize 63 afs/sss.se.scania.com@LAB.SCANIA.COM ptype 0 =
>> (KRB5_NT_UNKNOWN) vno 9
>> etype 0x1 (DES-CBC-CRC) keylength 8 (0xbff2e56b29943d3e)
>>
>> (Again publishing the key to the whole world ;-)=20
>>
>> ... and - using this key in AFS - I get the same error again : rxkad =
>> error=3D19270407
>>
>> I swapped back again to the key generated by ktutil.exe - and it works =
>> again.
>>
>> It seems that using the KTPASS.EXE generates bogus keys for me!
>>
>> I have not read this anywhere and I have read pretty much everyting,
>> did =
>> I miss something critical here or is this a bug/feature?
>>
>> /Erik
>>
>>
>
--------------ms090305010002080902090908
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
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX
DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o
fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U
8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0
ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD
A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo
pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v
L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0
0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL
zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4
TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV
GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07
E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX
lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB
gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax
myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc
6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAxMDUxNTUxNDRaMCMGCSqGSIb3DQEJBDEWBBSuoiTG
dO/A+eH4QTZhxiCTaSRMCzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ
KoZIhvcNAQEBBQAEggEATwx6Yr2EMshcVDrnA0MdtnJdw/AA7cgb8k0J4N/MR9m8rsWOEJKf
6JpFHzX34tYpJNt7VlmFzczakn5IXnXv4r7RjbrxPV5iwoegpfmKvM2p1d5+JlBz9LPmdD9c
mJAwA4e6111K5wqoFttCRDf6gumadjci9w3cN4MESJuT0IKuNWtAhxS9u43AI9gnBdEvRcDb
q8pJokEHm92pudmosLYA68JBaoGG9Fj8Ya5i+2l/q5NTEiOlRowOP01Q27eNcxKCe70C9QEF
LOew+m5BfHzwzoMwCX3YNYsCBo6BH6aVjsXoT4eWaGtBIzJjCb29EPFLA3tso8IEEh1CmxXI
eQAAAAAAAA==
--------------ms090305010002080902090908--