[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Lönroth Erik
erik.lonroth@scania.com
Mon, 8 Jan 2007 09:45:47 +0100
This is a multi-part message in MIME format.
------_=_NextPart_001_01C73301.645A4E28
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
" I am trying to piece things together like Eric.
What we need is clear steps on how to create the Windows
AD afs/cell.name user and the proper way to export the
afs/cell.name key. Would be nice to have this for both
W2K and W2003. The linux "asetkey" man page is real clear
on how to do this in linux, (thanks Russ). "
What we do now is that we have replaced the ktpass from WIN2003, SP1 =
with a working one.
We had big problems with a version that generated unusable tickets that =
gave us the annoying: =20
rxkad error=3D19270407
We basically follwed the procedure:
* Create AFS user in AD and set correct options. "Des only", "Delegate =
Service", "Password dont expires", "dont change at first login".
* Export keytab with "ktpass.exe", just make sure its not the version =
windows 2003,SP1.
* Import it to your AFS:cell(s) with "asetkey". (You might need to =
restart the openAFS server, I'm not sure.)
The thing that made this difficult for us was to find out about the =
WIN2003,SP1 bugg.
/Erik
-----Original Message-----
From: John W. Sopko Jr. [mailto:sopko@cs.unc.edu]
Sent: Fri 1/5/2007 5:39 PM
To: jaltman@secure-endpoints.com
Cc: openafs; L=F6nroth Erik
Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - =
rxkad error=3D19270407, arghhhh
=20
Jeffrey Altman wrote:
> John:
>=20
> 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.
I should have been more clear. I am only running a TEST
krb5 1.4.4 server under linux. I am still running kaserver.
Like lots of folks looking to migrate to K5, have been for
years.
Our test linux/krb5 server has a different kerberos realm name
then the Windows realm name. I am not attempting/planning to run
2 kdc's with the same REALM name. We setup different DNS records
to find the kdc's etc. I got k5 authentication working fine.
Had problems with the transition kit. I think mostly because
the kerberos realm name is different from the afs cell name.
(no need to respond to this issue).
I would prefer to keep the dns/realm/afs.cell names all the same.
The only way to do this is to run one kerberos 5 server. The
linux krb5_pam module seems to work fine for authenticating
to k5 and getting afs tokens. Aklog works great also. Have tested
linux krb5_pam and apache authentication to Windows AD.
We run 3 active directory servers, currently Windows 2000
to be upgraded to 2003 very soon. We have a Windows group that
manages these machines.
I am trying to piece things together like Eric.
What we need is clear steps on how to create the Windows
AD afs/cell.name user and the proper way to export the
afs/cell.name key. Would be nice to have this for both
W2K and W2003. The linux "asetkey" man page is real clear
on how to do this in linux, (thanks Russ).
I plan on trying to attend the AFS & Kerberos
Best Practices Workshop 2007. I am sure over the next few
months things will get more clear on this.
>=20
> 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.)
>=20
> 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.
>=20
> 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.
>=20
> Once the Windows domain has been renamed you can:
>=20
> * 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.
>=20
> ktpass -out <keytab> -princ afs/cs.unc.edu@WIN.CS.UNC.EDU \
> -crypto DES-CBC-CRC +rndPass -DesOnly
>=20
> 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
>=20
> 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.
>=20
> Jeffrey Altman
>=20
>=20
>=20
> 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: =3D?iso-8859-1?Q?L=3DF6nroth_Erik?=3D =
<erik.lonroth@scania.com>
>>> To: =3D?iso-8859-1?Q?L=3DF6nroth_Erik?=3D <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=3D19270407, arghhhh
>>>
>>> This is a multi-part message in MIME format.
>>>
>>> ------_=3D_NextPart_001_01C72F4D.B4C63582
>>> Content-Type: text/plain;
>>> charset=3D"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=3DF6nroth 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 - =
=3D
>>> rxkad error=3D3D19270407, arghhhh
>>> =3D20
>>> OK, I believe have resolved the problem now after 5 whole days of =
trial =3D
>>> and error.
>>>
>>> It turns out that using the "KTPASS" native from Active Directory =
=3D
>>> generates keys that is not liked by AFS.
>>>
>>> I instead used ktutil.exe (for windows) to generate my key that I =
then =3D
>>> imported as usual into AFS. =3D20
>>>
>>> On Microsoft AD side:
>>>
>>>> ktutil
>>> ktutil: addent -password -p afs/sss.se.scania.com@LAB.SCANIA.COM -k =
9
>>> -e =3D
>>> des-cbc-crc
>>> ktutil: wkt ./keytab.file
>>> ktutil: quit=3D20
>>>
>>> This file is then copied to linux and imported exactly as I would =
=3D
>>> normally:
>>>
>>> asetkey add 9 keytab.file afs/sss.se.scania.com
>>>
>>> Now - everything works=3D20
>>>
>>> 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" =3D
>>> (without changing anything else) and importing the key with =
"asetkey"
>>> as =3D
>>> normal.
>>>
>>> C:\ktpass -out afs-keytab-md5-verify -princ =3D
>>> afs/sss.se.scania.com@LAB.SCANIA.COM -mapuser afs -crypto =
DES-CBC-CRC =3D
>>> -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 =3D
>>> 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 =3D
>>> (KRB5_NT_UNKNOWN) vno 9
>>> etype 0x1 (DES-CBC-CRC) keylength 8 (0xbff2e56b29943d3e)
>>>
>>> (Again publishing the key to the whole world ;-)=3D20
>>>
>>> ... and - using this key in AFS - I get the same error again : rxkad =
=3D
>>> error=3D3D19270407
>>>
>>> I swapped back again to the key generated by ktutil.exe - and it =
works =3D
>>> 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 =3D
>>> I miss something critical here or is this a bug/feature?
>>>
>>> /Erik
>>>
>>>
--=20
John W. Sopko Jr. University of North Carolina
email: sopko AT cs.unc.edu Computer Science Dept., CB 3175
Phone: 919-962-1844 Sitterson Hall; Room 044
Fax: 919-962-1799 Chapel Hill, NC 27599-3175
------_=_NextPart_001_01C73301.645A4E28
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad =
error=3D19270407, arghhhh</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=3D2>" I am trying to piece things together like =
Eric.<BR>
What we need is clear steps on how to create the Windows<BR>
AD afs/cell.name user and the proper way to export the<BR>
afs/cell.name key. Would be nice to have this for both<BR>
W2K and W2003. The linux "asetkey" man page is real =
clear<BR>
on how to do this in linux, (thanks Russ). "<BR>
<BR>
What we do now is that we have replaced the ktpass from WIN2003, SP1 =
with a working one.<BR>
We had big problems with a version that generated unusable tickets that =
gave us the annoying: <BR>
<BR>
rxkad error=3D19270407<BR>
<BR>
We basically follwed the procedure:<BR>
<BR>
* Create AFS user in AD and set correct options. "Des only", =
"Delegate Service", "Password dont expires", =
"dont change at first login".<BR>
<BR>
* Export keytab with "ktpass.exe", just make sure its not the =
version windows 2003,SP1.<BR>
<BR>
* Import it to your AFS:cell(s) with "asetkey". (You might =
need to restart the openAFS server, I'm not sure.)<BR>
<BR>
The thing that made this difficult for us was to find out about the =
WIN2003,SP1 bugg.<BR>
<BR>
/Erik<BR>
<BR>
-----Original Message-----<BR>
From: John W. Sopko Jr. [<A =
HREF=3D"mailto:sopko@cs.unc.edu">mailto:sopko@cs.unc.edu</A>]<BR>
Sent: Fri 1/5/2007 5:39 PM<BR>
To: jaltman@secure-endpoints.com<BR>
Cc: openafs; L=F6nroth Erik<BR>
Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - =
rxkad error=3D19270407, arghhhh<BR>
<BR>
<BR>
<BR>
Jeffrey Altman wrote:<BR>
> John:<BR>
><BR>
> unless you plan to get rid of the MIT realm and move all of =
your<BR>
> principals to active directory, you are going to have to rename<BR>
> one of the Kerberos realms.<BR>
<BR>
I should have been more clear. I am only running a TEST<BR>
krb5 1.4.4 server under linux. I am still running kaserver.<BR>
Like lots of folks looking to migrate to K5, have been for<BR>
years.<BR>
<BR>
Our test linux/krb5 server has a different kerberos realm name<BR>
then the Windows realm name. I am not attempting/planning to run<BR>
2 kdc's with the same REALM name. We setup different DNS records<BR>
to find the kdc's etc. I got k5 authentication working fine.<BR>
Had problems with the transition kit. I think mostly because<BR>
the kerberos realm name is different from the afs cell name.<BR>
(no need to respond to this issue).<BR>
<BR>
I would prefer to keep the dns/realm/afs.cell names all the same.<BR>
The only way to do this is to run one kerberos 5 server. The<BR>
linux krb5_pam module seems to work fine for authenticating<BR>
to k5 and getting afs tokens. Aklog works great also. Have tested<BR>
linux krb5_pam and apache authentication to Windows AD.<BR>
<BR>
We run 3 active directory servers, currently Windows 2000<BR>
to be upgraded to 2003 very soon. We have a Windows group that<BR>
manages these machines.<BR>
<BR>
I am trying to piece things together like Eric.<BR>
What we need is clear steps on how to create the Windows<BR>
AD afs/cell.name user and the proper way to export the<BR>
afs/cell.name key. Would be nice to have this for both<BR>
W2K and W2003. The linux "asetkey" man page is real =
clear<BR>
on how to do this in linux, (thanks Russ).<BR>
<BR>
I plan on trying to attend the AFS & Kerberos<BR>
Best Practices Workshop 2007. I am sure over the next few<BR>
months things will get more clear on this.<BR>
<BR>
<BR>
><BR>
> In my family there are two first cousins named "Jeffrey" =
who were<BR>
> born two weeks apart. Our Mothers both loved the name and =
refused<BR>
> to let the other use it, and so, we both got the name and our =
parents<BR>
> did not speak to each other for months. We lived blocks away =
from<BR>
> each other and went to the same schools and of course once our =
parents<BR>
> got over the theft of their child's name, they started to baby =
sit<BR>
> for each other. You can imagine what life was like. Any =
one parent<BR>
> would call out "Jeffrey" and never know which kid they =
were going to<BR>
> get. In the end, there was mutual agreement that when both of =
the<BR>
> Jeffreys were present that we would be called by our middle =
names.<BR>
> Hence, I became Eric and he became Alan. (This worked just =
fine<BR>
> except when our second cousin Alan came to visit but that is a =
different<BR>
> story.)<BR>
><BR>
> The point is that your clients and services are always going to =
be<BR>
> confused if you have two realms with the same name and no other<BR>
> mechanism by which they can be identified. Now, because of =
the desire<BR>
> to have peer-to-peer realms, there is some discussion about =
developing<BR>
> a public key identifier that would turn the realm name into a =
display<BR>
> name. However, its not even specified yet let alone a =
standard and you<BR>
> wouldn't see it deployed in a Microsoft OS for ten years so there =
is<BR>
> little point in considering it.<BR>
><BR>
> Microsoft knows that many Windows 2000 domains were installed =
using<BR>
> the same name as MIT Kerberos realms but at the time Windows =
domains<BR>
> really did not handle having a name different from the DNS =
domain.<BR>
> With the release of Windows 2003, Microsoft fixed the issues with =
Domain<BR>
> names vs DNS names and also provided a tool that can be used to =
rename<BR>
> the Windows domain. The procedure is painful but it is better =
than<BR>
> running two realms with the same name.<BR>
><BR>
> Once the Windows domain has been renamed you can:<BR>
><BR>
> * Create a Windows domain account called =
"AFS.CS.UNC.EDU"<BR>
> * Use setspn to assign a service principal name to the =
account<BR>
> setspn -A afs/cs.unc.edu =
AFS.CS.UNC.EDU<BR>
> * Use a working (non-2003 SP1) version of ktpass to export =
the key<BR>
> The 2003 SP1 Support Tools version is =
5.2.3790.1830. Do not use it.<BR>
> The Vista version has not been released =
yet. It is supposed to be<BR>
> published under KB926036. I suspect we will =
see it on Jan 30.<BR>
><BR>
> ktpass -out <keytab> -princ =
afs/cs.unc.edu@WIN.CS.UNC.EDU \<BR>
> -crypto DES-CBC-CRC +rndPass =
-DesOnly<BR>
><BR>
> The vista version of ktpass will allow you =
to:<BR>
> -DumpSalt to have it display the salt =
that was used<BR>
> -RawSalt <salt> to =
specify a specific salt<BR>
> -SetUPN to set the user principal =
name in addition to the Service<BR>
> &nb=
sp; Principal Name<BR>
> -SetPass to set a user account =
password<BR>
> as well as supporting the new AES crypto =
types.<BR>
> * copy the keytab to your AFS servers and import the key with =
asetkey<BR>
><BR>
> The reason that ktutil could be used to generate the keytab was =
that<BR>
> the password for the service principal was known. Therefore, =
ktutil<BR>
> didn't have to query the Kerberos database.<BR>
><BR>
> Jeffrey Altman<BR>
><BR>
><BR>
><BR>
> John W. Sopko Jr. wrote:<BR>
>> I have been following this thread. I also want to test our =
Windows AD for<BR>
>> authentication. I have tested a krb5 server on linux and am =
familiar with<BR>
>> generating a keytab/KeyFile for the afs/cell.name service =
principal using<BR>
>> kadmin and asetkey. I got a bit confused with your Windows AD =
procedure.<BR>
>> Could you please summarize and post the steps you used =
including command<BR>
>> line options.<BR>
>><BR>
>> For example, one thread says you ran ktutil on linux not =
Windows but as<BR>
>> far as I know ktutil on linux is used to manipulate keytabs =
files not<BR>
>> export keys from the krb5 principal database. Looks like you =
basically<BR>
>> did this:<BR>
>><BR>
>> - Create Windows AD user afs/cell.name user with =
"DES" key only<BR>
>> - Used Microsoft 2003 SP1 ktpass.exe to export the =
afs/cell.name to a<BR>
>> keytab<BR>
>> - Used OpenAFS asetkey to import keytab to =
/usr/afs/etc/KeyFile<BR>
>> - This did not work<BR>
>> - You then used ktutil.exe on Windows to to export the =
afs/cell.name to<BR>
>> a keytab<BR>
>> - Used OpenAFS asetkey to import keytab to =
/usr/afs/etc/KeyFile<BR>
>> - Success<BR>
>> - Appears to be some issue with Microsoft 2003 SP1 =
ktpass.exe<BR>
>><BR>
>> Which ktutil command did you run, on Windows or L/Uinux?<BR>
>> Where did you get the ktutil command for Windows?<BR>
>> Did you upgrade to a Microsoft ktpass.exe that worked?<BR>
>><BR>
>> Appreciate the info and the time you saved us!<BR>
>><BR>
>> I would prefer to run the MIT K5 server on linux for OpenAFS =
but I bet<BR>
>> others have the same issue I have. Our Windows machines run in =
the same<BR>
>> DNS domain as our L/Unix machines. The Windows folks have been =
running<BR>
>> AD under our DNS/cell.name/realm name for sometime. Our afs =
cellname<BR>
>> is the same as our DNS name. I have tested using a different =
KRB realm<BR>
>> name and using the "domain_realm" mapping, it gets =
confusing to have 2<BR>
>> kerberos realm names in the same DNS domain. It does not make =
sense to<BR>
>> run 2 different krb5 servers for authentication.<BR>
>><BR>
>><BR>
>>> Date: Wed, 3 Jan 2007 16:40:33 +0100<BR>
>>> From: =3D?iso-8859-1?Q?L=3DF6nroth_Erik?=3D =
<erik.lonroth@scania.com><BR>
>>> To: =3D?iso-8859-1?Q?L=3DF6nroth_Erik?=3D =
<erik.lonroth@scania.com>,<BR>
>>> "Jeffrey Altman" =
<jaltman@secure-endpoints.com><BR>
>>> Cc: <openafs-info@openafs.org><BR>
>>> Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, =
openAFS -<BR>
>>> rxkad error=3D19270407, arghhhh<BR>
>>><BR>
>>> This is a multi-part message in MIME format.<BR>
>>><BR>
>>> ------_=3D_NextPart_001_01C72F4D.B4C63582<BR>
>>> Content-Type: text/plain;<BR>
>>> =
charset=3D"iso-8859-1"<BR>
>>> Content-Transfer-Encoding: quoted-printable<BR>
>>><BR>
>>> Correction on that:<BR>
>>><BR>
>>> The "ktutil" was run on the linux host! (not =
windows)<BR>
>>><BR>
>>> But still... the ktpass.exe gives me bogus keyfiles.<BR>
>>><BR>
>>> /Erik<BR>
>>><BR>
>>><BR>
>>> -----Original Message-----<BR>
>>> From: openafs-info-admin@openafs.org on behalf of =
L=3DF6nroth Erik<BR>
>>> Sent: Wed 1/3/2007 4:34 PM<BR>
>>> To: Jeffrey Altman<BR>
>>> Cc: openafs-info@openafs.org<BR>
>>> Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, =
openAFS - =3D<BR>
>>> rxkad error=3D3D19270407, arghhhh<BR>
>>> =3D20<BR>
>>> OK, I believe have resolved the problem now after 5 whole =
days of trial =3D<BR>
>>> and error.<BR>
>>><BR>
>>> It turns out that using the "KTPASS" native from =
Active Directory =3D<BR>
>>> generates keys that is not liked by AFS.<BR>
>>><BR>
>>> I instead used ktutil.exe (for windows) to generate my key =
that I then =3D<BR>
>>> imported as usual into AFS. =3D20<BR>
>>><BR>
>>> On Microsoft AD side:<BR>
>>><BR>
>>>> ktutil<BR>
>>> ktutil: addent -password -p =
afs/sss.se.scania.com@LAB.SCANIA.COM -k 9<BR>
>>> -e =3D<BR>
>>> des-cbc-crc<BR>
>>> ktutil: wkt ./keytab.file<BR>
>>> ktutil: quit=3D20<BR>
>>><BR>
>>> This file is then copied to linux and imported exactly as I =
would =3D<BR>
>>> normally:<BR>
>>><BR>
>>> asetkey add 9 keytab.file afs/sss.se.scania.com<BR>
>>><BR>
>>> Now - everything works=3D20<BR>
>>><BR>
>>> kinit sssler<BR>
>>> aklog<BR>
>>> touch /afs/sss.se.scania.com/home/sssler/somefile<BR>
>>> ls /afs/sss.se.scania.com/home/sssler/somefile<BR>
>>> /afs/sss.se.scania.com/home/sssler/somefile<BR>
>>><BR>
>>> Success!<BR>
>>><BR>
>>> I verified this by behaviour - AGAIN - by using the =
"KTPASS.EXE" =3D<BR>
>>> (without changing anything else) and importing the key with =
"asetkey"<BR>
>>> as =3D<BR>
>>> normal.<BR>
>>><BR>
>>> C:\ktpass -out afs-keytab-md5-verify -princ =3D<BR>
>>> afs/sss.se.scania.com@LAB.SCANIA.COM -mapuser afs -crypto =
DES-CBC-CRC =3D<BR>
>>> -pass *<BR>
>>> Targeting domain controller: SeSoCoLab11.scania.se<BR>
>>> Successfully mapped afs/sss.se.scania.com to afs.<BR>
>>> Type the password for afs/sss.se.scania.com:<BR>
>>> Type the password again to confirm:<BR>
>>> WARNING: pType and account type do not match. This might =
cause =3D<BR>
>>> problems.<BR>
>>> Key created.<BR>
>>> Output keytab to afs-keytab-md5-verify:<BR>
>>> Keytab version: 0x502<BR>
>>> keysize 63 afs/sss.se.scania.com@LAB.SCANIA.COM ptype 0 =
=3D<BR>
>>> (KRB5_NT_UNKNOWN) vno 9<BR>
>>> etype 0x1 (DES-CBC-CRC) keylength 8 =
(0xbff2e56b29943d3e)<BR>
>>><BR>
>>> (Again publishing the key to the whole world ;-)=3D20<BR>
>>><BR>
>>> ... and - using this key in AFS - I get the same error =
again : rxkad =3D<BR>
>>> error=3D3D19270407<BR>
>>><BR>
>>> I swapped back again to the key generated by ktutil.exe - =
and it works =3D<BR>
>>> again.<BR>
>>><BR>
>>> It seems that using the KTPASS.EXE generates bogus keys for =
me!<BR>
>>><BR>
>>> I have not read this anywhere and I have read pretty much =
everyting,<BR>
>>> did =3D<BR>
>>> I miss something critical here or is this a =
bug/feature?<BR>
>>><BR>
>>> /Erik<BR>
>>><BR>
>>><BR>
<BR>
--<BR>
John W. Sopko =
Jr. &nbs=
p; University of North Carolina<BR>
email: sopko AT cs.unc.edu Computer =
Science Dept., CB 3175<BR>
Phone: =
919-962-1844 &=
nbsp; Sitterson Hall; Room 044<BR>
Fax: =
919-962-1799 &=
nbsp; Chapel Hill, NC 27599-3175<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C73301.645A4E28--