[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh

John W. Sopko Jr. sopko@cs.unc.edu
Tue, 09 Jan 2007 15:48:04 -0500

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.


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)


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:


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,
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/cs.unc.edu@MSE.UNCCS.TEST -k 1 -e des-cbc-crc
Password for afs/cs.unc.edu@MSE.UNCCS.TEST:
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 
eagle/root [/usr/afs/etc] # cat krb.conf
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:

[sopko@eagle /]$ kinit
Password for sopko@MSE.UNCCS.TEST:
[sopko@eagle /]$ 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/cs.unc.edu@MSE.UNCCS.TEST
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
[sopko@eagle /]$ tokens

User's (AFS ID 3903) tokens for afs@cs.unc.edu [Expires Jan  9 22:10]
    --End of list--

[sopko@eagle /]$ ls /afs/cs.unc.edu/home
ls: /afs/cs.unc.edu/home: Permission denied

/var/log/messages 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)

Windows Event Viewer, System log shows this, sometimes:

While processing a TGS request for the target server afs/cs.unc.edu, the
account sopko@MSE.UNCCS.TEST 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.

Any ideas, thanks for all your help. Once I get this going I will
make a nice summary maybe even try the wiki <:)


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.

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