[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Hello!
I've been trying to get OpenAFS 1.4.2 to work with Microsoft Active Directory
(AD) 2003 as KDC for some week now, and I starting to believe I should have
went on that early vaccation after all. I just can't get it to work. It ends at:
19270407 = security object was passed a bad ticket
I have a lab environment consisting of an AD (lab.scania.com) and one AFS
server/cell. (cellname: sss.se.scania.com, servername: vmware01.scania.com)
I have verified that the OpenAFS works by setting up a MIT kerberos 5 server in
parallell (separate server) and successfully authenticatded and can access
read,write files in my AFS directory. But swapping to the AD gives no luck
whatsoever:
This is what it ends up to.
(On AD side)
C:\>ktpass -out afs-keytab-des-cbc-md5 -princ afs/[EMAIL PROTECTED] -mapuser
afs -crypto DES-CBC-MD5 -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-des-cbc-md5:
Keytab version: 0x502
keysize 63 afs/[EMAIL PROTECTED] ptype 0 (KRB5_NT_UNKNOWN) vno 7
etype 0x3 (DES-CBC-MD5) keylength 8 (0xd0d352801964ad19)
(I email this file to my RedHat ES4 linux server, vmware01, that also hold the
AFS-server)
I now add the key:
[EMAIL PROTECTED] ~]# asetkey add 7 afs-keytab-des-cbc-md5 afs/sss.se.scania.com
[EMAIL PROTECTED] ~]# asetkey list
kvno0: key is: e9d6f2e068d97386
kvno7: key is: d0d352801964ad19
--- I now clean up any old tickets/tokens:
[EMAIL PROTECTED] ~]# unlog
[EMAIL PROTECTED] ~]# kdestroy
--- I get my ticket - using my AD password:
[EMAIL PROTECTED] ~]# kinit -V sssler
Password for [EMAIL PROTECTED]:
Authenticated to Kerberos v5
[EMAIL PROTECTED] ~]# klist -e -5
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [EMAIL PROTECTED]
Valid starting ExpiresService principal
01/03/07 12:12:21 01/03/07 22:12:11 krbtgt/[EMAIL PROTECTED]
renew until 01/04/07 12:12:21, Etype (skey, tkt): DES cbc mode with
CRC-32, ArcFour with HMAC/md5
--- I successfully aklog
[EMAIL PROTECTED] ~]# aklog -d
Authenticating to cell sss.se.scania.com (server vmware01.sss.se.scania.com).
We've deduced that we need to authenticate to realm LAB.SCANIA.COM.
Getting tickets: afs/[EMAIL PROTECTED]
Using Kerberos V5 ticket natively
About to resolve name sssler to id in cell sss.se.scania.com.
Id 4067
Set username to AFS ID 4067
Setting tokens. AFS ID 4067 / @ LAB.SCANIA.COM
[EMAIL PROTECTED] ~]# tokens
Tokens held by the Cache Manager:
User's (AFS ID 4067) tokens for [EMAIL PROTECTED] [Expires Jan 3 22:30]
--End of list--
[EMAIL PROTECTED] ~]# klist -e -5
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [EMAIL PROTECTED]
Valid starting ExpiresService principal
01/03/07 12:30:37 01/03/07 22:30:34 krbtgt/[EMAIL PROTECTED]
renew until 01/04/07 12:30:37, Etype (skey, tkt): ArcFour with
HMAC/md5, ArcFour with HMAC/md5
01/03/07 12:30:36 01/03/07 22:30:34 afs/[EMAIL PROTECTED]
renew until 01/04/07 12:30:37, Etype (skey, tkt): DES cbc mode with
CRC-32, DES cbc mode with RSA-MD5
--- from here I think I should be able to touch a file in my home directory,
which I can do if I use MIT kerberos), but it fails with permission denied.
$ touch /afs/sss.se.scania.com/home/sssler
touch: cannot touch `/afs/sss.se.scania.com/home/sssler/foobar': Permission
denied
$ tail /var/log/messages
...
Jan 3 10:59:49 vmware01 kernel: afs: Tokens for user of AFS id 4067 for cell
sss.se.scania.com are discarded (rxkad error=19270407)
Basically, this is what I have done on the AD side:
* Created the user "afs" (afs/sss.se.scania.com) and set the options in the
"Account" tab:
[Account is sensitive and cannot be delegated]
[use DES encryption types]
[Password never expires]
[Do not require Kerberos preauthentication]
* I have set in the "Delegation" tab
[Trust user for delegation to any Service (Kerberos only)]
This is my /etc/krb5.conf
[libdefaults]
default_realm = LAB.SCANIA.COM
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = des-cbc-crc des-cbc-md5
default_tgs_enctypes = des-cbc-crc des-cbc-md5
[realms]
LAB.SCANIA.COM = {
kdc = sesoco0206.scania.com
default_domain = scania.com
}
[domain_realm]
.scania.se = LAB.SCANIA.COM
scania.se = LAB.SCANIA.COM
.scania.com = LAB.SCANIA.COM
scania.com = LAB.SCANIA.COM
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
What am I doing wrong as it seems it should be fairly straight forward?
/Erik Lönroth
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Have you set the authentication realm the AFS server's krb.conf file to LAB.SCANIA.COM ? Jeffrey Altman P.S. In your krb5.conf file, don't do this: default_tkt_enctypes = des-cbc-crc des-cbc-md5 default_tgs_enctypes = des-cbc-crc des-cbc-md5 smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Am Mittwoch, 3. Januar 2007 14:29 schrieb ext Jeffrey Altman: > P.S. In your krb5.conf file, don't do this: > > default_tkt_enctypes = des-cbc-crc des-cbc-md5 > default_tgs_enctypes = des-cbc-crc des-cbc-md5 Is this a general recommendation or only for Erik? Can you give some background info? Thanx... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Hambornerstraße 55 | Web: http://www.capgemini.com D-40472 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net pgplAifNVqoEk.pgp Description: PGP signature
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Dirk Heinrichs wrote: > Am Mittwoch, 3. Januar 2007 14:29 schrieb ext Jeffrey Altman: > >> P.S. In your krb5.conf file, don't do this: >> >> default_tkt_enctypes = des-cbc-crc des-cbc-md5 >> default_tgs_enctypes = des-cbc-crc des-cbc-md5 > > Is this a general recommendation or only for Erik? Can you give some > background info? > > Thanx... > > Dirk You *almost* never want to specify default_tkt_enctypes or default_tgs_enctypes. Doing so prevents the client from being able to handle stronger ticket types when the KDC wants to issue them. If you need to restrict a ticket enctype for a service such as AFS you do so by limiting the enctypes for which that service principal has keys in the Kerberos Database. For AFS, there should only be single DES keys associated with the service principal in MIT or Heimdal. In Active Directory, the "use DES only" flag should be set. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
I believe I have... My file looks like this. Can I be sure this is OK? In my missery I can't trust anything at the moment. [EMAIL PROTECTED] ~]# cat /usr/afs/etc/krb.conf LAB.SCANIA.COM LAB.SCANIA.COM sesocolab11.scania.com I have also looked in AD to se the Service principal binding (Is this right?) : C:\setspn -A afs/sss.se.scania.com afs Registering ServicePrincipalNames for CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=s cania,DC=com afs/sss.se.scania.com Updated object C:\setspn -L afs Registered ServicePrincipalNames for CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=sc ania,DC=com: afs/sss.se.scania.com HOST/afs HOST/afs.LAB /Erik -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Wed 1/3/2007 2:29 PM To: Lönroth Erik Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arg Have you set the authentication realm the AFS server's krb.conf file to LAB.SCANIA.COM ? Jeffrey Altman P.S. In your krb5.conf file, don't do this: default_tkt_enctypes = des-cbc-crc des-cbc-md5 default_tgs_enctypes = des-cbc-crc des-cbc-md5
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Lönroth Erik wrote: > I believe I have... My file looks like this. Can I be sure this is OK? > In my missery I can't trust anything at the moment. > > [EMAIL PROTECTED] ~]# cat /usr/afs/etc/krb.conf > LAB.SCANIA.COM > LAB.SCANIA.COM sesocolab11.scania.com This is fine. Although the second line is not used by AFS so you can remove it. Did you restart the AFS servers after setting this value? > I have also looked in AD to se the Service principal binding (Is this > right?) : > > C:\setspn -A afs/sss.se.scania.com afs > Registering ServicePrincipalNames for > CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=s > cania,DC=com > afs/sss.se.scania.com > Updated object > > C:\setspn -L afs > Registered ServicePrincipalNames for > CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=sc > ania,DC=com: > afs/sss.se.scania.com > HOST/afs > HOST/afs.LAB > That is fine. RXKADBADTICKET can be generated if the clocks between AFS and AD are not synchronized. Are they? Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
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. On Microsoft AD side: >ktutil ktutil: addent -password -p afs/[EMAIL PROTECTED] -k 9 -e des-cbc-crc ktutil: wkt ./keytab.file ktutil: quit 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 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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] ptype 0 (KRB5_NT_UNKNOWN) vno 9 etype 0x1 (DES-CBC-CRC) keylength 8 (0xbff2e56b29943d3e) (Again publishing the key to the whole world ;-) ... and - using this key in AFS - I get the same error again : rxkad error=19270407 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 -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Wed 1/3/2007 3:16 PM To: Lönroth Erik Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arg Lönroth Erik wrote: > I believe I have... My file looks like this. Can I be sure this is OK? > In my missery I can't trust anything at the moment. > > [EMAIL PROTECTED] ~]# cat /usr/afs/etc/krb.conf > LAB.SCANIA.COM > LAB.SCANIA.COM sesocolab11.scania.com This is fine. Although the second line is not used by AFS so you can remove it. Did you restart the AFS servers after setting this value? > I have also looked in AD to se the Service principal binding (Is this > right?) : > > C:\setspn -A afs/sss.se.scania.com afs > Registering ServicePrincipalNames for > CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=s > cania,DC=com > afs/sss.se.scania.com > Updated object > > C:\setspn -L afs > Registered ServicePrincipalNames for > CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=sc > ania,DC=com: > afs/sss.se.scania.com > HOST/afs > HOST/afs.LAB > That is fine. RXKADBADTICKET can be generated if the clocks between AFS and AD are not synchronized. Are they? Jeffrey Altman
RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
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: [EMAIL PROTECTED] on behalf of Lönroth 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=19270407, arg 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. On Microsoft AD side: >ktutil ktutil: addent -password -p afs/[EMAIL PROTECTED] -k 9 -e des-cbc-crc ktutil: wkt ./keytab.file ktutil: quit 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 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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] ptype 0 (KRB5_NT_UNKNOWN) vno 9 etype 0x1 (DES-CBC-CRC) keylength 8 (0xbff2e56b29943d3e) (Again publishing the key to the whole world ;-) ... and - using this key in AFS - I get the same error again : rxkad error=19270407 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 -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Wed 1/3/2007 3:16 PM To: Lönroth Erik Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arg Lönroth Erik wrote: > I believe I have... My file looks like this. Can I be sure this is OK? > In my missery I can't trust anything at the moment. > > [EMAIL PROTECTED] ~]# cat /usr/afs/etc/krb.conf > LAB.SCANIA.COM > LAB.SCANIA.COM sesocolab11.scania.com This is fine. Although the second line is not used by AFS so you can remove it. Did you restart the AFS servers after setting this value? > I have also looked in AD to se the Service principal binding (Is this > right?) : > > C:\setspn -A afs/sss.se.scania.com afs > Registering ServicePrincipalNames for > CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=s > cania,DC=com > afs/sss.se.scania.com > Updated object > > C:\setspn -L afs > Registered ServicePrincipalNames for > CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=sc > ania,DC=com: > afs/sss.se.scania.com > HOST/afs > HOST/afs.LAB > That is fine. RXKADBADTICKET can be generated if the clocks between AFS and AD are not synchronized. Are they? Jeffrey Altman
RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
On Wed, 3 Jan 2007, Lönroth Erik wrote: 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? When I was preparing my slides I had this error, and then I took a package from Jeff Altman with ktpass; then ktpass worked, but I assumed I had changed something else.
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Compare the keytab files produced with ktutil and ktpass for the same key. How are they different? Jeffrey Altman Lönroth Erik wrote: > 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. > > On Microsoft AD side: > >>ktutil > ktutil: addent -password -p afs/[EMAIL PROTECTED] -k 9 -e > des-cbc-crc > ktutil: wkt ./keytab.file > ktutil: quit > > 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 > > 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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] ptype 0 > (KRB5_NT_UNKNOWN) vno 9 > etype 0x1 (DES-CBC-CRC) keylength 8 (0xbff2e56b29943d3e) > > (Again publishing the key to the whole world ;-) > > ... and - using this key in AFS - I get the same error again : rxkad > error=19270407 > > 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 > > > > > > > > -Original Message- > From: Jeffrey Altman [mailto:[EMAIL PROTECTED] > Sent: Wed 1/3/2007 3:16 PM > To: Lönroth Erik > Cc: openafs-info@openafs.org > Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - > rxkad error=19270407, arg > > Lönroth Erik wrote: >> I believe I have... My file looks like this. Can I be sure this is OK? >> In my missery I can't trust anything at the moment. >> >> [EMAIL PROTECTED] ~]# cat /usr/afs/etc/krb.conf >> LAB.SCANIA.COM >> LAB.SCANIA.COM sesocolab11.scania.com > > This is fine. Although the second line is not used by AFS so you > can remove it. > > Did you restart the AFS servers after setting this value? > >> I have also looked in AD to se the Service principal binding (Is this >> right?) : >> >> C:\setspn -A afs/sss.se.scania.com afs >> Registering ServicePrincipalNames for >> CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=s >> cania,DC=com >> afs/sss.se.scania.com >> Updated object >> >> C:\setspn -L afs >> Registered ServicePrincipalNames for >> CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=sc >> ania,DC=com: >> afs/sss.se.scania.com >> HOST/afs >> HOST/afs.LAB >> > > That is fine. > > RXKADBADTICKET can be generated if the clocks between AFS and AD > are not synchronized. Are they? > > Jeffrey Altman > ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Derrick J Brashear wrote: > When I was preparing my slides I had this error, and then I took a > package from Jeff Altman with ktpass; then ktpass worked, but I assumed > I had changed something else. Right. What version of ktpass are you using? There was a bug in one version. The one that came with 2003 SP1 perhaps? smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Jeffrey Altman wrote: Compare the keytab files produced with ktutil and ktpass for the same key. How are they different? Does the test AD domain have more then one DC? If so is this a replication timing problem? It may take minutes for all the DCs to get in sync. It could be a salt issue, that the newer ktpass might fix. The old ktpass may have made the assumption the salt matched a principal for [EMAIL PROTECTED] which is what I think W2K did. (the SamAccountName is the -mapuser parameter, so would be afs in your case with a salt of "LAB.SCANIA.COMafs".) I think W2K3 and its ktpass used the standard salt derived from the principal. ... or in your case "LAB.SCANIA.COMaf.se.scania.com" I see in your first note you listed the DES key, and that was what you added with asetkey. You could also try using the same password with ktutil and see if it produces the same key which would indicate if it was using the standard salt. If not try using ktutil with a principal of [EMAIL PROTECTED] which would give the salt that matches the SamAccountName. You can see what salt AD is using, by using a network sniffer to look at the KRB5_ERROR message e-data, PA_ENCTYPE_INFO values that lists the salts while doing: kinit afs/[EMAIL PROTECTED] But this does not show what salt ktpass used to create the keytab. Jeffrey Altman Lönroth Erik wrote: 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. On Microsoft AD side: ktutil ktutil: addent -password -p afs/[EMAIL PROTECTED] -k 9 -e des-cbc-crc ktutil: wkt ./keytab.file ktutil: quit 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 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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] ptype 0 (KRB5_NT_UNKNOWN) vno 9 etype 0x1 (DES-CBC-CRC) keylength 8 (0xbff2e56b29943d3e) (Again publishing the key to the whole world ;-) ... and - using this key in AFS - I get the same error again : rxkad error=19270407 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 -Original Message- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Wed 1/3/2007 3:16 PM To: Lönroth Erik Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arg Lönroth Erik wrote: I believe I have... My file looks like this. Can I be sure this is OK? In my missery I can't trust anything at the moment. [EMAIL PROTECTED] ~]# cat /usr/afs/etc/krb.conf LAB.SCANIA.COM LAB.SCANIA.COM sesocolab11.scania.com This is fine. Although the second line is not used by AFS so you can remove it. Did you restart the AFS servers after setting this value? I have also looked in AD to se the Service principal binding (Is this right?) : C:\setspn -A afs/sss.se.scania.com afs Registering ServicePrincipalNames for CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=s cania,DC=com afs/sss.se.scania.com Updated object C:\setspn -L afs Registered ServicePrincipalNames for CN=afs,OU=Users,OU=VAS,OU=TEST,DC=lab,DC=sc ania,DC=com: afs/sss.se.scania.com HOST/afs HOST/afs.LAB That is fine. RXKADBADTICKET can be generated if the clocks between AFS and AD are not synchronized. Are they? Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Indeed our AD is 2003 SP1 and I assume "ktpass.exe" is the one that comes with it. I compared the keys generated: [EMAIL PROTECTED] ~]# klist -k keytab.file-ktpass -t -K Keytab name: FILE:keytab.file-ktpass KVNO Timestamp Principal - 9 01/01/70 01:00:00 afs/[EMAIL PROTECTED] (0xbff2e56b29943d3e) [EMAIL PROTECTED] ~]# klist -k keytab.file-kutil -t -K Keytab name: FILE:keytab.file-kutil KVNO Timestamp Principal - 9 01/03/07 15:01:32 afs/[EMAIL PROTECTED] (0x9e19640df73d19d5) Obvously some difference... Thanx alot for your help on this ! We were getting desperate on this over here! We will make sure to change "ktpass" for a "non-bogus one" and continue our work with openAFS. Also good to know we can generate keyfiles natively and get it to work. /Erik Lonroth P.S. We have changed our key after posting it in the forum ;) -Original Message- From: [EMAIL PROTECTED] on behalf of Jeffrey Altman Sent: Wed 1/3/2007 5:26 PM To: Derrick J Brashear Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arg Derrick J Brashear wrote: > When I was preparing my slides I had this error, and then I took a > package from Jeff Altman with ktpass; then ktpass worked, but I assumed > I had changed something else. Right. What version of ktpass are you using? There was a bug in one version. The one that came with 2003 SP1 perhaps?
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
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?= <[EMAIL PROTECTED]> To: =?iso-8859-1?Q?L=F6nroth_Erik?= <[EMAIL PROTECTED]>, "Jeffrey Altman" <[EMAIL PROTECTED]> Cc: Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arg 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: [EMAIL PROTECTED] 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, arg =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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] 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 -- 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 __
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
me. 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?= <[EMAIL PROTECTED]> >> To: =?iso-8859-1?Q?L=F6nroth_Erik?= <[EMAIL PROTECTED]>, >> "Jeffrey Altman" <[EMAIL PROTECTED]> >> Cc: >> Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - >> rxkad error=19270407, arg >> >> 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: [EMAIL PROTECTED] 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, arg >> =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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] 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 >> >> > smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
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?= <[EMAIL PROTECTED]>
To: =?iso-8859-1?Q?L=F6nroth_Erik?= <[EMAIL PROTECTED]>,
"Jeffrey Altman" <[EMAIL PROTECTED]>
Cc:
Subject: RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS -
rxkad error=19270407, arg
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: [EMAIL PROTECTED] 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, arg
=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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] -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/[EMAIL PROTECTED] 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
--
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
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
John W. Sopko Jr. wrote: > 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. oh, much relief felt by all :-) > 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). The instructions I provided should work for you. If they don't, scream. > 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. There is a talk from last years workshop by Derrick on this very topic. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Yes I will try your instructions, I am not in control of our Windows servers and they are running W2K. I do have access to a test W2003 AD server. > * 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. So use the original ktpass? Is there a way to verify the working version? Thanks for all your help. While we are on the subject. If we decide to have our L/Unix infrustrucure, including afs, authenticate to Windows AD; how comfortable do you feel that one day a Microsoft patch might break things? Our Windows group say they cannot guarantee this will not happen. I know this is a big question... Jeffrey Altman wrote: John W. Sopko Jr. wrote: 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. oh, much relief felt by all :-) 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). The instructions I provided should work for you. If they don't, scream. 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. There is a talk from last years workshop by Derrick on this very topic. Jeffrey Altman -- 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 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
John W. Sopko Jr. wrote: > Yes I will try your instructions, I am not in control > of our Windows servers and they are running W2K. I do > have access to a test W2003 AD server. > >> * 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. > > So use the original ktpass? Is there a way to verify the > working version? Thanks for all your help. As far as I am aware, all of the versions other than 2003 SP1, as identified above, work. The Vista version provides additional options that will make debugging easier. Unfortunately, its not available yet. > While we are on the subject. If we decide to have our > L/Unix infrustrucure, including afs, authenticate to > Windows AD; how comfortable do you feel that one day > a Microsoft patch might break things? Our Windows group > say they cannot guarantee this will not happen. I know > this is a big question... Will break what? Can your UNIX group guarantee that an update to MIT or Heimdal Kerberos won't break things? Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
RE: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
" 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: rxkad error=19270407 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:[EMAIL PROTECTED] Sent: Fri 1/5/2007 5:39 PM To: [EMAIL PROTECTED] Cc: openafs; Lönroth Erik Subject: Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arg Jeffrey Altman wrote: > 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. 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. > > 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.
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Jeffrey Altman wrote: > John W. Sopko Jr. wrote: >> Yes I will try your instructions, I am not in control >> of our Windows servers and they are running W2K. I do >> have access to a test W2003 AD server. >> >>> * 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. >> So use the original ktpass? Is there a way to verify the >> working version? Thanks for all your help. > > As far as I am aware, all of the versions other than 2003 SP1, > as identified above, work. > > The Vista version provides additional options that will make > debugging easier. Unfortunately, its not available yet. > >> While we are on the subject. If we decide to have our >> L/Unix infrustrucure, including afs, authenticate to >> Windows AD; how comfortable do you feel that one day >> a Microsoft patch might break things? Our Windows group >> say they cannot guarantee this will not happen. I know >> this is a big question... > > Will break what? > Can your UNIX group guarantee that an update to MIT or Heimdal > Kerberos won't break things? > > Jeffrey Altman I am not worried about this subject but our Windows admins get nerverous about this. Anyway... I could not find an old working ktpass.exe so pursued using ktutil to get things working and would prefer to do that anyway. See "AM I CRAZY?" below for doing so. I can get K5 tickets from the Windows AD KDC on linux and do aklog to get tokens but do not have afs permissions. The /var/log/messages syslog shows: Jan 9 14:21:36 eagle kernel: afs: Tokens for user of AFS id 3903 for cell cs.unc.edu are discarded (rxkad error=19270408) Configuration: -- The Windows test server realm/windows domain = MSE.UNCCS.TEST Our windows folks use this test server, madison-cs.mse.unccs.test for testing and I have access to it. This server is a Windows 2003 SP1 with AD running in 2000 mixed mode and there is also a secondary AD server. The linux afs test server is eagle.cs.unc.edu. Linux afs test cell is cs.unc.edu, (this is a test cell different from our production cs.unc.edu cell). Runs Red Hat 4 with latest 1.4.2 OpenAFS server/client. The kaserver is turned off. This system had been working to my test linux MIT K5 server CSX.UNC.EDU realm that I would use if cannot get Windows going. Here is what I tried On Windows 2003 SP1 server running AD in 2000 mixed mode, using the "Active Directory Users and Computers" gui: Created Windows domain user "sopko" with the gui, made no special changes to the account settings. Created Windows domain user "afs" with the gui. Brought up the properties Window for the afs userand checked these boxes: X = checked User must change password at next logon User cannot change password X Password never expires Store password using reversible encrytpion Acount is disabled Smart card is required for interactive logon X Account is trusted for delegation Account is sensitive and cnnot be delegated X Use DES encryption types for this account Do not require Kerberos preauthentication Since this server is not promoted to a 2003 AD there is no Delegation tab, checking "Account is trusted for delegation" is supposed to do the same thing. Here is a Microsoft blurb about this: http://technet2.microsoft.com/WindowsServer/en/library/bef202b0-c8e9-4999-9af7-f56b991a4fd41033.mspx?mfr=true I set the afs service principal on the Windows afs domain account: C:\temp>setspn -A afs/cs.unc.edu afs Registering ServicePrincipalNames for CN=afs service principal,CN=Users,DC=mse, C=unccs,DC=test afs/cs.unc.edu Updated object I reset the password for afs user after making the above changes. Have 2 AD servers, wait until acct info is synced. We have the "bad" version of ktpass, do not use, this is how I checked: In C:\Program Files\Support Tools\ktpass right click properties "version tab" shows 5.2.3790.1830 So use ktutil on the linux openafs server, setting the password the same as the afs users Windows password: eagle/root [/usr/afs/etc] # ktutil ktutil: add_entry -password -p afs/[EMAIL PROTECTED] -k 1 -e des-cbc-crc Password for afs/[EMAIL PROTECTED]: ktutil: write_kt keytab.kutil_generated ktutil: quit eagle/root [/usr/afs/etc] # rm KeyFile eagle/root [/usr/afs/etc] # asetkey add 1 keytab.kutil_generated afs/[EMAIL PROTECTED] eagle/root [/usr/afs/etc] # cat krb.conf MSE.UNCCS.TEST eagle/root [/usr/afs/etc] # /etc/init.d/openafs-server restart Stopping openafs-server: [ OK ] I manage ntp here, all clocks within 100 milliseconds. I get a token but it is no good: [EMAIL PROTECTED] /]$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED] /]$ aklog -d Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu). We've deduced that we need to authenticate to realm MSE.UNCCS.TEST. Getting tickets: afs/[EMAIL PROTECTED] Using Kerberos V5 ticket natively About to resolve name sopko to id in cel
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
John W. Sopko Jr. wrote: > In C:\Program Files\Support Tools\ktpass > right click properties "version tab" shows 5.2.3790.1830 > > So use ktutil on the linux openafs server, setting the > password the same as the afs users Windows password: > > eagle/root [/usr/afs/etc] # ktutil > ktutil: add_entry -password -p afs/[EMAIL PROTECTED] -k 1 -e > des-cbc-crc Where did you get the key version number of 1 from? The key version number must match the number that is actually issued by the KDC. You can identify the version number using the MIT Kerberos utility kvno > cell cs.unc.edu are discarded (rxkad error=19270408) The OpenAFS translate_et command will tell you this is because 19270408 = ticket contained unknown key version number > Windows Event Viewer, System log shows this, sometimes: > > While processing a TGS request for the target server afs/cs.unc.edu, the > account [EMAIL PROTECTED] did not have a suitable key for generating > a Kerberos ticket (the missing key has an ID of 8). The requested etypes > were 2. The accounts available etypes were 3 1. What in the world is requesting a ticket with DES-CBC-MD4 ? > AM I CRAZY? > --- > > Once I get Windows AD working can I run both our current kaserver and > Windows AD authentication against our production cs.unc.edu openafs cell > at the same time? If I can generate afs/cs.unc.edu service pincipals > with the same password on the kaserver and the AD server will this work? > > This may be a good migration path for us. We currently have 2 password > databases, kaserver and Windows AD. When we create accounts we use the > same user login name for both wndows and linux. Most users keep their > passwords the same so logging into Windows gives them an afs token. > Even if they don't we just tell them to use their Windows password > as we migrate machine configurations. > > This way we can migrate machines to authenticate to "Windows AD only" > over a short period of time and start testing real live systems. > > First I have to get Windows AD afs service pricnipal working. AFS only stores DES keys by key version number. Ensure that your kaserver key and your AD key have different version numbers and you will be just fine. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Jeffrey Altman wrote: John W. Sopko Jr. wrote: In C:\Program Files\Support Tools\ktpass right click properties "version tab" shows 5.2.3790.1830 So use ktutil on the linux openafs server, setting the password the same as the afs users Windows password: eagle/root [/usr/afs/etc] # ktutil ktutil: add_entry -password -p afs/[EMAIL PROTECTED] -k 1 -e des-cbc-crc Where did you get the key version number of 1 from? When I ran the "bad" ktpass command on windows it always generates kvno 1 by default. The ktpass /? (help) says: kvno : Override Key Version Number Default: query DC for kvno. Use /kvno 1 for Win2K compat. Since this Windows 2003 server is running in 2000 mixed mode I thought it forced/kept the kvno at 1 for w2k compatability. Below is the output of the ktpass, no matter how many times I run it it keeps the "vno" at 1. I check the keytab.mse file with ktutil and it is at 1. But you are right I do not know what is in the server. I did not think hard enough about this. > The key version number must match the number that is actually > issued by the KDC. You can identify the version number using > the MIT Kerberos utility > > kvno I tried this to get the kvno: eagle/root [/usr/afs/etc] # kinit afs Password for [EMAIL PROTECTED]: eagle/root [/usr/afs/etc] # kvno afs [EMAIL PROTECTED]: kvno = 4 I then ran: ktutil> add_entry -password -p afs/[EMAIL PROTECTED] -k 4 -e des-cbc-crc ktutil> write_kt keytab.ktutil_generated /usr/sbin/asetkey add 4 keytab.ktutil_generated afs/cs.unc.edu /etc/init.d/openafs-server restart I now get the same error as Eric had: Jan 9 17:14:27 eagle kernel: afs: Tokens for user of AFS id 3903 for cell cs.unc.edu are discarded (rxkad error=19270407) Do I need to map an account like Eric did with the "mapuser" option to ktpass? The key version number must match the number that is actually issued by the KDC. You can identify the version number using the MIT Kerberos utility kvno cell cs.unc.edu are discarded (rxkad error=19270408) The OpenAFS translate_et command will tell you this is because 19270408 = ticket contained unknown key version number Windows Event Viewer, System log shows this, sometimes: While processing a TGS request for the target server afs/cs.unc.edu, the account [EMAIL PROTECTED] did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8). The requested etypes were 2. The accounts available etypes were 3 1. What in the world is requesting a ticket with DES-CBC-MD4 ? AM I CRAZY? --- Once I get Windows AD working can I run both our current kaserver and Windows AD authentication against our production cs.unc.edu openafs cell at the same time? If I can generate afs/cs.unc.edu service pincipals with the same password on the kaserver and the AD server will this work? This may be a good migration path for us. We currently have 2 password databases, kaserver and Windows AD. When we create accounts we use the same user login name for both wndows and linux. Most users keep their passwords the same so logging into Windows gives them an afs token. Even if they don't we just tell them to use their Windows password as we migrate machine configurations. This way we can migrate machines to authenticate to "Windows AD only" over a short period of time and start testing real live systems. First I have to get Windows AD afs service pricnipal working. AFS only stores DES keys by key version number. Ensure that your kaserver key and your AD key have different version numbers and you will be just fine. Jeffrey Altman -- 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 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
[EMAIL PROTECTED] != afs/[EMAIL PROTECTED] choose one and stick with it. John W. Sopko Jr. wrote: > > > Jeffrey Altman wrote: >> John W. Sopko Jr. wrote: >> >>> In C:\Program Files\Support Tools\ktpass >>> right click properties "version tab" shows 5.2.3790.1830 >>> >>> So use ktutil on the linux openafs server, setting the >>> password the same as the afs users Windows password: >>> >>> eagle/root [/usr/afs/etc] # ktutil >>> ktutil: add_entry -password -p afs/[EMAIL PROTECTED] -k 1 -e >>> des-cbc-crc >> >> Where did you get the key version number of 1 from? > > When I ran the "bad" ktpass command on windows it always generates kvno 1 > by default. The ktpass /? (help) says: > > kvno : Override Key Version Number >Default: query DC for kvno. Use /kvno 1 for Win2K compat. > > Since this Windows 2003 server is running in 2000 mixed mode I thought > it forced/kept the kvno at 1 for w2k compatability. Below is the output of > the ktpass, no matter how many times I run it it keeps the "vno" > at 1. I check the keytab.mse file with ktutil and it is at 1. > > But you are right I do not know what is in the server. I did not > think hard enough about this. > >> The key version number must match the number that is actually >> issued by the KDC. You can identify the version number using >> the MIT Kerberos utility >> >> kvno > > I tried this to get the kvno: > > eagle/root [/usr/afs/etc] # kinit afs > Password for [EMAIL PROTECTED]: > eagle/root [/usr/afs/etc] # kvno afs > [EMAIL PROTECTED]: kvno = 4 > > I then ran: > > ktutil> add_entry -password -p afs/[EMAIL PROTECTED] -k 4 -e > des-cbc-crc > ktutil> write_kt keytab.ktutil_generated > > /usr/sbin/asetkey add 4 keytab.ktutil_generated afs/cs.unc.edu > > /etc/init.d/openafs-server restart > > I now get the same error as Eric had: > > Jan 9 17:14:27 eagle kernel: afs: Tokens for user of AFS id 3903 for > cell cs.unc.edu are discarded (rxkad error=19270407) > > Do I need to map an account like Eric did with the "mapuser" option > to ktpass? > > > > > > >> >> The key version number must match the number that is actually >> issued by the KDC. You can identify the version number using >> the MIT Kerberos utility >> >> kvno >> >>> cell cs.unc.edu are discarded (rxkad error=19270408) >> >> The OpenAFS translate_et command will tell you this >> is because >> >> 19270408 = ticket contained unknown key version number >> >>> Windows Event Viewer, System log shows this, sometimes: >>> >>> While processing a TGS request for the target server afs/cs.unc.edu, the >>> account [EMAIL PROTECTED] did not have a suitable key for generating >>> a Kerberos ticket (the missing key has an ID of 8). The requested etypes >>> were 2. The accounts available etypes were 3 1. >> >> What in the world is requesting a ticket with DES-CBC-MD4 ? >> >>> AM I CRAZY? >>> --- >>> >>> Once I get Windows AD working can I run both our current kaserver and >>> Windows AD authentication against our production cs.unc.edu openafs cell >>> at the same time? If I can generate afs/cs.unc.edu service pincipals >>> with the same password on the kaserver and the AD server will this work? >>> >>> This may be a good migration path for us. We currently have 2 password >>> databases, kaserver and Windows AD. When we create accounts we use the >>> same user login name for both wndows and linux. Most users keep their >>> passwords the same so logging into Windows gives them an afs token. >>> Even if they don't we just tell them to use their Windows password >>> as we migrate machine configurations. >>> >>> This way we can migrate machines to authenticate to "Windows AD only" >>> over a short period of time and start testing real live systems. >>> >>> First I have to get Windows AD afs service pricnipal working. >> >> AFS only stores DES keys by key version number. Ensure that your >> kaserver key and your AD key have different version numbers and >> you will be just fine. >> >> Jeffrey Altman > ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Jeffrey Altman wrote: [EMAIL PROTECTED] != afs/[EMAIL PROTECTED] choose one and stick with it. I am confused with Windows principals: [EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED] kinit(v5): Client not found in Kerberos database while getting initial credentials That is why I did: [EMAIL PROTECTED] /]$ kinit afs Password for [EMAIL PROTECTED]: So I have a Windows "afs" user account that I ran: setspn -A afs/cs.unc.edu afs To Add/Associate a service principal to the Windows login name. But I cannot kinit to afs/cs.unc.edu like I can under MIT KRB5, (my CSX.UNC.EDU linux server): |[EMAIL PROTECTED]:19% kinit afs/cs.unc.edu Password for afs/[EMAIL PROTECTED]: John W. Sopko Jr. wrote: Jeffrey Altman wrote: John W. Sopko Jr. wrote: In C:\Program Files\Support Tools\ktpass right click properties "version tab" shows 5.2.3790.1830 So use ktutil on the linux openafs server, setting the password the same as the afs users Windows password: eagle/root [/usr/afs/etc] # ktutil ktutil: add_entry -password -p afs/[EMAIL PROTECTED] -k 1 -e des-cbc-crc Where did you get the key version number of 1 from? When I ran the "bad" ktpass command on windows it always generates kvno 1 by default. The ktpass /? (help) says: kvno : Override Key Version Number Default: query DC for kvno. Use /kvno 1 for Win2K compat. Since this Windows 2003 server is running in 2000 mixed mode I thought it forced/kept the kvno at 1 for w2k compatability. Below is the output of the ktpass, no matter how many times I run it it keeps the "vno" at 1. I check the keytab.mse file with ktutil and it is at 1. But you are right I do not know what is in the server. I did not think hard enough about this. The key version number must match the number that is actually issued by the KDC. You can identify the version number using the MIT Kerberos utility kvno I tried this to get the kvno: eagle/root [/usr/afs/etc] # kinit afs Password for [EMAIL PROTECTED]: eagle/root [/usr/afs/etc] # kvno afs [EMAIL PROTECTED]: kvno = 4 I then ran: ktutil> add_entry -password -p afs/[EMAIL PROTECTED] -k 4 -e des-cbc-crc ktutil> write_kt keytab.ktutil_generated /usr/sbin/asetkey add 4 keytab.ktutil_generated afs/cs.unc.edu /etc/init.d/openafs-server restart I now get the same error as Eric had: Jan 9 17:14:27 eagle kernel: afs: Tokens for user of AFS id 3903 for cell cs.unc.edu are discarded (rxkad error=19270407) Do I need to map an account like Eric did with the "mapuser" option to ktpass? The key version number must match the number that is actually issued by the KDC. You can identify the version number using the MIT Kerberos utility kvno cell cs.unc.edu are discarded (rxkad error=19270408) The OpenAFS translate_et command will tell you this is because 19270408 = ticket contained unknown key version number Windows Event Viewer, System log shows this, sometimes: While processing a TGS request for the target server afs/cs.unc.edu, the account [EMAIL PROTECTED] did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8). The requested etypes were 2. The accounts available etypes were 3 1. What in the world is requesting a ticket with DES-CBC-MD4 ? AM I CRAZY? --- Once I get Windows AD working can I run both our current kaserver and Windows AD authentication against our production cs.unc.edu openafs cell at the same time? If I can generate afs/cs.unc.edu service pincipals with the same password on the kaserver and the AD server will this work? This may be a good migration path for us. We currently have 2 password databases, kaserver and Windows AD. When we create accounts we use the same user login name for both wndows and linux. Most users keep their passwords the same so logging into Windows gives them an afs token. Even if they don't we just tell them to use their Windows password as we migrate machine configurations. This way we can migrate machines to authenticate to "Windows AD only" over a short period of time and start testing real live systems. First I have to get Windows AD afs service pricnipal working. AFS only stores DES keys by key version number. Ensure that your kaserver key and your AD key have different version numbers and you will be just fine. Jeffrey Altman -- 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 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Even assuming you wanted to kinit to your service principal you would have to so with the correct principal name afs/[EMAIL PROTECTED] != afs/[EMAIL PROTECTED] Your default realm name is CSX.UNC.EDU, not MSE.UNCCS.TEST. However, you don't want to be able to kinit to that service principal. What you want is to be able to obtain a service ticket for it using a client principal kvno afs/[EMAIL PROTECTED] obtains a service ticket for the specified principal name. Assuming the kvno is still 4 after you set the service principal name. You should try to authenticate to your AFS servers again. John W. Sopko Jr. wrote: > > Jeffrey Altman wrote: >> [EMAIL PROTECTED] != afs/[EMAIL PROTECTED] >> >> choose one and stick with it. > > I am confused with Windows principals: > > [EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED] > kinit(v5): Client not found in Kerberos database while getting initial > credentials > > That is why I did: > > [EMAIL PROTECTED] /]$ kinit afs > Password for [EMAIL PROTECTED]: > > So I have a Windows "afs" user account that I ran: > > setspn -A afs/cs.unc.edu afs > > To Add/Associate a service principal to the Windows login > name. > > But I cannot kinit to afs/cs.unc.edu like I can > under MIT KRB5, (my CSX.UNC.EDU linux server): > > > |[EMAIL PROTECTED]:19% kinit afs/cs.unc.edu > Password for afs/[EMAIL PROTECTED]: > > > >> >> >> >> John W. Sopko Jr. wrote: >>> >>> Jeffrey Altman wrote: John W. Sopko Jr. wrote: > In C:\Program Files\Support Tools\ktpass > right click properties "version tab" shows 5.2.3790.1830 > > So use ktutil on the linux openafs server, setting the > password the same as the afs users Windows password: > > eagle/root [/usr/afs/etc] # ktutil > ktutil: add_entry -password -p afs/[EMAIL PROTECTED] -k 1 -e > des-cbc-crc Where did you get the key version number of 1 from? >>> When I ran the "bad" ktpass command on windows it always generates >>> kvno 1 >>> by default. The ktpass /? (help) says: >>> >>> kvno : Override Key Version Number >>>Default: query DC for kvno. Use /kvno 1 for Win2K compat. >>> >>> Since this Windows 2003 server is running in 2000 mixed mode I thought >>> it forced/kept the kvno at 1 for w2k compatability. Below is the >>> output of >>> the ktpass, no matter how many times I run it it keeps the "vno" >>> at 1. I check the keytab.mse file with ktutil and it is at 1. >>> >>> But you are right I do not know what is in the server. I did not >>> think hard enough about this. >>> The key version number must match the number that is actually issued by the KDC. You can identify the version number using the MIT Kerberos utility kvno >>> I tried this to get the kvno: >>> >>> eagle/root [/usr/afs/etc] # kinit afs >>> Password for [EMAIL PROTECTED]: >>> eagle/root [/usr/afs/etc] # kvno afs >>> [EMAIL PROTECTED]: kvno = 4 >>> >>> I then ran: >>> >>> ktutil> add_entry -password -p afs/[EMAIL PROTECTED] -k 4 -e >>> des-cbc-crc >>> ktutil> write_kt keytab.ktutil_generated >>> >>> /usr/sbin/asetkey add 4 keytab.ktutil_generated afs/cs.unc.edu >>> >>> /etc/init.d/openafs-server restart >>> >>> I now get the same error as Eric had: >>> >>> Jan 9 17:14:27 eagle kernel: afs: Tokens for user of AFS id 3903 for >>> cell cs.unc.edu are discarded (rxkad error=19270407) >>> >>> Do I need to map an account like Eric did with the "mapuser" option >>> to ktpass? >>> >>> >>> >>> >>> >>> The key version number must match the number that is actually issued by the KDC. You can identify the version number using the MIT Kerberos utility kvno > cell cs.unc.edu are discarded (rxkad error=19270408) The OpenAFS translate_et command will tell you this is because 19270408 = ticket contained unknown key version number > Windows Event Viewer, System log shows this, sometimes: > > While processing a TGS request for the target server > afs/cs.unc.edu, the > account [EMAIL PROTECTED] did not have a suitable key for > generating > a Kerberos ticket (the missing key has an ID of 8). The requested > etypes > were 2. The accounts available etypes were 3 1. What in the world is requesting a ticket with DES-CBC-MD4 ? > AM I CRAZY? > --- > > Once I get Windows AD working can I run both our current kaserver and > Windows AD authentication against our production cs.unc.edu openafs > cell > at the same time? If I can generate afs/cs.unc.edu service pincipals > with the same password on the kaserver and the AD server will this > work? > > This may be a good migration path for us. We currently have 2 password > databases, kaserver and Windows AD. When we create accounts we use the > same user login name for both wndows and linux. Most users keep their > passwords the same so logging into Windows gives them an afs token. >>
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Getting close, I can feel it: Verify Windows service account: --- C:\temp>setspn -L afs Registered ServicePrincipalNames for CN=afs service principal,CN=Users,DC=mse,DC =unccs,DC=test: afs/cs.unc.edu Change the Windows afs domain user password to a known password, this increments the kvno from 4 to 5. This is verified below. Create /usr/afs/etc/KeyFile with kvno 5: ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e des-cbc-crc Password for afs/[EMAIL PROTECTED]: ktutil: wkt keytab.ktutil eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil afs/[EMAIL PROTECTED] eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth key 5 has cksum 509175897 Keys last changed on Wed Jan 10 08:53:50 2007. All done. Get afs token and try afs access: - [EMAIL PROTECTED] /]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_3903_015mRF) Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 5 [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 01/10/07 08:56:28 01/10/07 18:56:06 afs/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ aklog -d Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu). We've deduced that we need to authenticate to realm MSE.UNCCS.TEST. Getting tickets: afs/[EMAIL PROTECTED] Using Kerberos V5 ticket natively About to resolve name sopko to id in cell cs.unc.edu. Id 3903 Set username to AFS ID 3903 Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST [EMAIL PROTECTED] /]$ tokens Tokens held by the Cache Manager: User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan 10 18:56] --End of list-- [EMAIL PROTECTED] /]$ ls /afs/cs.unc.edu/home ls: /afs/cs.unc.edu/home: Permission denied Jan 10 08:56:39 eagle kernel: afs: Tokens for user of AFS id 3903 for cell cs.unc.edu are discarded (rxkad error=19270407) eagle/root [/usr/afs/etc] # translate_et 19270407 19270407 (rxk).7 = security object was passed a bad ticket Jeffrey Altman wrote: Even assuming you wanted to kinit to your service principal you would have to so with the correct principal name afs/[EMAIL PROTECTED] != afs/[EMAIL PROTECTED] Your default realm name is CSX.UNC.EDU, not MSE.UNCCS.TEST. However, you don't want to be able to kinit to that service principal. What you want is to be able to obtain a service ticket for it using a client principal kvno afs/[EMAIL PROTECTED] obtains a service ticket for the specified principal name. Assuming the kvno is still 4 after you set the service principal name. You should try to authenticate to your AFS servers again. John W. Sopko Jr. wrote: Jeffrey Altman wrote: [EMAIL PROTECTED] != afs/[EMAIL PROTECTED] choose one and stick with it. I am confused with Windows principals: [EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED] kinit(v5): Client not found in Kerberos database while getting initial credentials That is why I did: [EMAIL PROTECTED] /]$ kinit afs Password for [EMAIL PROTECTED]: So I have a Windows "afs" user account that I ran: setspn -A afs/cs.unc.edu afs To Add/Associate a service principal to the Windows login name. But I cannot kinit to afs/cs.unc.edu like I can under MIT KRB5, (my CSX.UNC.EDU linux server): |[EMAIL PROTECTED]:19% kinit afs/cs.unc.edu Password for afs/[EMAIL PROTECTED]: John W. Sopko Jr. wrote: Jeffrey Altman wrote: John W. Sopko Jr. wrote: In C:\Program Files\Support Tools\ktpass right click properties "version tab" shows 5.2.3790.1830 So use ktutil on the linux openafs server, setting the password the same as the afs users Windows password: eagle/root [/usr/afs/etc] # ktutil ktutil: add_entry -password -p afs/[EMAIL PROTECTED] -k 1 -e des-cbc-crc Where did you get the key version number of 1 from? When I ran the "bad" ktpass command on windows it always generates kvno 1 by default. The ktpass /? (help) says: kvno : Override Key Version Number Default: query DC for kvno. Use /kvno 1 for Win2K compat. Since this Windows 2003 server is running in 2000 mixed mode I thought it forced/kept the kvno at 1 for w2k compatability. Below is the output of the ktpass, no matter
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
cs.unc.edu != mse.unccs.test Do you have the Kerberos realm specified in the afs/etc/krb.conf file? John W. Sopko Jr. wrote: > Getting close, I can feel it: > > Verify Windows service account: > --- > C:\temp>setspn -L afs > Registered ServicePrincipalNames for CN=afs service > principal,CN=Users,DC=mse,DC > =unccs,DC=test: > afs/cs.unc.edu > > Change the Windows afs domain user password to a known password, this > increments the kvno from 4 to 5. This is verified below. > > Create /usr/afs/etc/KeyFile with kvno 5: > > ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e des-cbc-crc > Password for afs/[EMAIL PROTECTED]: > ktutil: wkt keytab.ktutil > > eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil > afs/[EMAIL PROTECTED] > > eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth > key 5 has cksum 509175897 > Keys last changed on Wed Jan 10 08:53:50 2007. > All done. > > Get afs token and try afs access: > - > [EMAIL PROTECTED] /]$ klist > klist: No credentials cache found (ticket cache > FILE:/tmp/krb5cc_3903_015mRF) > > > Kerberos 4 ticket cache: /tmp/tkt3903 > klist: You have no tickets cached > > [EMAIL PROTECTED] /]$ kinit > Password for [EMAIL PROTECTED]: > > [EMAIL PROTECTED] /]$ klist > Ticket cache: FILE:/tmp/krb5cc_3903_015mRF > Default principal: [EMAIL PROTECTED] > > Valid starting ExpiresService principal > 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] > renew until 01/17/07 08:56:02 > > > Kerberos 4 ticket cache: /tmp/tkt3903 > klist: You have no tickets cached > > [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] > afs/[EMAIL PROTECTED]: kvno = 5 > > [EMAIL PROTECTED] /]$ klist > Ticket cache: FILE:/tmp/krb5cc_3903_015mRF > Default principal: [EMAIL PROTECTED] > > Valid starting ExpiresService principal > 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] > renew until 01/17/07 08:56:02 > 01/10/07 08:56:28 01/10/07 18:56:06 afs/[EMAIL PROTECTED] > renew until 01/17/07 08:56:02 > > > Kerberos 4 ticket cache: /tmp/tkt3903 > klist: You have no tickets cached > > [EMAIL PROTECTED] /]$ aklog -d > Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu). > We've deduced that we need to authenticate to realm MSE.UNCCS.TEST. > Getting tickets: afs/[EMAIL PROTECTED] > Using Kerberos V5 ticket natively > About to resolve name sopko to id in cell cs.unc.edu. > Id 3903 > Set username to AFS ID 3903 > Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST > [EMAIL PROTECTED] /]$ tokens > > Tokens held by the Cache Manager: > > User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan 10 18:56] >--End of list-- > > [EMAIL PROTECTED] /]$ ls /afs/cs.unc.edu/home > ls: /afs/cs.unc.edu/home: Permission denied > > Jan 10 08:56:39 eagle kernel: afs: Tokens for user of AFS id 3903 for > cell cs.unc.edu are discarded (rxkad error=19270407) > > eagle/root [/usr/afs/etc] # translate_et 19270407 > 19270407 (rxk).7 = security object was passed a bad ticket > > > Jeffrey Altman wrote: >> Even assuming you wanted to kinit to your service principal >> you would have to so with the correct principal name >> >> afs/[EMAIL PROTECTED] != afs/[EMAIL PROTECTED] >> >> Your default realm name is CSX.UNC.EDU, not MSE.UNCCS.TEST. >> >> However, you don't want to be able to kinit to that service >> principal. What you want is to be able to obtain a service >> ticket for it using a client principal >> >> kvno afs/[EMAIL PROTECTED] >> >> obtains a service ticket for the specified principal name. >> Assuming the kvno is still 4 after you set the service principal >> name. You should try to authenticate to your AFS servers again. >> >> >> John W. Sopko Jr. wrote: >>> Jeffrey Altman wrote: [EMAIL PROTECTED] != afs/[EMAIL PROTECTED] choose one and stick with it. >>> I am confused with Windows principals: >>> >>> [EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED] >>> kinit(v5): Client not found in Kerberos database while getting initial >>> credentials >>> >>> That is why I did: >>> >>> [EMAIL PROTECTED] /]$ kinit afs >>> Password for [EMAIL PROTECTED]: >>> >>> So I have a Windows "afs" user account that I ran: >>> >>> setspn -A afs/cs.unc.edu afs >>> >>> To Add/Associate a service principal to the Windows login >>> name. >>> >>> But I cannot kinit to afs/cs.unc.edu like I can >>> under MIT KRB5, (my CSX.UNC.EDU linux server): >>> >>> >>> |[EMAIL PROTECTED]:19% kinit afs/cs.unc.edu >>> Password for afs/[EMAIL PROTECTED]: >>> >>> >>> John W. Sopko Jr. wrote: > Jeffrey Altman wrote: >> John W. Sopko Jr. wrote: >> >>> In C:\Program Files\Support Tools\ktpass >>> right click properties "version tab" shows 5.2.3790.1830 >>> >>> So use ktutil on the linux openafs server, setting the >>> password the same as the afs users Windows password:
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Yes: eagle/root [/usr/afs/etc] # cat /usr/afs/etc/krb.conf MSE.UNCCS.TEST I tried making it lower case, restarting afs and that did not work either. Jeffrey Altman wrote: cs.unc.edu != mse.unccs.test Do you have the Kerberos realm specified in the afs/etc/krb.conf file? John W. Sopko Jr. wrote: Getting close, I can feel it: Verify Windows service account: --- C:\temp>setspn -L afs Registered ServicePrincipalNames for CN=afs service principal,CN=Users,DC=mse,DC =unccs,DC=test: afs/cs.unc.edu Change the Windows afs domain user password to a known password, this increments the kvno from 4 to 5. This is verified below. Create /usr/afs/etc/KeyFile with kvno 5: ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e des-cbc-crc Password for afs/[EMAIL PROTECTED]: ktutil: wkt keytab.ktutil eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil afs/[EMAIL PROTECTED] eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth key 5 has cksum 509175897 Keys last changed on Wed Jan 10 08:53:50 2007. All done. Get afs token and try afs access: - [EMAIL PROTECTED] /]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_3903_015mRF) Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 5 [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 01/10/07 08:56:28 01/10/07 18:56:06 afs/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ aklog -d Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu). We've deduced that we need to authenticate to realm MSE.UNCCS.TEST. Getting tickets: afs/[EMAIL PROTECTED] Using Kerberos V5 ticket natively About to resolve name sopko to id in cell cs.unc.edu. Id 3903 Set username to AFS ID 3903 Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST [EMAIL PROTECTED] /]$ tokens Tokens held by the Cache Manager: User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan 10 18:56] --End of list-- [EMAIL PROTECTED] /]$ ls /afs/cs.unc.edu/home ls: /afs/cs.unc.edu/home: Permission denied Jan 10 08:56:39 eagle kernel: afs: Tokens for user of AFS id 3903 for cell cs.unc.edu are discarded (rxkad error=19270407) eagle/root [/usr/afs/etc] # translate_et 19270407 19270407 (rxk).7 = security object was passed a bad ticket Jeffrey Altman wrote: Even assuming you wanted to kinit to your service principal you would have to so with the correct principal name afs/[EMAIL PROTECTED] != afs/[EMAIL PROTECTED] Your default realm name is CSX.UNC.EDU, not MSE.UNCCS.TEST. However, you don't want to be able to kinit to that service principal. What you want is to be able to obtain a service ticket for it using a client principal kvno afs/[EMAIL PROTECTED] obtains a service ticket for the specified principal name. Assuming the kvno is still 4 after you set the service principal name. You should try to authenticate to your AFS servers again. John W. Sopko Jr. wrote: Jeffrey Altman wrote: [EMAIL PROTECTED] != afs/[EMAIL PROTECTED] choose one and stick with it. I am confused with Windows principals: [EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED] kinit(v5): Client not found in Kerberos database while getting initial credentials That is why I did: [EMAIL PROTECTED] /]$ kinit afs Password for [EMAIL PROTECTED]: So I have a Windows "afs" user account that I ran: setspn -A afs/cs.unc.edu afs To Add/Associate a service principal to the Windows login name. But I cannot kinit to afs/cs.unc.edu like I can under MIT KRB5, (my CSX.UNC.EDU linux server): |[EMAIL PROTECTED]:19% kinit afs/cs.unc.edu Password for afs/[EMAIL PROTECTED]: John W. Sopko Jr. wrote: Jeffrey Altman wrote: John W. Sopko Jr. wrote: In C:\Program Files\Support Tools\ktpass right click properties "version tab" shows 5.2.3790.1830 So use ktutil on the linux openafs server, setting the password the same as the afs users Windows password: eagle/root [/usr/afs/etc] # ktutil ktutil: add_entry -password -p afs/[EMAIL PROTECTED] -k 1 -e des-cbc-crc Where did you get the key version number of 1 from? When I ran the "bad" ktpass command on windows it always generates kvno 1 by
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
It is the realm name which is upper-case. What does "klist -e" show for the ticket enc-types? John W. Sopko Jr. wrote: > Yes: > > eagle/root [/usr/afs/etc] # cat /usr/afs/etc/krb.conf > MSE.UNCCS.TEST > > I tried making it lower case, restarting afs and > that did not work either. > > > > Jeffrey Altman wrote: >> cs.unc.edu != mse.unccs.test >> >> Do you have the Kerberos realm specified in the >> >> afs/etc/krb.conf >> >> file? >> >> >> >> John W. Sopko Jr. wrote: >>> Getting close, I can feel it: >>> >>> Verify Windows service account: >>> --- >>> C:\temp>setspn -L afs >>> Registered ServicePrincipalNames for CN=afs service >>> principal,CN=Users,DC=mse,DC >>> =unccs,DC=test: >>> afs/cs.unc.edu >>> >>> Change the Windows afs domain user password to a known password, this >>> increments the kvno from 4 to 5. This is verified below. >>> >>> Create /usr/afs/etc/KeyFile with kvno 5: >>> >>> ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e des-cbc-crc >>> Password for afs/[EMAIL PROTECTED]: >>> ktutil: wkt keytab.ktutil >>> >>> eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil >>> afs/[EMAIL PROTECTED] >>> >>> eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth >>> key 5 has cksum 509175897 >>> Keys last changed on Wed Jan 10 08:53:50 2007. >>> All done. >>> >>> Get afs token and try afs access: >>> - >>> [EMAIL PROTECTED] /]$ klist >>> klist: No credentials cache found (ticket cache >>> FILE:/tmp/krb5cc_3903_015mRF) >>> >>> >>> Kerberos 4 ticket cache: /tmp/tkt3903 >>> klist: You have no tickets cached >>> >>> [EMAIL PROTECTED] /]$ kinit >>> Password for [EMAIL PROTECTED]: >>> >>> [EMAIL PROTECTED] /]$ klist >>> Ticket cache: FILE:/tmp/krb5cc_3903_015mRF >>> Default principal: [EMAIL PROTECTED] >>> >>> Valid starting ExpiresService principal >>> 01/10/07 08:56:02 01/10/07 18:56:06 >>> krbtgt/[EMAIL PROTECTED] >>> renew until 01/17/07 08:56:02 >>> >>> >>> Kerberos 4 ticket cache: /tmp/tkt3903 >>> klist: You have no tickets cached >>> >>> [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] >>> afs/[EMAIL PROTECTED]: kvno = 5 >>> >>> [EMAIL PROTECTED] /]$ klist >>> Ticket cache: FILE:/tmp/krb5cc_3903_015mRF >>> Default principal: [EMAIL PROTECTED] >>> >>> Valid starting ExpiresService principal >>> 01/10/07 08:56:02 01/10/07 18:56:06 >>> krbtgt/[EMAIL PROTECTED] >>> renew until 01/17/07 08:56:02 >>> 01/10/07 08:56:28 01/10/07 18:56:06 afs/[EMAIL PROTECTED] >>> renew until 01/17/07 08:56:02 >>> >>> >>> Kerberos 4 ticket cache: /tmp/tkt3903 >>> klist: You have no tickets cached >>> >>> [EMAIL PROTECTED] /]$ aklog -d >>> Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu). >>> We've deduced that we need to authenticate to realm MSE.UNCCS.TEST. >>> Getting tickets: afs/[EMAIL PROTECTED] >>> Using Kerberos V5 ticket natively >>> About to resolve name sopko to id in cell cs.unc.edu. >>> Id 3903 >>> Set username to AFS ID 3903 >>> Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST >>> [EMAIL PROTECTED] /]$ tokens >>> >>> Tokens held by the Cache Manager: >>> >>> User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan 10 18:56] >>>--End of list-- >>> >>> [EMAIL PROTECTED] /]$ ls /afs/cs.unc.edu/home >>> ls: /afs/cs.unc.edu/home: Permission denied >>> >>> Jan 10 08:56:39 eagle kernel: afs: Tokens for user of AFS id 3903 for >>> cell cs.unc.edu are discarded (rxkad error=19270407) >>> >>> eagle/root [/usr/afs/etc] # translate_et 19270407 >>> 19270407 (rxk).7 = security object was passed a bad ticket >>> >>> >>> Jeffrey Altman wrote: Even assuming you wanted to kinit to your service principal you would have to so with the correct principal name afs/[EMAIL PROTECTED] != afs/[EMAIL PROTECTED] Your default realm name is CSX.UNC.EDU, not MSE.UNCCS.TEST. However, you don't want to be able to kinit to that service principal. What you want is to be able to obtain a service ticket for it using a client principal kvno afs/[EMAIL PROTECTED] obtains a service ticket for the specified principal name. Assuming the kvno is still 4 after you set the service principal name. You should try to authenticate to your AFS servers again. John W. Sopko Jr. wrote: > Jeffrey Altman wrote: >> [EMAIL PROTECTED] != afs/[EMAIL PROTECTED] >> >> choose one and stick with it. > I am confused with Windows principals: > > [EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED] > kinit(v5): Client not found in Kerberos database while getting initial > credentials > > That is why I did: > > [EMAIL PROTECTED] /]$ kinit afs > Password for [EMAIL PROTECTED]: > > So I have a Windows "afs" user account that I ran: > > setspn -A afs/cs.unc.edu afs > > To Add/Associate a service principal
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
[EMAIL PROTECTED] /]$ klist -e Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 09:46:13 01/10/07 19:46:16 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 09:46:13, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 01/10/07 09:46:18 01/10/07 19:46:16 afs/[EMAIL PROTECTED] renew until 01/17/07 09:46:13, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with RSA-MD5 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached Jeffrey Altman wrote: It is the realm name which is upper-case. What does "klist -e" show for the ticket enc-types? John W. Sopko Jr. wrote: Yes: eagle/root [/usr/afs/etc] # cat /usr/afs/etc/krb.conf MSE.UNCCS.TEST I tried making it lower case, restarting afs and that did not work either. Jeffrey Altman wrote: cs.unc.edu != mse.unccs.test Do you have the Kerberos realm specified in the afs/etc/krb.conf file? John W. Sopko Jr. wrote: Getting close, I can feel it: Verify Windows service account: --- C:\temp>setspn -L afs Registered ServicePrincipalNames for CN=afs service principal,CN=Users,DC=mse,DC =unccs,DC=test: afs/cs.unc.edu Change the Windows afs domain user password to a known password, this increments the kvno from 4 to 5. This is verified below. Create /usr/afs/etc/KeyFile with kvno 5: ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e des-cbc-crc Password for afs/[EMAIL PROTECTED]: ktutil: wkt keytab.ktutil eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil afs/[EMAIL PROTECTED] eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth key 5 has cksum 509175897 Keys last changed on Wed Jan 10 08:53:50 2007. All done. Get afs token and try afs access: - [EMAIL PROTECTED] /]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_3903_015mRF) Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 5 [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 01/10/07 08:56:28 01/10/07 18:56:06 afs/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ aklog -d Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu). We've deduced that we need to authenticate to realm MSE.UNCCS.TEST. Getting tickets: afs/[EMAIL PROTECTED] Using Kerberos V5 ticket natively About to resolve name sopko to id in cell cs.unc.edu. Id 3903 Set username to AFS ID 3903 Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST [EMAIL PROTECTED] /]$ tokens Tokens held by the Cache Manager: User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan 10 18:56] --End of list-- [EMAIL PROTECTED] /]$ ls /afs/cs.unc.edu/home ls: /afs/cs.unc.edu/home: Permission denied Jan 10 08:56:39 eagle kernel: afs: Tokens for user of AFS id 3903 for cell cs.unc.edu are discarded (rxkad error=19270407) eagle/root [/usr/afs/etc] # translate_et 19270407 19270407 (rxk).7 = security object was passed a bad ticket Jeffrey Altman wrote: Even assuming you wanted to kinit to your service principal you would have to so with the correct principal name afs/[EMAIL PROTECTED] != afs/[EMAIL PROTECTED] Your default realm name is CSX.UNC.EDU, not MSE.UNCCS.TEST. However, you don't want to be able to kinit to that service principal. What you want is to be able to obtain a service ticket for it using a client principal kvno afs/[EMAIL PROTECTED] obtains a service ticket for the specified principal name. Assuming the kvno is still 4 after you set the service principal name. You should try to authenticate to your AFS servers again. John W. Sopko Jr. wrote: Jeffrey Altman wrote: [EMAIL PROTECTED] != afs/[EMAIL PROTECTED] choose one and stick with it. I am confused with Windows principals: [EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED] kinit(v5): Client not found in Kerberos database while getting initial credentials That is why I did: [EMAIL PROTECTED] /]$ kinit afs Password for [EMAIL PROTECTED]: So I have a Windows "afs" user account that I ran: setspn -A afs/cs.unc.edu afs To Add/Associate a service principal to
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
I think the problem is the afs/cs.unc.edu service key is the wrong encryption type even thought I checked the "Use DES encryption type for this account" in the gui. IT is using DES but with RSA-MD5 as shown in kinit -e. So I tried to change the principal account to use only plain DES-CBC-CRC. I try using the ktpass command shown below to change the password but it does not work. I still get the old kvno 5 and the encryption type does not change. Note I have to use the /ptype option else ktpass complains and will not work: C:\temp>ktpass -out keytab -princ afs/[EMAIL PROTECTED] -kvno 9 -cryptoDES-CBC-CRC -DesOnly -pass * /ptype KRB5_NT_PRINCIPAL NOTE: creating a keytab but not mapping principal to any user. For the account to work within a Windows domain, the principal must be mapped to an account, either at the domain level (with /mapuser) or locally (using ksetup) If you intend to map afs/[EMAIL PROTECTED] to an account through o ther means or don't need to map the user, this message can safely be ignored. Type the password for afs/cs.unc.edu: Type the password again to confirm: WARNING: pType and account type do not match. This might cause problems. Key created. Output keytab to keytab: Keytab version: 0x502 keysize 56 afs/[EMAIL PROTECTED] ptype 1 (KRB5_NT_PRINCIPAL) vno 9 etype 0x1 (DES-CBC-CRC) keylength 8 (0x92252f9240922516) [EMAIL PROTECTED] /]$ kdestroy [EMAIL PROTECTED] /]$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 5 [EMAIL PROTECTED] /]$ klist -e Ticket cache: FILE:/tmp/krb5cc_3903_RpApLt Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 11:49:24 01/10/07 21:49:26 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 11:49:24, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 01/10/07 11:49:31 01/10/07 21:49:26 afs/[EMAIL PROTECTED] renew until 01/17/07 11:49:24, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with RSA-MD5 John W. Sopko Jr. wrote: [EMAIL PROTECTED] /]$ klist -e Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 09:46:13 01/10/07 19:46:16 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 09:46:13, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 01/10/07 09:46:18 01/10/07 19:46:16 afs/[EMAIL PROTECTED] renew until 01/17/07 09:46:13, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with RSA-MD5 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached Jeffrey Altman wrote: It is the realm name which is upper-case. What does "klist -e" show for the ticket enc-types? John W. Sopko Jr. wrote: Yes: eagle/root [/usr/afs/etc] # cat /usr/afs/etc/krb.conf MSE.UNCCS.TEST I tried making it lower case, restarting afs and that did not work either. Jeffrey Altman wrote: cs.unc.edu != mse.unccs.test Do you have the Kerberos realm specified in the afs/etc/krb.conf file? John W. Sopko Jr. wrote: Getting close, I can feel it: Verify Windows service account: --- C:\temp>setspn -L afs Registered ServicePrincipalNames for CN=afs service principal,CN=Users,DC=mse,DC =unccs,DC=test: afs/cs.unc.edu Change the Windows afs domain user password to a known password, this increments the kvno from 4 to 5. This is verified below. Create /usr/afs/etc/KeyFile with kvno 5: ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e des-cbc-crc Password for afs/[EMAIL PROTECTED]: ktutil: wkt keytab.ktutil eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil afs/[EMAIL PROTECTED] eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth key 5 has cksum 509175897 Keys last changed on Wed Jan 10 08:53:50 2007. All done. Get afs token and try afs access: - [EMAIL PROTECTED] /]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_3903_015mRF) Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 5 [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 01/10/07 08:56:28 01/10/07 18:56:06 afs/[EMAIL PROTECT
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
DES-CBC-CRC and DES-CBC-MD5 use the same DES key and DES-CBC-MD5 is supported by OpenAFS 1.4.x. That is not your problem. There are many reasons a bad ticket error can be produced. One is that the stored key doesn't match the one used to encrypt the server portion of the service ticket. The problem could be the salt used when generating the key from the password. Look back in this thread for e-mails from Doug describing how to check the salt and from Marcus on how to test that your key is valid. John W. Sopko Jr. wrote: > I think the problem is the afs/cs.unc.edu service key > is the wrong encryption type even thought I checked the > "Use DES encryption type for this account" in the gui. > IT is using DES but with RSA-MD5 as shown in kinit -e. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Its all about the salt -- When DES is used with Krb5 a des key is generated by concatenating the password with the salt, and calling des_string_to_key So the only way to really know what the key is is to know thew password and the salt. The salt is normally derived from the principal by concatenating the realm and the components of the name without the /or @. Thus if the principal name was afs/[EMAIL PROTECTED] and the password was newpasswd the DES key would be generated from the string "newpasswdMSE.UNCCS.TESTafscs.unc.edu" Most of the Krb5 commands take care of the salt for you. Each principal has a key stored in the KDC, generated when the password was changed. *BUT* Microsoft implemented Kerberos a little differently: * They do not store a key, but store a password and generate the key on the fly as needed. With DES this requires the salt. * They store the password with the account. * Each account can have a UserPrincipalName and several ServicePrincipalNames. They did not use the correct salt from the principal, with W2k but used the SamAccountName (without the $) and the upper case DomainName. For normal users this would match krb5 way of using the salt, but not for a service principal. Thus all the service principals on an account have the same key. I believe in W2k3 they started generating the salt from the UPN. So where does this leave us,and how can we get around it? (msktutil is one way.) Another way is to create the AD account, and add the SPN, and set the password to something known. The salt can then be determened from the UPN, of to *really* be sure, do a network trace of the KRB5_ERROR packet returned when you do a kinit afs/[EMAIL PROTECTED] Then drill down in the e-data till you find the salt for DES. Then forget about asetkey, and use the AFS "bos_util adddes" command instead, to add the key to the keytab. Since bos_util was designed for Krb4 where no salt was used for DES we can in effect concatenate the password and the salt used in AD and use this as the password to bos_util adddes! Best to test this first on a non-server machine as bos_util wants to update the /usr/afs/etc/KeyTab file. John W. Sopko Jr. wrote: Getting close, I can feel it: Verify Windows service account: --- C:\temp>setspn -L afs Registered ServicePrincipalNames for CN=afs service principal,CN=Users,DC=mse,DC =unccs,DC=test: afs/cs.unc.edu Change the Windows afs domain user password to a known password, this increments the kvno from 4 to 5. This is verified below. Create /usr/afs/etc/KeyFile with kvno 5: ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e des-cbc-crc Password for afs/[EMAIL PROTECTED]: ktutil: wkt keytab.ktutil eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil afs/[EMAIL PROTECTED] eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth key 5 has cksum 509175897 Keys last changed on Wed Jan 10 08:53:50 2007. All done. Get afs token and try afs access: - [EMAIL PROTECTED] /]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_3903_015mRF) Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kinit Password for [EMAIL PROTECTED]: [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 5 [EMAIL PROTECTED] /]$ klist Ticket cache: FILE:/tmp/krb5cc_3903_015mRF Default principal: [EMAIL PROTECTED] Valid starting ExpiresService principal 01/10/07 08:56:02 01/10/07 18:56:06 krbtgt/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 01/10/07 08:56:28 01/10/07 18:56:06 afs/[EMAIL PROTECTED] renew until 01/17/07 08:56:02 Kerberos 4 ticket cache: /tmp/tkt3903 klist: You have no tickets cached [EMAIL PROTECTED] /]$ aklog -d Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu). We've deduced that we need to authenticate to realm MSE.UNCCS.TEST. Getting tickets: afs/[EMAIL PROTECTED] Using Kerberos V5 ticket natively About to resolve name sopko to id in cell cs.unc.edu. Id 3903 Set username to AFS ID 3903 Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST [EMAIL PROTECTED] /]$ tokens Tokens held by the Cache Manager: User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan 10 18:56] --End of list-- [EMAIL PROTECTED] /]$ ls /afs/cs.unc.edu/home ls: /afs/cs.unc.edu/home: Permission denied Jan 10 08:56:39 eagle kernel: afs: Tokens for user of AFS id 3903 for cell cs.unc.edu are discarded (rxkad error=19270407) eagle/root [/usr/afs/etc] # translate_et 19270407 19270407 (rxk).7 = secur
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Douglas E. Engert wrote: Its all about the salt -- When DES is used with Krb5 a des key is generated by concatenating the password with the salt, and calling des_string_to_key So the only way to really know what the key is is to know thew password and the salt. The salt is normally derived from the principal by concatenating the realm and the components of the name without the /or @. Thus if the principal name was afs/[EMAIL PROTECTED] and the password was newpasswd the DES key would be generated from the string "newpasswdMSE.UNCCS.TESTafscs.unc.edu" Most of the Krb5 commands take care of the salt for you. Each principal has a key stored in the KDC, generated when the password was changed. *BUT* Microsoft implemented Kerberos a little differently: * They do not store a key, but store a password and generate the key on the fly as needed. With DES this requires the salt. * They store the password with the account. * Each account can have a UserPrincipalName and several ServicePrincipalNames. They did not use the correct salt from the principal, with W2k but used the SamAccountName (without the $) and the upper case DomainName. For normal users this would match krb5 way of using the salt, but not for a service principal. Thus all the service principals on an account have the same key. I believe in W2k3 they started generating the salt from the UPN. So where does this leave us,and how can we get around it? (msktutil is one way.) I really did not think it would be this complex to generate a Windows service principal and corresponding /usr/afs/etc/KeyFile. I think the best route is to try windows ktpass again. The thing I do not understand is; you create a Windows domain account and then use setspn to add the afs/cs.unc.edu service principal. (Or I found the service principal gets added if you use the "-mapuser" option to ktpass). Then if I use ktpass to set the password, kvno and generate a keytab, neither the password or the kvno change for afs/cs.unc.edu service principal. I thought ktpass was supposed to do what MIT "kadmin ktadd" does, change the principals password and dump the key to a keytab so they matched. Maybe this is the problem with the "bad" ktpass version. At this point I am confused with ktpass, I read the microsoft docs: http://technet2.microsoft.com/WindowsServer/en/library/a412a943-4567-4674-9015-fe1b7bf0228c1033.mspx?mfr=true For example I re-created my domain account as AFS.CS.UNC.EDU and the ran ktpass like this: ktpass -out keytab -princ afs/[EMAIL PROTECTED] -kvno 7 -crypto DES-CBC-CRC -DesOnly -pass * -mapuser AFS.CS.UNC.EDU the -mapuser option adds the afs/cs.unc.edu service to the user account. You can verify this with setspn -L AFS.CS.UNC.EDU, I did not need to run the Windows "setspn -A afs/cs.unc.edu AFS.CS.UNC.EDU" command, (FYI). The kvno will always default to 1 if you do not specify it. But after I run this I run "kvno afs/cs.unc.edu @MSE.UNCCS.TEST" and the kvno is not 7. The kvno only increments if you change the password for the domain user, in this case AFS.CS.UNC.EDU. At this point I am not sure if there is one password for the user accunt and one for the service principal or if they are one and the same. I do not know where to get a "good" version of ktpass. I will ask our Windows guy, I searched Microsoft and they only have the SP1 version. Another way is to create the AD account, and add the SPN, and set the password to something known. The salt can then be determened from the UPN, I can try this for fun but we really need simpler solution. What do I run to determine this? of to *really* be sure, do a network trace of the KRB5_ERROR packet returned when you do a kinit afs/[EMAIL PROTECTED] Then drill down in the e-data till you find the salt for DES. Here it is, don't know how to decode the salt info, I got this using the command: /usr/sbin/tshark -V host eagle or host madison-cs and port 88 host eagle is the afs server, host madison-cs the Windows AD server. e-data padata: PA-ENCTYPE-INFO Type: PA-ENCTYPE-INFO (11) Value: 304E3025A003020103A11E041C4D53452E554E4343532E54... des-cbc-md5 des-cbc-crc Encryption type: des-cbc-md5 (3) Salt: 4D53452E554E4343532E544553544146532E43532E554E43... Encryption type: des-cbc-crc (1) Salt: 4D53452E554E4343532E544553544146532E43532E554E43... Then forget about asetkey, and use the AFS "bos_util adddes" command instead, to add the key to the keytab. Since bos_util was designed for Krb4 where no salt was used for DES we can in effect concatenate the password and the salt used in AD and use this as the password to bos_util adddes! Best to test this first on a non-server machine as bos_util wants to update the /usr/afs/etc/KeyTab file. If you can give me the password string to give bos_util I will try it, that is I will enter my known password I just need the other string/salt info. T
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
The -kvno option of ktpass is only to be used if you are generating a keytab entry to be used in conjunction with a Windows 2000 server. Do not use it if you are using a Windows 2003 server. The hex string that is specified as the Salt is just that a hex string. Convert the hex to ASCII characters. 4D 53 45 2E 55 4E 43 43 53 2E 54 45 53 54 41 46 53 2E 43 53 2E 55 ... M S E . U N C C S . T E S T A F S . C S . U ... smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
The Windows XP SP2 version of ktpass.exe can be found as part of the Support Tools pack: http://www.microsoft.com/downloads/details.aspx?familyid=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Jeffrey Altman wrote: The -kvno option of ktpass is only to be used if you are generating a keytab entry to be used in conjunction with a Windows 2000 server. Do not use it if you are using a Windows 2003 server. Then how do you get the kvno in the account and the keytab to match? Also as far as I can tell ktpass does not change the account password. The hex string that is specified as the Salt is just that a hex string. Convert the hex to ASCII characters. 4D 53 45 2E 55 4E 43 43 53 2E 54 45 53 54 41 46 53 2E 43 53 2E 55 ... M S E . U N C C S . T E S T A F S . C S . U ... -- 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 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
John W. Sopko Jr. wrote: I really did not think it would be this complex to generate a Windows service principal and corresponding /usr/afs/etc/KeyFile. No it should not be, but then again Microsoft did some things early on that did not follow the Kerberos conversions, including not using kvnos. We are living with thuse early decisions. think the best route is to try windows ktpass again. The thing I do not understand is; you create a Windows domain account and then use setspn to add the afs/cs.unc.edu service principal. (Or I found the service principal gets added if you use the "-mapuser" option to ktpass). Then if I use ktpass to set the password, kvno and generate a keytab, neither the password or the kvno change for afs/cs.unc.edu service principal. I thought ktpass was supposed to do what MIT "kadmin ktadd" does, change the principals password and dump the key to a keytab so they matched. Maybe this is the problem with the "bad" ktpass version. You have to have admin privilages in AD to change the enties, although a user can change thier own password, but I don't thin ktpass is doing that. At this point I am confused with ktpass, I read the microsoft docs: http://technet2.microsoft.com/WindowsServer/en/library/a412a943-4567-4674-9015-fe1b7bf0228c1033.mspx?mfr=true The only comment on this is the statememt: "You cannot map multiple service instances to the same user account." You can have multiple SPNs, but ktpass appearently can not handle it. For example I re-created my domain account as AFS.CS.UNC.EDU and the ran ktpass like this: ktpass -out keytab -princ afs/[EMAIL PROTECTED] -kvno 7 -crypto DES-CBC-CRC -DesOnly -pass * -mapuser AFS.CS.UNC.EDU the -mapuser option adds the afs/cs.unc.edu service to the user account. You can verify this with setspn -L AFS.CS.UNC.EDU, I did not need to run the Windows "setspn -A afs/cs.unc.edu AFS.CS.UNC.EDU" command, (FYI). The kvno will always default to 1 if you do not specify it. But after I run this I run "kvno afs/cs.unc.edu @MSE.UNCCS.TEST" and the kvno is not 7. The kvno only increments if you change the password for the domain user, in this case AFS.CS.UNC.EDU. Yes, one password per account, and the kvno is stored in the account as msDS-KeyVersionNumber with ( mmc and the ADSI plugin you can look at the AD entries.) At this point I am not sure if there is one password for the user accunt and one for the service principal or if they are one and the same. They are the same. I do not know where to get a "good" version of ktpass. I will ask our Windows guy, I searched Microsoft and they only have the SP1 version. Asw I said there is the other way, to avoid ktpass and asetkey. Another way is to create the AD account, and add the SPN, and set the password to something known. The salt can then be determened from the UPN, I can try this for fun but we really need simpler solution. msktutil we used this for unix hosts too. What do I run to determine this? You AD dmin can look at te entry. You as a user can run on the mmc command, then use the ADSI Edit plugin to look at your domain. of to *really* be sure, do a network trace of the KRB5_ERROR packet returned when you do a kinit afs/[EMAIL PROTECTED] Then drill down in the e-data till you find the salt for DES. Here it is, don't know how to decode the salt info, I got this using the command: /usr/sbin/tshark -V host eagle or host madison-cs and port 88 host eagle is the afs server, host madison-cs the Windows AD server. e-data padata: PA-ENCTYPE-INFO Type: PA-ENCTYPE-INFO (11) Value: 304E3025A003020103A11E041C4D53452E554E4343532E54... des-cbc-md5 des-cbc-crc Encryption type: des-cbc-md5 (3) Salt: 4D53452E554E4343532E544553544146532E43532E554E43... OK this is the salt! Its in asci, so: 4D 53 45 2E 55 4E 43 43 53 2E 54 45 53 54 41 46 53 2E 43 53 2E 55 4E 43... M S E . U N C C S . T E S T A F S . C S . U N C ... So this look like it is taking the realm(MSE.UNCCS.TEST) and the SamAccountName AFS.CS.UNC... and using these as the salt. (I assume the ... would be .EDU from uyourother messages. Encryption type: des-cbc-crc (1) Salt: 4D53452E554E4343532E544553544146532E43532E554E43... Then forget about asetkey, and use the AFS "bos_util adddes" command instead, to add the key to the keytab. Since bos_util was designed for Krb4 where no salt was used for DES we can in effect concatenate the password and the salt used in AD and use this as the password to bos_util adddes! Best to test this first on a non-server machine as bos_util wants to update the /usr/afs/etc/KeyTab file. If you can give me the password string to give bos_util I will try it, that is I will enter my known password I just need the other string/salt info. From the above message it looks like you would concatenate to the known password MSE.UNCCS.TESTA
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
John W. Sopko Jr. wrote: > > > Jeffrey Altman wrote: >> The -kvno option of ktpass is only to be used if you are generating >> a keytab entry to be used in conjunction with a Windows 2000 server. >> Do not use it if you are using a Windows 2003 server. > > Then how do you get the kvno in the account and the keytab to match? If you goal is to try to change the password, then the key version number you specify is not going to match the one in the active directory database. The default behavior of ktpass is to query the DC to obtain the kvno. It will use the correct version. The password field is optional. You don't have to specify it. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
I tried and it did not work, am I missing something? My linux server is a test server, I can do anything on it: Verify kvno of service principal: [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 2 I have admin rights on the AD, it also is a test server. I loaded the Active Directory ADSI Edit snapin and examined the Domain user AFS.CS.UNC.EDU everything looks in order, I think: sAMAccountName AFS.CS.UNC.EDU servicePrincipalName afs/cs.unc.edu msDS-KeyVersionNumber 2 userPrincipalName afs/[EMAIL PROTECTED] I then did this on the linux/afs server: eagle/root [/usr/afs/etc] # /bin/rm KeyFile eagle/root [/usr/afs/etc] # ../bin/bos_util adddes 2 input key: Retype input key: eagle/root [/usr/afs/etc] # /etc/init.d/openafs-server restart Stopping openafs-server: [ OK ] Starting openafs-server: Using an input key of: win_passwordMSE.UNCCS.TESTAFS.CS.UNC.EDU win_password = password set for Domain user AFS.CS.UNC.EDU Douglas E. Engert wrote: John W. Sopko Jr. wrote: I really did not think it would be this complex to generate a Windows service principal and corresponding /usr/afs/etc/KeyFile. No it should not be, but then again Microsoft did some things early on that did not follow the Kerberos conversions, including not using kvnos. We are living with thuse early decisions. think the best route is to try windows ktpass again. The thing I do not understand is; you create a Windows domain account and then use setspn to add the afs/cs.unc.edu service principal. (Or I found the service principal gets added if you use the "-mapuser" option to ktpass). Then if I use ktpass to set the password, kvno and generate a keytab, neither the password or the kvno change for afs/cs.unc.edu service principal. I thought ktpass was supposed to do what MIT "kadmin ktadd" does, change the principals password and dump the key to a keytab so they matched. Maybe this is the problem with the "bad" ktpass version. You have to have admin privilages in AD to change the enties, although a user can change thier own password, but I don't thin ktpass is doing that. At this point I am confused with ktpass, I read the microsoft docs: http://technet2.microsoft.com/WindowsServer/en/library/a412a943-4567-4674-9015-fe1b7bf0228c1033.mspx?mfr=true The only comment on this is the statememt: "You cannot map multiple service instances to the same user account." You can have multiple SPNs, but ktpass appearently can not handle it. For example I re-created my domain account as AFS.CS.UNC.EDU and the ran ktpass like this: ktpass -out keytab -princ afs/[EMAIL PROTECTED] -kvno 7 -crypto DES-CBC-CRC -DesOnly -pass * -mapuser AFS.CS.UNC.EDU the -mapuser option adds the afs/cs.unc.edu service to the user account. You can verify this with setspn -L AFS.CS.UNC.EDU, I did not need to run the Windows "setspn -A afs/cs.unc.edu AFS.CS.UNC.EDU" command, (FYI). The kvno will always default to 1 if you do not specify it. But after I run this I run "kvno afs/cs.unc.edu @MSE.UNCCS.TEST" and the kvno is not 7. The kvno only increments if you change the password for the domain user, in this case AFS.CS.UNC.EDU. Yes, one password per account, and the kvno is stored in the account as msDS-KeyVersionNumber with ( mmc and the ADSI plugin you can look at the AD entries.) At this point I am not sure if there is one password for the user accunt and one for the service principal or if they are one and the same. They are the same. I do not know where to get a "good" version of ktpass. I will ask our Windows guy, I searched Microsoft and they only have the SP1 version. Asw I said there is the other way, to avoid ktpass and asetkey. Another way is to create the AD account, and add the SPN, and set the password to something known. The salt can then be determened from the UPN, I can try this for fun but we really need simpler solution. msktutil we used this for unix hosts too. What do I run to determine this? You AD dmin can look at te entry. You as a user can run on the mmc command, then use the ADSI Edit plugin to look at your domain. of to *really* be sure, do a network trace of the KRB5_ERROR packet returned when you do a kinit afs/[EMAIL PROTECTED] Then drill down in the e-data till you find the salt for DES. Here it is, don't know how to decode the salt info, I got this using the command: /usr/sbin/tshark -V host eagle or host madison-cs and port 88 host eagle is the afs server, host madison-cs the Windows AD server. e-data padata: PA-ENCTYPE-INFO Type: PA-ENCTYPE-INFO (11) Value: 304E3025A003020103A11E041C4D53452E554E4343532E54... des-cbc-md5 des-cbc-crc Encryption type: des-cbc-md5 (3) Salt: 4D53452E554E4343532E544553544146532E43532E554E43... OK this is the salt! Its in asci, so: 4D 53 45 2E 55 4E 43 43 53 2E 54 45 53 54 41 46 53 2E 43 53 2E 55 4E 43... M S E . U N C C S . T E S T A F S .
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
John W. Sopko Jr. wrote: I tried and it did not work, am I missing something? My linux server is a test server, I can do anything on it: Verify kvno of service principal: [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 2 I have admin rights on the AD, it also is a test server. I loaded the Active Directory ADSI Edit snapin and examined the Domain user AFS.CS.UNC.EDU everything looks in order, I think: sAMAccountName AFS.CS.UNC.EDU servicePrincipalName afs/cs.unc.edu msDS-KeyVersionNumber 2 userPrincipalName afs/[EMAIL PROTECTED] The only thing I can see is that in the trace you ran the other day you where referring to kvno 7. Today it says kvno 2. Did you recreate the account and reset the password? If so can you run the trace again and make sure it is not using a different salt? I then did this on the linux/afs server: eagle/root [/usr/afs/etc] # /bin/rm KeyFile eagle/root [/usr/afs/etc] # ../bin/bos_util adddes 2 input key: Retype input key: eagle/root [/usr/afs/etc] # /etc/init.d/openafs-server restart Stopping openafs-server: [ OK ] Starting openafs-server: Using an input key of: win_passwordMSE.UNCCS.TESTAFS.CS.UNC.EDU That looks correct, based on the trace from the other day I assume using: kinit afs/[EMAIL PROTECTED] But it looks like you recreated the account, I would run the trace again. On my system I see the salt as derived from the UPN, ANL.GOVafsanl.gov SO try: win_passwordMSE.UNCCS.TESTafscs.unc.edu (Case sensitive, no @ or / with the realm first.) win_password = password set for Domain user AFS.CS.UNC.EDU Douglas E. Engert wrote: John W. Sopko Jr. wrote: I really did not think it would be this complex to generate a Windows service principal and corresponding /usr/afs/etc/KeyFile. No it should not be, but then again Microsoft did some things early on that did not follow the Kerberos conversions, including not using kvnos. We are living with thuse early decisions. think the best route is to try windows ktpass again. The thing I do not understand is; you create a Windows domain account and then use setspn to add the afs/cs.unc.edu service principal. (Or I found the service principal gets added if you use the "-mapuser" option to ktpass). Then if I use ktpass to set the password, kvno and generate a keytab, neither the password or the kvno change for afs/cs.unc.edu service principal. I thought ktpass was supposed to do what MIT "kadmin ktadd" does, change the principals password and dump the key to a keytab so they matched. Maybe this is the problem with the "bad" ktpass version. You have to have admin privilages in AD to change the enties, although a user can change thier own password, but I don't thin ktpass is doing that. At this point I am confused with ktpass, I read the microsoft docs: http://technet2.microsoft.com/WindowsServer/en/library/a412a943-4567-4674-9015-fe1b7bf0228c1033.mspx?mfr=true The only comment on this is the statememt: "You cannot map multiple service instances to the same user account." You can have multiple SPNs, but ktpass appearently can not handle it. For example I re-created my domain account as AFS.CS.UNC.EDU and the ran ktpass like this: ktpass -out keytab -princ afs/[EMAIL PROTECTED] -kvno 7 -crypto DES-CBC-CRC -DesOnly -pass * -mapuser AFS.CS.UNC.EDU the -mapuser option adds the afs/cs.unc.edu service to the user account. You can verify this with setspn -L AFS.CS.UNC.EDU, I did not need to run the Windows "setspn -A afs/cs.unc.edu AFS.CS.UNC.EDU" command, (FYI). The kvno will always default to 1 if you do not specify it. But after I run this I run "kvno afs/cs.unc.edu @MSE.UNCCS.TEST" and the kvno is not 7. The kvno only increments if you change the password for the domain user, in this case AFS.CS.UNC.EDU. Yes, one password per account, and the kvno is stored in the account as msDS-KeyVersionNumber with ( mmc and the ADSI plugin you can look at the AD entries.) At this point I am not sure if there is one password for the user accunt and one for the service principal or if they are one and the same. They are the same. I do not know where to get a "good" version of ktpass. I will ask our Windows guy, I searched Microsoft and they only have the SP1 version. Asw I said there is the other way, to avoid ktpass and asetkey. Another way is to create the AD account, and add the SPN, and set the password to something known. The salt can then be determened from the UPN, I can try this for fun but we really need simpler solution. msktutil we used this for unix hosts too. What do I run to determine this? You AD dmin can look at te entry. You as a user can run on the mmc command, then use the ADSI Edit plugin to look at your domain. of to *really* be sure, do a network trace of the KRB5_ERROR packet returned when you do a kinit afs/[EMAIL PROTECTED] Then drill down in the e-data till you find the salt for DES. Here it is, don't know how to dec
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Douglas E. Engert wrote: John W. Sopko Jr. wrote: I tried and it did not work, am I missing something? My linux server is a test server, I can do anything on it: Verify kvno of service principal: [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] afs/[EMAIL PROTECTED]: kvno = 2 I have admin rights on the AD, it also is a test server. I loaded the Active Directory ADSI Edit snapin and examined the Domain user AFS.CS.UNC.EDU everything looks in order, I think: sAMAccountName AFS.CS.UNC.EDU servicePrincipalName afs/cs.unc.edu msDS-KeyVersionNumber 2 userPrincipalName afs/[EMAIL PROTECTED] The only thing I can see is that in the trace you ran the other day you where referring to kvno 7. Today it says kvno 2. Did you recreate the account and reset the password? If so can you run the trace again and make sure it is not using a different salt? Originally the sAMAccountName was afs, I deleted that account and started over using sAMAccountName=AFS.CS.UNC.EDU, the trace yesterday was using the AFS.CS.UNC.EDU account and that is what the tshark trace showed. The kvno is 2 for sure as proved aboce. I just ran this, the -x option prints the the frame in ascii: eagle/root [/usr/afs/etc] # /usr/sbin/tshark -V -x port 88 Value: 304E3025A003020103A11E041C4D53452E554E4343532E54... des-cbc-md5 des-cbc-crc Encryption type: des-cbc-md5 (3) Salt: 4D53452E554E4343532E544553544146532E43532E554E43... Encryption type: des-cbc-crc (1) Salt: 4D53452E554E4343532E544553544146532E43532E554E43... Type: PA-ENC-TIMESTAMP (2) Type: PA-PK-AS-REP (15) 00 02 55 e1 d4 3a 00 d0 00 0f 34 00 08 00 45 00 ..U..:4...E. 0010 00 f8 c1 08 00 00 7f 11 ad 7d c0 a8 f3 0a 98 02 .}.. 0020 80 b9 00 58 ca 18 00 e4 97 2c 7e 81 d9 30 81 d6 ...X.,~..0.. 0030 a0 03 02 01 05 a1 03 02 01 1e a4 11 18 0f 32 30 ..20 0040 30 37 30 31 31 31 31 36 32 34 32 32 5a a5 04 02 07062422Z... 0050 02 4d 30 a6 03 02 01 19 a9 10 1b 0e 4d 53 45 2e .M0.MSE. 0060 55 4e 43 43 53 2e 54 45 53 54 aa 23 30 21 a0 03 UNCCS.TEST.#0!.. 0070 02 01 00 a1 1a 30 18 1b 06 6b 72 62 74 67 74 1b .0...krbtgt. 0080 0e 4d 53 45 2e 55 4e 43 43 53 2e 54 45 53 54 ac .MSE.UNCCS.TEST. 0090 75 04 73 30 71 30 59 a1 03 02 01 0b a2 52 04 50 u.s0q0Y..R.P 00a0 30 4e 30 25 a0 03 02 01 03 a1 1e 04 1c 4d 53 45 0N0%.MSE 00b0 2e 55 4e 43 43 53 2e 54 45 53 54 41 46 53 2e 43 .UNCCS.TESTAFS.C 00c0 53 2e 55 4e 43 2e 45 44 55 30 25 a0 03 02 01 01 S.UNC.EDU0%. 00d0 a1 1e 04 1c 4d 53 45 2e 55 4e 43 43 53 2e 54 45 MSE.UNCCS.TE 00e0 53 54 41 46 53 2e 43 53 2e 55 4e 43 2e 45 44 55 STAFS.CS.UNC.EDU 00f0 30 09 a1 03 02 01 02 a2 02 04 00 30 09 a1 03 02 0..0 0100 01 0f a2 02 04 00 .. I then did this on the linux/afs server: eagle/root [/usr/afs/etc] # /bin/rm KeyFile eagle/root [/usr/afs/etc] # ../bin/bos_util adddes 2 input key: Retype input key: eagle/root [/usr/afs/etc] # /etc/init.d/openafs-server restart Stopping openafs-server: [ OK ] Starting openafs-server: Using an input key of: win_passwordMSE.UNCCS.TESTAFS.CS.UNC.EDU That looks correct, based on the trace from the other day I assume using: kinit afs/[EMAIL PROTECTED] But it looks like you recreated the account, I would run the trace again. On my system I see the salt as derived from the UPN, ANL.GOVafsanl.gov SO try: win_passwordMSE.UNCCS.TESTafscs.unc.edu Just tried no luck. What is UPN please, User Principal Name? As shown above, I got these from ADSI edit: sAMAccountName AFS.CS.UNC.EDU servicePrincipalName afs/cs.unc.edu msDS-KeyVersionNumber 2 userPrincipalName afs/[EMAIL PROTECTED] I cut/paste the win_passord to make sure they are the same, I can successfully kinit to the service principal: [EMAIL PROTECTED] /]$ kinit afs/cs.unc.edu Password for afs/[EMAIL PROTECTED] (Case sensitive, no @ or / with the realm first.) win_password = password set for Domain user AFS.CS.UNC.EDU Douglas E. Engert wrote: John W. Sopko Jr. wrote: I really did not think it would be this complex to generate a Windows service principal and corresponding /usr/afs/etc/KeyFile. No it should not be, but then again Microsoft did some things early on that did not follow the Kerberos conversions, including not using kvnos. We are living with thuse early decisions. think the best route is to try windows ktpass again. The thing I do not understand is; you create a Windows domain account and then use setspn to add the afs/cs.unc.edu service principal. (Or I found the service principal gets added if you use the "-mapuser" option to ktpass). Then if I use ktpass to set the password, kvno and generate a keytab, neither the password or the kvno change for afs/cs.unc.edu service principal. I thought ktpass was supposed to do what MIT "kadmin ktadd" does, change the princip
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Douglas E. Engert wrote:
Not sure what's wrong. Your system is saying the salt is the
sAMAccountName. My W2K3 system says it is the
UserPrincipalName (UPN). But then again we have not changed the
password since we went from W2K to W2K3.
Since all the other methods (ktpass and asetkey) are failing
too, there must be something else going on here. I assume you
have deleted the account, and started over each time.
Is there more then one DC in the domain?
Yes, 2 in the MSE.UNCCS.TEST domain.
Is this a W2K or w2K3 domain?
This is a w2003 server running in w2k mixed mode for
now, our windows admins are going to be upgrading
our production Windows CS.UNC.EDU REALM soon, they
will still use mixed mode then move to 2003 mode
only.
Is the more then one MSE.UNCCS.TEST realm and kdc?
There are 2 test AD's servers
in the MSE.UNCCS.TEST realm, are production REALM
is CS.UNC.EDU.
Domain names are usually based on DNS names, so
why did you not use TEST.CS.UNC.EDU as the AD domain?
I did not choose the name, this is a test server our
Wndows group uses. They were testing Microsoft Exchange
at one time and that is where the MSE came from. We run
our own linux DNS server so can do as we wish. This server
is only routable on our internal network.
What actually fails? Getting an AFS token with aklog?
What is the error message?
My test afs server, host eagle, is running openafs 1.4.2,
it has the same cell name, cs.unc.edu as our production
server but they do not share any other afs info. I wanted
to simulate authentication to our production cell name.
I am using eagle as a test client also.
I got this test cell/server working to my linux/mit krb5
server using the realm name CSX.UNC.EDU since our windows
servers have taken over CS.UNC.EDU kerberos realm. I had no
problems generating a service key under mit k5
and this test server and getting afs perissions. My goal
was for us to run one K5 server for authentication, a Windows
server, if I can get comfortable doing that.
I have the linux/afs krb5.conf configured like this:
[libdefaults]
default_realm = MSE.UNCCS.TEST
dns_lookup_realm = false
dns_lookup_kdc = true
renew_lifetime = 14d
[domain_realm]
.cs.unc.edu = MSE.UNCCS.TEST
cs.unc.edu = MSE.UNCCS.TEST
[realms]
MSE.UNCCS.TEST = {
master_kdc = madison-cs.mse.unccs.test
kpasswd_server = madison-cs.mse.unccs.test
ticket_lifetime = 604800
}
Host madison-cs is the AD server I have been working on.
We have kerberos DNS records so dns_lookup_kdc
works fine.
kinit works fine, aklog works fine, get tokens fine.
Get "permission denied" when trying to access a protected
directory and the following error in the syslog /var/log/messages:
Jan 11 12:14:05 eagle kernel: afs: Tokens for user of AFS id 3903 for cell
cs.unc.edu are discarded (rxkad error=19270407)
eagle/root [/usr/afs/bin] # /usr/bin/translate_et 19270407
19270407 (rxk).7 = security object was passed a bad ticket
For example:
[EMAIL PROTECTED] /]$ whoami
sopko
[EMAIL PROTECTED] /]$ tokens
Tokens held by the Cache Manager:
--End of list--
[EMAIL PROTECTED] /]$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_3903_l8r6DK)
Kerberos 4 ticket cache: /tmp/tkt3903
klist: You have no tickets cached
[EMAIL PROTECTED] /]$ kinit
Password for [EMAIL PROTECTED]:
[EMAIL PROTECTED] /]$ aklog -d
Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu).
We've deduced that we need to authenticate to realm MSE.UNCCS.TEST.
Getting tickets: afs/[EMAIL PROTECTED]
Using Kerberos V5 ticket natively
About to resolve name sopko to id in cell cs.unc.edu.
Id 3903
Set username to AFS ID 3903
Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST
[EMAIL PROTECTED] /]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_3903_l8r6DK
Default principal: [EMAIL PROTECTED]
Valid starting ExpiresService principal
01/11/07 12:28:05 01/11/07 22:28:08 krbtgt/[EMAIL PROTECTED]
renew until 01/18/07 12:28:05, Etype (skey, tkt): ArcFour with
HMAC/md5, ArcFour with HMAC/md5
01/11/07 12:28:13 01/11/07 22:28:08 afs/[EMAIL PROTECTED]
renew until 01/18/07 12:28:05, Etype (skey, tkt): DES cbc mode with
CRC-32, DES cbc mode with RSA-MD5
Kerberos 4 ticket cache: /tmp/tkt3903
klist: You have no tickets cached
[EMAIL PROTECTED] /]$ tokens
Tokens held by the Cache Manager:
User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan 11 22:28]
--End of list--
[EMAIL PROTECTED] /]$ ls /afs/cs.unc.edu/home
ls: /afs/cs.unc.edu/home: Permission denied
[EMAIL PROTECTED] /]$
John W. Sopko Jr. wrote:
Douglas E. Engert wrote:
John W. Sopko Jr. wrote:
I tried and it did not work, am I missing something?
My linux server is a test server, I can do anything on it:
Verify kvno of service principal:
[EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED]
afs/[EMAIL PROTECTED]: kvno = 2
I have admin rights on the AD, it also is a test
server. I loaded the Active Directory ADSI Edit snapin
and examined the Domain user AFS.
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
On Wed, 10 Jan 2007, Jeffrey Altman wrote: Look back in this thread for e-mails from Doug describing how to check the salt and from Marcus on how to test that your key is valid. These should end up in the Wiki. Anyone bored? ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
If I get Windows authentication working I will document it. I want to do more research The beginning of the semester started yesterday and I am getting busy. Derrick J Brashear wrote: On Wed, 10 Jan 2007, Jeffrey Altman wrote: Look back in this thread for e-mails from Doug describing how to check the salt and from Marcus on how to test that your key is valid. These should end up in the Wiki. Anyone bored? -- 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 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
Douglas E. Engert wrote:
I don't see anything wrong. But there are some situations
that could have caused problems in testing:
aklog will look in your ticket cache to see if there is an
existing ticket for AFS and use it to create the AFS token.
Thus after each attempt to change the key on the AD side,
you have to kinit (to destroy the old ticket) so aklog will have
to contact the KDC to get a new service ticket with the key you
just changed. So during your testing you may have had a good key
in AD and the KeyFile but not know it.
Did kdestroy many times..
If you have more then one DC in the domain, there is a propagation
delay, and it could be that the aklog contacts the other DC, and
thus might get a ticket with the old key. Doing all you AD updates
to one DC and having it listed as the only KDC in the realm, can
get around this. You said you where using dns_lookup_kdc = true and
the domain had two DCs if I recall. So this could be a problem,
set dns_lookup_kdc = false
kdc = madison-cs.mse.unccs.test
did a trace, I am only going to madison-cs
I am running out of ideas.
We use AD for our Kerberos KDCs, and have all employees registered.
200 or so use AFS, many from Windows, via aklog, ak5log and gssklog.
I found this and am going to try to get the hotfix for ktpassword:
http://support.microsoft.com/kb/919557
John W. Sopko Jr. wrote:
Douglas E. Engert wrote:
You said your test cell was at one time working with MIT k5
realm of CSX.UNC.EDU
Did you change the server realm of cell file?
/usr/afs/etc/krb.conf
to have the line
MSE.UNCC.TEST
yes
(The aklog use the K5 realm of one of the AFS servers,
to figure out what realm it things the servers are in.
The servers use the /usr/afs/etc/krb.conf.
or assume the realm is upper(cellname)
Clock skew between the AD and the AFS server or client?
I manage ntp, skey is less the 100mSec
The RXKADBADTICKET can be produced for more then a bad key,
maybe something else is going on here.
I am runing out if ideas, other then to try and use the
token with some service running under a debugger, to see
where the RXKADBADTICKET is coming from.
I am going to pursue ktpass for now and see if I can
figue out the problems with it. There is a new ktpass for
windows XP. I built mskutil and took a quick look,
I would prefer not to use that.
According to the afs docs you are supposed to change your
afs principal key once a month. I change ours 2 times
a year. I am still using kaserver.
If afs users are to use windows ad we need to figure
out a good easy documented way to generate the service
key.
John W. Sopko Jr. wrote:
Douglas E. Engert wrote:
Not sure what's wrong. Your system is saying the salt is the
sAMAccountName. My W2K3 system says it is the
UserPrincipalName (UPN). But then again we have not changed the
password since we went from W2K to W2K3.
Since all the other methods (ktpass and asetkey) are failing
too, there must be something else going on here. I assume you
have deleted the account, and started over each time.
Is there more then one DC in the domain?
Yes, 2 in the MSE.UNCCS.TEST domain.
Is this a W2K or w2K3 domain?
This is a w2003 server running in w2k mixed mode for
now, our windows admins are going to be upgrading
our production Windows CS.UNC.EDU REALM soon, they
will still use mixed mode then move to 2003 mode
only.
Is the more then one MSE.UNCCS.TEST realm and kdc?
There are 2 test AD's servers
in the MSE.UNCCS.TEST realm, are production REALM
is CS.UNC.EDU.
Domain names are usually based on DNS names, so
why did you not use TEST.CS.UNC.EDU as the AD domain?
I did not choose the name, this is a test server our
Wndows group uses. They were testing Microsoft Exchange
at one time and that is where the MSE came from. We run
our own linux DNS server so can do as we wish. This server
is only routable on our internal network.
What actually fails? Getting an AFS token with aklog?
What is the error message?
My test afs server, host eagle, is running openafs 1.4.2,
it has the same cell name, cs.unc.edu as our production
server but they do not share any other afs info. I wanted
to simulate authentication to our production cell name.
I am using eagle as a test client also.
I got this test cell/server working to my linux/mit krb5
server using the realm name CSX.UNC.EDU since our windows
servers have taken over CS.UNC.EDU kerberos realm. I had no
problems generating a service key under mit k5
and this test server and getting afs perissions. My goal
was for us to run one K5 server for authentication, a Windows
server, if I can get comfortable doing that.
I have the linux/afs krb5.conf configured like this:
[libdefaults]
default_realm = MSE.UNCCS.TEST
dns_lookup_realm = false
dns_lookup_kdc = true
renew_lifetime = 14d
[domain_realm]
.cs.unc.edu = MSE.UNCCS.TEST
cs.unc.edu = MSE.UNCCS.TEST
[realms]
MSE.UNCCS.TEST = {
master_kdc = madison-cs.mse.unccs.test
kpasswd_server = madison-cs
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
The KB article you found: http://support.microsoft.com/kb/919557 Sounds like what Jeff was talking about as part of Vista. I guess it is available seperatly. "The Ktpass tool uses the host name part of the servicePrincipalName attribute instead of the samAccountName attribute that the Key Distribution Center (KDC) uses to salt the password." This indicates the salt that should be used is MSE.UNCCS.TESTAFS.CS.UNC.EDU as was indicated by the krb5_error e-data. It would also indicate that you should be able to use the bos_util adddes to create the key. P.S. You use +DesOnly and not -DesOnly on your ktpass when you changed the password last? John W. Sopko Jr. wrote: Douglas E. Engert wrote: I don't see anything wrong. But there are some situations that could have caused problems in testing: aklog will look in your ticket cache to see if there is an existing ticket for AFS and use it to create the AFS token. Thus after each attempt to change the key on the AD side, you have to kinit (to destroy the old ticket) so aklog will have to contact the KDC to get a new service ticket with the key you just changed. So during your testing you may have had a good key in AD and the KeyFile but not know it. Did kdestroy many times.. If you have more then one DC in the domain, there is a propagation delay, and it could be that the aklog contacts the other DC, and thus might get a ticket with the old key. Doing all you AD updates to one DC and having it listed as the only KDC in the realm, can get around this. You said you where using dns_lookup_kdc = true and the domain had two DCs if I recall. So this could be a problem, set dns_lookup_kdc = false kdc = madison-cs.mse.unccs.test did a trace, I am only going to madison-cs I am running out of ideas. We use AD for our Kerberos KDCs, and have all employees registered. 200 or so use AFS, many from Windows, via aklog, ak5log and gssklog. I found this and am going to try to get the hotfix for ktpassword: http://support.microsoft.com/kb/919557 John W. Sopko Jr. wrote: Douglas E. Engert wrote: You said your test cell was at one time working with MIT k5 realm of CSX.UNC.EDU Did you change the server realm of cell file? /usr/afs/etc/krb.conf to have the line MSE.UNCC.TEST yes (The aklog use the K5 realm of one of the AFS servers, to figure out what realm it things the servers are in. The servers use the /usr/afs/etc/krb.conf. or assume the realm is upper(cellname) Clock skew between the AD and the AFS server or client? I manage ntp, skey is less the 100mSec The RXKADBADTICKET can be produced for more then a bad key, maybe something else is going on here. I am runing out if ideas, other then to try and use the token with some service running under a debugger, to see where the RXKADBADTICKET is coming from. I am going to pursue ktpass for now and see if I can figue out the problems with it. There is a new ktpass for windows XP. I built mskutil and took a quick look, I would prefer not to use that. According to the afs docs you are supposed to change your afs principal key once a month. I change ours 2 times a year. I am still using kaserver. If afs users are to use windows ad we need to figure out a good easy documented way to generate the service key. John W. Sopko Jr. wrote: Douglas E. Engert wrote: Not sure what's wrong. Your system is saying the salt is the sAMAccountName. My W2K3 system says it is the UserPrincipalName (UPN). But then again we have not changed the password since we went from W2K to W2K3. Since all the other methods (ktpass and asetkey) are failing too, there must be something else going on here. I assume you have deleted the account, and started over each time. Is there more then one DC in the domain? Yes, 2 in the MSE.UNCCS.TEST domain. Is this a W2K or w2K3 domain? This is a w2003 server running in w2k mixed mode for now, our windows admins are going to be upgrading our production Windows CS.UNC.EDU REALM soon, they will still use mixed mode then move to 2003 mode only. Is the more then one MSE.UNCCS.TEST realm and kdc? There are 2 test AD's servers in the MSE.UNCCS.TEST realm, are production REALM is CS.UNC.EDU. Domain names are usually based on DNS names, so why did you not use TEST.CS.UNC.EDU as the AD domain? I did not choose the name, this is a test server our Wndows group uses. They were testing Microsoft Exchange at one time and that is where the MSE came from. We run our own linux DNS server so can do as we wish. This server is only routable on our internal network. What actually fails? Getting an AFS token with aklog? What is the error message? My test afs server, host eagle, is running openafs 1.4.2, it has the same cell name, cs.unc.edu as our production server but they do not share any other afs info. I wanted to simulate authentication to our production cell name. I am using eagle as a test client also. I got this test cell/server working to my linux
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
John W. Sopko Jr. wrote: > I found this and am going to try to get the hotfix for ktpassword: > > http://support.microsoft.com/kb/919557 Good. You found the Windows 2003 SP1 ktpass version that works. I don't know why Microsoft makes it so hard to find this. I searched for it and came up empty. Btw, the Vista ktpass has not been finalized yet. The reason being is that it turns out they do not plan to release it until Windows Server 2007 is public. I have put a request in for copies of Ktpass.exe 5.2.3790.2732 as well. When I receive it I will put a link to it on my web site. smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
red face, red face, red face...my bad, my bad, my bad Homer says do! ps -ef|grep fileserver root 4579 4574 0 10:55 ? 00:00:00 /usr/afs/bin/fileserver -L -realm CSX.UNC.EDU Need I say more. It works! That is when I change to "-realm MSE.UNCCS.TEST" I used bos "../bin/bos_util adddes kvno" with the Windows salt win_passwordMSE.UNCCS.TESTAFS.CS.UNC.EDU. I guess this option does the same thing as the /usr/afs/etc/krb.conf but overrider's the setting. Not a wasted exercise, learned a lot and you guys are really a big help! I will pursue getting the latest ktpass.exe. Also I see Windows SP2 for 2003 beta is out with the new ktpass.exe so it will be in the release version: http://support.microsoft.com/kb/914962 Jeffrey Altman wrote: John W. Sopko Jr. wrote: I found this and am going to try to get the hotfix for ktpassword: http://support.microsoft.com/kb/919557 Good. You found the Windows 2003 SP1 ktpass version that works. I don't know why Microsoft makes it so hard to find this. I searched for it and came up empty. Btw, the Vista ktpass has not been finalized yet. The reason being is that it turns out they do not plan to release it until Windows Server 2007 is public. I have put a request in for copies of Ktpass.exe 5.2.3790.2732 as well. When I receive it I will put a link to it on my web site. -- 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 ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh
John W. Sopko Jr. wrote: > red face, red face, red face...my bad, my bad, my bad > Homer says do! > > ps -ef|grep fileserver > root 4579 4574 0 10:55 ? 00:00:00 /usr/afs/bin/fileserver > -L -realm CSX.UNC.EDU > > Need I say more. That would certainly be the cause of much pain. Since I just got back from the gym I think that the appropriate punishment are 20 laps, 200 push ups, and 500 crunches. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
